2018-06-03: SQAdays в Минске - начинаем тестировать роботов и дополненную реальность
(Новая страница: «{{Conf-Ref}} Неделю назад был на [https://sqadays.com/ru/program/55692 SQAdays-23] в Минске, публикую свои впечатлени…») |
м |
||
(не показана одна промежуточная версия этого же участника) | |||
Строка 8: | Строка 8: | ||
Конечно, нельзя сказать, что их раньше совсем не тестировали, естественно и роботы и шлемы были достаточно давно, для них велась разработка и тестирование. Но сейчас продукт становится массовым. Это как с мобильными приложениями: сначала каждый телефон имел собственный встроенный софт, и очень малое количество загружаемых java-приложений сторонней разработки. А потом пришла эпоха смартфонов, приложений — миллионы, их все надо быстро разрабатывать и тестировать, и это — совсем другое тестирование, чем прежнее кропотливое тестирование платформ нового телефона. Так и здесь — роботы и шлемы становятся платформами с базовым софтом, на котором надо разрабатывать множество конечных специализированных приложений. Только, если сравнивать с телефонами, технологии гораздо более сырые, сделанные на живую нитку. И им предстоит еще длинный путь, который, тем не менее, будет пройден очень быстро. А сейчас видно самое начало — вот мои впечатления от докладов, которые я писал в ходе конференции. | Конечно, нельзя сказать, что их раньше совсем не тестировали, естественно и роботы и шлемы были достаточно давно, для них велась разработка и тестирование. Но сейчас продукт становится массовым. Это как с мобильными приложениями: сначала каждый телефон имел собственный встроенный софт, и очень малое количество загружаемых java-приложений сторонней разработки. А потом пришла эпоха смартфонов, приложений — миллионы, их все надо быстро разрабатывать и тестировать, и это — совсем другое тестирование, чем прежнее кропотливое тестирование платформ нового телефона. Так и здесь — роботы и шлемы становятся платформами с базовым софтом, на котором надо разрабатывать множество конечных специализированных приложений. Только, если сравнивать с телефонами, технологии гораздо более сырые, сделанные на живую нитку. И им предстоит еще длинный путь, который, тем не менее, будет пройден очень быстро. А сейчас видно самое начало — вот мои впечатления от докладов, которые я писал в ходе конференции. | ||
− | [https://www.facebook.com/mtsepkov/posts/1759559124101034 Пост] Дарья Лашкевич. Особенности тестирования робота — домашнего помощника. Реальный проект, обучение робота поднимать и подавать мячики двумя руками по голосовым командам. Обучение нейронки и тестирование результата. Там комбинация алгоритмики и обученных нейронок — распознавание команд, ориентация в комнате, нахождение предмета, поднятие мячика, часть из них — предварительно обученные, например, распознавание речи, или встать после падения. На входе у робота — чистые сенсоры, слух, две камеры, сонар. Интересно! Конечная цель — робот сам убирается дома, кладет вещи на места. | + | [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/1759773207412959 Пост] '''Dariia Bondarieva'''. Между двух реальностей. Тестирование AR/MR. Рассказ про тестирование продуктов для шлема виртуальной реальности. Технология очень новая, сырая, с багами, например, если модель сделаешь слишком маленькой или чрезмерно большой — то только перезагрузка, и рассказ был о том, как с этим работать. Казалось бы, такому докладу — не место для конференции, потому что содержание очевидно: берем приложение и тестируем как можем, баги — обходим. Но поскольку технология действительно на фронтире, то многим очень интересно просто на нее посмотреть изнутри, познакомиться, примерить на себя, понять: хочешь или не хочешь. Потому что там еще и побочные эффекты, которые с классическими компьютерами в далеком прошлом: зрение может упасть, устаешь после 20 минут и так далее. Согласен ли платить здоровьем за работу на фронтире? Спасибо Дарье и организаторам за доклад! |
[https://www.facebook.com/mtsepkov/posts/1760564174000529 Пост] Вчерашние доклады про тестирование роботов и шлемов виртуальной реальности с точки зрения технологий тестирования переносят нас на зарю тестирования, когда технологий и средств не существовало, да и само тестирование во многом вели на конечных пользователях, при этом пользователями были профессионалы. Среды визуального расположения виртуальных объектов поверх реальных в приложениях для шлемов виртуальной реальности по сложности сопоставимы с такими профессиональными приложениями, как photoshop. Принципиальная разница в двух моментах. Во-первых, это не единственная профессиональная среда для работы, таких приложений будут разрабатывать очень много для разных применений. Во-вторых, эти приложения — не для профессионала, а для конечного пользователя, с соответствующими современными требованиями по эргономике и интуитивному освоению. | [https://www.facebook.com/mtsepkov/posts/1760564174000529 Пост] Вчерашние доклады про тестирование роботов и шлемов виртуальной реальности с точки зрения технологий тестирования переносят нас на зарю тестирования, когда технологий и средств не существовало, да и само тестирование во многом вели на конечных пользователях, при этом пользователями были профессионалы. Среды визуального расположения виртуальных объектов поверх реальных в приложениях для шлемов виртуальной реальности по сложности сопоставимы с такими профессиональными приложениями, как photoshop. Принципиальная разница в двух моментах. Во-первых, это не единственная профессиональная среда для работы, таких приложений будут разрабатывать очень много для разных применений. Во-вторых, эти приложения — не для профессионала, а для конечного пользователя, с соответствующими современными требованиями по эргономике и интуитивному освоению. | ||
Строка 20: | Строка 20: | ||
= А что с остальным тестированием? = | = А что с остальным тестированием? = | ||
− | А все остальные доклады по тестированию можно, на мой взгляд, разделить на несколько категорий. Во-первых, доклады про теоретические основы, излагающие базовые практики. Таким был доклад Karolina Zmitrowicz «Building good test strategy», который в итоге занял первое место. Такой возврат к классике сейчас весьма характерен и определяется логикой развития отрасли, я об этом недавно писал в [[Блог:Максима Цепкова/2018-05-03: AnalystDays - очередной шаг спирали развития аналитиков|отчете об AnalystDays]]. К сожалению, не все доклады столь хороши, бывает, что изложение старой теории дают в стиле обзорной лекции о том, что на свете все бывает, есть разные тренды, и об этом написано много разных книг, из которых предлагается узнавать содержание самостоятельно. Или доклад становится просто байками из истории тестирования, которые, конечно, интересны, но все-таки, хочется услышать обобщение и соотнесение с сегодняшним днем, а не просто сторителлинг о прекрасном прошлом. | + | А все остальные доклады по тестированию можно, на мой взгляд, разделить на несколько категорий. Во-первых, доклады про теоретические основы, излагающие базовые практики. Таким был доклад '''Karolina Zmitrowicz''' «Building good test strategy», который в итоге занял первое место. Такой возврат к классике сейчас весьма характерен и определяется логикой развития отрасли, я об этом недавно писал в [[Блог:Максима Цепкова/2018-05-03: AnalystDays - очередной шаг спирали развития аналитиков|отчете об AnalystDays]]. К сожалению, не все доклады столь хороши, бывает, что изложение старой теории дают в стиле обзорной лекции о том, что на свете все бывает, есть разные тренды, и об этом написано много разных книг, из которых предлагается узнавать содержание самостоятельно. Или доклад становится просто байками из истории тестирования, которые, конечно, интересны, но все-таки, хочется услышать обобщение и соотнесение с сегодняшним днем, а не просто сторителлинг о прекрасном прошлом. |
− | Во-вторых, доклады о современной практике. И тут я бы отметил хорошую пару докладов про тестирование BigData от Алексея Лянгузова и Константина Плетенева, а также неожиданный доклад Андрея Мясникова на баркемпе о тестировании интеграции. Надеюсь, в будущем Андрей расскажет свой доклад в основной программе, и тогда появится запись. Не все доклады были хороши, часть из них, с моей точки зрения, была слишком начального уровня по изложению. Из опыта прошлых конференций я знаю, что на те же тему были гораздо более систематизированные доклады, в которых собственный опыт соотносился и позиционировался в общем теоретическом пространстве тестирования, а не просто излагался. И да, те доклады тоже были для не высокого уровня участника конференции, я не имею ввиду сильно продвинутые материалы. Понятно, что над таким надо больше работать, и докладчику и куратору из ПК. И так же понятно, что каждый делает, что может в условиях своего рабочего графика. Тем не менее, рискну дать совет: завести в ПК человека, который неплохо помнит прошлые конференции, и при подаче заявки просто кидает ссылки на хорошие доклады на те же темы. Я думаю, поможет подготовке, хотя, конечно, опасность что кто-то из докладчиков, посмотрев их, решит, что «все уже сказано до меня». Но лично я так — не думаю, отрасль идет вперед, материал докладчика — оригинальный, а участники — новые. Так что доклад будет востребован, даже если несколько лет назад на ту же тему о чем-то рассказывали. Просто, познакомившись с этим, сделаешь свой доклад лучше. | + | Во-вторых, доклады о современной практике. И тут я бы отметил хорошую пару докладов про тестирование BigData от '''Алексея Лянгузова''' и '''Константина Плетенева''', а также неожиданный доклад '''Андрея Мясникова''' на баркемпе о тестировании интеграции. Надеюсь, в будущем Андрей расскажет свой доклад в основной программе, и тогда появится запись. Не все доклады были хороши, часть из них, с моей точки зрения, была слишком начального уровня по изложению. Из опыта прошлых конференций я знаю, что на те же тему были гораздо более систематизированные доклады, в которых собственный опыт соотносился и позиционировался в общем теоретическом пространстве тестирования, а не просто излагался. И да, те доклады тоже были для не высокого уровня участника конференции, я не имею ввиду сильно продвинутые материалы. Понятно, что над таким надо больше работать, и докладчику и куратору из ПК. И так же понятно, что каждый делает, что может в условиях своего рабочего графика. Тем не менее, рискну дать совет: завести в ПК человека, который неплохо помнит прошлые конференции, и при подаче заявки просто кидает ссылки на хорошие доклады на те же темы. Я думаю, поможет подготовке, хотя, конечно, опасность что кто-то из докладчиков, посмотрев их, решит, что «все уже сказано до меня». Но лично я так — не думаю, отрасль идет вперед, материал докладчика — оригинальный, а участники — новые. Так что доклад будет востребован, даже если несколько лет назад на ту же тему о чем-то рассказывали. Просто, познакомившись с этим, сделаешь свой доклад лучше. |
− | И третья категория докладов — те, которые не о тестировании, а о софт-скилл и командной работе. И, надо отметить, что здесь теория и практика развиваются быстрее, чем в тестировании. И я слышал отзывы участников, что именно эта категория докладов оказалась самая ценная — и что я теперь скажу руководителю по возвращению, он же посылал меня совершенствоваться профессионально. На самом деле, софт-скилл и командная работа сейчас — необходимая часть компетенций любого IT-шника, а не только руководителя группы или тест-лида. Коммуникации с заказчиком, разработчиками, аналитиками — существенная часть работы и совершенствование в них — тоже важно. Обо всем этом был, говорят, хороший мастер-класс Сергея Крупенина во второй день (на котором меня не было), хороший рассказ Игоря Гольдшмидта, и многие другие. | + | И третья категория докладов — те, которые не о тестировании, а о софт-скилл и командной работе. И, надо отметить, что здесь теория и практика развиваются быстрее, чем в тестировании. И я слышал отзывы участников, что именно эта категория докладов оказалась самая ценная — и что я теперь скажу руководителю по возвращению, он же посылал меня совершенствоваться профессионально. На самом деле, софт-скилл и командная работа сейчас — необходимая часть компетенций любого IT-шника, а не только руководителя группы или тест-лида. Коммуникации с заказчиком, разработчиками, аналитиками — существенная часть работы и совершенствование в них — тоже важно. Обо всем этом был, говорят, хороший мастер-класс '''Сергея Крупенина''' во второй день (на котором меня не было), хороший рассказ '''Игоря Гольдшмидта''', и многие другие. |
− | [[Файл:SQAdays-2018-05-ph1.jpg| | + | <div style="float:right; margin: 0 0 0 0.5em;">[[Файл:SQAdays-2018-05-ph1.jpg|330px]] [[Файл:SQAdays-2018-05-ph2.jpg|200px]]</div> |
− | Об этом же я с Алексеем Федоровым говорил на баркемпе — мы рассматривали модель Спиральной динамики и различные переходы между уровнями. Впрочем, сорока минут не хватило, остался открытым главный вопрос — что побуждает человека совершать переходы, как срабатывает этот механизм. Так что тема, думаю, будет продолжена, а подробнее о модели можно прочитать [[Краткое описание уровней Спиральной динамики]] и в других материалах [[:Категория:Спиральная динамика]] | + | Об этом же '''я с Алексеем Федоровым''' говорил на баркемпе — мы рассматривали модель Спиральной динамики и различные переходы между уровнями. Впрочем, сорока минут не хватило, остался открытым главный вопрос — что побуждает человека совершать переходы, как срабатывает этот механизм. Так что тема, думаю, будет продолжена, а подробнее о модели можно прочитать [[Краткое описание уровней Спиральной динамики]] и в других материалах [[:Категория:Спиральная динамика]] |
− | Фото Александры Ковалевой (опубликовано в Telegram-канале) На #BarCamp Максим Цепков и Алексей Федоров заканчивают обсуждать с участниками смену mindset. Краткое резюме — пока мы, тестировщики, синие. Но есть хороший шанс двигаться в оранжевый. А вообще цветов много. За подробностями к ребятам))) | + | Фото Александры Ковалевой (опубликовано в Telegram-канале): ''На #BarCamp Максим Цепков и Алексей Федоров заканчивают обсуждать с участниками смену mindset. Краткое резюме — пока мы, тестировщики, синие. Но есть хороший шанс двигаться в оранжевый. А вообще цветов много. За подробностями к ребятам)))'' |
Ну а теперь впечатления из постов, которые я писал во время конференции. Сразу скажу, что они представляют меньше трети докладов — потому что шло одновременно три трека, а часть слотов я выступал и общался на баркемпе. | Ну а теперь впечатления из постов, которые я писал во время конференции. Сразу скажу, что они представляют меньше трети докладов — потому что шло одновременно три трека, а часть слотов я выступал и общался на баркемпе. | ||
Строка 36: | Строка 36: | ||
= Понравилось = | = Понравилось = | ||
− | [https://www.facebook.com/mtsepkov/posts/1760599053997041 Пост] Второй день начался двумя докладами про тестирование: Konstantin Pletenev и Алексей Лянгузов | + | [https://www.facebook.com/mtsepkov/posts/1760599053997041 Пост] Второй день начался двумя докладами про тестирование: '''Konstantin Pletenev''' и '''Алексей Лянгузов''' рассказывали каждый о своем опыте. Доклады оказались сильно добавляющие и очень разные, вплоть до того, что Константин в начале дал определение BigData, а Алексей, наоборот, отказался его давать, приведя ссылки на три других доклада, где вопрос рассмотрен с разных сторон. По содержанию Константин хорошо и стройно рассказывал про опыт их проекта, уложенный в достаточно простую модель конвейера обработки данных. Который, в частности, обвешивается разными запросами, проверяющими целостность целостность обработки. А Алексей нарисовал гораздо более обширную карту местности, а дальше сосредотачивался на отдельных ее фрагментах, но куда менее системно. Что, в общем-то, объяснимо ограниченностью времени. Какой из докладов более полезен -сложно сказать, в терминах жанров документов первый я бы определил как quick start с концептуальной схемой, а второй — как concept review с картами домена. Нужно и то и другое. |
− | [https://www.facebook.com/mtsepkov/posts/1760642713992675 Пост] Внеплановый доклад Андрей Мясников | + | [https://www.facebook.com/mtsepkov/posts/1760642713992675 Пост] Внеплановый доклад '''Андрей Мясников''' на баркэмпе «Иди тестируй в свой двор» о том, как правильно строить тестирование интеграции так, чтобы тестировать свой сервис, а не сервисы соседей. Но при этом интеграция — действовала и была быстрая диагностика. Комбинация практик построения надежной коммуникации на всех уровнях с техническими средствами многоуровневой диагностики и мониторинга, позволяющими локализовать проблему. И множество примеров. Вот за такие сюрпризы вне программы люблю SQAdays и другие живые конференции. |
− | [https://www.facebook.com/mtsepkov/posts/1759706700752943 Пост] Igor Goldshmidt. Миссия невыполнима: QA Estimation Failed. Впечатление очень не однозначное. Казалось бы, капитанский доклад — о том, что в IT любые оценки — сильно ненадежные и потому в ходе работы надо постоянно сверять текущее продвижение с оценкой, и во-время поднимать флаг о критическом отставании, и принимать меры: оперативно перепланировать, привлекать помощь команды, резать скоуп или переносить на следующий спринт, советуясь при этом с PO о возможности, и так далее. Как бы все все знают. Но на практике — во-первых, поднимают флаг не тогда, когда в середине работы фейл оценок стал очевиден, а выбрав все время и даже перебрав его. А во-вторых, выводы из этого делают одни и те же: мы не учли фактор X (Y, Z), в следующий раз учтем и уложимся в оценке. И доклад был как раз о том, что нужно принять ситуацию неверных оценок, и как жить в этой ситуации, детально, на деятельности тестировщика, а не в общем виде. | + | [https://www.facebook.com/mtsepkov/posts/1759706700752943 Пост] '''Igor Goldshmidt'''. Миссия невыполнима: QA Estimation Failed. Впечатление очень не однозначное. Казалось бы, капитанский доклад — о том, что в IT любые оценки — сильно ненадежные и потому в ходе работы надо постоянно сверять текущее продвижение с оценкой, и во-время поднимать флаг о критическом отставании, и принимать меры: оперативно перепланировать, привлекать помощь команды, резать скоуп или переносить на следующий спринт, советуясь при этом с PO о возможности, и так далее. Как бы все все знают. Но на практике — во-первых, поднимают флаг не тогда, когда в середине работы фейл оценок стал очевиден, а выбрав все время и даже перебрав его. А во-вторых, выводы из этого делают одни и те же: мы не учли фактор X (Y, Z), в следующий раз учтем и уложимся в оценке. И доклад был как раз о том, что нужно принять ситуацию неверных оценок, и как жить в этой ситуации, детально, на деятельности тестировщика, а не в общем виде. |
Впрочем, отмечу, что проблема старая. Эдвард Йордан в своей книге «Смертельный марш» писал о том, что вот уже более 30 лет каждое новое поколение разработчиков уверено, что уж оно-то не повторит ошибки предшественников и будет делать проекты в срок, воотруженное новыми способами — а количество безнадежных, провальных преоктов — не уменьшается. Agile явно предложил признать это и корректирвоать путь — и все равно. И это проблема mindset: инженер не может смириться со своим системным бесслилием в невозможности оценки. | Впрочем, отмечу, что проблема старая. Эдвард Йордан в своей книге «Смертельный марш» писал о том, что вот уже более 30 лет каждое новое поколение разработчиков уверено, что уж оно-то не повторит ошибки предшественников и будет делать проекты в срок, воотруженное новыми способами — а количество безнадежных, провальных преоктов — не уменьшается. Agile явно предложил признать это и корректирвоать путь — и все равно. И это проблема mindset: инженер не может смириться со своим системным бесслилием в невозможности оценки. | ||
Строка 46: | Строка 46: | ||
А в заключении: доклад начинался супер-заходом. В пакете — ручка и бумага, оцените, как быстро вы протестируете, что ручка пишет по бумаге? Расчет был, что назовут малую оценку, а потом — увидят, что ручка разобрана и зафейлят. А по факту оказалось, что на бумаге как-то есть линия — значит ручка пишет, зеденый тест прошел сразу :) | А в заключении: доклад начинался супер-заходом. В пакете — ручка и бумага, оцените, как быстро вы протестируете, что ручка пишет по бумаге? Расчет был, что назовут малую оценку, а потом — увидят, что ручка разобрана и зафейлят. А по факту оказалось, что на бумаге как-то есть линия — значит ручка пишет, зеденый тест прошел сразу :) | ||
− | [https://www.facebook.com/mtsepkov/posts/1760650820658531 Пост] Sunav Sodhani. Testers are from Mars and Developers are from Venus. Название доклада — аллюзия к известной книге Джона Грэя «Мужчины с Марса, женщины с Венеры» по построению семейных отношений. И забавно, что разработчики ассоциированы с женщинами, а тестировщики — с (суровыми) мужиками. Хотя доклад, про обратную позицию тестировщиков: они должны наладить коммуникацию с разработчиками и говорить на их техническом языке, не забывая идентифицировать технические корни проблем, и отдать именно разработчикам ответственность за качество, противодействуя стереотипу «разработчик создает фичи, а тестировщик — лишь баги», и оставив себе позицию того, кто лишь помогает и поддерживает работу качественное кодирование разработчиков чек-листами, тест-кейсами и многим другим. В терминах книги это, скорее, женская позиция в семье разработчик-тестировщик :) | + | [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/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 и многопользовательская система ввода и редактирования файлов на структурном Фортране с указателями (был там такой диалект), работавшая в одном треде для экономии ресурсов. И все это было очень давно, и из сегодня кажется очень похожим. Байки из прошлого, хорошее завершение дня… | + | [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. И так далее. | Но, к сожалению, весь доклад — лишь биография. Все-таки, было бы интересны параллели IT-тогда и IT сейчас. Они есть, они интересны, например, несколько лет назад я четко засек, что работая с множеством NoSQL баз данных разработчики заново решают задачи, которые решали в 80-х, до эпохи высокопроизводительного SQL. И так далее. | ||
− | [https://www.facebook.com/mtsepkov/posts/1759595547430725 Пост] Святослав Логин. Как провести тестирование безопасности веб-приложений. Начало — понятное: незакрытые кавычки и другие ошибки приводят к возможности внедрить свой скрипт. И это — показано. А дальше рассказ пошел о том, что вручную все это не проверить, и надо пользоваться системой. И о системе рассказ уровня how-to: сюда вводите url, такие настройки, она поработает и выдаст результаты. Как-то это грустно для доклада на конференции, потому что по сути получается доклад о том, что вот, есть средства проверки кода, они выдают всякие полезные предупреждения, и инструкция о том, как их запустить, и какие предупреждения бывают: (Может, я просто не дослушал до сути доклада… | + | [https://www.facebook.com/mtsepkov/posts/1759595547430725 Пост] '''Святослав Логин'''. Как провести тестирование безопасности веб-приложений. Начало — понятное: незакрытые кавычки и другие ошибки приводят к возможности внедрить свой скрипт. И это — показано. А дальше рассказ пошел о том, что вручную все это не проверить, и надо пользоваться системой. И о системе рассказ уровня how-to: сюда вводите url, такие настройки, она поработает и выдаст результаты. Как-то это грустно для доклада на конференции, потому что по сути получается доклад о том, что вот, есть средства проверки кода, они выдают всякие полезные предупреждения, и инструкция о том, как их запустить, и какие предупреждения бывают: (Может, я просто не дослушал до сути доклада… |
− | [https://www.facebook.com/mtsepkov/posts/1759599010763712 Пост] Alexander Podelko. Требования к производительности: основа разработки высокопроизводительных систем. Как-то ужасно. Очень медленная лекция о базовых основах по учебникам: (Вот есть метрика числа пользователей, но важно чем они занимаются… Вот есть требования, но требования к производительности — они особые, не жесткие, и как их выявлять — неясно, нет согласия. прорывная для него идея — несколько источников требований: спросите бизнес и проверьте на старой системе. И так далее, очевидные вещи, и ссылки на «во многом актуальные статьи» 1968 года по взаимодействию с системами… | + | [https://www.facebook.com/mtsepkov/posts/1759599010763712 Пост] '''Alexander Podelko'''. Требования к производительности: основа разработки высокопроизводительных систем. Как-то ужасно. Очень медленная лекция о базовых основах по учебникам: (Вот есть метрика числа пользователей, но важно чем они занимаются… Вот есть требования, но требования к производительности — они особые, не жесткие, и как их выявлять — неясно, нет согласия. прорывная для него идея — несколько источников требований: спросите бизнес и проверьте на старой системе. И так далее, очевидные вещи, и ссылки на «во многом актуальные статьи» 1968 года по взаимодействию с системами… |
И ссылки в варианте «вот, автор написал интересную книжечку, можно найти почитать» — без раскрытия содержания или ключевых моментов. Ну хоть предложение — что там интересного? И бесконечные: все пользуются разным, получают разное, вы ищите свое оптимальное… | И ссылки в варианте «вот, автор написал интересную книжечку, можно найти почитать» — без раскрытия содержания или ключевых моментов. Ну хоть предложение — что там интересного? И бесконечные: все пользуются разным, получают разное, вы ищите свое оптимальное… |
Текущая версия на 11:10, 5 июня 2018
Неделю назад был на 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 года по взаимодействию с системами…
И ссылки в варианте «вот, автор написал интересную книжечку, можно найти почитать» — без раскрытия содержания или ключевых моментов. Ну хоть предложение — что там интересного? И бесконечные: все пользуются разным, получают разное, вы ищите свое оптимальное…
На этом — заканчиваю отчет. Спасибо спикерам, организаторам и всем участникам.