Неделю назад был на SQAdays-23 в Минске, публикую свои впечатления и собираю и посты, которые публиковал в ходе конференции в facebook и telegram. Кстати, организаторы впервые вместо twitter использовали telegram-канал SQAdays и общение было гораздо более живым, как в twitter 5+ лет назад, когда он еще жил. Хотя кейсов, когда доклад обсуждают в чате прямо во время доклада я пока не видел, а в twitter это было. Ну, все еще впереди, думаю. Про мои отзывы мне уже во второй день сказали, что посты какие-то слишком злые — я так не считаю, и в целом конференция мне понравилась. Впрочем, судите сами.

На прошлом SQAdays в Питере меня поразила реплика на открытии, что, мол, в тестировании не происходит ничего нового, я тогда свое недоумение обсудил и высказал в отчете. И вот сейчас организаторы это новое показали, хотя и немного — на конфе были доклады о тестировании роботов и шлемов дополненной реальности.

Конечно, нельзя сказать, что их раньше совсем не тестировали, естественно и роботы и шлемы были достаточно давно, для них велась разработка и тестирование. Но сейчас продукт становится массовым. Это как с мобильными приложениями: сначала каждый телефон имел собственный встроенный софт, и очень малое количество загружаемых java-приложений сторонней разработки. А потом пришла эпоха смартфонов, приложений — миллионы, их все надо быстро разрабатывать и тестировать, и это — совсем другое тестирование, чем прежнее кропотливое тестирование платформ нового телефона. Так и здесь — роботы и шлемы становятся платформами с базовым софтом, на котором надо разрабатывать множество конечных специализированных приложений. Только, если сравнивать с телефонами, технологии гораздо более сырые, сделанные на живую нитку. И им предстоит еще длинный путь, который, тем не менее, будет пройден очень быстро. А сейчас видно самое начало — вот мои впечатления от докладов, которые я писал в ходе конференции.

Пост Дарья Лашкевич. Особенности тестирования робота — домашнего помощника. Реальный проект, обучение робота поднимать и подавать мячики двумя руками по голосовым командам. Обучение нейронки и тестирование результата. Там комбинация алгоритмики и обученных нейронок — распознавание команд, ориентация в комнате, нахождение предмета, поднятие мячика, часть из них — предварительно обученные, например, распознавание речи, или встать после падения. На входе у робота — чистые сенсоры, слух, две камеры, сонар. Интересно! Конечная цель — робот сам убирается дома, кладет вещи на места.

Пост Dariia Bondarieva. Между двух реальностей. Тестирование AR/MR. Рассказ про тестирование продуктов для шлема виртуальной реальности. Технология очень новая, сырая, с багами, например, если модель сделаешь слишком маленькой или чрезмерно большой — то только перезагрузка, и рассказ был о том, как с этим работать. Казалось бы, такому докладу — не место для конференции, потому что содержание очевидно: берем приложение и тестируем как можем, баги — обходим. Но поскольку технология действительно на фронтире, то многим очень интересно просто на нее посмотреть изнутри, познакомиться, примерить на себя, понять: хочешь или не хочешь. Потому что там еще и побочные эффекты, которые с классическими компьютерами в далеком прошлом: зрение может упасть, устаешь после 20 минут и так далее. Согласен ли платить здоровьем за работу на фронтире? Спасибо Дарье и организаторам за доклад!

Пост Вчерашние доклады про тестирование роботов и шлемов виртуальной реальности с точки зрения технологий тестирования переносят нас на зарю тестирования, когда технологий и средств не существовало, да и само тестирование во многом вели на конечных пользователях, при этом пользователями были профессионалы. Среды визуального расположения виртуальных объектов поверх реальных в приложениях для шлемов виртуальной реальности по сложности сопоставимы с такими профессиональными приложениями, как photoshop. Принципиальная разница в двух моментах. Во-первых, это не единственная профессиональная среда для работы, таких приложений будут разрабатывать очень много для разных применений. Во-вторых, эти приложения — не для профессионала, а для конечного пользователя, с соответствующими современными требованиями по эргономике и интуитивному освоению.

