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

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

Должен ли я ожидать от них большего, чем «ваше ПО рухнуло, когда я нажал кнопку», или я должен понять, что случилось?

РЕДАКТИРОВАТЬ:

Один из моих коллег отметил, что мы, вероятно, все разработчики, поэтому результаты могут немного пострадать

QA всегда должен стараться сделать ошибки максимально легкими для воспроизведения, и описание ошибки должно содержать предпринятые шаги.

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

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

Похоже, что ваш отдел QA проводит слишком много предварительных испытаний (т.е. у них нет хорошего плана тестирования).

Поисковое тестирование хорошо, и выявляет проблемные области, но оттуда они должны определить воспроизводимые тестовые наборы (т. Е. План тестирования) для выполнения, которые выявят конкретные ошибки.

Существует ряд причин, по которым необходимо правильное воспроизведение (не только хорошее, но и необходимое):

1. Вы должны повторить, чтобы вы могли отладить / отследить причину.
2. QA должен будет иметь возможность проверить исправление, как только вы закончите.
3. Дальнейшие тестовые проходы должны будут сделать регрессии на предыдущих ошибках.
4. Известные ошибки могут быть сброшены, если экспозиция слишком мала или слишком маловероятна.

Итак, как отмечает SteveCzetty: закройте его без репро и вернитесь к работе.

Если ошибка не может быть воспроизведена последовательно, как QA узнает, была ли она исправлена?

Да, вы должны ожидать от них большего. Они должны быть в состоянии сказать:

1. Запущен новый экземпляр программы
2. Я нажал кнопку А
3. Ввести «тестовый текст» в поле ИМЯ ТЕСТА в форме № 1
4. Нажатая кнопка B
5. Заметил, что программа вылетела с этим сообщением (см. Скриншот).

Если все, что они говорят, «это разбилось», они не очень хороши. Даже если описанные выше шаги не воспроизводимы на 100%, достаточно большая выборка этих сбоев может помочь сузить причину, как только обнаружен шаблон.

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

QA должен задокументировать каждую найденную проблему, даже если они не знают, как это произошло. Задача QA - попытаться воспроизвести проблемы, но реально это не всегда возможно. Иногда это не имеет ничего общего с тем, что они сделали за последние 10 минут. Что-то вошло в недопустимое состояние день назад, и это стало очевидным из-за одного из последних 10 шагов.

С этими ошибками "1 на 1000" QA должна попытаться воспроизвести их немного. Если они не имеют успеха, они должны документировать ошибку, а затем попробуйте немного больше.

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

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

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

По моему опыту, самые сочные ошибки не обнаружены в следующих планах тестирования. Иногда вам нужно несколько минут тушить, чтобы выровнять луну и звезды, что вызывает неприятную ошибку. Если QA может выполнить какую-то детективную работу и найти возможные причины, похлопайте их по спине. Но иногда, кто знает, что случилось?

Многие ошибки не воспроизводятся, пока вы не знаете, как их исправить. Это не значит, что их не нужно исправлять. В прошлом году я исправил ошибку, которую до сих пор не знаю, как воспроизвести. Это требует некоторой причудливой комбинации точно синхронизированной ошибки передачи вместе с очень конкретными мусорными данными в определенной области памяти в стеке. К сожалению, одному из наших клиентов «повезло», чтобы постоянно находиться в таком состоянии.

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

Если вы имеете в виду, должен ли QA включать шаги, чтобы воспроизвести ошибку, если они могут, тогда ответ - да. Если вы имеете в виду, что они должны записывать только те ошибки, которые они могут воспроизвести, то абсолютно нет. Ошибки - это ошибки, происходят ли они только в полночь в полнолуние или каждый раз, когда вы на них смотрите. Некоторые ошибки являются недетерминированными (классический пример - неинициализированная переменная, где полученное значение является полуслучайным), это не означает, что их не следует регистрировать, исследовать и, если возможно, исправлять.

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

ИМО, ты должен. QA не делают свою работу, если они не могут дать вам никаких шагов воспроизведения. Не тратьте свое время на попытки воспроизвести то, что вы не можете, просто закройте его как «Невозможно воспроизвести» и продолжайте.

Ваше время гораздо ценнее.

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

• Действия по воспроизведению
• Фактическое поведение
• Ожидаемое поведение

Например:

• Я удалил всех поставщиков из базы данных (используя DELETE * FROM tSuppliers), открыл диалоговое окно поставщиков и щелкнул раскрывающийся список поставщиков.
• В списке содержится следующее сообщение: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Когда я нажал на сообщение, приложение исчезло с экрана и диспетчера задач.
• Я ожидал увидеть пустой список или (желательно) сообщение типа «Поставщики не найдены». Нажатие на пустой список или сообщение не должно иметь никакого эффекта. Приложение не должно исчезать без предупреждения ни при каких обстоятельствах.

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

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

Деньги на карту здесь. Почему любой член команды должен быть в состоянии создать плохо определенную, маловероятную задачу, которая обременяет (надеюсь) высокооплачиваемого разработчика?

Речь идет не о порядке клевания, иерархии, высокомерии, «мы против них» или чем-то в этом роде. Это просто инвестирование в деятельность, которая повышает ценность продукта.

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

ваша команда QA отстой

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

В частности, укажите их в разделе «Покажите мне, как показать себя» :

Это эпоха интернета. Это эпоха всемирного общения. Это эпоха, когда я могу отправить свое программное обеспечение кому-нибудь в России одним нажатием кнопки, и он может так же легко присылать мне комментарии об этом. Но если у него есть проблемы с моей программой, он не может заставить меня стоять перед ней, пока она не работает. «Покажи мне» - это хорошо, когда можешь, но часто не можешь.

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

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

• Улучшения тестируемости, которые можно получить, если на них сфокусирован профессиональный тестер, могут быть очень похожи на магию. Я узнал об этом сам несколько месяцев назад. Инженер QA, работающий с нашей командой, дал мне несколько запросов на тестируемость для разработки некоторых компонентов нашего приложения. Вещи, о которых он спрашивал, не имели для меня особого смысла, но я просто дал ему понять, что он знает как профессионал. Вскоре после того, как я закончил, он разработал инструмент, который на порядок уменьшил усилия по тестированию . Он сказал, что большая часть этого была основана на этих загадочных запросах, которые я реализовал, пойди разберись.