Как быть с минорными дефектами

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

И это было очень правильное замечание в том смысле, что главную функциональность надо тестировать в первую очередь. 

Но! 

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

Ответ тестировщика в этом случае должен быть - НЕТ. Нельзя сделать вид, что мы этого не видели. 

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

 

Почему мы не должны соглашаться

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

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

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

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

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

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