И тут очень интересно, как будет в целом развиваться экосистема вокруг шлемов виртуальной реальности или роботов разных производителей. Во-первых, пойдут ли они по пути мобилок, где при множестве производителей есть единая система Android, вокруг которой и сосредоточенная разработка, или каждый вендор будет пробовать поддерживать свою экосистему. Если свою — то будет ли он делать ее централизованно собственными силами, как Apple свой iOS, или попробует сложить вокруг сообщество, экосистему разработки, или вообще забьет на это и будет конкурировать за счет чисто инженерных решений в шлемах виртуальной реальности. И появятся ли крупные вендоры, продукты которых будут занимать солидную долю рынка, или работать будет открытые сообщества разработчиков. Интересно все это потому, что есть определенные идеологические утверждения, например, о преимуществе открытой разработки против вендорских решений. А еще есть практика, что в новых динамичных областях, например, при реализации парадигм реактивного программирования, вендоры просто не успевают и рулят именно сообщества — не взирая на относительно низкое качество решений и другие сопутствующие проблемы.

А еще интересно, будет ли первый шаг заключаться в том, что наработанные инструменты автоматизации тестирования и написания скриптов для полуручного тестирования, исключающие рутинную часть работы будут перенесены на новые технологии, или технологическое отличие слишком велико и начало будет совсем в других инструментах?

А все остальные доклады по тестированию можно, на мой взгляд, разделить на несколько категорий. Во-первых, доклады про теоретические основы, излагающие базовые практики. Таким был доклад Karolina Zmitrowicz «Building good test strategy», который в итоге занял первое место. Такой возврат к классике сейчас весьма характерен и определяется логикой развития отрасли, я об этом недавно писал в отчете об AnalystDays. К сожалению, не все доклады столь хороши, бывает, что изложение старой теории дают в стиле обзорной лекции о том, что на свете все бывает, есть разные тренды, и об этом написано много разных книг, из которых предлагается узнавать содержание самостоятельно. Или доклад становится просто байками из истории тестирования, которые, конечно, интересны, но все-таки, хочется услышать обобщение и соотнесение с сегодняшним днем, а не просто сторителлинг о прекрасном прошлом.

Во-вторых, доклады о современной практике. И тут я бы отметил хорошую пару докладов про тестирование BigData от Алексея Лянгузова и Константина Плетенева, а также неожиданный доклад Андрея Мясникова на баркемпе о тестировании интеграции. Надеюсь, в будущем Андрей расскажет свой доклад в основной программе, и тогда появится запись. Не все доклады были хороши, часть из них, с моей точки зрения, была слишком начального уровня по изложению. Из опыта прошлых конференций я знаю, что на те же тему были гораздо более систематизированные доклады, в которых собственный опыт соотносился и позиционировался в общем теоретическом пространстве тестирования, а не просто излагался. И да, те доклады тоже были для не высокого уровня участника конференции, я не имею ввиду сильно продвинутые материалы. Понятно, что над таким надо больше работать, и докладчику и куратору из ПК. И так же понятно, что каждый делает, что может в условиях своего рабочего графика. Тем не менее, рискну дать совет: завести в ПК человека, который неплохо помнит прошлые конференции, и при подаче заявки просто кидает ссылки на хорошие доклады на те же темы. Я думаю, поможет подготовке, хотя, конечно, опасность что кто-то из докладчиков, посмотрев их, решит, что «все уже сказано до меня». Но лично я так — не думаю, отрасль идет вперед, материал докладчика — оригинальный, а участники — новые. Так что доклад будет востребован, даже если несколько лет назад на ту же тему о чем-то рассказывали. Просто, познакомившись с этим, сделаешь свой доклад лучше.

