3

Предлагаю к ознакомлению запись доклада-мастер класса, с примерами практического применения элементов 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 часа.

И что? 🙂

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

5

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

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

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

 

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

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

5

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

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

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

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

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

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

12

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

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

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

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

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

CF4a68gVIAEcZp0

Эту ошибку при написании ui автотестов я, как мне кажется, встречаю чаще
всего.

Update. По просьбам трудящихся обновил пример с более абстрактного, на более жизненный. Суть осталось неизменной.

Представьте, у вас есть такой простой набор тестов.

Набор чеков в коде, в стиле Selenide, будет примерно таким:

Видите ошибку?

Если вы просто повторили язык теста, то чеки пройдут положительно и тест будет "зелёненьким", даже когда "Оплатить" будет всегда "disabled" (в частности, после выполнения заполнения корзины).

Более правильным, конечно, будет вариант

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

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

А вы говорите не нужны юнит-тесты.

Дали мне сегодня весь проект запустить. Скачал из git. Запустил на сборку. Выдаёт ошибку в юнит-тесте.
Окей - говорю программистам. У нас не выдаёт, отвечают. Запускают - действительно не выдаёт, у меня при запуске теста из IDE тоже не выдаёт. А из командной строки - выдает. Программисты, хотите упражнение? Метод модифицирует web элемент таг с атрибутами вроде:

И assert сравнивает строковый результат, и у меня из командной строки валится потому что атрибут один меняет порядок (сперва attr2, затем attr1). Примерно так:

Симптомы - выше (где-то меняет, где-то не меняет). В чем проблема? Решение ниже.

...читать далее Походные заметки про простое тестирование

25

48NCCrj

Итак, раз уж я в прошлом выпуске Radio QA cпалил в чатике заготовку, то вот вам она еще раз постом.

Ручной тестировщик - врач, а автоматизатор - специалист по настройке и ремонту медицинского оборудования, с некоторыми знаниями медицины.

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

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

Отсюда же очевидно, что проекты, которым нужен хороший доктор, должны искать именно высококвалифицированных тестировщиков, а не кликеров (которых по данной терминологии с трудом претендуют на звание "санитаров").

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

Кто не согласен - прошу в комменты!

10

Посмотрел лекцию для начинающих автоматизировать с Selenium

Очень приветствую создание и распространение обучающего материала, это правильно и нужно! Правда есть "но".
К сожалению не обошлось в этом материале без принципиальных фактических ошибок. В частности часть про явные и неявные ожидания (explicit/implicit waits) лектор предваряет ремаркой о том, что тема про эти два вида ожидания довольная сложна для понимания, и немедленно подтверждает тезис тем, что путает их между собой и даёт неверное пояснение.

Давайте же разберёмся, в чем разница. Страница помощи Selenium-а абсолютно невнятно освещает этот вопрос, поэтому попробую проще  своими словами.

Explicit Wait - явное (непосредственное, прямое) ожидание используется "здесь и сейчас" на один конкретный поиск элемента. В частности, даже паттерн "sleep" (ждать и ничего не делать) является примером explicit wait, но его применение не поощряется.
На практике рекомендуется использование WebDriverWait в сочетании с методами класса ExpectedConditions, которые позволяют сократить ожидание. Если элемент появился раньше времени, заданного при инициализации WebDriverWait - Selenium не будет ждать, а продолжит исполнение теста.

Пример кода на Java:

Implicit Wait - неявное (косвенное, скрытое) ожидание устанавливается один раз в коде вне операции поиска и действительно до изменения. Значение по умолчанию - 0, т.е. никакого ожидания. Implicit Wait применяется ко всем последующим операциям поиска неявно (т.е. скрытно, без указания напрямую в методе поиска, как мы видели в примере выше). ...читать далее Правда о явных и неявных ожиданиях в Selenium

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

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

Надеюсь, что все закончится обратной волной на воспитание высококачественных ручных тестировщиков.

Кстати, о тонких чувствах ручных тестировщиков, ушедших в автоматизацию, в субботу 04.07 в 16:00 мск выходит подкаст на Radio QA 🙂

3

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

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

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

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

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

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

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