QAжется, работает!

Додо Брэндс 13 лет 🎉🎉🎉

Внезапно исчезнувшая рубрика #бриллиантовый_контент возвращается. С регулярностью проблемы, ну и ладно. Будет нерегулярная. В поисках способа оставать в курсе того что происходит в сфере тестирования и обеспечения качества наткнулся на рассылку Softwaretestingweekly. Раз в неделю приходит письмо со ссылками на разные статьи которые были написаны разным ребятами. Таким образом остается понимание, что происходит вокруг, что обсуждают и чем интересуются в индустрии. И не нужно постоянно шерстить разные источники в поиске статей. Единственный недостаток - вы зависите от того, что нашел автор рассылки, что он посчитал важным и значимым включить в рассылку. Ну и иногда бывает реклама, но все рекламные ссылки помечаются. В целом мне этого хватает. Поэтому если хотите быть в курсе информационной повестки индустрии тестирования ПО - подписывайтесь на рассылку. Кто уже подписан на рассылку - пишите в комментарии что нравится и что не нравится в ней.

Теперь этот попап будет выглядеть так

Если вы помните, то один из продуктов в котором я выступаю в качестве QA/QC это Приложение для печати этикеток. Вот тут подробнее что это такое. Мы обнаружили небольшую проблему связанную с пользовательским опытом. Наши bluetooth принтеры называются Printer_73A и еще они поддерживают режим Bluetooth low energy (BLE). Поэтому когда выполняется поиск bluetooth утстройств пользователи видят Printer_73A и Printer_73A_BLE. Приложении для печати не поддерживает работу в режиме BLE. Поэтому подключиться к Printer_73A_BLE не выйдет. Но некоторые пользователи пытались подключиться к Printer_73A_BLE и у них ожидаемо ничего не получалось. Плюс была проблема, что в пиццерии может быть несколько принтеров, один планшет мог использоваться сначала с одним принтером потом с другим. И в итоге у них на планшете спарено 2 разных принтера с холодного цеха и с горячего цеха. А наше приложение запоминало последний принтер к которому было подключено и при нажатии кнопки Подключить оно пыталось подключиться к последнему запомненому принтеру. И если его не находило проваливалось в бесконечное подключение. Помогало только перезапуск приложения. Мы решили одним махом зафиксить две проблемы. Решение было простое и элегантное - попап внутри приложения. В попапе мы показываем все спаренные принтеры (предварительно отфильтровав все названия в которыех есть BLE) и пользователь может подключить приложение к любому из спареных принтеров. Если спареных принтеров нет - есть кнопка Добавить принтер которая ведет в настройки Bluetooth, где можно выполнить поиск устройств и спарить планшет с принтером. В будущем и поиск устройств реализуем в приложении. Мы сделали зарелизили и сидим довольные. Заглянув в тикеты техподдержки мы обнаружили с десяток обращений в которых пользователи жалуются что не могут подключить принтер. Оказывается пользователи жмут кнопку Подключить - мы открываем попап со списком принтеров, но мы не подсветили что принтер кликабельный и в интерфейсе никак не подписали что нужно выбрать принтер (в комментах к прошлому посту кто-то правильно подсветил это) пользователи не могут понять что нужно всего-то нажать на название принтера и магия случится. Пользователи поняли только две кнопки Добавить принтер и Отмена. Как делают пользователи: - Идут в настройки Bluetooth (потому что всегда так делали) - Спаривают планшет и принтер - Возвращаются в приложение - Нажимают кнопку Подключить - Открывается попап - Пользователь ловит втфак - Нажимает Добавить принтер - Оказывается в настройках и попадает в бесконечную рекурсию - Пишет в техническую поддержку. Мораль такова, что любые изменения лучше отдать на ревью дизайнеру, если есть такая возможность. У нас была, но мы ей не воспользовались и поплатились. Быстрофиксом немного подправили текст в попапе и запланировали поход к дизайнеру.

Пока заканчиваю пост про фейл - у нас в Додо сегодня квартальное демо. Все it-продукты показывают что сделали за первый квартал. Если кому-то интересно - залетайте - трансляция открыта для всех. Мы же открытая компания. https://www.youtube.com/watch?v=KDCUkynnj84

Сегодня напишу историю небольшого фейла, а пока затравочка - как думаете, что не так с этим попапом? Позже напишу свою версию того, что не так и как мы к этому пришли)

