Наверное всем тестировщикам известно, что такое негативное тестирование. Думаю даже, что это любимый тип тестирования для многих из-нас.
При выполнении негативного тестирования мы проверяем как ведет себя приложение, получая на вход неправильные данные (например, символы в поле, где ожидаются цифры) или в нестандартных ситуациях (например, если выключить принтер во время печати документа) .
Во многих ресурсах по тестированию, при описании последовательности выполнения видов тестирования, негативное тестирование отделяют в отдельную процедуру и ставят на 4-е место.
При этом приводится следующий план тестирования:
При выполнении негативного тестирования мы проверяем как ведет себя приложение, получая на вход неправильные данные (например, символы в поле, где ожидаются цифры) или в нестандартных ситуациях (например, если выключить принтер во время печати документа) .
Во многих ресурсах по тестированию, при описании последовательности выполнения видов тестирования, негативное тестирование отделяют в отдельную процедуру и ставят на 4-е место.
При этом приводится следующий план тестирования:
- Изучение документации (для того, чтобы понять что, собственно тестируем)
- Дымовое тестирование или Smoke testing (первый прогон программы, чтобы понять работает ли она вообще)
- Позитивное тестирование (для того, чтобы проверить работу программы при получении ею "правильных" входных данных)
- Негативное тестирование
Но почему так?! Почему нужно негативное тестирование отделять от позитивного и выполнять потом? Как показывает практика, оставленное на потом почти всегда остается не выполненным.
А можем ли мы сказать что программа работает, если проверили ее реакцию только на правильные входные данные?
А главное, я вот представляю ситуацию. Сижу я тестирую формочку. Проверила все соответственно ТЗ, проверила как обрабатываются данные, которые ожидается, что пользователь будет вводить в поля (заметьте, ожидается совсем не значит, что так и будет) и тут же в моем тестерском уме возникает небезосновательное подозрение, что если ввести вот в это поле "0" - то произойдет что-то нехорошее :) И что? Я должна сказать себе "Нет. По плану у меня сейчас позитивное тестирование. Негативное на следующей неделе, вот тогда и проверю с нулем"?
По-моему, такой подход неправильный. Он не просто неправильный, он неэффективный.
Во-первых, проведение отдельно позитивного и негативного тестирования займет больше времени, чем если их совместить.
Во-вторых, есть риск, что негативное тестирование вообще не будет проведено или проведено кое-как в условиях страшного недостатка времени.
А в третих, это противоречит тестерскому мышлению. Ведь основная задача тестировщика - стараться проверить реакцию программы на все действия, которые с ней может совершить пользователь. И, поверьте, большинство этих действий не укладываются в критерии позитивного тестирования.
А можем ли мы сказать что программа работает, если проверили ее реакцию только на правильные входные данные?
А главное, я вот представляю ситуацию. Сижу я тестирую формочку. Проверила все соответственно ТЗ, проверила как обрабатываются данные, которые ожидается, что пользователь будет вводить в поля (заметьте, ожидается совсем не значит, что так и будет) и тут же в моем тестерском уме возникает небезосновательное подозрение, что если ввести вот в это поле "0" - то произойдет что-то нехорошее :) И что? Я должна сказать себе "Нет. По плану у меня сейчас позитивное тестирование. Негативное на следующей неделе, вот тогда и проверю с нулем"?
По-моему, такой подход неправильный. Он не просто неправильный, он неэффективный.
Во-первых, проведение отдельно позитивного и негативного тестирования займет больше времени, чем если их совместить.
Во-вторых, есть риск, что негативное тестирование вообще не будет проведено или проведено кое-как в условиях страшного недостатка времени.
А в третих, это противоречит тестерскому мышлению. Ведь основная задача тестировщика - стараться проверить реакцию программы на все действия, которые с ней может совершить пользователь. И, поверьте, большинство этих действий не укладываются в критерии позитивного тестирования.
"Во многих ресурсах по тестированию"
ОтветитьУдалитьа можно ссылку где это так делают?
Разделение на позитивное и негативное тестирование происходит на уровне тест кейсов, т.е. кейс может быть позитивным или негативным, и тест съюты строят по функционалу а не признаку позитивный\негативный
Да, согласна с Вами SpotHolder. При построении плана функционального тестирования, и, в частности тест сьютов, мы должны концентрироватся на функционале. Самые критичные с сложные модули системы тестим в первую очередь, выполняя как позитивные тести, так и негативные тесты.
ОтветитьУдалитьЯ очень удивилась, когда в статьях и обсуждениях увидела другую точку зрения.
Сейчас вряд ли вспомню все места, где я подобное читала, но вот несколько.
1. http://software-testing.ru/library/testing/general-testing/88
2. http://softwaretestingwinners.blogspot.com/2009/03/habits-of-highly-effective-testers.html
Особенно меня смутили слова в комментарии "Not performing negative testing does not mean that testing is not being performed. The project management team always has the decision that the testing team would not perform negative testing."
хм, действительно пишут, но это скорее неправильные пчелы. ну и мед они дают неправильный
ОтветитьУдалитьЗдравствуйте.
ОтветитьУдалитьЯ считаю, что приоритеты надо расставлять не в зависимости от типов тестирования, а для того, чтобы найти наиболее критичные дефекты как можно быстрее. Поэтому иногда, например во внутренних проектах, негативное тестирование можно задвинуть подальше. В других случаях только и делают, что выполняют негативное тестирование. Идеального плана тестирования для всех случаев не бывает.