Сначала ссылки: 1-ая часть от исходника, в котором это читала я (внизу в схожих статьях есть вторая) и 2-ая часть со ссылкой на первую на сайте software-testing.ru.
Копипастить статью не имеет смысла, поэтому небольшая история...
Работала я себе, работала на небольшом проекте. Проверяла реализацию по ТЗ, про тест-кейсы только краем уха слышала.
Но начальнику моему это не нравилось, показал он мне на тесты с соседнего проекта в TestLink-е. "Напиши и ты".
Сказано - сделано. В свободное от тестирования время (небезызвестные "очереди" в тестировании) начала, как паук, оплетать систему кейсами.
Занятие довольно скучное, быстро надоело. Так что тесты я стала писать копипастой из ТЗ:
Действия:
Ввести значения в поля «A» и «B».
Ожидаемый результат:
Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «А» и «B». (Иногда еще также в графе с ожидаемым результатом встречаются такие «шедевры» как: См. в ТЗ, в соответствии с ТЗ, наблюдаем ожидаемые значения и т.п.).
Не, ну а что? Кому они, в конце концов, нужны то? Мне, единственному тестировщику? Кстати, так до конца проекта я единственным и оставалась...
Начальник посмотрел, посмотрел, потом кинул мне ссылку на статью, "на, почитай".
Почитала. Устыдилась. Переписала тест-кейсы, в итоге наш ма-а-а-аленький проектик обогнал по количеству (и качеству!) самый большой в компании.
Погордилась собой :) И перешла к чек-листам.
Однако эту статью я вспоминаю до сих пор. Даже спустя 4 года третий пункт всегда всплывает у меня в мозгах, когда хочется схалтурить...
Крайне рекомендую прочитать, если вы вдруг по каким-то причинам видите ее впервые.
Копипастить статью не имеет смысла, поэтому небольшая история...
Работала я себе, работала на небольшом проекте. Проверяла реализацию по ТЗ, про тест-кейсы только краем уха слышала.
Но начальнику моему это не нравилось, показал он мне на тесты с соседнего проекта в TestLink-е. "Напиши и ты".
Сказано - сделано. В свободное от тестирования время (небезызвестные "очереди" в тестировании) начала, как паук, оплетать систему кейсами.
Занятие довольно скучное, быстро надоело. Так что тесты я стала писать копипастой из ТЗ:
Действия:
Ввести значения в поля «A» и «B».
Ожидаемый результат:
Значение в поле «Сумма» должно рассчитываться как сумма значений из полей «А» и «B». (Иногда еще также в графе с ожидаемым результатом встречаются такие «шедевры» как: См. в ТЗ, в соответствии с ТЗ, наблюдаем ожидаемые значения и т.п.).
Не, ну а что? Кому они, в конце концов, нужны то? Мне, единственному тестировщику? Кстати, так до конца проекта я единственным и оставалась...
Начальник посмотрел, посмотрел, потом кинул мне ссылку на статью, "на, почитай".
Почитала. Устыдилась. Переписала тест-кейсы, в итоге наш ма-а-а-аленький проектик обогнал по количеству (и качеству!) самый большой в компании.
Погордилась собой :) И перешла к чек-листам.
Однако эту статью я вспоминаю до сих пор. Даже спустя 4 года третий пункт всегда всплывает у меня в мозгах, когда хочется схалтурить...
Крайне рекомендую прочитать, если вы вдруг по каким-то причинам видите ее впервые.
Хорошая статья.
ОтветитьУдалитьНо не является ли такое написание тест-кейсов лишней работой?
Команда, работающая над продуктом, на столь безответсвенная и недумающая, для того, что бы провести по требованию серию очевидных проверок?
Нужна ли работа, которую иногда делают тестировщики на форуме, в блогах - чеклисты проверки того-то, проверки того-то (которые по сути представляют из себя набор входных параметров), или и так, адекватный специалист в состоянии увидев это требование проверить определенные параметры?
Этот комментарий был удален автором.
ОтветитьУдалитьА вот пример в стиле BDD (Given/When/Then):
ОтветитьУдалитьСценарий: Расчет суммы для двух натуральных чисел
Когда я рассчитываю сумму для A = <VA> и B = <VB>
То сумма должна быть <R>
Примеры:
|VA | VB | R |
|2 | 3 | 5 |
|3 | 2 | 5 |
|0 | 0 | 0 |
|0 | 1 | 1 |
|1 | 0 | 1 |
|-1 | 0 | -1|
|0 | -1 | -1|
|-1 | -1 | -1|
|1 | -1 | 0 |
Да, в виде таблички - почему бы и нет?
ОтветитьУдалитьЯ сейчас кейсы в виде таблички и расписываю, если, конечно, они небольшие.
Сергей, а вы вообще не пишите ни кейсов, ни чек-листов?
Как вы тогда, например, проверите чужой автотест без описания? Это слишком долго :)
|-1 | -1 | -1|
ОтветитьУдалитьЭто что же за сложение такое странное?
явна бага в тестах.
>> Teklaron:
Удалить>> |-1 | -1 | -1|
>> Это что же за сложение такое странное?
>> явна бага в тестах.
Это бизнес-логика такая :)
этот пост сделан наверное ради шутки.
ОтветитьУдалитьtoTeklaron: да, сложение и впрямь очень
Почему же ради шутки? Полезная ссылка, мое имхо
ОтветитьУдалитьКак раз насчет пунктов 3 и 4 в статье можно поспорить (пункт 2 принимается при соблюдении пары условий).
ОтветитьУдалитьТаким подходом впустую убито немало времени при минимальном выхлопе.
А чем хороши тест-кейсы из п.3 от "ленивого тестировщика"?
ОтветитьУдалитьЗачем дублировать конфлюенс?
А п.4 нужен не всегда, да.
Они плохи тем,что из класса эквивалентности выбрали 1 фиксированное значение. Недостаток скриптованного тестирования всегда заключается в отсутствии гибкости. Классы эквивалентности не дают 100% уверенности в том, что для приложения действительно все значения класса эквивалентны. Если указывать в тест кейсах диапазон значений, из которых следует выбрать А и В, вероятность постепенной проверки бОльшего количества вариаций значений растет => вероятность поймать баг специфических значений.
УдалитьЯ говорю о мануальном тестировании. С автоматизацией еще проще.
Диапазон - это хорошо.
УдалитьНо указать диапазон - не есть написать "согласно ТЗ" в результате :)