И третья категория докладов — те, которые не о тестировании, а о софт-скилл и командной работе. И, надо отметить, что здесь теория и практика развиваются быстрее, чем в тестировании. И я слышал отзывы участников, что именно эта категория докладов оказалась самая ценная — и что я теперь скажу руководителю по возвращению, он же посылал меня совершенствоваться профессионально. На самом деле, софт-скилл и командная работа сейчас — необходимая часть компетенций любого IT-шника, а не только руководителя группы или тест-лида. Коммуникации с заказчиком, разработчиками, аналитиками — существенная часть работы и совершенствование в них — тоже важно. Обо всем этом был, говорят, хороший мастер-класс Сергея Крупенина во второй день (на котором меня не было), хороший рассказ Игоря Гольдшмидта, и многие другие.

Об этом же я с Алексеем Федоровым говорил на баркемпе — мы рассматривали модель Спиральной динамики и различные переходы между уровнями. Впрочем, сорока минут не хватило, остался открытым главный вопрос — что побуждает человека совершать переходы, как срабатывает этот механизм. Так что тема, думаю, будет продолжена, а подробнее о модели можно прочитать Краткое описание уровней Спиральной динамики и в других материалах Категория:Спиральная динамика

Фото Александры Ковалевой (опубликовано в Telegram-канале): На #BarCamp Максим Цепков и Алексей Федоров заканчивают обсуждать с участниками смену mindset. Краткое резюме — пока мы, тестировщики, синие. Но есть хороший шанс двигаться в оранжевый. А вообще цветов много. За подробностями к ребятам)))

Ну а теперь впечатления из постов, которые я писал во время конференции. Сразу скажу, что они представляют меньше трети докладов — потому что шло одновременно три трека, а часть слотов я выступал и общался на баркемпе.

Пост Второй день начался двумя докладами про тестирование: Konstantin Pletenev и Алексей Лянгузов рассказывали каждый о своем опыте. Доклады оказались сильно добавляющие и очень разные, вплоть до того, что Константин в начале дал определение BigData, а Алексей, наоборот, отказался его давать, приведя ссылки на три других доклада, где вопрос рассмотрен с разных сторон. По содержанию Константин хорошо и стройно рассказывал про опыт их проекта, уложенный в достаточно простую модель конвейера обработки данных. Который, в частности, обвешивается разными запросами, проверяющими целостность целостность обработки. А Алексей нарисовал гораздо более обширную карту местности, а дальше сосредотачивался на отдельных ее фрагментах, но куда менее системно. Что, в общем-то, объяснимо ограниченностью времени. Какой из докладов более полезен -сложно сказать, в терминах жанров документов первый я бы определил как quick start с концептуальной схемой, а второй — как concept review с картами домена. Нужно и то и другое.

Пост Внеплановый доклад Андрей Мясников на баркэмпе «Иди тестируй в свой двор» о том, как правильно строить тестирование интеграции так, чтобы тестировать свой сервис, а не сервисы соседей. Но при этом интеграция — действовала и была быстрая диагностика. Комбинация практик построения надежной коммуникации на всех уровнях с техническими средствами многоуровневой диагностики и мониторинга, позволяющими локализовать проблему. И множество примеров. Вот за такие сюрпризы вне программы люблю SQAdays и другие живые конференции.

Пост Igor Goldshmidt. Миссия невыполнима: QA Estimation Failed. Впечатление очень не однозначное. Казалось бы, капитанский доклад — о том, что в IT любые оценки — сильно ненадежные и потому в ходе работы надо постоянно сверять текущее продвижение с оценкой, и во-время поднимать флаг о критическом отставании, и принимать меры: оперативно перепланировать, привлекать помощь команды, резать скоуп или переносить на следующий спринт, советуясь при этом с PO о возможности, и так далее. Как бы все все знают. Но на практике — во-первых, поднимают флаг не тогда, когда в середине работы фейл оценок стал очевиден, а выбрав все время и даже перебрав его. А во-вторых, выводы из этого делают одни и те же: мы не учли фактор X (Y, Z), в следующий раз учтем и уложимся в оценке. И доклад был как раз о том, что нужно принять ситуацию неверных оценок, и как жить в этой ситуации, детально, на деятельности тестировщика, а не в общем виде.

