The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Есть программное обеспечение, которое нужно протестировать. Есть команда тестировщиков. В бюджете есть некоторые деньги. В расписании есть некоторое время. Мы начинаем прямо сейчас. Тестировщики пытаются сломать продукт, находя ошибки, сообщая о них, взаимодействуя с программистами при необходимости, делая все возможное, чтобы найти, что не так. В конце концов, они останавливаются и говорят “мы закончили”. Как они знают, когда остановиться? Когда достаточно протестирования? Очевидно - когда осталось нет ошибок и продукт может быть отправлен! Если вы думаете так, у меня плохие новости для вас. Вы основательно ошибаетесь.
Все это идеально объясняет Гленфорд Майерс в своей великой книге “Искусство тестирования программного обеспечения”. Я просто повторю это здесь.
Во-первых, “тестирование - это процесс выполнения программы с целью нахождения ошибок” (стр. 6). Обратите внимание, цель - найти ошибки. Не доказать, что продукт работает хорошо, а доказать, что он не работает так, как задумано. Цель любого тестировщика - показать, как продукт может быть сломан, как он не справляется с разными входными данными, как он выходит из строя при стрессе, как он неправильно воспринимает пользователя, как он не соответствует требованиям. Вот почему доктор Майерс называет тестирование “деструктивным, даже жестоким процессом” (стр. 6). Это то, чего большинство тестировщиков не понимают.
Во-вторых, любое программное обеспечение имеет неограниченное количество ошибок. Доктор Майерс говорит, что “нельзя протестировать программу, чтобы гарантировать ее безошибочность” (стр. 10) и что “практически невозможно найти все ошибки в программе” (стр. 8). Это также то, чего большинство тестировщиков не понимают. Они считают, что количество ошибок ограничено, и что они должны найти все и закончить. Но их количество неограничено, в любом программном продукте. Неважно, насколько маленьким или большим, сложным или простым, новым или старым является продукт.
Имея в виду эти аксиомы, давайте попробуем решить, когда тестировщикам нужно остановиться. Согласно доктору Майерсу, “одним из самых сложных вопросов при тестировании программы является определение момента остановки, поскольку невозможно знать, является ли только что обнаруженная ошибка последней оставшейся ошибкой” (стр. 135).
Они не могут найти все ошибки, сколько бы времени мы им ни дали. И они мотивированы находить все больше и больше ошибок. Но в какой-то момент мы должны принять решение и выпустить продукт. Получается, мы выпустим его с ошибками внутри? Да, действительно! Мы выпустим продукт, полный ошибок. Вопрос только в том, сколько из них уже было найдено и насколько они критичны.
Давайте все это объединим. Слишком много ошибок, чтобы найти все из них в разумное время. Однако мы должны выпустить новую версию, рано или поздно. В то же время, тестировщики всегда будут говорить нам, что там есть еще больше ошибок и они могут найти их, просто им нужно больше времени. Что делать?
Доктор Майерс говорит, что “поскольку цель тестирования - найти ошибки, почему бы не сделать критерием завершения обнаружение заранее определенного количества ошибок?” (стр. 136). Действительно, мы должны предсказать, сколько ошибок достаточно найти, чтобы иметь желаемый уровень уверенности в том, что продукт готов к отправке. Затем отправим его, осознавая, что в нем все еще есть неограниченное количество еще необнаруженных ошибок.
Дэвид Уэст в книге Object Thinking говорит, что “программное обеспечение выпускается для использования не тогда, когда известно, что оно правильное, а когда темп обнаружения ошибок замедляется до того, который руководство считает приемлемым” (стр. 13).
Таким образом, единственным действительным критерием для завершения процесса тестирования является обнаружение предсказанного количества ошибок.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-15 at 07:07
