tgoop.com/productbombing/65
Last Update:
Почему всегда болит тестирование?!
В первый день моего отпуска я летела на самолёте в Грецию. По прилёту мой Slack просто взорвался. Оказалось, что за эти 4 часа наш продуктивный стенд не выдержал нагрузки и упал. Упал в самый жаркий период использования нашего продукта.
☠ Это была катастрофа, которую ребята быстро исправили. Но на этом сложности не закончились. Люди повсюду видели надпись "проверь VPN", хотя по факту просто неправильно отрабатывали валидации на фронте. Периодически у нас возникали те условия, которых в требованиях не было.
Я могу продолжать до бесконечности, но к чему я веду? Баги есть у всех. Они есть у нашего большого продукта, есть на Фэйсбуке, есть на Нетфликсе. Вопрос лишь в критичности этих багов.
🙈 Значит ли это, что мы все плохо работаем? По большей части нет. Только что, что мы недостаточно хорошо выстраиваем процесс тестирования.
Тут часто включается эффект когнитивного искажения. Мы не любим думать о том, что можем совершать ошибки, поэтому ненавидим оценивать риски. Наш мозг думает в режиме "нормально все будет" и триггерит нас принимать неправильные решения быстро. Тестирование - как хорошая привычка. Его культуру нужно прививать.
На моем прошлом продукте тестирование (даже функциональное) болело так сильно, что нас физически трясло. Оно было как кот Шредингера: вроде тестировщики и есть, а баги не находятся и не закрываются😂.
И поняли мы это только когда у нас завершился рефакторинг, и в системе оказалось 300+ багов, которые никто не находил, а если и находил, то не логировал или логировал неправильно.
Пример: Блокирующий баг в джире: "В карте KPI у HRа не хватает кнопки Согласовать". 🤯
В смысле?! Это все? На каком стенде ты это проверял? Под каким пользователем нашел ошибку? На каком этапе была карта? У какого пользователя? В каком браузере? Какие были твои шаги перед тем, как ты нашел ошибку? Где скрин? Панель разработчика открывал?
И самое главное: а ты вообще уверен, что это ошибка, а не ожидаемое поведение системы? (Спойлер: нет).
Разработчик не понимал, что за баг, воспроизвести по такому описанию не мог, поэтому ставил статус "не воспроизводится" и закрывал задачу. А тестировщик потом заводил ее заново 😜.
В целом это история с хэппи эндом. Правда, выстраивать процесс тестирования пришлось техническому писателю, системному аналитику и мне (звучит как начало плохого анекдота. За тем исключением, что мы в бар не заходили, а пошли ботать в выходные на Яндекс.Практикум).
Почему мы? Я искренне считаю, что за процесс тестирования отвечает в том числе продакт. Да, с помощью тимлида, но кому аутнется, когда в продукте будет 300 багов? У кого из-за этого упадут метрики?
Через боль и страдания мы пришли к конкретному описанию багов в джире.
Логировали:
- где возникла ошибка (стенд, браузер)
- под каким пользователем ее обнаружили
- шаги воспроизведения
- ожидаемое поведение
- фактическое поведение системы
- скрин с открытой панелью разработчика
- воспроизводимость ошибки.
Но это были только первые шаги к выстраиванию тестирования. И сейчас во многом мне придется пройти через этот процесс еще раз (у нас в команде нет QA, поэтому пока возникают трудности).
BY Продуктовая бомбежка
Share with your friend now:
tgoop.com/productbombing/65