Если на готовом сайте обнаруживается ошибка, то тестировщику, выполнявшему ее проверку, весело не придется.
Данная статья посвящена описанию действий, которые помогут тестировщику устранить дефекты на готовом сайте и научат предотвращать появу таковых в дальнейшей работе.
Действие 1. Никакой паники, только спокойствие
Понятное дело, что человек, тестировавший продукт и затем передавший его в релиз, начнет переживать, если на онлайн-окружении обнаружится дефект. В мыслях тестировщика сразу же появляется вопрос: «Как такое могло случиться?».
Начинается анализ своей работы, нацеленный на поиск ответа. Однозначно, такое решение не является эффективным.
В первую очередь, необходимо убедится, что дефект устранен. Если вами будет управлять паника, то вы, мало того, что не сможете этого сделать, но наоборот, не проведете исследование и тестирование до конца.
Действие 2. Воспроизведение дефекта
Если о наличии дефекте на готовом сайте сообщил заказчик или другой сотрудник вашей команды, сразу же попытайтесь его воспроизвести. Может, это ошибка пользователя или проблема конфигурации.
Проверьте, выполнили ли вы все шаги, заданные пользователем и, если возможно, убедитесь, что вы используете то же программное обеспечение и аппаратное обеспечение, что и заказчик (пользователь).
Например, откройте продукт на смартфоне того же типа и используйте ту же сборку. Если проблема не воспроизводится, подайте запрос на получение дополнительных данных и пробуйте дальше.
Действие 3. Постарайтесь получить максимум информации
После воспроизведения ошибки, попытайтесь узнать всё об этой проблеме: воспроизводится ли она в предыдущей сборке, воспроизводится ли на тест-стенде, возникает ли она в определенном браузере (операционной системе, нужны ли конкретные параметры конфигурации для ее воспроизведения и т. д. Чем больше данных вы узнаете, тем скорее дефект будет исправлен разработчиками.
Действие 4. Найдите причину
Разработчик уже активно работает над определением причины возникновения проблемы.
Ваша задача, как тестировщика, после того, как первопричина будет найдена, обязательно узнать, что это было и понять, как так произошло. Только так вам будет ясно, как тестировать исправленный дефект и какие тесты лучше использовать.
Алгоритм действий в подобной ситуации
Действие 5. Определите, когда исправлять ошибку
Когда дефект обнаруживается на готовом сайте, хочется как можно скорее его исправить, но это не всегда правильно. Часто случается так, что исправление одной ошибки порождает возникновение новых. Изначально, необходимо проверить все сферы, на которые мог повлиять этот дефект.
Прежде чем приступать к исправлению, определите, сколько пользователей затронуто и какого масштаба проблема.
Может быть, дефект затронул всего 1% пользователей, но если он серьезный и их возможности пользоваться продуктом ограничены, может быть, его необходимо исправлять немедленно.
Или второй вариант: проблема касается всех пользователей, но она настолько мизерная, что на эксплуатацию приложения не влияет.
Действие 6. Протестируйте исправление ошибки
Тестируя исправленную ошибку, делайте это несколько раз. Проверьте все возможные для использования устройства и браузеры, затем выполните регресс-тесты в тех местах, которые могли повлиять на код.
Если вы добросовестно выполнили действие 4, то знаете, какие области следует проверить. И, напоследок, правильным будет провести дымовой тест для того, чтобы убедится, что функционал приложения не нарушен.
Действие 7. Анализ ситуации: «Почему это случилось?»
Когда дефект на готовом сайте исправлен, тестировщик может вздохнуть с облегчением. Но есть очень важный момент: нужно проанализировать ситуацию и постараться определить, как проблема попала на готовый сайт.
Основная задача здесь не найти виноватых, а просто понять, как это произошло, чтобы в будущем такого случая больше не было.
Может, разработчики внесли правки в код, а вас не поставили в известность, поэтому исправления и не проверялись.
Может, вы, тестируя опредленную функцию сайта, не проверили все браузеры и в одном из них проявился дефект. Это уже не важно, главное, убедитесь в том, что вы правильно донесли проблему своей команде.
Действие 8. Мозговой штурм как вариант предотвращения подобных проблем
Когда причина появления ошибки на готовом сайте раскрыта, стоит разработать стратегии, как избежать подобного в дальнейшем. Естественно, лучше всего это сделать с командой.
Может, изменений требует процесс: например, по каждой функции сайта владельцу продукта необходимо давать отмашку для убеждения в том, что упущений нет. Либо нужно узнавать о любом изменении в коде разработчиками, даже если по их убеждениям, ничего не поменялось.
Может, нужно менять стратегию работы: если одну функцию будут проверять два тестировщика, меньше вероятность допустить ошибку.
А может, следует изменить и процесс, и стратегию.
Оставить комментарий