Вторая статья из цикла «Один день в жизни тестировщика». В предыдущей статье мы говорили о планировании. В этом примере мы рассмотрим, чем занимается тестировщик в самый разгар итерации.

Контекст:

• проект разработки портала спортивных новостей;
• методология – Scrum;
• 5 программистов и 2 тестировщика;
• итерации продолжительностью 2 недели;
• все работают в одной локации;

Первый день второй недели. После утреннего митинга, обсуждения прошедших активностей и планов на текущий день все усаживаются на рабочие места. Тестировщики проводят между собой Debrief, чтобы определить, кто какую задачу берет на себя.

После согласования, оба приступают к тестированию своих User Story.

Первый тестировщик приступил к работе, используя Acceptance Test как отправную точку для проведения тестирования. Он использовал этот сценарий как некий маршрут для прохождения по новым частям системы, но при этом не забывал смотреть «по сторонам». В один момент он столкнулся с непредвиденным поведением системы, что ввело его в ступор.

Все 5 попыток повторить действия не увенчались успехом. Напористость тестировщика не позволила ему оставить эту проблему и он позвал второго тестировщика, с просьбой помочь разобраться в проблеме. Спустя минуту, коллега подвинул стул и внимательно выслушал ситуацию. Ребята решили сделать небольшой анализ проблемы и составить некий план, по которому нужно будет найти пути воспроизведения ошибки

Первый тестировщик принялся за тестирование. В это же время второй следил за действиями первого, пытаясь найти новые идеи. Первый тестировщик открыл файл настроек, где изменил параметры пересчета цены. Затем открыл UI часть системы, залогинился, добавил новый товар в систему, зашел под аккаунтом обычного пользователя и совершил две покупки. Проверка оказалась успешной – проблема не была найдена.

«А что если теперь изменить настройки module2 с указанием аналогичных значений и проверить операцию суммирования еще раз с новым созданным товаром?» – предложил второй тестировщик.

Решили осуществить проверку, но опять-таки получили успешный результат. Проверка платежной системы заняла 10 минут, но им все таки удалось найти ошибку и stacktrace в файле логов, где должны собираться все совершенные платежи. Первый тестировщик просто не посмотрел в этот файл, когда тестировал в одиночку, соответственно не смог выявить, на каком шаге возникла ошибка.

С этим сообщением оба тестировщика обратились к программисту, который отвечал за реализацию этой задачи. Программист откликнулся и попросил дать ему stacktrace, чтобы понять причину ошибки. Спустя несколько минут, покопавшись в коде, программист сказал, что в логике не учтена ситуация совершения платежа пользователем с негативным балансом на счету. Также он отметил, что должна быть добавлена валидация на эту ошибка и написан интеграционный тест, который сможет верифицировать эту логику.

Тестировщики спросили: “Сколько времени займет, чтобы исправить это?”
«По оптимистическим оценкам – 30-50 минут» – ответил программист.

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

В чем мораль этой истории?

Работая в паре, можно выявить ошибку значительно быстрее, чем пытаться разобраться самому. Узнав у разработчика дополнительные детали, можно описать дефект таким образом, чтобы больше не возникало уточняющих вопросов.

Какие ошибки допустил первый тестировщик в своей работе?

Он тестировал невнимательно, случайным способом, соответственно не смог сказать, в чем именно заключалась найденная проблема.

Как он смог быть решить эту проблему самостоятельно за 5 минут?

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

Дайте свое виденье разрешения проблемы. Как в будущем избежать потерю времени?

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!