Сторонникам концепции, согласно которой тестирование имеет своей целью поиск дефектов, настоятельно рекомендую почитать вот эту заметку, чтобы попытаться понять позицию противоположной стороны: http://www.questioni...of-testing.html
Теперь представим, что есть нечто сложнее, чем 2+2=4. Допустим по требованиям/спеке дано f(x)=y. По результатам эксперимента получается, что f(x)=2y. Где ошибка?Первично то, что у нас есть задача и ее реализация. Нам нужно сравнить то что получилось с тем, что должно было получиться. Другими словами, сложить 2+2 и получить 4. Если мы складываем 2+2 и получаем 5, то это ошибка. В случае программы - дефект. Цель тестировщика - сравнить левую и правую части уравнения и сделать вывод о наличии или отсутствии ошибки. Если этот процесс не является поиском дефектов, то что это?
Если механически сравнить левую и правую сторону, то ошибка всегда получается в программе. А может ошибка в спецификации и правильно f(x)=2y, что и подтвержденено результатами эксперимента. Надо чуть чуть думать, просто сравнить не получается.
...
Вначале 2 LeshaL,
а кто сказал, что часть уравнения, с которой нужно сравнивать, - это программа?
А думать нужно всегда, даже когда просто гвоздь в стену заколачиваешь.
Теперь для двух Алексеев и всех остальных,
давайте рассмотрим типовое поведение тестировщика.
1. Тестировщик получает на тестирование некую программу (модель реализации) с задачей ее проверить (собственно, это типовая функция свойственная данной роли в проекте).
2. Тестировщик составляет у себя в голове некоторое представление о данной программе. Что она должна делать и как? Назовем это тестовой моделью.
На основании чего он составляет эту модель? На основании спецификации. На основании существующих в компании глассных и не глассных правил. На основании своего предыдущего опыта и здравого смысла. На основании еще черт знает какой информации. Но в любом случае у него есть некая модель или представление о том, что и как должно работать в программе.
3. Далее тестировщик работает с программой, тестирует ее. Если поведение программы (модель реализации) совпадает с его тестовой моделью (той что в голове), то у него не возникает противоречий. Если же программа ведет себя не так, как должна (другими словами, модель реализации не совпадает с тестовой моделью), то у тестировщика возникает конфликт. В результате этого могут быть оформлены следующие отчеты о результатах тестирования:
- баг - если тестировщик точно знает, что программа ведет себя не так как должна,
- вопрос - если тестировщик не уверен, что программа должна вести себя так, как она ведет,
- предложение на внесение изменений - если тестировщик знает, что программа ведет себя не так, как должна, но при этом поведение программы совпадает с функциональной моделью (бизнес-моделью).
Тут многие начинают говорить о том, что баги - это не все. А некоторые (не при детях будет сказано) говорят, что это даже не главное. Что, мол, программа - это очень сложная вещь (а не 2+2). Что она постоянно меняется. Типа заказчик сам не знает чего хочет (постоянно вносит изменения в бизнес-модель). И аналитик может напортачить (допустить ошибку в функциональной модели). Да и, что греха таить, тестировщик сам может накосячить (неправильно составить тестовую модель).
В итоге, все нужно выволить на заказчика и пусть он решает, что нужно исправлять, а что нет, дефект это или не дефект и т.п.
Правильно! Сто раз правильно!
Но что это меняет? Суть работы не меняется. У тестировщика есть его ожидания (тестовая модель) и если они не совпадают с действительностью (с моделью реализации), то он оформляет отчет. А уже потом, по этому отчету принимается решение - исправлять или не исправлять, дефект или фича, говорить заказчику или не говорить и т.п.
Поэтому я утверждаю, что тестирование - первично. Результат тестирования - отчет (в моем понимании, отчет о несоответствии того что должно быть и что есть). А уже потом риск менеджмент, релиз менеджмент, тактическое и стратегическое управление и другие фенечки.