Вы можете научить собаку множеству разнообразных трюков, но вы не сможете научить ее летать, потому что это зарезервировано для птиц, самолетов и летающих тарелок…
Я попытался объяснить паре Agile-команд почему разработчики обычно не относятся к хорошим тестировщикам. Потрудившись над восстановлением в памяти всех причин, которые приходили мне в голову, я решил составить из них краткий список и опубликовать его.
Не поймите меня превратно, я думаю, что разработчики должны принимать участие в тестировании, особенно в Agile-командах, но я также осознаю их ограниченность и когнитивные слепые пятна, которые обычно вредят их тестам. А как говорится, первый шаг к устранению своих слабостей это понимание того, что они у вас есть.
Почему разработчики (обычно) пасут задних в тестировании?
1. «Родительские чувства» к своему коду
Разработчики эмоционально привязаны к тому, что они пишут. Это может звучать глупо, но трудно относиться объективно к тому, что ты создал.
Например, я знаю, что мои дети не совершенны, однако я уверен, что мне было бы неприятно, если бы кто-нибудь пришел ко мне и стал их критиковать (ведь они же — совершенства, не так ли?).
2. Фокусирование на «правильных путях»
В основе разработки программ лежит воплощение положительного сценария в продукте. Большая часть усилий разработчиков уходит на то, чтобы все работало правильно, эффективно, с высокой производительностью. Внутренне переключиться с позитивного /созидающего мышления на негативное/«что-может-пойти-не-так» – не простая задача, и быстро ее не решить.
3. Работа, основанная на принципе упрощения сложных сценариев
Одна из основных составляющих работы тестировщика — поиск сложных сценариев (например, выполнение множественных действий одновременно или бесконечное повторение одной и той же операции), с помощью которых можно сломать систему и найти баги. То есть, обычно мы берем простые вещи и ищем пути для их усложнения.
Наши «противники» разработчики, наоборот, сильны в том чтобы взять сложный процесс или проект и разбить их на максимально мелкие составляющие, что позволит им прийти к решению. Я все еще помню свой шок в колледже, когда я впервые понял, что все, что компьютер может делать, это операции AND, OR, NOT, NAND, NOR, XOR и XNOR с использованием нулей и единиц.
4. Неспособность увидеть маленькие детали в больших картинах
Я не могу объяснить причины этого явления, но будучи тестировщиком наблюдал его неоднократно.
Один из побочных эффектов, возникающих при становлении хорошего тестировщика, это выработка чувствительности к обнаружению того, что «не подходит» к общей картине (как в задачах «найди лишний предмет»). Это нельзя передать, это можно только почувствовать. А затем мы применяем некоторые систематические процессы чтобы найти конкретную проблему. Один разработчик как-то сказал мне, что у тестировщиков «нюх» на баги, и наверное он был недалек от истины.
5. Недостаток сквозной и реально-пользовательской перспективы
В силу природы своих задач разработчики концентрируются на отдельных компонентах или функциях в своем продукте, не имея четкого понимания, как их пользователи работают с их системой в целом.
Нам, тестировщикам, нужна гораздо более широкая перспектива продуктов, мы должны понимать их и тестировать в целом, используя техники, позволяющие симулировать вероятное поведение реального пользователя.
6. Меньше опыта с распространенными багами и ошибками приложений
Опять-таки, то, что приходит со временем и опытом, это наше знание распространенных багов и ошибок в приложениях. Конечно, когда в активе разработчика будут тысячи строк кода, набранные ним на своей клавиатуре, он также повстречает много багов и ошибок, но будучи тестировщиками мы приобретаем этот опыт быстрее и в более глубоком смысле.
Опытный тестировщик смотрит на форму и автоматически задумывается о распространенных багах и отказах, которые он может найти в ней, и начинает проверять их наличие.
Подводя итоги
Не то чтобы они не хотели делать это. Разработчики просто неспособны тестировать так же, как профессиональные тестировщики. Это не значит, что они не могут помочь в тестировании, а в некоторых специфических областях они смогут это сделать даже лучше нас. Но прежде чем начать, разработчикам стоит выявить свои «слепые пятна» и компенсировать их.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]