Мы с нашими QA инженерами иногда обсуждаем способы поиска элементов на веб странице. И всегда возникает вопрос, как лучше искать элементы на странице? С помощью синтетических data_test_id или с помощью условно "пользовательских" getByRole() или getByText(). Когда-то наш фронтенд разрабочтик показал документацию к Testing Library. Документация говорит, что приоритетней использование getByRole(). Но каких-то причин делать так не писали. Только The more your tests resemble the way your software is used, the more confidence they can give you. Короче говоря тестируйте приложение так как оно используется и будет вам счастье. В таких спорах я обычно спрашиваю, если на кнопке оплаты заказа будет написано не “Оплатить”, а например “Отменить” это будет считаться багом? Если это баг, то находя элементы по data_test_id ваши тесты этот баг не найдут. Недавно читал статью про локаторы и вспомнил про наши обсуждения. В статье была ссылка на документацию Playwright. Разработчики Playwright тоже предлагают использовать не синтетические локаторы. Playwright comes with multiple built-in locators. To make tests resilient, we recommend prioritizing user-facing attributes and explicit contracts such as page.getByRole(). Так же они пишут про взаимодействие с элементами следующее`Testing by test ids is the most resilient way of testing as even if your text or role of the attribute changes the test will still pass. QA's and developers should define explicit test ids and query them with page.getByTestId(). However testing by test ids is not user facing. If the role or text value is important to you then consider using user facing locators such as role and text locators.` А как вы взаимодействуете с элементами и почему именно так?

После поста QA Павука поступили просьбы расшарить его. Обещал - сделал. Вынес Павука на отдельную личную доску и сделал доступ по ссылке. Если есть обратная связь или предложения по улучшению - пишите в тред или мне в личку. Чтобы включить комменты на доске (чтобы фидбэк писать сразу на доске) - нужен платный аккаунт в миро, у меня его нет 😁

Пока возвращаюсь в обычный режим после недели усиленной работы, напоминаю, что мы все еще в поисках коллеги в продукт кассы/киоски самообслуживания. В вакансии есть территориальное ограничение - Москва или Сыктывкар. Откликнуться можно по ссылке или пишите мне в личку. Отправьте всем кому может быть интересно❤️

Недавно тестировал редизайн формы редактирования настроек пиццерии. В форме есть несколько инпутов, в которые нужно вписать числа, целые или дробные. Площадь помещения, координаты. Как было реализовано - при вводе числа и точки все было нормально, но после ввода запятой или других символов - они появлялись в поле и потом исчезали. Происходила очистка невалидных данных. Например я ввел 66,55 и после снятия фокуса с инпута широта стала 6655. Интересно где бы оказалась пиццерия на карте с таким значением 😬 Вообще по-моему мнению любое неявное для пользователя поведение это плохое поведение. Тем более удаление того что пользователь ввел. Для убедительности доводов пошел копать, что пишут в интернетах и нашел достаточно структурированное объяснение как нужно действовать в таких случаях. По ссылке это третий ответ от SwankyLegg. А в последнем комментарии дана ссылка на документацию в которой написано как должен вести себя числовой инпут в таких случаях. По ссылке есть числовые инпуты примера и можно попробовать понабирать текст и посмотреть как они себя ведут. В итоге мы сделали как положено. Инпут принимает и точку и запятую как разделитель дробной части и пользователю не нужно думать про это. И запретили ввод символов кроме чисел, точки и запятой. Пользователи не будут удивляться куда пропал только что введенный символ.

