Мифы и грабли: Цель тестирования в проверке соответствия требованиям

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

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


Но глядя со своей колокольни, я не могу считать эту деятельность тестированием. Честно говоря, я даже не интересовался, как все это должно называться. Допустим, валидация. Или верификация. Не важно, речь в заметке пойдет не об этом, а почему проверку соответствия требованиям, т.е проверку качества, я не могу считать тестированием (вы можете оставаться при своем мнении).

Итак, вы проверяете соответствует ли ваш продукт требованиям. А задаетесь ли вы при этом такими вопросами:

1. Возможно ли составить полный список требований?
2. Если нет, можно ли считать работу выполненной проверив соответствие списку требований?
3. Надо ли тестировать то, что в требованиях не описано?
4. Верны ли требования сами по себе?
   
5. Я что, долбаный робот? :) и т.д.

Если задаетесь, то вы наверняка принимаете активное участие в формировании требований. А если кто читал "Роман об управлении проектами" Демарко наверняка помнят главу про плохую спецификацию провалившегося проекта (система для аэропорта). Да и вообще, практика подключения тестировщиков к проекту на этапе формирования требований давно себя зарекомендовала с самой лучшей стороны, особенно если вспомнить правило 1-10-100.

Что по поводу качества, мне нравится высказывание Gerald Weinberg: "Quality is value to some person", т.е. у каждого свои представления о качестве. У разработчика. у менеджера, у тестировщика, у пользователя и т.д. Поэтому тестирование осложняется тем, что тестировщикам приходится часто сталкиваться с проблемами, которые влекут за собой конфликт интересов. Тут уже надо включать голову и здравый смысл. Некоторым конечно проще перевести стрелки на менеджера или лицо более ответственное, но грамотный тестировщик обычно всегда в состоянии предложить решение и донести его до заинтересованных сторон (так называемых stakeholders). Потому что у этого тестировщика сформирована общая картина проекта и он понимает что от него хочет каждая из заинтересованных сторон. Кажется, я уже ударился в проповедование context-driven testing. :)

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