Comments 11
Многие компании, которые разрабатывают ПО имеют много врождённых болезней:
- Считают тестировщиков людьми второго сорта, поэтому платят им намного меньше программистов и ведут себя высокомерно по отношению к тестировщикам.
- Полагают, что тестировщики отвечают за качество продукта, хотя на самом деле это командная работа всех участников, начиная с владельца бизнеса, аналитика, разработчиков и заканчивая тестировщиками.
- Всех вполне устраивает текущий уровень качества ПО и количество багов, поэтому никто не хочет что-то менять, чтобы улучшить эти показатели.
- Проблемы в коммуникациях между участникам всего процесса. Наличие токсичных и некомпетентных людей в командах.
- Пофигизм со стороны руководства.
- Проектные проблемы: отсутствие нормального планирования, поломанные бизнес процессы, "денег нет, но вы держитесь", "зачем нанимать ещё одного человека, если этот ещё не умер от нагрузки", "надо сделать ещё вчера", "требуется срочно запилить какую-то функцию, потому что менеджер вчера это пообещал на митинге с крупным клиентом" и прочее.
- Считают, что если продукт получился г… но, то это вина тестировщиков, а не всей компании целиком. И прочие фантазии руководителей компании.
>> Сколько из вас сможет ответить на вопрос “как часто на прод попадают баги?” <<
Скорость выхода на продажи для менеджера гораздо важнее, чем качественный продукт. Это неустранимое противоречие с технарями. От сроков представления продукта и первых продаж зависит их КиПиАй / премии, бонусы.
Это как в фарминдустрии - плевать на побочные эффекты, у нас ведь хорошие юристы. Главное - быть первым на рынке и в патентном бюро.
Кроме того, баги могут быть критичными для бизнеса, или некритичными.
Если баг встретился у одного из 1000 пользователей и не привел к финансовым потерям, то его могут даже и не чинить.
Проблема многих айтишников, что они считают цифры, которые бизнесу не нужны, ибо эти цифры не превращаются напрямую в деньги. И многие айтишники постоянно забывают, что они просто винтики для бизнесменов. И не могут понять что да, они и есть винтики.
Все идеи с улучшением проекта должны отталкиваться от двух вещей - улучшение с точки зрения финансов, улучшение с точки зрения репутации (которое теоретически приводит к финансам). Все остальное - зависит от культуры компании/менеджера или менеджеров которые этой компанией управляют.
"эффективный менеджер" с говнокодерами могут делать миллионный бизнес. Сотрудники будут плеваться и ругаться, а бизнес будет плыть. И возможно не какое-то время а просто плыть и рвать конкурентов.
Поэтому да, создать хорошую рабочую культуру и атмосферу это не нанять HR для организации тимбилдингов, а заниматься качеством и продукта и работы.
Но... это зачастую работает там, где высокая конкуренция и нужны грамотные специалисты, у которых есть выбор где работать.
А еще это работает, когда бизнес немного понимает, как работает айти часть. И что бывают баги, которые могут очень сказаться на пользовательских метриках и привести к большим убыткам или вообще потере бизнеса.
Если баг встретился у одного из 1000 пользователей и не привел к финансовым потерям, то его могут даже и не чинить.
Поэтому сообщать о багах надо всегда, всем и везде.
Не анализируют баги с продакшена
… И чаще всего не исправляют баги, о которых сообщают пользователи через техподдержку.
Какой процент релизов выпускается без багов?
0%. Продуктов без багов не существует, даже в теории.
Выпускала несколько релизов в неделю, каждый релиз тщательно проверялся ручным тестировщиком
Это невозможно.
Тем не менее общий посыл статьи правильный. Поставил плюс (точнее, два плюса )).
Сколько из этих багов можно было предотвратить на этапе тестирования? А разработки? А аналитики?
Сложно придумать баг который нельзя было бы предотвратить. Крайнего можно найти всегда.
Через 6 месяцев легко можно посмотреть, приведут ли изменения в процессах к какому-то результату, считать нужные цифры ребята научились.
Через десять лет или я помру, или ишак. За 6 месяцев в команде любого масштаба может накопиться столько изменений, что любое изменение в такой метрике можно будет объяснить чем угодно. Ушел/пришел ведуший разраб, новые тестировщики; сменился стек, продукт, вектор разработки; зима, всем холодно, лето, всем жарко.
В малой команде будет анализироваться выборка из ~12 релизов, которые все были разные по всем измеримым и неизмеримым параметрам, в большой компании метрика будет измняться на очень значительные +-1.5%, потому что все команды разные по всем измеримым и т.д.
Оказалось, что страницу логина всё-таки задели.
Очень сильно надеюсь, что это синтетический пример. Это не проблема "стабильности" автотестов, это проблема "зачем тестировать вручную если мы писали автотесты". Уж простите, минимальный смок могут позволить себе все.
Вопрос в том, насколько? Как давно они стали нестабильными? Какой процент нестабильных тестов в вашей сборке?
Без ответа на эти вопросы работать с нестабильностями невозможно. А работать с ними нужно, иначе ваши тесты бесполезны.
Сегодня я увидел оповещение о том, что один из моих регулярных скриптов упал. Скрипт выгружает картинки, обрезает их, заливает в хранилище. Скрипт упал из-за того, что съел картинку, в tiff-теге был NaN, а библиотека для работы с изображениями, которую я использовал, не ожидала NaN в метках. Я исправил скрипт таким образом, чтобы он работал с этим случаем, и перезапустил его.
Для этого мне не потребовалось подсчитать, сколько раз за последние N дней этот скрипт падал, кто тот негодяй, что создал картинку с NaN в теге, какой процент моих скриптов может бросить ошибку от неожиданного ввода. Мне потребовалось только открыть текстовый редактор и исправить скрипт.
Я согласен с тем, что если программа не работает, то тот, кто ответственен за ее поддержку, зря ест свой хлеб. Но сомневаюсь в том, что такая метрика дармоедов может быть полезна. Один нерабочий тест может привести к пропуску ошибки так же, как и сотня нерабочих тестов.
По моему мнению, статья не убеждает, что ошибка - это не единичный независимый случай, который должен быть азобран индивидуально и стать толчком (в совокупности с подобными случаями) для выработки практики, которая позолит избежать схожих случаев. И не предлагает никаких подходов, которые помогли бы установить закономерности в цикле разработки, за исключением фрагмента:
часть этих багов совсем не критичные, их необязательно править asap, отвлекая людей от текущей работы;
что предполагало индивидуальный разбор каждой ошибки.
Автор, прошу подумать над тем, чтобы рассказать о вашем опыте внедрения метрик тестирования с упором на то, как это помогло найти закономерности и изменить рабочие практики. И в том числе повлиять на глобальные метрики, которые вы описали в этой статье. Потому что ваша статья рассказывает о том "что?", но не говорит "зачем?".
Цифры, которые мы не считаем