Why 100% Test Pass Rates Are Bad by Andrew Schiano
Когда тест показывает оценку 100%, как правило есть причина для ликования. Это означает, что у вашего продукта высокое качество. Тесты, которые так тщательно разработаны, проходят, доказывая, что продукт работает так, как ожидалось. Также показывает, что ваши тестовые случаи высокого качества; результаты воспроизводимы, и они успешно проверяют функциональность продукта. Эта та цель, к которой ты стремился с начала тестирования, правильно? Если это так, то вы выбрали неверную цель.
100%-е прохождение подразумевает, что ваш продукт работает точно, как ожидалось. Задача тестирования, однако, не доказывать, что приложение работает, как ожидалось. В сущности, эта цель может даже не достижима, потому что все сложные приложения имеют дефекты. Какой смысл всё это делать, имея цель, которая не может быть достигнута? Ваша цель должна быть в написании тестов, которые обнажают эти дефекты так, чтобы можно было сделать обоснованное решение об их исправлении.
Другая причина неверной цели 100%-го прохождения в заключается том что, когда все ваши тесты последовательно проходят, они прекращают обеспечивать вас новой информацией. Вы можете наблюдать прекрасный проход тестов каждое утро, и в дальнейшем не обращать внимание на них. Другими словами, как только вы достигнете своей "цели", ваши тесты перестанут помогать вам улучшить ваш продукт.
Чтобы быть справедливым, с точки зрения управления 100%-й проход тестов это верная цель. Так как это убеждает менеджера в качестве продукта. Но если менеджер и тестировщик оба стремятся к совершенному проходу тестов, это не вызывает доверия. В этом случае, никто не ищет баги и 100% проход тестов мало чего значит.
Теперь предположим у вас прекрасный проход тестов, но тестировщики должны стремится доказать, что приложение не работает как ожидалось. Прекрасный проход тестов показывает руководству, что несмотря на факт о том, что вы ищете баги, вы всё ещё не можете найти их. Это дает уверенность руководству в области качества программного обеспечения.
Если у вас 100%-й проход тестов, и есть ещё время до Завершения Всего Тестирования, не думайте что это конец игры. В продукте есть ошибки, и ваши тесты не могут найти их. Измените тесты. Напишите новые. Но продумайте каждый тестовый случай с целью доказать, что программное обеспечение не работает как ожидалось. Рекомендации могут показаться очевидными, а некоторые тестировщики не подумают в таком плане; они очень сильно заинтересованны иметь гладкий тест и по плану.
Edsger Dijkstra писал, "Тестирование может показать присутствие ошибок, но не их отсутствие." Как только вы измените ваш тип мышления и напишите тесты доказывающие, что продукт не работает, вместо того, чтобы доказывать, что он работает, вы будете удивлены, как насколько больше ошибок вы обнаружите. Это простое изменение сделает из вас лучшего тестировщика, и вашим продуктам будет лучше от этого.
Чтобы быть справедливым, с точки зрения управления 100%-й проход тестов это верная цель. Так как это убеждает менеджера в качестве продукта. Но если менеджер и тестировщик оба стремятся к совершенному проходу тестов, это не вызывает доверия. В этом случае, никто не ищет баги и 100% проход тестов мало чего значит.
Теперь предположим у вас прекрасный проход тестов, но тестировщики должны стремится доказать, что приложение не работает как ожидалось. Прекрасный проход тестов показывает руководству, что несмотря на факт о том, что вы ищете баги, вы всё ещё не можете найти их. Это дает уверенность руководству в области качества программного обеспечения.
Если у вас 100%-й проход тестов, и есть ещё время до Завершения Всего Тестирования, не думайте что это конец игры. В продукте есть ошибки, и ваши тесты не могут найти их. Измените тесты. Напишите новые. Но продумайте каждый тестовый случай с целью доказать, что программное обеспечение не работает как ожидалось. Рекомендации могут показаться очевидными, а некоторые тестировщики не подумают в таком плане; они очень сильно заинтересованны иметь гладкий тест и по плану.
Edsger Dijkstra писал, "Тестирование может показать присутствие ошибок, но не их отсутствие." Как только вы измените ваш тип мышления и напишите тесты доказывающие, что продукт не работает, вместо того, чтобы доказывать, что он работает, вы будете удивлены, как насколько больше ошибок вы обнаружите. Это простое изменение сделает из вас лучшего тестировщика, и вашим продуктам будет лучше от этого.
