Мы практически каждый день репортим/создаем/вносим баги/кейсы/ишью, но порой забываем, то что когда-то нам рассказывали или мы читали, учили. А может нам просто некогда иногда в спешке задумываться о многих банальных вещах, которые всё таки важны в нашей работе. Тем более когда сроки поджимают, когда надо успеть много и когда ты разрываешься между задачами. Тем не менее перечитать иногда (например раз в месяц) и напомнить себе и коллегам о том каким же всё таки должен быть хороший баг репорт, я думаю стоит. Тем более что занимает это не больше чем просмотр 10 минутного видео или чтение "Баша".К примеру, у вас есть популярный ресурс онлайн-казино http://www.play-vulkan-klyb.com/ и конечно вы заинтересованы в его правильной и актуальной работе - чем более стабльно он будет себя вести, тем больше посетителей сыграют в игровые автоматы на нем. Вот по этому и нужно смотреть на отчеты по работе.
И так по порядку, прежде всего стоит помнить, что описание ошибки должно иметь 3 вещи:
- Что привело к ошибкам.
- Что ожидали.
- Что получилось.
Из всех материалов, перечитанных мною в последнее время я выделил несколько моментов которые мне кажутся Важными, несколько Советов, которых стоит придерживаться при работе с баг-репортами, несколько принципов, которыми стоит руководствоваться. А так же отметил для себя некоторые интересные обоснования, с психологической точки зрения тех моментов, когда мы (тестеры) ведем себя тем или иным образом. Может быть понимание этих вещей поможет нам проявить себя в лучшем виде в эти самые моменты.
Обо всем по порядку.
И так, то что важно:
- Потратьте некоторое время, чтобы убедиться, что найденная вами бага ещё не внесена в BTS.
- Вносите ошибку сразу как только она обнаружена, насколько бы феноменальной память у вас не была.
- Не ленитесь убедиться в повторяемости и актуальности ошибки (перезапустить всё что можно перезапустить).
- Соберите всевозможную дополнительную информацию о возможных причинах, закономерностях, различиях в средах воспроизведения вплоть до личных предположений и т. д.
- Исключайте лишние действия (минимизация описания ошибки).
- Детально описывайте все входные (вводные) данных вплоть до мельчайших подробностей.
- Будьте конкретны — одно и тоже действие можно воспроизвести по разному, кликнуть на кнопку или использовать хоткей, иногда это очень важно.
- Прочитайте сами то, что написали, попробуйте воспроизвести так как написано, чтобы убедиться в понятности описания.
- Не забывайте об Описании ошибочного поведения. Что именно является ошибочным и почему и т. д.
- Не забывайте об описании ожидаемого поведения, а так же его обоснования (ссылка на требования, примеры, аналоги, какие-либо подтверждения правильности ожидаемого поведения, одним словом аргументы).
Несколько Советов, на мой взгляд актуальных в нашей работе:
- Закрыть ошибку может только тот, кто её увидел и внёс (открыл) ( ИМХО об этом стоит прописать в правилах использования любого багтрека).
- Необходимо по возможности всегда использовать контроль версий (в BTS).
- Стоит опускать предположения, но не опускать факты (опускать диагноз, но не опускать симптомы).
- Опишите, почему вы считаете, что то что вы увидели — неправильно (этот пункт пересекается с описанием ошибочного поведения).
- Храните по возможности всю доп. информацию об ошибках у себя (если позволяет время и тех возможность). Эта информация может понадобиться разработчикам, в случае если вы по своему мнению что-то упустили в описании баги.
- "Попробуйте выработать рефлекс — если компьютер делает что-то неожиданное — замереть." (Когда что-то происходит неправильно, сразу прекратите делать что бы то ни было).
- По возможности описывайте альтернативные способы воспроизведения баги. Это даст дополнительную пищу для ума в исследовании баги программистом.
- По возможности указывайте ссылки на требования. (Пункт смежен с описанием ожидаемого поведения).
- Постарайтесь убедиться что это ошибка именно тестируемого приложения, а не ошибка тестера или другого приложения.
- Одна бага это одна проблема, один кейс и одно в багтреке. Избегайте описания нескольких проблем в одном репорте.
Принципы, которые объединяют в себе советы и важные моменты перечисленные выше (как бы взгляд с другой стороны):
- Простота(одна проблема — один репорт, не поленитесь учитывать психологию программиста, который будет заниматься проблемой (если знакомы лично), громоздкий отчет всегда вызывает желание отложить его на потом.)
- Понятность (суть проблемы должна быть описана кратко и чётко, а путь воспроизведения должен быть минимальным. Для этого необходимо проводить дополнительный анализ проблемы.)
- Воспроизводимость (этот фактор очень важен, порой даже является решающим, для того чтобы программист вообще занялся это проблемой, изучил её и исправил)
- Разборчивость (на мой взгляд сходное значение с понятностью в данном аспекте).
- Беспристрастность (будьте деликатнее в ваших отчетах, ни в коем случае не оценивайте работу программиста, исключите всякое проявление предвзятого отношения в отчетах)
Анализ проблемы
Цели:
- Выявить наиболее серьёзные последствия проблемы — возможно обнаруженная вами проблема может влечь за собой более серьёзные последствия чем кажется на первый взгляд. Программа перешедшая в состояние сбоя, может повести себя дальше абсолютно непредсказуемо.
- Найти простейший и кратчайший путь воспроизведения — увеличивает вероятность исправления ошибки.
- Найти альтернативные действия, приводящие к тому же результату - это заставит обратить на проблему больше внимания, тем более когда альтернативный способ воспроизведения содержит более привычные действия пользователя.
- Выявить связанные проблемы — проблемы которые могут возникать в похожих разделах программы или при похожих действиях пользователя.
Интересные психологические моменты:
- Завышение приоритетов баг на поздних стадиях проекта. Является своего рода психологическим последствием приближающейся сдачи проекта или крайних сроков, либо же попытка компенсировать сложность обнаружения весомых дефектов, потому как чем дольше проект в разработке тем сложнее обнаруживаются дефекты.
Добавить пост 