Я работаю тестировщиком больше 10 лет. Успела поработать в НПО, где только знакомились с тестированием. В крупном рабовладельце аутсорсе, отчитывающемся перед заказчиком за каждую чашку кофе. В продуктовой компании с более чем 100 тестировщиками и выстроенными (нууу, как-то) процессами. Каждая компания уникальна, как снежинка, но есть нюанс. Есть работа, которой тестировщики пренебрегают независимо от зрелости компании и её ценностей. Недавно я участвовала в опросе 85 команд разработки, начиная от свеженьких стартапов, заканчивая лютыми энтерпрайзами. И была крайне удивлена, сколько же общего у этих ребят. Вот что они не делают.
Не анализируют баги с продакшена
Да, начну с таких банальных вещей. Сколько из вас сможет ответить на вопрос “как часто на прод попадают баги?”. Предположим, на уровне “да постоянно” / ”не так уж и часто, нас устраивает” смогут ответить все. А в цифрах? Какой процент релизов выпускается без багов? Какое процентное соотношение критичных / мажорных / минорных багов с прода? Сколько из этих багов можно было предотвратить на этапе тестирования? А разработки? А аналитики? Если можете ответить на все эти вопросы, возьмите печеньку с полки, вы заслужили. Не можете – тоже возьмите печеньку, вам понадобится много энергии для расчетов.
Не буду рассказывать, почему работать с багами с прода – обязательная обязанность всей команды, и в частности тестировщика. Лучше расскажу, что происходит, когда это не делается.
Жила-была команда Х. Выпускала несколько релизов в неделю, каждый релиз тщательно проверялся ручным тестировщиком, а разработчики писали юниты и системные тесты. В общем, ребята старались, как могли. Но раздел со срочными правками после релизов на их канбан-доске никак не уменьшался. Что же сделали наши канбанята тестировщики? Они решили посмотреть:
сколько доработок с прода команда чинит в экстренном режиме,
по каким причинам эти проблемы появляются,
точно ли это ли всё критичные доработки.
Посмотрели и поняли, что:
часть этих багов совсем не критичные, их необязательно править asap, отвлекая людей от текущей работы;
бОльшая часть багов вызывает у всей команды вопрос “а, чё, как это вообще связано с нашими доработками?”. Т.е. это всё сложный регресс, и не стоит полагаться, что его отловят ручные тестировщики.
В общем, ответственность с себя сняли, часть работы отложили на потом. Молодцы, работаем дальше. Это помогло команде составить план действий на полгода, опираясь не на субъективные ощущения, а на настоящие цифры. Через 6 месяцев легко можно посмотреть, приведут ли изменения в процессах к какому-то результату, считать нужные цифры ребята научились.
Не стабилизируют автотесты
В мире разработчиков считается нормой, что тесты стабильны на 100%. Можете себе представить юнит-тесты, которые падают, потому что не дождались появления какой-то сущности? А UI-тесты, которые падают только из-за ошибок в продуктовом коде? Может, у меня была тяжёлая судьба, но и то, и другое я представляю себе с трудом.
В моём мире UI-тесты в большинстве команд нестабильны. Вопрос в том, насколько? Как давно они стали нестабильными? Какой процент нестабильных тестов в вашей сборке?
Без ответа на эти вопросы работать с нестабильностями невозможно. А работать с ними нужно, иначе ваши тесты бесполезны.
Давайте вспомним команду Х. Ребята-тестировщики без дела не сидят, в свободное от ручного тестирования время пишут автотесты с использованием Selenium. Стильно, модно, молодёжно, но нестабильно. Какая-то часть тестов постоянно падает, то Stale element reference exception, то No such element… Некоторые тесты уже примелькались, и все запомнили, что LoginButton_ShouldOpenLoginPage часто падает из-за странных ошибок, хотя функциональность работает. Вы же догадались, что будет дальше? В очередной сборке тест упал, тестировщик подумал “ну мы же не задели страницу логина в этой задаче” и не стал разбираться. А после релиза ба-бах – и на доске появляется новый тикет в разделе “СРОЧНО”. Оказалось, что страницу логина всё-таки задели. Но тест так часто ложно кричал “волки”, что в этот раз его проигнорировали.
Чем бы тут помогло точное знание о том, какие тесты нестабильны, как давно, по каким причинам? Ну, во-первых, эти знания немнооожко стимулируют команду заниматься стабилизацией.
Во-вторых, знание о том, какие тесты нестабильны, позволит не надеяться на эти тесты, вычеркнуть их из своей ментальной карты покрытых сценариев. Тестировать руками, пропускать меньше багов. Задолбаться и все-таки починить тесты.
Ну и что?
Вы вот, наверное, прочитали это всё и думаете, а зачем она нам это рассказала? Объясню.
Тестировщик – профессия творческая. Но не думайте, что творческим людям не нужны конкретные цифры.
Субъективная оценка всегда неточная, а часто – неверная. Если вы устали от ощущения, что сколько бы вы ни делали, работы меньше не становится, попробуйте посчитать в циферках, а сколько вы реально сделали? Сколько тестов стабилизировали? Сколько новых нестабильных появилось? Где кроется проблема? Как давно вы пропустили баг на прод? Как это можно было предотвратить? А сколько багов пропускает второй тестировщик из вашей команды? Что он делает по-другому? Чем его релизы отличались от ваших?
Не надейтесь на «я 5 лет в проекте и всё знаю». Посчитайте настоящие цифры. Они вас удивят.
Комментарии (11)
mesvobodnye
27.08.2023 13:18+2>> Сколько из вас сможет ответить на вопрос “как часто на прод попадают баги?” <<
Скорость выхода на продажи для менеджера гораздо важнее, чем качественный продукт. Это неустранимое противоречие с технарями. От сроков представления продукта и первых продаж зависит их КиПиАй / премии, бонусы.
Это как в фарминдустрии - плевать на побочные эффекты, у нас ведь хорошие юристы. Главное - быть первым на рынке и в патентном бюро.
saboteur_kiev
27.08.2023 13:18+2Кроме того, баги могут быть критичными для бизнеса, или некритичными.
Если баг встретился у одного из 1000 пользователей и не привел к финансовым потерям, то его могут даже и не чинить.
Проблема многих айтишников, что они считают цифры, которые бизнесу не нужны, ибо эти цифры не превращаются напрямую в деньги. И многие айтишники постоянно забывают, что они просто винтики для бизнесменов. И не могут понять что да, они и есть винтики.
Все идеи с улучшением проекта должны отталкиваться от двух вещей - улучшение с точки зрения финансов, улучшение с точки зрения репутации (которое теоретически приводит к финансам). Все остальное - зависит от культуры компании/менеджера или менеджеров которые этой компанией управляют.
"эффективный менеджер" с говнокодерами могут делать миллионный бизнес. Сотрудники будут плеваться и ругаться, а бизнес будет плыть. И возможно не какое-то время а просто плыть и рвать конкурентов.Поэтому да, создать хорошую рабочую культуру и атмосферу это не нанять HR для организации тимбилдингов, а заниматься качеством и продукта и работы.
Но... это зачастую работает там, где высокая конкуренция и нужны грамотные специалисты, у которых есть выбор где работать.
Yuri_nedre
27.08.2023 13:18А еще это работает, когда бизнес немного понимает, как работает айти часть. И что бывают баги, которые могут очень сказаться на пользовательских метриках и привести к большим убыткам или вообще потере бизнеса.
Mike-M
27.08.2023 13:18Если баг встретился у одного из 1000 пользователей и не привел к финансовым потерям, то его могут даже и не чинить.
Поэтому сообщать о багах надо всегда, всем и везде.
Mike-M
27.08.2023 13:18-1Не анализируют баги с продакшена
… И чаще всего не исправляют баги, о которых сообщают пользователи через техподдержку.
Какой процент релизов выпускается без багов?
0%. Продуктов без багов не существует, даже в теории.
Выпускала несколько релизов в неделю, каждый релиз тщательно проверялся ручным тестировщиком
Это невозможно.
Тем не менее общий посыл статьи правильный. Поставил плюс (точнее, два плюса )).
pentela
27.08.2023 13:18Сколько из этих багов можно было предотвратить на этапе тестирования? А разработки? А аналитики?
Сложно придумать баг который нельзя было бы предотвратить. Крайнего можно найти всегда.
Через 6 месяцев легко можно посмотреть, приведут ли изменения в процессах к какому-то результату, считать нужные цифры ребята научились.
Через десять лет или я помру, или ишак. За 6 месяцев в команде любого масштаба может накопиться столько изменений, что любое изменение в такой метрике можно будет объяснить чем угодно. Ушел/пришел ведуший разраб, новые тестировщики; сменился стек, продукт, вектор разработки; зима, всем холодно, лето, всем жарко.
В малой команде будет анализироваться выборка из ~12 релизов, которые все были разные по всем измеримым и неизмеримым параметрам, в большой компании метрика будет измняться на очень значительные +-1.5%, потому что все команды разные по всем измеримым и т.д.
Оказалось, что страницу логина всё-таки задели.
Очень сильно надеюсь, что это синтетический пример. Это не проблема "стабильности" автотестов, это проблема "зачем тестировать вручную если мы писали автотесты". Уж простите, минимальный смок могут позволить себе все.
Вопрос в том, насколько? Как давно они стали нестабильными? Какой процент нестабильных тестов в вашей сборке?
Без ответа на эти вопросы работать с нестабильностями невозможно. А работать с ними нужно, иначе ваши тесты бесполезны.
Сегодня я увидел оповещение о том, что один из моих регулярных скриптов упал. Скрипт выгружает картинки, обрезает их, заливает в хранилище. Скрипт упал из-за того, что съел картинку, в tiff-теге был NaN, а библиотека для работы с изображениями, которую я использовал, не ожидала NaN в метках. Я исправил скрипт таким образом, чтобы он работал с этим случаем, и перезапустил его.
Для этого мне не потребовалось подсчитать, сколько раз за последние N дней этот скрипт падал, кто тот негодяй, что создал картинку с NaN в теге, какой процент моих скриптов может бросить ошибку от неожиданного ввода. Мне потребовалось только открыть текстовый редактор и исправить скрипт.
Я согласен с тем, что если программа не работает, то тот, кто ответственен за ее поддержку, зря ест свой хлеб. Но сомневаюсь в том, что такая метрика дармоедов может быть полезна. Один нерабочий тест может привести к пропуску ошибки так же, как и сотня нерабочих тестов.
По моему мнению, статья не убеждает, что ошибка - это не единичный независимый случай, который должен быть азобран индивидуально и стать толчком (в совокупности с подобными случаями) для выработки практики, которая позолит избежать схожих случаев. И не предлагает никаких подходов, которые помогли бы установить закономерности в цикле разработки, за исключением фрагмента:
часть этих багов совсем не критичные, их необязательно править asap, отвлекая людей от текущей работы;
что предполагало индивидуальный разбор каждой ошибки.
Автор, прошу подумать над тем, чтобы рассказать о вашем опыте внедрения метрик тестирования с упором на то, как это помогло найти закономерности и изменить рабочие практики. И в том числе повлиять на глобальные метрики, которые вы описали в этой статье. Потому что ваша статья рассказывает о том "что?", но не говорит "зачем?".
Thomas_Hanniball
Многие компании, которые разрабатывают ПО имеют много врождённых болезней:
Yuri_nedre
Я как-то встречал заказчика, который не хотел оплачивать часы тестирования, мол "заставьте разработчиков сразу писать хороший код"
sim31r
Или вариант, когда тестируют пользователи на продуктивном сервере. Если будут жалобы, тогда и будут исправляться ошибки.
Mike-M
К сожалению, практика показывает, что ошибки чаше всего не исправляются даже после жалоб со стороны пользователей.