Pull to refresh

Comments 27

Тестер помни: багрепорт «ничего не работает!» оскорбляет чувства программирующих.
>>Пример плохого заголовка: «Все виснет, когда я вставляю текст из буфера обмена»

— У нас в компании это пример самого распространенного заголовка.
у вас так часто всё виснет когда вставляешь из буфера обмена?))
Кэп подсказывает, что смысл комментария в том, у нас часто пишут «плохие» заголовки, а не именно такие, как в примере, на то он и пример.
У нас, кстати, часто. Почему-то большинство программистов не любят ставить ограничение на количество символов в текстовом поле…
UFO just landed and posted this here
Да, хорошее замечание.
Сам всегда выделяю красной рамкой место, на которое надо обратить внимание. А вот упомянуть об этом в посте забыл.
Вы серьёзно предлагаете перебирать посимвольно кусок текста тестировщику, если с этим куском падает приложение? Даже бинарным поиском тестировщик на это потратит в разы больше времени, чем программист с дебаггером, мне кажется.

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

А пример, конечно, весьма условный, не из рабочей практики.
Ну это распространенное пожелание к тестировщикам. Во времена работы в Cybiko на одном из совещаний был высказан тезис, что хороший тестировщик, должен уметь находить ошибки кода, архитектуры и дизайна, качественно описывать их и предлагать работающее исправление. На что было предложено тогда уволить всех программистов и дизайнеров. Начальнику отдела — бросать тестировщикам ярлык для проверки, чтобы потом они исправлением ошибок доводили продукт до ума ;-)
Находить ошибки кода и архитектуры (ага, при тестировании методом черного ящика к тому же :) ) может тестировщик 90lvl, такой в лучшем случае один на всю компанию :)
Можно еще упомянуть принцип «Что? Где? Когда?». В большинстве случаев это помогает написать удачный заголовок/подробное описание, Например,
Что: неправильный расчет данных
Где: на странице NNN
Когда: после ввода а поле Y отрицательного значения.
не соглашусь про видео. бывают последовательности и результаты, которые намного проще показать на видео чем описывать или скриншотить
а проще ли их потом воспроизвести программисту? или вам самим для проверки исправления бага?
И не забывайте о конфигурации тестового стенда!
Возможно в этом посте это подразумевалось под шагами, но обычно она указывается отдельно и может включать в себя( в зависммости от типа тестируемого ПО:
1. Версия тестируемой программы.
2. Версия окружения( система, браузер, специальные библиотеки).
3. Версия железа на котором происходит ошибка( если РС, то процессор, память, видео. Для мобильных устройств — тип мобильного устройства).
Да, про это немного есть в посте.
Я разделил пункт на «affect version» и «environment»
affect version — версия тестируемой программы
environment — версия окружения, железа.
Ага, теперь увидел. При первом прочтении как то проскользнуло.
Еще хорошо бы написать что делать если ошибка не воспроизводится, или воспроизводится статистически( т.е. конкретного алгоритма как ее получить — нет, но в течении некоторого времени она проявляется). Конечно это индивидуально для каждой компании, но мы такого рода ошибки собирали, потом помогало понимать что может еще рухнуть.
Вы забыли о следующем моменте: как быть, когда существует несколько путей воспроизведения ошибки?
Достаточно указать один, самый короткий/простой для воспроизведения.
Главное — воспроизвести ошибку, чтобы понять ее причину.

А когда вы перепроверяете, то можете попробовать все пути воспроизведения.
Опять же зависит от платформы и политики компании. Иногда бывает полезно разнести разные пути воспроизведения в разные записи. Возможно они инициированы разными проблемами в коде и исправление одной на другие не повлияет — проверять придется все.
а в нашем баг трекере раздел Environment ограничивается именем ОС! Из-за этого приходится постоянно задавать одни и те же вопросы :(. Вообще, очень правильная статья
Попросите ответственного за BTS добавить еще поле — сейчас инструмент не решает всех возложенных на него задач.

У нас Environment — это просто поле для свободного ввода, можно писать все, что нужно в рамках данной конкретной задачи.
Из воспоминаний профессиональной юности: Когда прислала подобное руководство девочке-тестеру, которая любит писать баг-репорты в стиле «Программа не работает», она перестала со мной общаться и перевелась в др. отдел. Добавила статью в избранное — теперь в случае возникновения подобной ситуации будут ненавидеть Вас :)
Систем, которые выполняют подобные функции и стоят копейки или даже бесплатно — кучи — JIRA, BaseCamp, HollyTask. Вот даже тут почитать: www.hollytask.com/ru_bugreport
Sign up to leave a comment.

Articles