Наблюдения и размышления с элементами сарказма
Записали пилотный выпуск нового проекта.
Собеседование-симуляция не претендует на раскрытие темы «настоящих» собеседований в настоящих компаниях, а служит для расширения горизонтов зрителей и ведущих выпуска.
Если формат понравился - не стесняйтесь лайкать, комментировать и репостить видео, это будет мотивировать нас продолжать выпуски.
Меня попросили придумать задачку "на подумать" без элементов автоматизации для тестировщиков.
Не вопрос, подумал я и быстро накидал условие. Решив задачку прямо на мобильнике за 2 минуты, я удовлетворённо поделился ей в группах Telegram.
Программа может быть проинсталлирована на 3 операционные системы. Каждая ОС имеет 3 версии. Каждая версия доступна на 4 языках.
Программа доступна в 2 версиях - демо и полная. Каждая инсталляция длится 5 минут, для смоук теста нужно ещё 10 минут.
Один тестировщик может выполнять ручное тестирование, ему доступно неограниченное количество систем со всеми нужными языками и ОС.
Сколько времени нужно запланировать на тестирование?
Любителям поломать голову рекомендую перед тем как читать дальше, попробовать решить задачу самостоятельно.
...читать далее История одного pairwise или как заменить мозги Гуглом и проиграть
Продолжительное время я допускал классическую ошибку. Определения в духе
Severity - определяет степень влияния на работоспособность приложения
казались мне логичными и правильными.
Не работает одна из функций без workaround-a - major. Сбился текст до нечитаемости - minor. Просто и понятно. Но, как оказалось - неверно.
Чтобы понять почему, давайте вспомним, зачем нужно Severity дополнительно к Priority. Самое популярное применение - это предварительный фильтр, помогающий лицам принимающим решения об устранении. Когда поток дефектов велик, удобно концентрироваться на важных проблемах (major), и только пробегать по неважным (minor). Второе популярное применение - метрика качества продукта (много мажорных - плохо, мало - хорошо).
Последние годы происходит переосмысление тестирования, индустрия переходит от "верификации спецификации" к широкому "изучению влияния проблемы на прибыльность бизнеса". Несомненно существует корреляция, и нерабочие функции, чаще обходятся дороже, чем проблемы с вёрсткой. Но в каждом конкретном случае находятся исключения. Зачем же тогда мы автоматически призываем ставить функциональные проблемы выше нефункциональных?
Я предлагаю скорректированное определение:
Severity - определяет степень влияния проблемы на прибыльности бизнеса
Классический (неверный) пример: "На лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании)." Данный дефект принято считать минорным, но "имеющим большие репутационные риски, а значит - высокоприоритетным". Согласно новому определению, дефект, который несёт большие риски для бизнеса, не может быть минорным. Данный дефект - самый настоящий мажор, требующий повышенного, а не пониженного внимания.
Еще один пример - "неработающие функции, которыми практически не пользуются пользователи" против "время отклика приложения для платных пользователей увеличилось в 3 раза (но всё работает)". Какой из дефектов более мажорный?
Важный вопрос - в каких случаях Severity не нужна вовсе? Так как Severity используется для фокусировки и измерения промежуточного состояния, она не нужна, когда команда своевременно справляется со всеми найденными дефектами. Если мы успеваем внимательно прочитать и пофиксить (или решить, что с дефектом можно жить без фикса) всё - то вполне достаточно оперативной приоритезации, и Severity не нужна.
Другие заметки про Severity в этом блоге
В данной заметке присутствуют цитаты из этой статьи
Если вы используете maven для сборки (альтернатива - gradle), то вы можете легко сгенерировать примерный проект с помощью публичного архетипа selenide-junit5-archetype.
Выберите groupId (обычно домен компании в обратном порядке), и artifactId - (название проекта).
|
1 |
mvn archetype:generate -B -DarchetypeGroupId=org.selenide -DarchetypeArtifactId=selenide-junit5-archetype -DgroupId=com.example -DartifactId=ui-tests |
Проект создастся в папке указанной в artifactId. Его можно открыть с помощью IDE, на данный момент он состоит из 3 небольших классов и файла конфигурации pom.xml
|
1 |
cd ui-tests |
Мы можем запустить тесты с браузером по умолчанию (Chrome)
|
1 |
mvn test |
Запустить с браузером Firefox
|
1 |
mvn -Dselenide.browser=firefox |
Запустить Chrome в невидимом режиме (headless)
|
1 |
mvn -Dselenide.browser=chrome -Dselenide.headless=true |
Подробная инструкция со списком опций генерации и дополнительными примерами находится на Github.
Предлагаю к ознакомлению запись доклада-мастер класса, с примерами практического применения элементов KISS-Driven автоматизации в UI тестировании.
Слайды:
Довольно часто я получаю вопросы такого типа:
Слушал ваш доклад на <конференция>. Вы рассказывали про KISS и про много вещей которые не укладываются в голове, (отказ от наследования, дублирование кода...) но вот ни слова не рассказали о конкретно ваших показателях и какие у вас результаты. Поэтому хотел узнать: сколько у вас всего e2e тестов? Сколько времени они у вас длятся, какой самый длинный тест, сколько из этих тестов flaky? и сколько % времени вы тратите на "maintenance"? Спасибо.
Постараюсь ответить.
Я считаю, что все указанные вопросы абсолютно нерелевантны к теме как писать тесты. Аргументы:
Во-первых любая выборка от одного человека (даже учитывая применение на разных проектах) ничтожно мала, чтобы служить базисом для чего угодно.
Во-вторых различные проекты имеют различную специфику, поэтому какое-то усреднение количества тестов "в среднем по больнице" - бессмысленный источник для сравнения.
В-третих объективный научный подход было бы параллельное ведение несколькими одинаковыми по профессиональными уровню командами автоматизации тестов, когда одна команда разрабатывает и поддерживает одни и те же тесты по KISS принципам, а вторая строит деревья наследования PageObjects и описывает переходы между страницами, с использованием паттернов автоматизации. Сравнение метрик между обоими проектами на некоторой достаточно большой выборке могла бы являться объективным критерием превосходства одной из методик. Очевидно, что такие эксперименты неосуществимы на практике.
Попробую для программистов сделать несколько утрированную аналогию. Как вам помогают GoF Design Patterns? Сколько классов и пакетов вы написали этими паттернами в % к остальным? Сколько находится багов в этих классах? Как сложно находить там баги? Сколько % времени у вас уходит на поддержку кода с этими паттернами?
В целом успех проекта очень редко в достаточной мере зависит от успехов в автоматизации UI тестов. Моя оценка влияния разницы между отличными UI тестами и полным их отсутствием - <5% к вероятности успеха в целом (см. нестабильность тестов). Плохие UI тесты могут даже сильно тормозить проект и приносить вред по сравнению с отказом от них.
А для тех у кого есть праздный интерес к ничего не значащим вне контекста цифрам:
И что? 🙂
По теме доклада я готов к ведению профессиональных дискуссий с применением логических аргументов. Переходящих на личности троллей я тут в комментах баню.
... это бесполезнейшее из знаний, постоянно перетекающих по ресурсам с статьями сомнительной ценности.
Очередной образчик с таблицей бессмысленных сравнений. Там "превентивный процесс", а тут "превентивные меры". Штоа? "Фокус на исполнение тестирования путём выполнения...." - да ну?! И т.д.
Тем не менее, этой разнице постоянно пытаются учить начинающих тестировщиков, при этом еще делают фокус на том, что начнёте пока с тестирования, а потом, прокачаетесь для QA.
Данные сравнения актуальны не более, чем сравнение в мире разработки между Coding, Programming и Development. То есть вообще не актуальны. Предлагаю оставить изучение разницы археотестировщикам, а нам всем заниматься исключительно Development & QA.
В подарок - правильный Roadmap развития тестировщика.
В одной из твиттерных дискуссий Michael Bolton заметил, что тестировать, как точки зрения пользователя - это всего лишь часть тестирования, и предложил тестировать с точки зрения тестировщика.
Когда его спросили как это, он привел следующие 6 пунктов, которых я постараюсь адекватно перевести.
А чувствуете ли вы разницу между тестированием как пользователь и как тестировщик?
Прочитал в сети аргументы, что, мол, раз Atlassian выпилило поле Severity из набора полей в JIRA по умолчанию, то это значит, что индустрия пришла к тому, что Severity никому не нужно.
Полная ерунда. Поле Severity ушло из стандарта JIRA потому что индустрия, пришла к тому, что JIRA чаще используется НЕ в качестве баг-трекера, а в качестве таск-трекера. Для тасков, в отличии от багов - поле Severity действительно не нужно. Я поддерживаю решение Atlassian оставить набор полей по умолчанию таким, чтобы большинство проектов не должны были что-то изменять. Но там где вы используете JIRA как баг-трекер, добавьте в большинстве случаев Severity для багов. Зачем и почему - описано в видео:
Наконец-то сбылась мечта - высказаться про цель тестирования на QA конференции. Попасть на конференцию с темой, про которой у программных комитетов нередко автоматически выскакивает ответ - "да о чём тут говорить, все и так уже знают" было непросто, так что спасибо организаторам QAFest за оказанное доверие!
Рекомендации для просмотра: от 3+ месяца опыта в тестировании - до неограниченного. Если у вас меньше 3 месяцев опыта, то вероятно, вы еще не проникнитесь сутью вопроса по неопытности, просто посмотрите видео чуть попозже. Если у вас очень много опыта (например 5++ лет) - возможно, хотя и маловероятно, что вы действительно всё это уже знаете. Для остальных - гарантирую, что в видео будут вещи, о которых вы не задумывались раньше.
Видео (слайды дополнительно внизу):
Слайды:
Приятного просмотра, спорить и обсуждать можно в комментариях!
Все вы знаете, что UI-тесты бывают нестабильны.
Почему? Недавно мне попалась статья "Автоматизация тестирования: как избежать распространенных ошибок", которая среди прочего, даёт ответ на этот вопрос. У приведённого ответа есть преимущества и недостатки. Преимущество заключается в его простоте. Досадный недостаток - в том, что этот ответ абсолютно, просто таки в корне, неверен.
Давайте же разбираться, почему этот ответ неверен, и почему на самом деле UI-тесты, как правило, нестабильны.
...читать далее Почему нестабильны UI-тесты. А на самом деле?