2

Предлагаю к ознакомлению запись доклада-мастер класса, с примерами практического применения элементов KISS-Driven автоматизации в UI тестировании.

 

Слайды:

Довольно часто я получаю вопросы такого типа:

Слушал ваш доклад на <конференция>. Вы рассказывали про KISS и про много вещей которые не укладываются в голове, (отказ от наследования, дублирование кода...) но вот ни слова не рассказали о конкретно ваших показателях и какие у вас результаты. Поэтому хотел узнать: сколько у вас всего e2e тестов? Сколько времени они у вас длятся, какой самый длинный тест, сколько из этих тестов flaky? и сколько % времени вы тратите на "maintenance"? Спасибо.

Постараюсь ответить.

Я считаю, что все указанные вопросы абсолютно нерелевантны к теме как писать тесты. Аргументы:

Во-первых любая выборка от одного человека (даже учитывая применение на разных проектах) ничтожно мала, чтобы служить базисом для чего угодно.

Во-вторых различные проекты имеют различную специфику, поэтому какое-то усреднение количества тестов "в среднем по больнице" - бессмысленный источник для сравнения.

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

Попробую для программистов сделать несколько утрированную аналогию. Как вам помогают GoF Design Patterns? Сколько классов и пакетов вы написали этими паттернами в % к остальным? Сколько находится багов в этих классах? Как сложно находить там баги? Сколько % времени у вас уходит на поддержку кода с этими паттернами?

В целом успех проекта очень редко в достаточной мере зависит от успехов в автоматизации UI тестов. Моя оценка влияния разницы между отличными UI тестами и полным их отсутствием - <5% к вероятности успеха в целом (см. нестабильность тестов). Плохие UI тесты могут даже сильно тормозить проект и приносить вред по сравнению с отказом от них.

А для тех у кого есть праздный интерес к ничего не значащим вне контекста цифрам:

  • В разных проектах с моих участием было написано между 20 и 100 тестами.
  • Самый короткий - длится секунду, самый длинный минуты 3. 🙂
  • Настоящих flacky среди них очень мало, но это не благодаря KISS, а благодаря фреймворку Selenide, который очень хорошо решает многие проблемы со стороны тестов. В среднем по больнице около 5% тестов показывали разный результат на повторных прогонах, что в 99% случаев было связано с ошибками в софте.
  • Время на поддержку по KISS всегда уходит мало, статистику я не вёл. Один раз был случай, надо было поменять свести около 100 классов написаных копипастом в 5. Причина - нас дезинформировали о структуре кода страниц в разработке. Сперва утверждалось, что каждая страница (они были действительно подозрительно похожи друг на друга) является отдельным элемента в исходном коде, поэтому для упрощения поддержки написали класс на каждую такую "страницу" копипастом. Потому оказалось, что нет - как и показалось - один класс генерировал большие группы страниц, решили переделать. Рефакторинг занял примерно 4 часа.

И что? 🙂

По теме доклада я готов к ведению профессиональных дискуссий с применением логических аргументов. Переходящих на личности троллей я тут в комментах баню.

Прочитал в сети аргументы, что, мол, раз Atlassian выпилило поле Severity из набора полей в JIRA по умолчанию, то это значит, что индустрия пришла к тому, что Severity никому не нужно.

Полная ерунда. Поле Severity ушло из стандарта JIRA потому что индустрия, пришла к тому, что JIRA чаще используется НЕ в качестве баг-трекера, а в качестве таск-трекера. Для тасков, в отличии от багов - поле Severity действительно не нужно. Я поддерживаю решение Atlassian оставить набор полей по умолчанию таким, чтобы большинство проектов не должны были что-то изменять. Но там где вы используете JIRA как баг-трекер, добавьте в большинстве случаев Severity для багов. Зачем и почему - описано в видео:

2

CV0BdxXWsAIvYoi

В субботу 23.04 буду в Москве на конференции по автоматизированному тестированию "QA Conference".
Я буду рассказывать про сравнительно узкую техническую тему - использование PageObjects в UI Automation.
И для заманухи - в докладе я покажу, в каких местах Copy&Paste кода - хорошая идея. 🙂

Этот и другие вбросы - в Москве, в гостинице "Салют" с 10 утра, приходите или смотрите online. Я думаю, что будет, как обычно, довольно живенько и спорно!

http://qaconf.ru/matrix.html

3

Очередная критическая разборка доклада, на этот раз на очереди Андрей Ладутько с беседой об аудите:

В целом доклад мне показался интересным, но в некоторых моментах неполным или спорным. Мне показалось, что в начале Андрей несколько нервничал и спешил, затем темп стал лучше и ведение доклада стало очень уверенным.