Впрочем, отмечу, что проблема старая. Эдвард Йордан в своей книге «Смертельный марш» писал о том, что вот уже более 30 лет каждое новое поколение разработчиков уверено, что уж оно-то не повторит ошибки предшественников и будет делать проекты в срок, воотруженное новыми способами — а количество безнадежных, провальных преоктов — не уменьшается. Agile явно предложил признать это и корректирвоать путь — и все равно. И это проблема mindset: инженер не может смириться со своим системным бесслилием в невозможности оценки.

А в заключении: доклад начинался супер-заходом. В пакете — ручка и бумага, оцените, как быстро вы протестируете, что ручка пишет по бумаге? Расчет был, что назовут малую оценку, а потом — увидят, что ручка разобрана и зафейлят. А по факту оказалось, что на бумаге как-то есть линия — значит ручка пишет, зеденый тест прошел сразу :)

Пост Sunav Sodhani. Testers are from Mars and Developers are from Venus. Название доклада — аллюзия к известной книге Джона Грэя «Мужчины с Марса, женщины с Венеры» по построению семейных отношений. И забавно, что разработчики ассоциированы с женщинами, а тестировщики — с (суровыми) мужиками. Хотя доклад, про обратную позицию тестировщиков: они должны наладить коммуникацию с разработчиками и говорить на их техническом языке, не забывая идентифицировать технические корни проблем, и отдать именно разработчикам ответственность за качество, противодействуя стереотипу «разработчик создает фичи, а тестировщик — лишь баги», и оставив себе позицию того, кто лишь помогает и поддерживает работу качественное кодирование разработчиков чек-листами, тест-кейсами и многим другим. В терминах книги это, скорее, женская позиция в семье разработчик-тестировщик :)

Пост Mitko Mitev. The Future of Software Testing. Есть гиды, которые рассказывают про страну, для которых то, что мы видим вокруг — тема для рассказа о том, как это устроено внутри и как люди там живут — и это интересно. А есть те, кто просто описывают словами и так наблюдаемое — и это — ни о чем. К сожалению, доклад делал гид второго типа, докладчик прост перечислял новое: появляются боты, роботы, они обучаются и общаются с людьми и другими роботами, а некоторые AI — еще учатся тестировать, заменяют тестировщика… И тестировщику надо со всем этим работать. Вопрос — как работать, что меняется -не поднимался. Ну кроме общих слов — быстро, гибко, DevOps, Continious delivery. Вот только что слушал Дарью Лашкевич про тестирование роботов — там нет всех этих слов, там совсем про другое. И да, без высокой теории, одна практика. А вот здесь — привязка новых слов к старой теории на уровни поп-выпуска новостей, с кучей графиков ни о чем. Увы…

Пост 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. И так далее.

Пост Святослав Логин. Как провести тестирование безопасности веб-приложений. Начало — понятное: незакрытые кавычки и другие ошибки приводят к возможности внедрить свой скрипт. И это — показано. А дальше рассказ пошел о том, что вручную все это не проверить, и надо пользоваться системой. И о системе рассказ уровня how-to: сюда вводите url, такие настройки, она поработает и выдаст результаты. Как-то это грустно для доклада на конференции, потому что по сути получается доклад о том, что вот, есть средства проверки кода, они выдают всякие полезные предупреждения, и инструкция о том, как их запустить, и какие предупреждения бывают: (Может, я просто не дослушал до сути доклада…

Пост Alexander Podelko. Требования к производительности: основа разработки высокопроизводительных систем. Как-то ужасно. Очень медленная лекция о базовых основах по учебникам: (Вот есть метрика числа пользователей, но важно чем они занимаются… Вот есть требования, но требования к производительности — они особые, не жесткие, и как их выявлять — неясно, нет согласия. прорывная для него идея — несколько источников требований: спросите бизнес и проверьте на старой системе. И так далее, очевидные вещи, и ссылки на «во многом актуальные статьи» 1968 года по взаимодействию с системами…

И ссылки в варианте «вот, автор написал интересную книжечку, можно найти почитать» — без раскрытия содержания или ключевых моментов. Ну хоть предложение — что там интересного? И бесконечные: все пользуются разным, получают разное, вы ищите свое оптимальное…

На этом — заканчиваю отчет. Спасибо спикерам, организаторам и всем участникам.