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 часа.

И что? 🙂

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

2

... это бесполезнейшее из знаний, постоянно перетекающих по ресурсам с статьями сомнительной ценности.

QA Club Сообщество тестировщиков Тестирование ПО 2017-11-09 21-25-39

Очередной образчик с таблицей бессмысленных сравнений. Там "превентивный процесс", а тут "превентивные меры". Штоа? "Фокус на исполнение тестирования путём выполнения...." - да ну?! И т.д.

Тем не менее, этой разнице постоянно пытаются учить начинающих тестировщиков, при этом еще делают фокус на том, что начнёте пока с тестирования, а потом, прокачаетесь для QA.

Данные сравнения актуальны не более, чем сравнение в мире разработки между Coding, Programming и Development. То есть вообще не актуальны. Предлагаю оставить изучение разницы археотестировщикам, а нам всем заниматься исключительно Development & QA.

В подарок - правильный Roadmap развития тестировщика.

Goals and Purposes of Testing.key 2017-11-09 21-44-59

В одной из твиттерных дискуссий Michael Bolton заметил, что тестировать, как точки зрения пользователя - это всего лишь часть тестирования, и предложил тестировать с точки зрения тестировщика.
Когда его спросили как это, он привел следующие 6 пунктов, которых я постараюсь адекватно перевести.

  1. Тестировщик активно принимает во внимание прогнозируемые риски, и готов обращать внимания на новые, доселе непредвиденные.
  2. При моделировании пользователей, рисков, покрытия, тестовых оракулов и т.п., тестировщик обычно предпочитает выражение "один из", выражению "конкретный", чтобы не модель не получилась чересчур ограниченной.
  3. Тестировщик практикует диаметральную смену методов (быстро/медленно, тщательно/бегло, поиск багов/знакомство с системой), чтобы диверсифицировать подходы.
  4. Тестировщик изучает технологии, чтобы понять их силу, слабость, известные проблемы и потенциальные уязвимости.
  5. Тестировщик чередует фокусирование на конкретной системе и её компонентах, дефокусированием  и изучением картины в целиком.
  6. Тестировщик чувствуют себя ответственными за моделирование элементов продукта и его связей с пользователями. Тестировщик ответственны за адекватную отчётность.

    А чувствуете ли вы разницу между тестированием как пользователь и как тестировщик?

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

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

8

Наконец-то сбылась мечта - высказаться про цель тестирования на QA конференции. Попасть на конференцию с темой, про которой у программных комитетов нередко автоматически выскакивает ответ - "да о чём тут говорить, все и так уже знают" было непросто, так что спасибо организаторам QAFest за оказанное доверие!

Рекомендации для просмотра: от 3+ месяца опыта в тестировании - до неограниченного. Если у вас меньше 3 месяцев опыта, то вероятно, вы еще не проникнитесь сутью вопроса по неопытности, просто посмотрите видео чуть попозже. Если у вас очень много опыта (например 5++ лет) - возможно, хотя и маловероятно, что вы действительно всё это уже знаете. Для остальных - гарантирую, что в видео будут вещи, о которых вы не задумывались раньше.

Видео (слайды дополнительно внизу):

Слайды:

Приятного просмотра, спорить и обсуждать можно в комментариях!

5

Все вы знаете, что UI-тесты бывают нестабильны.

Почему? Недавно мне попалась статья "Автоматизация тестирования: как избежать распространенных ошибок", которая среди прочего, даёт ответ на этот вопрос. У приведённого ответа есть преимущества и недостатки. Преимущество заключается в его простоте. Досадный недостаток - в том, что этот ответ абсолютно, просто таки в корне, неверен.

Автоматизация_тестирования__как_избежать_распространенных_ошибок___DOU

 

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

...читать далее Почему нестабильны UI-тесты. А на самом деле?

4

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

А просто рассказ о том, как я пишу тест-кейсы и что с ними делаю. Причем даже в собеседовании на позиции автоматизаторов и тест-менеджеров. Собеседники почему-то сразу расплываются в улыбке и на лице их становится практически написано, что они меня хотят взять.

Сам забываю об этом, поэтому решил написать пост для себя, в качестве напоминания.

5

Рядовой Сидоров, если вы такой умный, то почему строем не ходите!? (неизвестный прапорщик из известного анекдота)

Почему-то в ответ на предыдущий пост, некоторые комментаторы как бы хотят сказать нам своими репликами, что если человек не умеет программировать, то он - дебил не в состоянии понять, как работает программа. С чего это вдруг? А я вот например видал дебилов людей, которые умеют программировать и не в состоянии понять, как работает и зачем нужна программа. Ну и что с того.

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

Для того, чтобы понять как работает двигатель внутреннего сгорания, не обязательно уметь собирать двигатели. Образованный человек сможет понять, как работает программа без владения языком программирования. А сможете ли вы объяснить ему или другому стороннему программисту?

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

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

12

Давайте рассмотрим типичную для многих современных проектов ситуацию: мы начинаем только с программистами-на-все-руки (нет времени объяснять, надо кодить). Через некоторое время выясняется, что есть проблемы с качеством. Почему?

Мой ответ - потому что создаём много кода (умеем же), но мало проверяем код и идеи тестированием (потому что не умеем). Многие проекты осознают и берут в проект тестировщика (или нескольких). И теперь объясните мне внятно те, кто продвигают идею "польза от тестировщика только, если он умеет писать код" - вы действительно хотите чтобы в проекте стало ещё больше кода?

Более логичным выводом является то, что тестировщик должен уметь писать код, если в проекте создаётся слишком мало кода и этот код успевает отлично протестироваться. Вы знаете такие проекты? Сводите меня туда на экскурсию, я хочу у вас учиться!

Альтернатива - научить всех программистов тестированию только кажется разумной. Она настолько же разумна, как и идея научить всех тестировщиков программированию, и программистов с тестировщиками - дизайну пользовательских интерфейсов и фотошопу. Да, есть отдельные личности, способные успешно совмещать несколько направлений и получать от этого удовольствие, но в большинстве своём, дизайнеры, программисты и тестировщики (настоящие, а не те, у кого должность на визитке отпечатана) - любят и хорошо выполняют свою работу, и не очень способны, или, как минимум, не получают удовольствия от работы смежного направления.

Кесарю - кесарево, а слесарю - слесарево.

CF4a68gVIAEcZp0

4

 

41NCHGYJCzLИзвестным Егор стал  благодаря своему блогу, в котором он и начал выкладывать свои будоражащие мир идеи об объектно-ориентированном программировании (ООП), а так же после знаменитого выпуска 105 подкаста "Разбор Полетов", где Егор провел неравный, но весьма увлекательный бой,  с хорошо подготовленной группой профессионалов, которые обстоятельно заклевали покритиковали его подход.

Данная рецензия именно на книгу, и меньше на сам подход Егора к ООП.

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

...читать далее Рецензия на книгу “Elegant Objects” Егора Бугаенко