Перевод статьи «This Scenario Explains How Important It is to Document the Frequently Encountered Errors».
Верите ли вы, что ошибки в программном обеспечении возникают только один раз, и после исправления они больше никогда не появляются? Я считаю, что около 30% ошибок повторяются.
В этой статье я хочу рассказать о том, как важно документировать часто встречающиеся ошибки.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Сценарий №1
Код развернут и готов к тестированию. Джон, тестировщик, уже приготовил необходимые тест-кейсы. В процессе тестирования он столкнулся с проблемой. Ему показалось, что она была замечена несколько раз ранее, но Джон не знал, как ее решить.
Джон и Шерил пошли искать Смита, который встречал эту же ошибку ранее и решил ее. К сожалению, Смит в тот день был в отпуске.
Что теперь делать Джону? Должен ли Джон попытаться связаться со Смитом, чтобы найти решение, даже если Смит недоступен?
Эта ситуация говорит о том, что если какая-то проблема неоднократно встречается в нескольких релизах, хорошей практикой будет документировать детали ошибки и ее решения , а также размещать их в общем доступе. Это устранит зависимость от одного человека и поможет всем членам команды самостоятельно найти решение в случае необходимости.
Сценарий №2
Джон тестирует новый релиз и снова сталкивается с известной ошибкой. На этот раз он знает, что в одном из прошлых релизов был создан баг-репорт. Но возникает вопрос: “Как мне найти именно нужный баг-репорт?”.
Как вы думаете, что поможет Джону в этом случае?
- Поиск дефекта в инструменте отслеживания дефектов по его описанию?
- Поиск всех прошлых баг-репортов?
- Обращение за помощью к руководителю команды?
Все эти варианты возможны.
Но, на мой взгляд, если подобные проблемы хорошо задокументированы в отдельном разделе и предоставлены команде, это приносит большую пользу и экономит время.
Области, в которых часто возникают ошибки
1. Файл параметров – Основываясь на своем опыте работы, во многих случаях я замечал, что файл параметров указывал на неправильное подключение к БД. Это многократно приводило к одним и тем же проблемам. Основной причиной было то, что соединение было общим для dev и QA. Поэтому файл параметров всегда нужно было обновлять в соответствии с потребностями, чтобы избежать ошибок.
2. URL, указывающий на неправильную БД.
3. Проблемы с доступом – Тестировщики сталкиваются с проблемой, когда у них недостаточные или неправильные права доступа к БД. В этом случае документ, описывающий шаги, которые необходимо предпринять для подключения, был бы очень полезен.
4. Проблемы с тестовыми данными – использование неправильного формата или значений тестовых данных чаще всего приводит к проблемам.
5. Проблемы с БД – DB connection timed out является одной из таких распространенных проблем. Некоторые простои являются временными, запланированными, а иногда нам может понадобиться помощь DBA (Database administrator).
Большинство повторяющихся ошибок, как правило, связаны с проблемами тестовой среды.
Однако проблемы с кодом нельзя игнорировать. Приведенные выше пункты являются общими и не включают проблемы кода, поскольку проблемы кода более специфичны для конкретного приложения, фреймворка, языка программирования и т.д.
Причинами дефектов также могут быть ошибки ввода данных.
Преимущества документирования ошибок
1. Устранение зависимости – В сценарии 1 Джон был зависим от Смита в решении проблемы. Если бы существовал документ, который помог бы Джону, этой зависимости не было бы.
2. Более быстрое выполнение – Возьмем сценарий 2. Тестировщику не пришлось бы просматривать весь список уже зарегистрированных дефектов, если бы существовал специальный документ для часто встречающихся проблем.
3. Помощь новым членам команды в развитии навыков самостоятельности.
Заключение
Документировать часто встречающиеся проблемы определенно является полезной практикой, так как этот документ станет очень ценным справочником в будущем.
Документирование во время выполнения теста может стать утомительным занятием, но в качестве лучшей практики можно делать черновые записи во время выполнения, которые позже можно обобщить и обновить в общих документах.