13 мар. 2009 г.

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

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

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


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

Итак, вы проверяете соответствует ли ваш продукт требованиям. А задаетесь ли вы при этом такими вопросами:
  1. Возможно ли составить полный список требований?
  2. Если нет, можно ли считать работу выполненной проверив соответствие списку требований?
  3. Надо ли тестировать то, что в требованиях не описано?
  4. Верны ли требования сами по себе?
  5. Я что, долбаный робот? :) и т.д.
Если задаетесь, то вы наверняка принимаете активное участие в формировании требований. А если кто читал "Роман об управлении проектами" Демарко наверняка помнят главу про плохую спецификацию провалившегося проекта (система для аэропорта). Да и вообще, практика подключения тестировщиков к проекту на этапе формирования требований давно себя зарекомендовала с самой лучшей стороны, особенно если вспомнить правило 1-10-100.

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

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

4 комментария:

Alexey Bulat комментирует...

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

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

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

Вот.
Статья - зачот!

clauster комментирует...

Спасибо, Алексей!

Galina комментирует...

Тестирование - это в общем случае "жесткое" использование программы по назначению и не по назначению :) Заметка хороша, читается влёт :)

rkononov@gmail.com комментирует...

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