Недавно я упоминала в видео, доступном для подписчиков, что не рассказала, почему используется метод тестирования с помощью черного ящика, несмотря на его очевидные недостатки. Напомню, что о тестировании методом черного ящика мы говорили в этой статье. При работе по этому методу, мы имеем только входные и выходные параметры и ничего не знаем о том, что внутри.
Его основным недостатком является невозможность покрытия тестами всего программного функционала, т.к. мы точно не знаем, какой он и как должен работать. Такие ситуации могут быть, о них я расскажу позже. Для тестирования методом черного ящика используются специальные техники, т.к. мы знаем входные параметры и можем их исследовать, находить классы эквивалентности и исследовать их границы, как в этой статье, или создавать тесты для каждой пары значений, как в этой статье, или следовать интуиции и изучать поведение системы, отклоняющееся от заданных характеристик, при помощи методов исследовательского тестирования, как в этой статье.
Существует две основных причины, по которым без тестирования методом черного ящика не обойтись:
- на проекте много ручных тестировщиков, которые тестируют программу преимущественно методом черного ящика.
К чему это может привести?
Если пирамида тестов является перевернутой, как в случае с "рожком мороженого", описанным в этой статье, то программисты будут узнавать о дефектах со значительными задержками, и только при тестировании всей системы, а не после написания новых модулей. Это негативно скажется на их работе и может привести к частой смене программистов на проекте. Разбираться в чужом коде занятие неблагодарное, и в итоге ничего другого не останется, как тестировать весь чужой код целиком, методом черного ящика. - крупная компания купила мелкий стартап, т.е. есть программный код, приносящий прибыль, и его нужно дорабатывать, выпускать новые версии, адаптировать для своих пользователей и решать другие задачи, связанные с его доработкой. На программу, конечно же, есть документация, но и в этом случае может не найтись желающих разбираться в чужом программном коде, т.к. время программистов дорого. Что в итоге остается? Правильно, метод черного ящика.
Как же можно избежать тестирования методом черного ящика?
Существует сравнительно новый метод разработки через тестирование, который мы рассматривали в этой статье. При работе по этому методу вначале пишутся автоматизированные тесты, затем под них пишется программный код. Автотесты работают быстро и позволяют за считанные минуты прогнать тесты на одном или нескольких модулях. В этом случае мы тестируем методом белого ящика, когда весь функционал полностью известен и покрыт тестами.
Для того, чтобы узнать, как эффективно и последовательно проводить тестирование, советую почитать книгу Рекса Блэка, одного из признанных гуру в этой области: