Быть тестировщиком - это не просто найти ошибку

В команде должны быть не «моя работа» и «ваша работа», а «наша работа».
Как команда разработчиков программного обеспечения, мы стремимся создать идеальную систему, на которую мы способны. Быть тестировщиком не означает просто найти как можно больше ошибок, чтобы доказать, что разработчик делает что-то неправильно. Вместо этого он выпускает стабильный продукт с минимальными проблемами. Также, чтобы быть в курсе почти всех дефектов, с которыми команда согласилась запустить.

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

1. Помогите предотвратить ошибки

Разработчик не тестировщик, поэтому им может потребоваться ваша помощь, чтобы предотвратить ошибки и протестировать свою работу, прежде чем сказать: «Я готов».

Один из принципов гибкого тестирования - «предотвращение ошибок вместо их поиска».

Действия, которые помогают предотвратить ошибки:

  1. Обсудите масштаб истории и убедитесь, что вы оба понимаете масштаб истории, как и ожидалось.
  2. Просмотрите истории перед тем, как начать фазу разработки, и отметьте все отсутствующие критерии приемлемости.
  3. Дайте разработчикам идеи, которые помогут им писать эффективные модульные тесты.
  4. Поделитесь своими тестовыми примерами с разработчиком на этапе разработки.

2. Когда сообщать об ошибке

Что такое ошибка?

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

А отчет об ошибке - это способ сообщить разработчику, что часть кода ведет себя не так, как ожидалось или задумано.

Как тестировщик, прежде чем сообщать об ошибке, проверьте следующее:

  1. Понять масштаб истории.
  2. Не сообщайте об усовершенствовании как об ошибке.
  3. Свяжите ошибку с нужной историей.
  4. Не включайте в отчет более одной ошибки.
  5. Убедитесь, что о проблеме еще не сообщалось.

3. Как сообщить об ошибке

Мы все согласились с тем, что должна быть разница между проблемой, о которой сообщает конечный пользователь, и проблемой, о которой сообщает тестировщик.

Время, необходимое разработчику для решения проблемы, иногда зависит от того, как было сообщено об ошибке! Если вы потратите больше времени на отслеживание проблемы и отправите хороший отчет об ошибке, это сократит время, затрачиваемое на ее решение.

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

Отчет об ошибке должен содержать следующее:

  • Название (краткое описание дефекта)
  • Предварительное условие при необходимости
  • Среда
  • Приоритет и серьезность
  • Действия по воспроизведению
  • Ожидаемый результат
  • Фактический результат
  • Вложения

4. Напишите воспроизводимый отчет об ошибке.

Иногда разработчик не может воспроизвести воспроизводимую проблему. Вы можете пропустить детали, которые помогут разработчику воспроизвести и отладить, включая следующее:

  1. Отладка в другой среде (тестировщик не использует ту же среду, которую отлаживает разработчик).
  2. Разные данные (тестер использует один набор, а разработчик - другой при отладке).
  3. Проблема связана с ресурсами вне самого приложения (например, мало места в памяти или низкое энергопотребление).
  4. Иногда это из-за запутанного отчета об ошибке!

Когда вы говорите «сбой происходит, когда вы открываете профиль клиента», это не то же самое, что «сбой происходит, когда вы открываете профиль клиента с данными X», поскольку профиль клиента не имеет данных X, и это не значит. не вылететь!

Как правило, разработчик программного обеспечения не сомневается в вас, но ему необходимы шаги, предпринятые для устранения дефекта.

Некоторые моменты, о которых следует помнить, сообщая о проблеме:

  1. Напишите хорошее описание ошибки
    Идеальное название - ясное, короткое и дает разработчику краткое изложение того, в чем заключается ошибка.
  2. Будьте максимально конкретными и не допускайте двусмысленности.
  3. Повторите ошибку трижды, прежде чем писать отчет об ошибке.
    Если вы упомянули, что это произошло три раза, это должно означать, что вы проверили ошибку с разными данными и способами, и все они не работают, т.е. все вызывают одно и то же. проблема.
  4. Если вы нашли обходной путь, укажите его.
  5. Убедитесь, что вы установили подходящий приоритет.
    Поймите, какие бои стоит драться, а где можно отпустить. В противном случае каждый будет тратить много времени на исправление не столь важных вещей.
  6. Не вините.
  7. Прочтите отчет об ошибке, прежде чем нажимать кнопку отправки.

5. Помогите разработчику отследить проблемы конечного пользователя.

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

Конечный пользователь сообщает о следующих типах проблем:

  1. Группа по контролю качества уже сообщала о проблеме, но она была лишена приоритета и решена не исправлять до запуска.
    Это лучший случай! Нам просто нужно изменить приоритеты, если несколько пользователей сообщают об этом как о досадной проблеме.
  2. Простая проблема, о которой вы, как тестировщик, не заметили.
    Сообщите об этом. Тогда спросите себя, почему вы это пропустили? И постарайтесь не допустить повторения этого снова!
  3. Проблема, которая возникает только с этим пользователем (с конкретными данными).
    Если это не происходит, за исключением упомянутых данных / варианта использования / пользователя, нам нужно знать, почему и чем они отличаются от тех, которые вы используете при тестировании. . И применимо ли иметь такой же вариант использования в тестовой среде. Если нет, обязательно поднимите флаг и при необходимости обратитесь за помощью к команде.
  4. Проблема с отсутствующими деталями
    Если вы не можете воспроизвести, используя те же данные и ту же среду, здесь возникает вопрос: нужны ли вам дополнительные сведения?
    Если да, попросите об этом.
  5. Если дополнительных сведений нет, здесь нам нужно научиться как сообщить о невоспроизводимом дефекте!

Что, если это была непоследовательная проблема, которая произошла всего один раз, и вы, как тестировщик, не можете воспроизвести ее снова?

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

Я считаю, что любая проблема / проблема несоответствия является проблемой в программном обеспечении, и причина проблемы не была определена. Даже если вы не можете воспроизвести проблему, и это уже заняло у вас много времени, нам все равно нужно сообщить о ней, чтобы продолжить отслеживание, и после этого мы сможем получить шаги для ее устранения!

Проблемы такого типа нельзя игнорировать, так как конечный пользователь / заказчик тоже может их заметить, но вы должны знать, когда продолжать поиск, а когда прекратить поиск.

6. Как сообщить о невоспроизводимом дефекте?

  1. Создайте для него билет [Расследование].
  2. Укажите количество воспроизведений.
  3. Включите точные данные, использованные во время тестирования.
  4. Добавьте вложения, если были.
  5. Встретьтесь и обсудите это с другим QA-инженером, а затем, если необходимо, с разработчиком.
  6. Упомяните о влиянии (статусе риска) этой проблемы.
  7. Добавьте журналы, если они есть. Возможно, что журналы могут содержать некоторую информацию, которую разработчик может использовать для воспроизведения проблемы в системе.

Заключение

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

Не имея возможности воспроизвести ошибку, разработчики спотыкаются в темноте.