Взяли задачу на тестирование, которая обычно делается одним тестером 2-4 часа и дали ее всем на час.
Все — это моя группа автоматизаторов, я и один ручной тестер у которого лицо выражением не напоминало «язанятанеподходи».
То есть четыре участника.
Час тестим постановку, потом собираемся, рассказываем о кейсах, которые использовали и которые не успели проверить. Делимся ошибками и обсуждаем — как нашли и почему не нашли.
По результатам: я и ручной тестер нашли две одинаковые ошибки. Один АТ не нашел баг. Другой ат сперва придумывал реально крутые нетипичные и многообещающие кейсы, а потом нашел очевидный баг, который никто не заметил.
Выводы. Опыт полезный, руководителю ручных тестеров порекомендовал ставить его на поток в таком виде:
Берется большая задача. На 4 часа, на 2 дня — неважно. Назначается ответственный. Он собирает народ, все вместе ее тестируют 1 час, затем собираются, обсуждают. Ответственный записывает все результаты этого брейнсторма и дальше пилит сам.
Больше велосипедов, хороших и разных.
И да, у нас появились еще две тестировщицы, ня. Не наташи, но вопрос решается.
Пикрандом по запросу "Наташа":
Слово Канеру
Возможность для тестирования возникает каждый раз, когда артефакт разработки переходит из одних рук в другие
Программы появляются не сразу готовыми, их пишут функция за функцией, фича за фичей. Аналогично — спецификации, требования и мануалы: они пишутся по разделам, глава за главой, часть за частью. Возможность для тестирования возникает каждый раз, когда такая часть готова. Это способ тестировать на всех этапах разработки продукта. Тестируйте то, что готово к тестированию, как только оно станет готовым к тестированию.
Комментариев нет:
Отправить комментарий