Home

Перевод и адаптация: Кристина Журавлева (ПрактиТест)

Многие слышали, что разработчики не могут быть хорошими тестировщиками.

Хотелось бы все-таки разобраться почему. В этом мне поможет англоязычная статья Джоэля Монтвелиски. Конечно перевод будет вольным с небольшими отступлениями и моими мыслями на эту тему.

Правда, что вы можете научить собаку нескольким трюкам, но вы уж точно не сможете научить ее летать.

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

1. “Родительские чувства” к коду

Разработчики привязаны к тому, что они пишут. Может быть это прозвучит глупо, но очень сложно оценивать объективно то, что ты создаешь.

2. Акцентирование на позитивных моментах

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

3. Работа на основе принципа упрощения сложных вещей

Рассматривание сложных сценариев с целью нахождения багов является одной из составляющих процесса тестирования. В двух словах мы берем простую вещь и придумываем как ее можно усложнить.

Разработчики поступают ровно наоборот. Они берут сложный процесс или проект и разбивают его на более мелкие компоненты с целью найти решение проблемы.

4. Неспособность видеть мелкие детали на большой картине

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

5. Недостаток опыта работы с типичными багами и программными ошибками

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

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

Обсудить статью в форуме