8014
правок
Изменения
м
Нет описания правки
Конечно, нельзя сказать, что их раньше совсем не тестировали, естественно и роботы и шлемы были достаточно давно, для них велась разработка и тестирование. Но сейчас продукт становится массовым. Это как с мобильными приложениями: сначала каждый телефон имел собственный встроенный софт, и очень малое количество загружаемых java-приложений сторонней разработки. А потом пришла эпоха смартфонов, приложений — миллионы, их все надо быстро разрабатывать и тестировать, и это — совсем другое тестирование, чем прежнее кропотливое тестирование платформ нового телефона. Так и здесь — роботы и шлемы становятся платформами с базовым софтом, на котором надо разрабатывать множество конечных специализированных приложений. Только, если сравнивать с телефонами, технологии гораздо более сырые, сделанные на живую нитку. И им предстоит еще длинный путь, который, тем не менее, будет пройден очень быстро. А сейчас видно самое начало — вот мои впечатления от докладов, которые я писал в ходе конференции.
[https://www.facebook.com/mtsepkov/posts/1759559124101034 Пост] '''Дарья Лашкевич'''. Особенности тестирования робота — домашнего помощника'''. Реальный проект, обучение робота поднимать и подавать мячики двумя руками по голосовым командам. Обучение нейронки и тестирование результата. Там комбинация алгоритмики и обученных нейронок — распознавание команд, ориентация в комнате, нахождение предмета, поднятие мячика, часть из них — предварительно обученные, например, распознавание речи, или встать после падения. На входе у робота — чистые сенсоры, слух, две камеры, сонар. Интересно! Конечная цель — робот сам убирается дома, кладет вещи на места.
[https://www.facebook.com/mtsepkov/posts/1759773207412959 Пост] '''Dariia Bondarieva'''. Между двух реальностей. Тестирование AR/MR'''. Рассказ про тестирование продуктов для шлема виртуальной реальности. Технология очень новая, сырая, с багами, например, если модель сделаешь слишком маленькой или чрезмерно большой — то только перезагрузка, и рассказ был о том, как с этим работать. Казалось бы, такому докладу — не место для конференции, потому что содержание очевидно: берем приложение и тестируем как можем, баги — обходим. Но поскольку технология действительно на фронтире, то многим очень интересно просто на нее посмотреть изнутри, познакомиться, примерить на себя, понять: хочешь или не хочешь. Потому что там еще и побочные эффекты, которые с классическими компьютерами в далеком прошлом: зрение может упасть, устаешь после 20 минут и так далее. Согласен ли платить здоровьем за работу на фронтире? Спасибо Дарье и организаторам за доклад!
[https://www.facebook.com/mtsepkov/posts/1760564174000529 Пост] Вчерашние доклады про тестирование роботов и шлемов виртуальной реальности с точки зрения технологий тестирования переносят нас на зарю тестирования, когда технологий и средств не существовало, да и само тестирование во многом вели на конечных пользователях, при этом пользователями были профессионалы. Среды визуального расположения виртуальных объектов поверх реальных в приложениях для шлемов виртуальной реальности по сложности сопоставимы с такими профессиональными приложениями, как photoshop. Принципиальная разница в двух моментах. Во-первых, это не единственная профессиональная среда для работы, таких приложений будут разрабатывать очень много для разных применений. Во-вторых, эти приложения — не для профессионала, а для конечного пользователя, с соответствующими современными требованиями по эргономике и интуитивному освоению.
[https://www.facebook.com/mtsepkov/posts/1759706700752943 Пост] '''Igor Goldshmidt'''. Миссия невыполнима: QA Estimation Failed. Впечатление очень не однозначное. Казалось бы, капитанский доклад — о том, что в IT любые оценки — сильно ненадежные и потому в ходе работы надо постоянно сверять текущее продвижение с оценкой, и во-время поднимать флаг о критическом отставании, и принимать меры: оперативно перепланировать, привлекать помощь команды, резать скоуп или переносить на следующий спринт, советуясь при этом с PO о возможности, и так далее. Как бы все все знают. Но на практике — во-первых, поднимают флаг не тогда, когда в середине работы фейл оценок стал очевиден, а выбрав все время и даже перебрав его. А во-вторых, выводы из этого делают одни и те же: мы не учли фактор X (Y, Z), в следующий раз учтем и уложимся в оценке. И доклад был как раз о том, что нужно принять ситуацию неверных оценок, и как жить в этой ситуации, детально, на деятельности тестировщика, а не в общем виде.
Впрочем, отмечу, что проблема старая. Эдвард Йордан в своей книге «Смертельный марш» писал о том, что вот уже более 30 лет каждое новое поколение разработчиков уверено, что уж оно-то не повторит ошибки предшественников и будет делать проекты в срок, воотруженное вооруженное новыми способами — а количество безнадежных, провальных преоктов — не уменьшается. Agile явно предложил признать это и корректирвоать корректировать путь — и все равно. И это проблема mindset: инженер не может смириться со своим системным бесслилием бессилием в невозможности оценки.
А в заключении: доклад начинался супер-заходом. В пакете — ручка и бумага, оцените, как быстро вы протестируете, что ручка пишет по бумаге? Расчет был, что назовут малую оценку, а потом — увидят, что ручка разобрана и зафейлят. А по факту оказалось, что на бумаге как-то есть линия — значит ручка пишет, зеденый зеленый тест прошел сразу :)
[https://www.facebook.com/mtsepkov/posts/1760650820658531 Пост] '''Sunav Sodhani'''. Testers are from Mars and Developers are from Venus'''. Название доклада — аллюзия к известной книге Джона Грэя «Мужчины с Марса, женщины с Венеры» по построению семейных отношений. И забавно, что разработчики ассоциированы с женщинами, а тестировщики — с (суровыми) мужиками. Хотя доклад, про обратную позицию тестировщиков: они должны наладить коммуникацию с разработчиками и говорить на их техническом языке, не забывая идентифицировать технические корни проблем, и отдать именно разработчикам ответственность за качество, противодействуя стереотипу «разработчик создает фичи, а тестировщик — лишь баги», и оставив себе позицию того, кто лишь помогает и поддерживает работу качественное кодирование разработчиков чек-листами, тест-кейсами и многим другим. В терминах книги это, скорее, женская позиция в семье разработчик-тестировщик :)
= Остальное =
[https://www.facebook.com/mtsepkov/posts/1759567374100209 Пост] '''Mitko Mitev'''. The Future of Software Testing'''. Есть гиды, которые рассказывают про страну, для которых то, что мы видим вокруг — тема для рассказа о том, как это устроено внутри и как люди там живут — и это интересно. А есть те, кто просто описывают словами и так наблюдаемое — и это — ни о чем. К сожалению, доклад делал гид второго типа, докладчик прост перечислял новое: появляются боты, роботы, они обучаются и общаются с людьми и другими роботами, а некоторые AI — еще учатся тестировать, заменяют тестировщика… И тестировщику надо со всем этим работать. Вопрос — как работать, что меняется -не поднимался. Ну кроме общих слов — быстро, гибко, DevOps, Continious delivery. Вот только что слушал Дарью Лашкевич про тестирование роботов — там нет всех этих слов, там совсем про другое. И да, без высокой теории, одна практика. А вот здесь — привязка новых слов к старой теории на уровни поп-выпуска новостей, с кучей графиков ни о чем. Увы…
[https://www.facebook.com/mtsepkov/posts/1759795374077409 Пост] '''Marco Sogliani'''. 50+ Years of Experience in Sofware Quality and Testing'''. Реально история 50 лет, с 1960-х и IBM-360 — учился в штатах и развертывал первую инсталляцию у заказчиков в Италии, первое использование PL/1 в Европе, до этого писали на Algol, Cobol и Fortran… А PL/1 был мультитредовым, в отличие от них… Мой опыт на 20 лет меньше, БЭСМ-6 и многопользовательская система ввода и редактирования файлов на структурном Фортране с указателями (был там такой диалект), работавшая в одном треде для экономии ресурсов. И все это было очень давно, и из сегодня кажется очень похожим. Байки из прошлого, хорошее завершение дня…
Но, к сожалению, весь доклад — лишь биография. Все-таки, было бы интересны параллели IT-тогда и IT сейчас. Они есть, они интересны, например, несколько лет назад я четко засек, что работая с множеством NoSQL баз данных разработчики заново решают задачи, которые решали в 80-х, до эпохи высокопроизводительного SQL. И так далее.
[https://www.facebook.com/mtsepkov/posts/1759595547430725 Пост] '''Святослав Логин'''. Как провести тестирование безопасности веб-приложений'''. Начало — понятное: незакрытые кавычки и другие ошибки приводят к возможности внедрить свой скрипт. И это — показано. А дальше рассказ пошел о том, что вручную все это не проверить, и надо пользоваться системой. И о системе рассказ уровня how-to: сюда вводите url, такие настройки, она поработает и выдаст результаты. Как-то это грустно для доклада на конференции, потому что по сути получается доклад о том, что вот, есть средства проверки кода, они выдают всякие полезные предупреждения, и инструкция о том, как их запустить, и какие предупреждения бывают: (Может, я просто не дослушал до сути доклада…
[https://www.facebook.com/mtsepkov/posts/1759599010763712 Пост] '''Alexander Podelko'''. Требования к производительности: основа разработки высокопроизводительных систем'''. Как-то ужасно. Очень медленная лекция о базовых основах по учебникам: (Вот есть метрика числа пользователей, но важно чем они занимаются… Вот есть требования, но требования к производительности — они особые, не жесткие, и как их выявлять — неясно, нет согласия. прорывная для него идея — несколько источников требований: спросите бизнес и проверьте на старой системе. И так далее, очевидные вещи, и ссылки на «во многом актуальные статьи» 1968 года по взаимодействию с системами…
И ссылки в варианте «вот, автор написал интересную книжечку, можно найти почитать» — без раскрытия содержания или ключевых моментов. Ну хоть предложение — что там интересного? И бесконечные: все пользуются разным, получают разное, вы ищите свое оптимальное…