Года 4 назад был на митапе и вдохновился докладом про то, как тестировщики сделали майнд-мапу для мобильных разработчиков. В ней разные проверки, особенности, требования, которые нужно учесть при разработке. Разработчик берет карту и проходит по ней в контексте своей задачи. На выходе получаются требования которые нужно учесть при разработке. Как итог более качественная фича. Я сделал своей команде веб фулстеков такую штуку и знаете что? Это работает. Разработчики называют майнд-мап - QA-Павук. Вначале мы с разработчиками после планирования брали фичу и проходили по этому майнд-мапу. Не было ни одного раза, чтобы мы не добавили хотя бы один пункт в приемочные критерии задачи. Затем разработчики стали без меня использовать эту карту для составления требований. Дальше больше павук стал развиваться - после каких-либо инцидентов или появлении новых требований о которых мы не думали раньше, мы добавляем в павука новые пункты. Например как-то мы забыли проверить как фича работает на других бизнесах кроме пиццы и после релиза пришлось откатывать и чинить поведение для коффен. По итогу у нас появился пункт “Проверить что фича работает на разных прод окружениях” Важно понимать, что этот павук решает проблему конкретной фичи в конкретном продукте. Но не решает проблему взаимодействия фичи в вашем сервисе с кучей других зависимых сервисов с точки зрения функциональности. Эту проблему мы пытаемся решить по другому. Но пока результатов нет рассказывать не буду. До разработки фичи тратится дополнительный час на то чтобы пройти по этому майндмэпу и вспомнить все что нужно учесть при разработке, а в результате получается более качественный продукт. У меня нет количественных метрик, которые покажут, что да, после вендрения этой штуки количество доработок после релиза или после тестирования снизилось. Но есть обратная связь от разработчиков, которые говорят, что это полезная штука и продолжают пользуются ей без тычков и напоминаний.

Нашел баг в Rider - захотел поделиться Осторожно. Людям страдающим эпилепсией лучше не смотреть 😬 Открываете 2 солюшена в одном окне и открываете любой файл для редактирования в обоих солюшенах. Затем сворачивайте Rider и наблюдайте магию. А вы часто находите баги в IDE? #баги_в_приложениях

В открытый доступ выложили доклад Димы Тучса (Head of qa в ДИ) The art of JUnit extensions про использование Extentions в JUnit. На видео Дима, Java код, в общем, все как мы любим (кроме Java кода конечно же 🙃)

Я внезапно вспомнил, что не поделился с вами целью на квартал. Но эта работа больше чем квартал, поэтому ничего страшного, поделюсь сейчас. Мы начали работу над сервисом по созданию тестовых данных. Контекст У нас есть монолитные веб автотесты. Api тесты и UI тесты. Для них реализовано создание тестовых данных. Тестовые данные, без которых ничего нельзя дальше делать, создаются перед выполнением тестов. Например пользователь, продукт, ингредиент и т.д. Затем непосредственно перед запуском, каждый тест создает тестовые данные, которые нужны только ему. Например сотрудник, меню продуктов, пиццерия, касса и т.д. Создание тестовых данных намертво прикручено к этим тестам и является их неотъемлемой частью. Кроме веб тестов, есть тесты на мобильное приложение пиццы. В этих тестах все ответы от бэка замоканы. Тестировался только UI мобильного приложения. Ребята похавали коричневой субстанции с этими моками и было решено переводить эти тесты на реальное взаимодействие с бэком. Сразу же после этого решения встал вопрос, как готовить тестовые данные? Через БД? Через Api? Использовать копию БД с прода или предзаполненный бэкап БД? Почему, а главное зачем Чтобы не придумывать велосипед еще раз, решили переисполоьзовать создание тестовых данных монолитных тестов. В перспективе, когда будем писать тесты на сайт или курьерское приложение которые будут взаимодействовать с бэком, этот сервис поможет нам тоже. Кроме автотестов, этот сервис можно будет использовать для генерации тестовых данных при ручном тестировании, что тоже облегчит работу других QA инженеров. А как вы готовите тестовые данные для ваших тестов?

Прошлую неделю был в отпуске, но теперь я вернулся, а это значит будут новые посты. Организаторы CodeFest недавно выложили видео доклада Юли @emotional_maniac "Тестируем с широко закрытыми глазами", про тестирование доступности. Смотрим, ставим лайки https://www.youtube.com/watch?v=0vw8hJfP6so

