Сообщений в теме: 14

[yamironova]

/Тема вынесена из чата Школы Тест-Менеждеров /

 

"За неделю тестировщики не нашли баги, которые были бы найдены, если четко следовали тест-кейсам
Но баги пропущены, вот сижу думаю - наорать на них как обычно или придумать что-то новенькое?
Да и как вообще "лучше" наругаться?

 

Сегодня релиз, а у нас найдено два бага, из-за которых тут нужно делать полный re-test уже готового функционала.

Проставлено, что passed и время затраченное на тест кейс имеется, но в реальности кейс наполовину failed.

 

Да, баг обнаружил другой тестировщик, который проходил тот же самый тест-кейс в UserAcceptanceTesting.

 

 

У кого были такие случаи? Это лечится? Что вообще делать?"

[Сергей]

Первый раз простить, второй предупредить и поговорить, третий уволить...

[neman]

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

[lurk]

Включать запись монитора во время прохождения тестов. Это удобно. 

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

[ch_ip]

Выяснять причину пропуска. Без этого невозможно делать дальнейшие выводы.

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

 

Случаи были, но покуда я не менеджер, не знаю, чем оно всё заканчивалось.

[Vasiliy]

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

[Сергей]

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

[Лелик32]

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

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

 

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

[Flari]

"тестировщики не нашли баги". Если это случилось даже не с одним тестировщиком, то точно нужно все выяснить с тестировщиками один-на-одни.

 

Вдруг девелоперы решили пофиксить баг, но подумали, что изменение минорное и тесты просто не нужны :)

 

"вот сижу думаю - наорать на них как обычно или придумать что-то новенькое?"

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

[Petrov.Sergey]

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

 

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

 

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

Описывать в каждом тесткейсе все 50 expected results - слишком геморройно, поэтому описываются лишь ключевые. Expected result, в котором была обнаружена ошибка, не был "ключевым". Но факт остаётся фактом.

Показали, объяснили, рассказали всё по полочкам ещё раз под запись (я как "наставник" + наш общий начальник отдела). Он выступил с инициативой занести этот момент, оказавшийся для него проблемным, в ТЗ.

 

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

[yamironova]

Спасибо большое от автора вопроса  и от меня!

Автор вопроса очень рад вашим ответам, обдумывает их, но сам пока не готов отвечать на ваши вопросы)

[Flari]

Спасибо большое от автора вопроса  и от меня!

Автор вопроса очень рад вашим ответам, обдумывает их, но сам пока не готов отвечать на ваши вопросы)

Для этого достаточно завести анонимный аккаунт:)

[pachkun]

Сегодня релиз, а у нас найдено два бага, из-за которых тут нужно делать полный re-test уже готового функционала.

 

У кого были такие случаи? Это лечится? Что вообще делать?"

Трудно сказать, ибо мало информации.

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

P.S. А может этот человек “пинает болт”, тогда лучше уволить, а не искать ему оправдание.

[Лелик32]

Например, у нас буквально в пятницу на бою нашли ошибку, которую тестировщик не просто должен был найти, но и видел! Он просто не понял, что это ошибка.
 
Ему объяснялось несколько раз, что должно присутствовать в результирующей модели. Но он забыл, т.к. привычки записывать всю новую информацию у него нет.
Описывать в каждом тесткейсе все 50 expected results - слишком геморройно, поэтому описываются лишь ключевые. Expected result, в котором была обнаружена ошибка, не был "ключевым". Но факт остаётся фактом.
Показали, объяснили, рассказали всё по полочкам ещё раз под запись (я как "наставник" + наш общий начальник отдела). Он выступил с инициативой занести этот момент, оказавшийся для него проблемным, в ТЗ.

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

[EugeneL]

Cкорее всего, для правильного понимания кейса требуется обладать несколько  большим объемом знаний бизнес-логики, чем в случае, когда тестовые сценарии хорошо документировны. Было бы не лишним проверить, как часто в тестовых сценариях встречается значение "ок" или " " (прописью: пробел) в графе "Ожидаемый результат".