Психология тестирования

Преамбула и disclaimer. Эта заметка обращена в первую очередь к начинающим программистам и тестировщикам. Те, кто имеет опыт работы в крупной компании, в которой процесс обеспечения качества поставлен на высоком уровне, в подобных рекомендациях, как правило, не нуждается. Хотя… :)

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

К тестировщикам…

Коллеги, разработчики – это те, кто создаёт "основной продукт ИТ-фирмы". Среди них могут быть самые разные люди, различающиеся уровнем квалификации, темпераментом и многими другими качествами. И всё же – именно они разрабатывают то, за что заказчик платит деньги.

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

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

Также помните, что периодически (часто?) вам приходится консультироваться с разработчиками по множеству технических вопросов. Поверьте, этот процесс протекает куда легче, быстрее и приятнее, когда общение с вами разработчикам в радость.

Вывод: да, вы обеспечиваете и контролируете качество программного продукта, но вы не обеспечиваете и не контролируете качество чьего-то характера, психики, взглядов, предпочтений и т.д. – т.е. вы не тестируете людей. Будьте добрее.

К разработчикам…

Коллеги, тестировщики – это те, кто позволяет проекту стать лучше. Что это значит? Это значит, что заказчик будет доволен, что фирма будет процветать, и у всех будут деньги. Если вы считаете, что ваша задача – "написать с горем пополам работающую братскую могилу кода и поскорее уйти в отпуск", вы долго не задержитесь ни на какой работе. Если же вы понимаете, что от качества вашего кода зависит общее качество проекта, вы начинаете заботиться о повышении качества того, что вы пишете.

Многие из вас по праву считают себя классными специалистами. Супер. Хорошо, что такие есть. А вот теперь представим задачу: "Написать функцию, складывающую два числа". Если кто-то сразу потянулся к клавиатуре – вычеркните себя из списка классных специалистов.

Зададим вопросы:
1. На каком языке программирования?
2. Откуда берутся числа (веб-форма, клавиатура, файл и т.п.)?
3. Происходит ли некая предварительная проверка данных? Если да, то какая?
4. Каковы допустимые значения чисел (отдельный прикол: 10-тизначное 2000000000 ещё влазит в 32 бита, а также 10-тизначное 7000000000 – уже нет)? А в какой системе счисления будут числа?
5. А под какой платформой мы работаем? Влезет ли число в разрядность стандартных числовых типов данных? Если нет, то следует ли нам написать некое "своё сложение с блэк-джеком и… прочими развлечениями"? Если надо писать такое, то какие требования по производительности?
6. Если складываются дроби, есть ли какие-то требования по точности (чтобы мы не потеряли некий сто-N-ный разрядик)?
7. Какие стандартные исключительные ситуации предусмотрены? Как наша функция о них будет сообщать?
8. Как сообщать о нестандартных исключительных ситуациях?
9. Что ещё мы должны знать, чтобы написать действительно хороший код?

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

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

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

Общий вывод: каждый специалист хорош на своём месте. Исключение (игнорирование) интересов какой-то части слаженного механизма проектной команды или возрастающее напряжение внутри оной приводит только к проблемам.