Buddy testing и Pair testing

Buddy testing (Совместное тестирование) — это когда два человека тестируют отдельно один и тот же модуль. У каждого свой взгляд на тестирование:

• Разработчик смотрит через призму кода.
• Тестировщик — через призму своих знаний и опыта. 

Потом можно сравнить результаты:

• Сколько багов нашли оба?
• Сколько только разработчик? Почему тестировщик их не нашел, каких знаний ему не хватает?
• Сколько нашел лишь тестировщик? Ну, молодец, чё! По статусу положено )))

Это необязательно должны быть разработчик и тестировщик. Любые два человека — два джуниор-тестировщика, один джуниор и один опытный, тестировщик и аналитик, тестировщик и разработчик... Но смысл всё тот же, сравнить результаты.

Pair testing (Парное тестирование) – это когда два человека тестируют вместе. Сидят за одним компьютером. Один печатает, второй подсказывает, что делать. Потом меняются местами. Или сначала обсуждают план, а потом уже один делает, второй смотрит.

Это как парное программирование! Один пишет код под присмотром другого, потом сидят и обсуждают. Решили и на тестирование практику перенести. 

Парная работа помогает поделиться взглядами и идеями.

В принципе, оба варианта полезны для обучения, когда у двух тестировщиков разный опыт знаний и опыта. И тут все зависит от того, как вам больше нравится проводить обучение:

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

В идеале оба метода применяются по времени — на тестирование выделяется час или два. Тогда разницы особой нет, кроме индивидуальных предпочтений. Но бывает и такое, что ограничений по времени нет.

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

— Ну что, показывай, как тестировал. Хм, погоди, почему ты начал с «покататься головой по клавиатуре», ты чего?? Всегда сначала позитивное тестирование! Ну ладно, показывай, что нашел. А теперь посмотри мой список ошибок. Видишь? 

Вот эти критикалы ты пропустил, потому что пытался рандомно все разломать. А ведь достаточно было почитать ТЗ и попробовать отойти от основного сценария. Пользователи ведь не пытаются сломать специально, но они могут недочитать ТЗ или случайно сделать не так, как надо. (делаем пометку в блокноте)

А вот тут, посмотри, вроде проверял это поле, а баг не нашел. Потому что попробовал ввести лишь 1000 символов. Это же ни о чем, 21 век на дворе. Ввел бы несколько миллиардов и повесил систему, видишь? (еще пометка)

А вот это не нашел почему? Вроде тестировал блок.

— А я такого кейса не предусмотрел...

— Ну смотри, это делается так...

— Ого, спасибо, запомню!

— Итого, подведем итоги, чему мы научились. Записывай:

1. Всегда сначала позитивное тестирование, потом негативное. 
2. При тестировании сначала проверяем основной сценарий, потом думаем, какие могут быть альтернативы. По бизнес-логике, а не просто «вбить абра-кадабру»
3. При поиске границ не забываем о технологической. И она далеко-далеко, а не просто 100 или 200 символов. Изучи материалы по граничным значениям.
4. ...

Все понял? Со всем согласен?

— Да, ок!

См также:

Позитивное и негативное тестирование

Где брать идеи для тестов (подборка полезных ссылок)

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