7 популярных мифов о тестировании

Миф 2

Тестируют только полностью написанную программу

Это не так. Тестирование идёт параллельно с разработкой. Чем раньше удаётся обнаружить ошибки, тем проще и дешевле будет их исправить.

Так, при разработке технических требований можно сколько угодно править и дополнять проектную документацию. Но если выяснится, что в требованиях было что-то не то, а код уже написан, последствия будут серьёзные. Возможно, придётся переписывать программу, а это время и большие затраты. Поэтому аналитики тщательно тестируют требования — ещё до начала разработки кода.

Когда разрабатывается код, тестирование проводят сами программисты и тестировщики. Они проверяют каждый готовый модуль. Программисты ищут ошибки в коде, а после подключения к программе тестируют модуль ещё раз.

Затем за программу берутся тестировщики. Они проверяют программу снаружи, не заглядывая в код: работают с ней так, как это будет делать пользователь, ищут баги вручную или с помощью автоматических тестов. Потом они передают сведения о найденных ошибках разработчикам, чтобы те их исправили. И так с каждым модулем до конца разработки.

А ещё делают так: программист сначала пишет тест на языке разработки, чтобы проверить какие-то функции будущей программы. Затем он пишет код, который выполняет действия, необходимые для прохождения этого теста. Когда тест удачно пройден, разработчик переходит к следующим функциям. Это называется test-driven development (TDD), или разработка через тестирование.

Бывает даже, что сначала тестировщик составляет пошаговый план поведения пользователя. Потом специалисты по автоматизации тестирования составляют автоматические тесты. А вот под них уже пишется код — такой, чтобы он прошёл эти тесты. Технология называется behavior-driven development (BDD), или разработка на основе поведения.

Когда программа полностью написана, её тестируют как единое целое. Только когда все баги будут исправлены, программу передают заказчику.

Миф 3

Любую программу можно протестировать так, что в ней совсем не останется ошибок

В это верят клиенты и даже некоторые руководители проектов. Но в жизни так не бывает:

• Даже в небольшой программе есть огромное количество комбинаций входных данных. Проверить их полностью невозможно.
• Количество возможных действий пользователя и перемещений по программе также слишком велико для полной проверки.

И миллион тестов не даёт никаких гарантий: миллион первый тест может запросто оказаться ошибочным. Пример — так называемая ошибка гейзенбаг. В рабочих условиях она появляется, а при отладке пропадает.

Из-за одной такой ошибки в США облучились люди. Аппарат Therac-25 использовали для лучевой терапии больных раком. В программе управления возник гейзенбаг: оператор нажимал на кнопку, пациент получал дозу облучения, но иногда датчик не улавливал данные и выдавал сообщение «Нулевая доза». Оператор ещё несколько раз жал на кнопку, и пациент получал огромную дозу радиации. В итоге несколько человек погибло.

Миф 4

Только тестировщики несут ответственность за программу, и если что-то не так — во всём виноваты они

Нет, программу делает вся команда и нельзя перекладывать ответственность на одного её члена. Тестировщики выявляют баги и сообщают о них разработчикам и проектировщикам. А те принимают решение: исправлять их или по каким-то причинам оставить.

Бывает, что тестировщикам просто не хватает времени на глубокую проверку: например, программу дорабатывали на ходу, меняли требования и добавляли функции. В таких условиях тестировщики иногда не справляются и продукт получается так себе.

Миф 5

Тестирование — скучная и монотонная работа

Нет. Тестирование похоже на дизайн, это очень творческая работа. Тестировщик должен понимать, как работает система в целом и отдельные её части, найти слабые места и проверить их на сбои в первую очередь. Он разрабатывает тестовые подходы и пишет сами тесты. Тут не обойтись без воображения и фантазии.

Миф 6

Тестировщики не любят программистов и нарочно придираются к мелочам

Чтобы выпустить хороший программный продукт, нужно найти в нём все (или почти все) ошибки. Так что ничего личного — это просто работа.

Не стоит обижаться на тестировщика, даже если он тычет пальцем в спецификацию и говорит, что в каком-то месте должен быть шрифт Arial Narrow, а у вас стоит обычный Arial. Не думайте, что он придирается, лучше сделайте как написано в спецификации. По каким-то причинам там действительно нужен этот шрифт.