7 декабря 2010 г.



Так возможно ли качественное тестирование силами разработчиков?

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

Так вот, я с такими утверждениями категорически не согласен. Могу согласиться, разве что, с тем, что время разработчиков действительно может стоить дорого. Но вот остальное, на мой взгляд, очередной миф.

Безусловно, тестирование на проекте должно присутствовать. Но не как отдел или конкретные сотрудники, а как процесс. Если уж бросаться в крайности, то не важно, кто именно занимается тестированием. Важно, что тестированием занимаются в принципе и оно органично вписано в процесс разработки ПО.


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

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

Теперь к мифу о том, что программисты не любят заниматься тестированием. Соответственно, они будут делать это малоэффективно. Помните бородатый анекдот про «Вы любите кошек?». Так вот, тут тоже самое. Значит вы просто не умеете правильно готовить процесс тестирования для разработчиков.

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

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

Мы представили наш процесс тестирования в виде ролевой игры. Описали ключевых персонажей, наделили их базовыми характеристиками. Составили для каждого из них список главных задач, решение которых являлось бы индикатором того, что наш продукт работает как следует. Далее мы создали несколько базовых сценариев использования модуля, т.к. процесс производства не плоский - в нем есть несколько различных веток, которые выполняются в зависимости от разных входных условий. Прохождение всех сценариев значило бы, что продукт готов к использованию.

И процесс тестирования пошел! Теперь тестированием занимались не программисты, а «грузчики», «приемщики продукции», «менеджеры производства» и прочие. В результате было найдено много различных дефектов, в том числе и таких, заметить которые можно лишь понимая задачи конечного пользователя - не дефекты в кодировании, а недостатки взаимодействия программы и пользователя. Достаточно было сделать процесс тестирование небанальным и интересным для всех. Результат получен. Время разработчиков потрачено эффективно.

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

-



Понравилось сообщение - подпишитесь на блог Подписка на блогFollow grodnosoft on Twitter




Читайте также:


Комментов: 0

Отправить комментарий