Тестировщики, как и любые люди, не застрахованы от ошибок. Сегодня мы расскажем о наиболее распространённых ошибках тестировщиков, а также о том, как их можно избежать.
Проблема 1. Тестировщик видит баги везде, даже там где их нет.
Очень частая ошибка тестировщиков — когда тестировщик заводит ошибки на всё, что ему не понравилось. Да, заводить ошибки — это часть работы тестировщика, но он не должен этого делать необдуманно.
Каждая система имеет свои особенности. И не всегда логика системы, описанная в требованиях, будет совпадать с логикой отдельно взятого тестировщика. Тестировщик должен знать все особенности системы, которую он тестирует. Ведь всякая ошибка, заведённая тестировщиком, попадает на анализ к аналитику или разработчику. Он тратит время на её воспроизведение, анализ проблемы. Как думаете, им понравится ежедневно обрабатывать ошибки тестировщиков, которые по сути ошибками не являются? Нет. У них и без этого полно работы.
Как этого избежать?
- Когда вы увидели ошибку — воспроизведите её ещё раз. А лучше 2-3 раза, чтобы убедиться, что она действительно воспроизводится и разработчик тоже сможет её воспроизвести.
- Не бросайтесь сразу заводить ошибку. Проведите анализ: действительно ли данное поведение системы некорректно? Найдите требования по этой части системы. Если зафиксированных требований нет, обратитесь к аналитику или, если аналитика нет, к разработчику за разъяснением как должна система работать правильно.
И только убедившись, что это действительно ошибка — заводите её.
Проблема 2. Тестировщик пропускает ошибки.
Это тоже довольно распространённая проблема, когда тестировщик тестирует доработки “поверхностно”, без какого-либо плана. То есть он получил задачу на тестирование, проверил основные моменты и, не углубляясь в задачу, пропустил её дальше. Всё, задача проверена, ошибок нет. Но это неправильно. Как справиться с этой проблемой?
- Тестировщик, получив задачу на тестирование, не должен сразу бросаться сломя голову её тестировать. Сначала нужно провести анализ. Нужно изучить требования, что вообще было реализовано, как оно должно работать. После этого необходимо составить план тестирования задачи. Для этого можно просто написать чек-лист: какие именно проверки будут выполнены в рамках тестирования. На каждое требование — минимум 1 проверка.
- Не забывайте и про негативные проверки. Пользователям, как и всем людям, свойственно ошибаться. Система должна корректно обрабатывать все ошибки.
- Также не забывайте про регрессионное тестирование. Уточните у разработчика что могла задеть его доработка, какие части системы нужно дополнительно проверить. Также используйте личный опыт и знание системы. Помните, что любое изменение в коде может повлечь за собой возникновение новых ошибок в ранее корректно работавших частях системы.
Проблема 3. Тестировщик не заводит найденные ошибки.
По сути, эта проблема — деградация тестировщика как специалиста. Периодически она возникает потому, что ошибки найденные тестировщиком часто оспариваются. И не потому что это не ошибки, а потому что по мнению аналитиков, разработчиков, а иногда и заказчика, они низкого приоритета. И тестировщик, регулярно слыша, что эта ошибка никому не мешает, её никто не заметит, её никто не будет править, просто перестаёт заводить часть найденных ошибок. И это плохо.
Это плохо потому, что некоторые не заведённые ошибки могут таки оказаться важными. Но тестировщик их пропустил, не завёл, а когда на них наткнулся заказчик и задал вопрос “чем вообще занимаются тестировщики?”, огрёб по шапке от начальства. Заведённые дефекты — это страховка для тестировщика. Тестировщик обязан сообщать обо всех ошибках в системе. Это его работа. А править эти ошибки или нет — решают уже другие. И в случае чего, по шапке будет получать уже не тестировщик, а тот, кто не передал ошибку разработчику для исправления. Поэтому не деградируйте, не подстраивайтесь под окружающих, если это может дискредитировать вас как специалиста.
Проблема 4.Тестировщик плохо описывает ошибки.
Если тестировщик плохо описывает ошибку, то разработчик не сможет её быстро воспроизвести. Или не сможет воспроизвести вовсе, потому что не знает нюансов, которые нужно соблюсти для её воспроизведения. В обоих случаях разработчик может отклонить ошибку, потому что он просто её не понял. И начинается “перекидывание” задачи от разработчика к тестировщику и обратно. Это, естественно, занимает лишнее и довольно большое время, которое разработчик мог бы потратить на исправление ошибки, а тестировщик — на тестирование других задач.
Как этого избежать? Тестировщик должен грамотно заводить ошибки.
- Нужно описать предусловие, где будет чётко указано в каком состоянии должна находиться система для того, чтобы ошибка воспроизвелась. Здесь нужно указать под каким пользователем воспроизводится ошибка, если для её воспроизведения пользователь должен быть авторизован в системе. Дать ссылку на страницу, которая должна быть открыта для того, чтобы можно было начать выполнять шаги воспроизведения ошибки, указать версию приложения, операционную систему и прочие условия, которые необходимо соблюсти перед тем как начать воспроизводить ошибку.
- Чётко описывать шаги воспроизведения. Последовательно, шаг за шагом указать куда нажать, что ввести. Выполнено действие в системе — описан шаг. Действие — шаг.
- Нужно чётко указать фактический результат. То есть описать к какому результату приводят описанные шаги воспроизведения. Не просто написать “возникла ошибка”, а расписать как именно выглядит эта ошибка, что именно происходит в системе. Как можно более однозначно.
- Также нужно указать ожидаемый результат: как должна повести себя система в этой ситуации. Это опять же очень поможет разработчику как можно быстрее исправить ошибку, так как он будет знать как именно должна отработать система в этой конкретной ситуации.
- При описании ошибок очень помогают скриншоты и видео с экрана, где видны шаги воспроизведения ошибки. При этом на скриншотах и видео нужно выделять места, на которые нужно обратить внимание, чтобы было понятно куда вообще смотреть.
Правильному оформлению дефектов на практике у мы учим на нашем курсе “Тестирование ПО. Начальный уровень”.
Проблема 5. Тестировщик не задаёт вопросы когда ему что-то не понятно.
Эта проблема из категории “Я сам!”. Самостоятельно разобраться — это хорошо, никто не спорит. Только здесь есть одно “Но”. На работе, если вы будете долго сидеть над задачей и не будет никакого прогресса, к вам подойдёт начальник и спросит об успехах. И если успехов нет и при этом вы ни к кому не обращались за помощью — это минус к вашей карме. Потому что вам платят за работу, а не за попытки её выполнить. У каждой задачи есть определённый срок, к которому она должна быть завершена.
Как этого избежать? Если вам попалась задача, которая не понятна, не стесняйтесь попросить помощи у старших товарищей. Вполне вероятно, что вам за 5 минут на пальцах расскажут то, над чем вы корпели целый день и так и не смогли понять. Или дадут документацию, которая снимет все ваши вопросы.
Проблема 6. Но есть и другая сторона медали, когда тестировщик задаёт слишком много вопросов.
По любому поводу тестировщик задаёт сотню вопросов. Даже те, ответ на которые он получил день назад. Тут могут быть различные причины почему человек так поступает: он не запоминает информацию, ему проще спросить, чем прочитать документацию и тд. Только этот человек не учитывает того, что своими бесконечными вопросами он не даёт работать другим.
Что можно сделать, чтобы не переборщить с вопросами?
- Когда вы получили задачу — сначала прочитайте доступную документацию.
- После того как вы прочли документацию — составьте список возникших вопросов
- Подойдите с этим списком к вашим коллегам из тестировщиков. Возможно, у ваших коллег уже есть знания по этим вопросам. Или вам смогут посоветовать какую-то дополнительную документацию.
- Если внутри группы знаний нет, или вы единственный тестировщик, то подойдите со списком вопросов к аналитику. Аналитик должен знать ответы на них. Если аналитика нет или он не знает ответа на какие-то вопросы, то обратитесь к разработчику.
- Самое важное — задокументируйте все полученные ответы, чтобы в будущем, когда полученные знания выветрятся из головы, не идти с теми же самыми вопросы по второму, а то и третьему кругу. А также, чтобы вы могли помочь вашим коллегам, если у них возникнут те же самые вопросы. Лучше всего для этих целей вести единую базу знаний, куда будет иметь доступ любой заинтересованный сотрудник вашей компании.
Это основные ошибки, которые допускают как начинающие, так и довольно опытные тестировщики. Надеемся, что наши советы помогут вам их избежать.