Ретроспективный анализ ошибки

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

Я пропустил баг...

Искать виноватых бесполезно. Окей, виноваты не вы, проверку не выполнил Вася. Дали втык, отобрали зарплату. Полегчало? Через месяц Маша допустит ту же ошибку. Повторяем наказание. Ничего не меняется. Ребята ходят по граблям, на которые уже наступали.

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

Мой метод

Я сохранила себе шаблон для заполнения. Фактически это набор вопросов, на которые стоит ответить. Чек-лист «а не забыл ли я подумать вот о чем?». Он помогает не забыть копнуть чуть глубже и понять, что надо сделать, чтобы ошибка не повторялась.

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

Шаблон

Примеры


В гуглодоке оно как-то лучше смотрится, чем в блоггере =)
Но список вопросов могу продублировать:

1. Когда и где обнаружена?
2. Суть проблемы 
3. Причина проблемы
4. Решение проблемы
5. Меры по обнаружению и исправлению у Заказчиков
6. Более подробная информация

Как я к этому пришла

Мне лучше думается, когда я выношу мысли на бумагу. Или в ноутбук, так тоже работает. Хотя, когда надо именно подумать, я беру простую бумагу, ручку, и пишу. Или рисую. Вроде как даже научно доказано, что при печатании и написании от руки включаются разные участки мозга.

Когда баг нашел Заказчик, а не я, я сидела и размышляла — «Почему я его не нашла? Что можно сделать, чтобы такое не повторялось?». Размышлялось мне плохо, в голове был сумбур. Чтобы его упорядочить, я создала шаблон с вопросами, на которые надо ответить. И стала его заполнять!  

Каково же было мое удивление, когда в одной из задач я обнаружила, что проблему решили локально, но ничего не сделали для того, чтобы она не повторялась. Вот как в примере с фотографией. В рамках исследования выяснилось, что аватарка большая была установлена до ввода ограничений. Мы исправили конкретно эту аватарку.  

И ээээээ... И чего?  (o_O) Она ведь может быть не единственной такой! И даже не у одного заказчика, а у разных. Раз раньше ограничение больше было, вполне могли загрузить.  

Почему не проверялось, есть такое или нет? Почему нет системного исправления? 

Начала думать, как это проверить. Поговорила с разработчиком, как лучше исправить. В итоге поставили задачу на задачу миграции. А если бы не шаблон, так бы и продолбалось, потом опять выстрелило бы где-нибудь. ¯\_(ツ)_/¯ 

Работает шаблончик то! 

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

Сравните:


— Пользователь ввел 101 и система упала. Что за фигня?!
— Ну не знаю, я вроде тестил..
— Почему пропустил?
— Не подумал о такой проверке...
— Так, ребята, в следующий раз тестируем лучше!


и


— Пользователь ввел 101 и система упала. Почему мы такое пропустили?
— Ну не знаю, я вроде тестил..
— А какие сценарии проверялись?
— Я вводил 1, 10 (среднее в интервале), 100 (максимум).
— А за границами интервала?
— Нет, а зачем? Допустимый же только 1-100.
— Угу, но видишь как упало все. Так что стоит проверять не только внутри интервала, но и за его пределами. Пополни чек-лист стандартных проверок. Ах да, еще поиск технологической границы туда добавь. Вообще давай вместе проревьюим этот чек-лист, устарел, наверное...

«Ой, я продолбал, надо тестировать лучше» — слишком абстрактно. Надо копнуть чуть дальше. Это не всегда получается, если держать все в уме. Отвлекли — и ты уже забыл, на чем остановился. А записал — запомнил!

К тому же я успела с десяток проблем так описать. Это очень пригодилось, когда кто-то спрашивал в чатике «а у вас уже было похожее?». А ты такой ХОП — и даешь ссылку на описание проблемы, где вся информация в сжатом виде, не надо читать все 50 комментариев в реальной задаче.

Когда метод НЕ работает

Когда я рассказывала о своем методе коллеге на SQA Days (в кулуарах, это не доклад был), он отнесся к нему весьма скептически:

— Ты публикуешь разбор прямо в конфлюенсе, где все его видят? Ты что! Так вообще никто делать не будет, публично признаваться в своих косяках? Да их потом премии лишат за такое, зачем показывать менеджеру, где ты налажал? Я сам как менеджер иногда такое делаю чисто для себя, но держу в закрытом доступе все размышления.

Сначала я слегка офигела от его слов. Мне даже в голову не приходило, что надо бояться рассказывать о решении проблемы. Что тебя могут наказать за то, что ты нашел это решение — ведь исходно ты проблему пропустил, редиска! Или не ты, а твой коллега — и тогда ты подставишь его таким анализом.

Потом я подумала: «Какая же у меня классная работа! Раз я даже не думала о том, что тут надо чего-то стыдиться». Мы не ищем виноватых, мы думаем, как не пропускать такие баги в дальнейшем.

Но ведь это важно! Команда должна учиться на своих ошибках. Иначе так и будут наступать на одни и те же грабли: сломалась система при вводе нуля, тестировщик подумал «блин, надо тестировать лучше», но чек-лист проверок пополнять не стал. Потом снова сломалось в нуле уже в другом месте и вот уже новый тестировщик чертыхается "как я мог об этом забыть", и снова ничего не делает... И так по кругу.

И ладно еще когда надо просто записать чек-лист проверок на будущее. А если забыли исправить саму причину ошибки? Исправили лишь локальное проявление и на этом успокоились, «работает — не трогай»? Значит, этот баг снова выстрелит, а оно вам надо?

Резюме

Письменный анализ по шаблону — это:

1. Чек-лист «а не забыл ли я подумать вот о чем?». Он помогает не забыть копнуть чуть глубже и понять, что надо сделать, чтобы ошибка не повторялась.
2. Краткое описание проблемы и решения, которое можно скинуть коллеге, если у него похожий случай.

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

Анализируйте баг методом «5 почему», ищите корень зла. И исправляйте именно его. Причем задумавшись: «А нет ли такой же проблемы в уже существующих базах? Может, нужна какая-то задача миграции?»

А после исправления подумайте, как не пропускать такие баги:

• Если налажал новичок — возможно, где-то что-то не объяснили. Надо провести обучение или отправить его на курсы.
• Если налажал старичок — тем более важно подумать, почему. Может, проверять надо столько всего, что без чек-листа какие-то пункты продалбываются. В целом он знает, что это надо проверять, но тут вылетело из головы. И тогда надо записать чек-лист проверок.

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

«Важно не то, сколько раз ты упал, а то, сколько раз поднялся» © Если вы будете учиться на своих ошибках, то это круто! Ошибаются все, а вот выводы делают немногие.

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

PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков