Home

Автор: Эльвира Скачко

Я работаю тестировщиком больше 10 лет. Успела поработать в НПО, где только знакомились с тестированием. В крупном рабовладельце аутсорсе, отчитывающемся перед заказчиком за каждую чашку кофе. В продуктовой компании с более чем 100 тестировщиками и выстроенными (нууу, как-то) процессами. Каждая компания уникальна, как снежинка, но есть нюанс. Есть работа, которой тестировщики пренебрегают независимо от зрелости компании и её ценностей. Недавно я участвовала в опросе 85 команд разработки, начиная от свеженьких стартапов, заканчивая лютыми энтерпрайзами. И была крайне удивлена, сколько же общего у этих ребят. Вот что они не делают.

Не анализируют баги с продакшена

Да, начну с таких банальных вещей. Сколько из вас сможет ответить на вопрос “как часто на прод попадают баги?”. Предположим, на уровне “да постоянно” / ”не так уж и часто, нас устраивает” смогут ответить все. А в цифрах? Какой процент релизов выпускается без багов? Какое процентное соотношение критичных / мажорных / минорных багов с прода? Сколько из этих багов можно было предотвратить на этапе тестирования? А разработки? А аналитики? Если можете ответить на все эти вопросы, возьмите печеньку с полки, вы заслужили. Не можете – тоже возьмите печеньку, вам понадобится много энергии для расчетов.

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

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

1. сколько доработок с прода команда чинит в экстренном режиме,

2. по каким причинам эти проблемы появляются,

3. точно ли это ли всё критичные доработки.

Посмотрели и поняли, что:

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

2. бОльшая часть багов вызывает у всей команды вопрос “а, чё, как это вообще связано с нашими доработками?”. Т.е. это всё сложный регресс, и не стоит полагаться, что его отловят ручные тестировщики.

В общем, ответственность с себя сняли, часть работы отложили на потом. Молодцы, работаем дальше. Это помогло команде составить план действий на полгода, опираясь не на субъективные ощущения, а на настоящие цифры. Через 6 месяцев легко можно посмотреть, приведут ли изменения в процессах к какому-то результату, считать нужные цифры ребята научились.

Не стабилизируют автотесты

В мире разработчиков считается нормой, что тесты стабильны на 100%. Можете себе представить юнит-тесты, которые падают, потому что не дождались появления какой-то сущности? А UI-тесты, которые падают только из-за ошибок в продуктовом коде? Может, у меня была тяжёлая судьба, но и то, и другое я представляю себе с трудом.

В моём мире UI-тесты в большинстве команд нестабильны. Вопрос в том, насколько? Как давно они стали нестабильными? Какой процент нестабильных тестов в вашей сборке?

Без ответа на эти вопросы работать с нестабильностями невозможно. А работать с ними нужно, иначе ваши тесты бесполезны.

Давайте вспомним команду Х. Ребята-тестировщики без дела не сидят, в свободное от ручного тестирования время пишут автотесты с использованием Selenium. Стильно, модно, молодёжно, но нестабильно. Какая-то часть тестов постоянно падает, то Stale element reference exception, то No such element… Некоторые тесты уже примелькались, и все запомнили, что LoginButton_ShouldOpenLoginPage часто падает из-за странных ошибок, хотя функциональность работает. Вы же догадались, что будет дальше? В очередной сборке тест упал, тестировщик подумал “ну мы же не задели страницу логина в этой задаче” и не стал разбираться. А после релиза ба-бах – и на доске появляется новый тикет в разделе “СРОЧНО”. Оказалось, что страницу логина всё-таки задели. Но тест так часто ложно кричал “волки”, что в этот раз его проигнорировали.

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

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

Ну и что?

Вы вот, наверное, прочитали это всё и думаете, а зачем она нам это рассказала? Объясню.

Тестировщик – профессия творческая. Но не думайте, что творческим людям не нужны конкретные цифры.

Субъективная оценка всегда неточная, а часто – неверная. Если вы устали от ощущения, что сколько бы вы ни делали, работы меньше не становится, попробуйте посчитать в циферках, а сколько вы реально сделали? Сколько тестов стабилизировали? Сколько новых нестабильных появилось? Где кроется проблема? Как давно вы пропустили баг на прод? Как это можно было предотвратить? А сколько багов пропускает второй тестировщик из вашей команды? Что он делает по-другому? Чем его релизы отличались от ваших?

Не надейтесь на «я 5 лет в проекте и всё знаю». Посчитайте настоящие цифры. Они вас удивят.

Обсудить в форуме