Способы борьбы с флаки тестами Думаю многие тестировщики сталкивались с проблемой флакующих тестов. А если кто-то не сталкивался, то я вам по-хорошему завидую. Флаки тест - это тест, который меняет свой статус с успешного на упавший или наоборот без изменений кода. Например вы запустили вы пайплайн с тестами, упал один тест, перезапустили на той же версии кода - тест прошел. Мы в Додо боролись несколькими способами. Первым решением было добавить ретраи для упавших тестов. Флаков стало меньше, но и время прохождения тестов увеличилось. Затем мы решили меншонить авторов коммитов после которых падали тесты. Логика была такая - если после твоих изменений упал тест, значит ты его сломал - иди и чини. Но такой подход может сработать если у вас тесты не флакуют. Поэтому большинство меншенов было ложные. В результате многие разработчики замьютили чат с нотификациями. Затем мы решили попробовать игнорирование тестов. Если тест флакует, мы его игнорируем и он больше не запускается в пайплайне. Мы предупреждаем владельцев компонента в котором заигнорили тест и надеялись что они его починят. Мы испытывали большое внутреннее сопротивление игнорированию тестов, потому что у нас их не много, даже критические сценарии не покрыты на 100%. И игнорирование этих тестов потенциальный выстрел себе в ногу. И команды не особо их чинили. Поэтому мы решили чинить их в QA гильдии самостоятельно, но далеко не всегда находили время для их починки, поэтому они копятся и копятся. Сейчас мы находимся здесь. И вот вчера на встрече м потенциальным спикером на конференцию TechLead 2024, я узнал про практику Карантин. Мартин Фаулер описал ее в своем блоге. Суть проста - флакующие тесты выносим в отдельную джобу на CI, отдельно от других тестов и не считаем эти тесты блокирующими релиз. Это ведет к тому, что мы перестаем перезапускать пайплайн с тестами. Ускоряется цикл обратной связи. Но при этом мы не получаем недостатков заигноренных тестов. Еще важная мысль для этой практики - не нужно раздувать этот карантин до бесконечности. Либо нужно ограничить время нахождения теста в карантине либо ограничить количество тестов в карантине. При достижении лимитов необходимо чинить все тесты и опустошать карантин. По итогу карантин - хорошая практика если не превращать ее в кладбище автотестов.

Способы борьбы с флаки тестами. Думаю многие тестировщики сталкивались с проблемой флакующих тестов. А если кто-то не сталкивался, я вам по-хорошему завидую. Флаки тест - это тест, который меняет свой статус с успешного на упавший или наоборот без изменений кода. Например запустили вы пайплайн с тестами, упал один тест, перезапустили на той же версии кода - тест прошел. Мы в Додо боролись несколькими способами. Первым решением было добавить ретраи для упавших тестов. Флаков стало меньше, но и время прохождения тестов увеличилось. Затем мы решили меншонить авторов коммитов после которых падали тесты. Логика была такая - если после твоих изменений упал тест, значит ты его сломал - иди и чини. Но такой подход может сработать если у вас тесты не флакуют. Поэтому большинство меньшенов было ложные. В результате многие разработчики замьютили чат с нотификациями. Затем мы решили попробовать игнорирование тестов. Если тест флакует, мы его мгнорируем и он больше не запускается в пайплайне. Мы предупреждаем владельцев компонента в котором заигнорили тест и надеялись что они его починят. Мы испытывали большое внутреннее сопротивление игнорированию тестов, потому что у нас их не много, даже критические сценарии не покрыты на 100%. И игнорирование этих тестов потенциальный выстрел себе в ногу. И команды не особо их чинили. Поэтому мы решили чинить их в QA гильдии самостоятельно, но далеко не всегда находили время для их починки, поэтому они копятся и копятся. Сейчас мы находимся здесь. И вот вчера я узнал про практику Карантин. Мартин Фаулер описал ее в своем блоге. Суть проста - флакующие тесты выносим в отдельную джобу на CI, отдельно от других тестов и не считаем эти тесты блокирующими релиз. Это ведет к тому, что мы перестаем перезапускать пайплайн с тестами. Ускоряется цикл обратной связи. Но при этом мы не получаем недостатков заигноренных тестов. Еще важная мысль для этой практики - не нужно раздувать этот карантин до бесконечности. Либо нужно ограничить время нахождения теста в карантине либо ограничить количество тестов в карантине. При достижении лимитов необходимо чинить все тесты и опустошать карантин. По итогу карантин - хорошая практика если не превращать ее в кладбище автотестов.

Итак, о моих вакансиях с подробностями. Первая - железячный QA. Мы ищем QA инженера в Москве или в Сыктывкаре, с опытом тестирования чего-то железного. То есть, мы пишем софт для касс, киосков самообслуживания, драйверы для них и т.д. Мы тестируем новое оборудование и софт для него. И если вы знаете такого QA - или вы вдруг сами такой - мы точно договоримся о приятных условиях работы. Важно - Т.к. работа с железками, а железки в офисе в Москве и в Сыктывкаре, то надо быть там или хотеть туда (в Москву, конечно 🥲) переехать. Пишите плиз мне напрямую - @dtuchs

У нас есть еще вакансии в команду, приходите сами или отправляйте друзьям-коллегам