Иногда моя команда QA сообщает об ошибках, но ни я, ни они не имеют представления о том, как их воспроизвести. Это приводит к очень долгим и разочаровывающим сеансам отладки, которые иногда даже не дают результатов.
Мое программное обеспечение сильно связано с проприетарным оборудованием, поэтому ошибки могут возникать сразу со многих сторон.
Должен ли я ожидать от них большего, чем «ваше ПО рухнуло, когда я нажал кнопку», или я должен понять, что случилось?
РЕДАКТИРОВАТЬ:
Один из моих коллег отметил, что мы, вероятно, все разработчики, поэтому результаты могут немного пострадать
Ответы:
QA всегда должен стараться сделать ошибки максимально легкими для воспроизведения, и описание ошибки должно содержать предпринятые шаги.
Однако, если они не могут легко воспроизвести ошибки, они все равно должны войти в базу данных ошибок с подходящими заголовками / заголовками и полным описанием того, что они сделали, чтобы вызвать ошибку. В описании ошибки должно быть четко указано, что они не могут воспроизвести ошибку (возможно, с некоторым комментарием в духе «попробовал пять раз, это случилось один раз»). Таким образом, если кто-то еще увидит ту же ошибку, он может добавить в базу данных ошибок свои выводы, а также вы получите как можно больше информации, что в дальнейшем может быть жизненно важным для экономии вашего времени на поиск проблемы.
Кроме того, вы можете фильтровать информацию - в разных системах может быть много ошибок, которые, как вы знаете, связаны (например) с одной областью кода - если QA ничего не сообщает (так как они не могут их воспроизвести) ) тогда эта информация вам не достанется.
источник
... a full description of what they did to cause the bug
, Чем это отличается от репо?The software crashed
противThe software crashed editing foowidgets
противThe software crashes when viewing a foowidget and toggling the frobulator 10 times followed by pressing this key sequence (stack trace attached)
. Последняя деталь может быть не очевидна, но наличие второго описания вместо первого, безусловно, полезно.Похоже, что ваш отдел QA проводит слишком много предварительных испытаний (т.е. у них нет хорошего плана тестирования).
Поисковое тестирование хорошо, и выявляет проблемные области, но оттуда они должны определить воспроизводимые тестовые наборы (т. Е. План тестирования) для выполнения, которые выявят конкретные ошибки.
Существует ряд причин, по которым необходимо правильное воспроизведение (не только хорошее, но и необходимое):
Итак, как отмечает SteveCzetty: закройте его без репро и вернитесь к работе.
источник
Если ошибка не может быть воспроизведена последовательно, как QA узнает, была ли она исправлена?
источник
Да, вы должны ожидать от них большего. Они должны быть в состоянии сказать:
Если все, что они говорят, «это разбилось», они не очень хороши. Даже если описанные выше шаги не воспроизводимы на 100%, достаточно большая выборка этих сбоев может помочь сузить причину, как только обнаружен шаблон.
источник
Мой совет, чтобы прочитать эти ошибки и дать им старые добрые мысли. Если вы не можете выяснить потенциальную причину, забудьте о них сейчас.
QA должен задокументировать каждую найденную проблему, даже если они не знают, как это произошло. Задача QA - попытаться воспроизвести проблемы, но реально это не всегда возможно. Иногда это не имеет ничего общего с тем, что они сделали за последние 10 минут. Что-то вошло в недопустимое состояние день назад, и это стало очевидным из-за одного из последних 10 шагов.
С этими ошибками "1 на 1000" QA должна попытаться воспроизвести их немного. Если они не имеют успеха, они должны документировать ошибку, а затем попробуйте немного больше.
Причина, по которой им следует ввести ошибку довольно рано, заключается в том, что программист знает код намного лучше, чем QA, и может сразу же узнать о проблеме. Это может быть код, который они переработали. Возможно, они наполовину реализовали функцию, о которой забыли. Возможно, они не имеют ни малейшего представления, но у тестера нет смысла тратить несколько часов, пытаясь воспроизвести проблему, очевидную для человека, который ее кодировал. Тестер всегда может добавить больше деталей к ошибке позже.
Ошибка должна включать как можно больше информации. Все, что тестер может вспомнить о подготовке к проблеме, должно быть написано до мельчайших подробностей. Любые журналы сбоев, снимки базы данных или соответствующие скриншоты также должны быть прикреплены.
Если ошибка не воспроизводится, отлично! Это не повредит иметь его в базе данных. Если программа выпущена и пользователь сообщает об аналогичной ошибке позже, вы можете сравнить их опыт с тем, что есть в отчете, и найти какие-либо сходства.
По моему опыту, самые сочные ошибки не обнаружены в следующих планах тестирования. Иногда вам нужно несколько минут тушить, чтобы выровнять луну и звезды, что вызывает неприятную ошибку. Если QA может выполнить какую-то детективную работу и найти возможные причины, похлопайте их по спине. Но иногда, кто знает, что случилось?
источник
Многие ошибки не воспроизводятся, пока вы не знаете, как их исправить. Это не значит, что их не нужно исправлять. В прошлом году я исправил ошибку, которую до сих пор не знаю, как воспроизвести. Это требует некоторой причудливой комбинации точно синхронизированной ошибки передачи вместе с очень конкретными мусорными данными в определенной области памяти в стеке. К сожалению, одному из наших клиентов «повезло», чтобы постоянно находиться в таком состоянии.
Поэтому, во что бы то ни стало, поощряйте QA включать шаги воспроизводимости, где это возможно, но не вините их, если они не могут. Иногда это поможет вам узнать, куда добавить журналирование. Иногда все, что он делает, это говорит вам, что не вызывает ошибку, но отчет об ошибке всегда полезен.
источник
Если вы имеете в виду, должен ли QA включать шаги, чтобы воспроизвести ошибку, если они могут, тогда ответ - да. Если вы имеете в виду, что они должны записывать только те ошибки, которые они могут воспроизвести, то абсолютно нет. Ошибки - это ошибки, происходят ли они только в полночь в полнолуние или каждый раз, когда вы на них смотрите. Некоторые ошибки являются недетерминированными (классический пример - неинициализированная переменная, где полученное значение является полуслучайным), это не означает, что их не следует регистрировать, исследовать и, если возможно, исправлять.
Невоспроизводимые ошибки, как правило, должны иметь низкий приоритет, но они должны определенно регистрироваться.
источник
ИМО, ты должен. QA не делают свою работу, если они не могут дать вам никаких шагов воспроизведения. Не тратьте свое время на попытки воспроизвести то, что вы не можете, просто закройте его как «Невозможно воспроизвести» и продолжайте.
Ваше время гораздо ценнее.
источник
Отчет об ошибке должен содержать:
Например:
DELETE * FROM tSuppliers
), открыл диалоговое окно поставщиков и щелкнул раскрывающийся список поставщиков.GUPOS ERROR #0000000: SOMETHING WENT WRONG!
. Когда я нажал на сообщение, приложение исчезло с экрана и диспетчера задач.Итак, да - он должен содержать шаги для воспроизведения. Тот факт, что они не чувствуют необходимости включать это, может показаться, что они думают, что их работа заключается в том, чтобы «сломать программное обеспечение», а не выявлять неисправности.
источник
QA должен быть в состоянии воспроизвести ошибки на основе введенных шагов. Если они изо всех сил старались, но по-прежнему не могли воспроизвести, им все равно нужно было бы вводить ошибки, содержащие столько же деталей, сколько у них есть с отметкой времени, чтобы разработчики могли взглянуть на приложение и отладочные журналы для получения более подробной информации.
источник
Деньги на карту здесь. Почему любой член команды должен быть в состоянии создать плохо определенную, маловероятную задачу, которая обременяет (надеюсь) высокооплачиваемого разработчика?
Речь идет не о порядке клевания, иерархии, высокомерии, «мы против них» или чем-то в этом роде. Это просто инвестирование в деятельность, которая повышает ценность продукта.
Когда проблема может быть продемонстрирована, чтобы негативно и измеримо повлиять на стоимость продукта, тогда она должна быть исследована, воспроизведена и исправлена. Исправьте дефектный трубопровод, чтобы отфильтровать шум.
источник
ваша команда QA отстой
Подойдите к ним и скажите им, чтобы они прочитали документ, который любой профессиональный тестировщик должен был напечатать прямо в их мозгах (я был тестером однажды, и у меня все еще есть это прямо в моем мозгу): Как сообщать об ошибках эффективно .
В частности, укажите их в разделе «Покажите мне, как показать себя» :
Если они начинают кричать на вас, жалуясь на то, что «жуки могут поступать сразу со многих сторон» , скажите им, что они сосут даже больше, чем вы думали раньше. Скажите им, что тестируемость - это функция, которую они должны оценивать среди других функций проекта, и они должны приложить усилия для правильной реализации этой функции.
источник