Начну с критики по содержанию доклада:

  • "аудит - предпоследняя фаза проекта" - вообще говоря, я бы не включал аудит вообще в фазы проекта. По моему опыту, он чаще проводится после окончания проекта или его части, чтобы использовать опыт в следующих проектах. Или в середине проекта - когда все ужас-ужас. Или, упаси Болтон, назначается судом, когда заказчик не смог договорится с исполнителем, как полюбовно разрулить абсолютное недовольство заказчика результатом.
    Конечно, никто не запретит рутинно проводить аудит "предпоследним перед сдачей", но вроде и частью процесса он обычно не является. Для меня это полезный тул - который можно использовать (иногда).

    Update. Неправильно услышал, говорилось, что тестирование - предпоследняя фаза. Это тоже вещь довольно спорная, но то, что результаты тестирование ближе к концу наиболее полны и заметны - с этим не поспоришь.

  • "Жизненный цикл процесса", "надо обсуждать весь процесс" - тут возникла путаница, мне показалось, что докладчик в большинстве случаев имел ввиду полный процесс разработки (который включает тестирование). Но в заголовке доклада - "процесс тестирования", и на некоторых других слайдах тоже однозначно он. Местами было сложно понять, какой из процессов имеется ввиду в данный момент, следовало как-то лучше разграничить.

...читать далее Линч-пакет: Андрей Ладутько “Как оценить процесс тестирования на проекте”

2

В этот раз видео появилось быстро. Доклад вышел удачно, некоторый поток слов-паразитов мне сдержать не удалось, но тем не менее было динамично и весело, особенно вопросы (последние 12 минут). Спасибо модератору за 7 бонусных минут сверх положенного времени :).

Подробный разбор будет чуть позже, пока что в качестве тизера - комикс из доклада.

SevPrioComicsFull1
Смотрите, задавайте вопросы!

 

2

Продолжаем разбирать доклады с SQA Days 17 в жестком стиле, но с согласия докладчика :). Сегодня у нас в пакете доклад Игоря Бондаренко "Безопасность мобильных приложений. Что тестировать?" 

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

В принципе эмоции от доклада были очень положительные, поэтому начну в этот раз с хороших моментов.
Доклад был короткий (15 мин), был хорошо структурирован и бодро рассказан. Тайминг был соблюден идеально. Примеры были, в основном, понятные. Слайды - читаемые.

Серьёзных огрехов, честно говоря, вообще замечено не было, но так как формат линча предполагает критику - будем докапываться к мелочам :). Замеченные ошибки без градации - все не очень серьёзные.

  • Перемешаны английские и русские термины в слайдах

...читать далее Линч-пакет: Игорь Бондаренко “Безопасность мобильных приложений”

4

Начну серию постов, в которых постараюсь очень критически отрецензировать доклады коллег. Разрешение на линч было дано мне авторами, находящимися в здравом уме и твёрдой памяти, добровольно и без принуждения 🙂

Первый под горячую руку попал доклад - Сергея Атрощенкова с SQA Days 17 в Минске
Для удобства чтения я повторю слайды и видео тут:

 

...читать далее Линч-пакет: Сергей Атрощенков “Моделирование угроз безопасности”

7

В пятницу 29 мая, в Минске буду читать доклад на SQA Days 17.

Приходите - я очень старался сделать доклад интересным!
Я предполагаю, что все зрители понимают основы использования, и уже так или иначе сталкивались с применением на практике.

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

Кто после доклада приведет мне линки на советы и приёмы аналогичные указанным - получит пиво/шоколадку 🙂

SeverityVsPriority_Рус_key

До встречи на докладе!

 

1

Первое видео с квартирника про IT работу и жизнь за рубежом, который я вел в Новосибирске. Несколько оффтопиком к теме блога, в нем о тестировании говориться не будет.
Как и ожидалось, все темы пройти не успели - эксперты, поначалу неуверенно высказывавшиеся о желании участвовать, пришли в полном составе!
И это несмотря на то, что квартирник был поставлен первым слотом в 10 утра между первым и вторым днём конференции (ну вы поняли). 🙂
Местами было занудно, но все равно квартирник занял второе место в побочной секции квартирников и мини-докладов.

 

И сразу онтопиком квартирник, занявший 3-ее место про тестирование с ведущей Таней Писчасовой "Мир без тестировщиков. Миф или реальность?"

Наконец опубликовано видео с моего доклада на SQA Days 16. Хотите сделать ваше ручное тестирование быстрее и гибче? Обязательно посмотрите 🙂

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

Если у вас есть свои вопросы - задавайте, постараюсь ответить. В конце поста добавлю и пример с решением, который описывал в докладе.

Видео:

Слайды:

...читать далее No-Test-Cases: избавьтесь от тест-кейсов в ручном тестировании