Home

Автор: Алексей Лемешко

Статья была переработана с учётом полученной в форуме критики и рекомендаций.

Этой статьей я хотел бы описать своё понимание тестирования программного обеспечения — процесса не тривиального, как мне всегда казалось, и, я даже не мог себе представить, весьма интересного.

Меня всегда интересовало, что такое тестирование ПО. Зачем нанимать кого-то для тестирования программного продукта, если разработчик и сам может потратить пару часов на такое не значительное по приоритету задание. И, наконец-то, зачем вообще тестировать? Ведь программисты ребята умные — пишут правильно. Но

не все так просто как мне казалось.

Перейдя из программистов в тестеры, не имея достаточного количества теории за пазухой, я достаточно долго пытался «поломать» программный продукт, давая на вход заведомо неверные входные данные. И, как не странно, ломалось. Создавалось сообщение об ошибке, и очередной день считался прожитым не зря.

Позже, я начал сталкиваться с тем, что, сколько тесты не гоняй, а ошибки все равно выплывают. Не имея какого-либо представления о том, что и как должно даваться «на вход» тестируемому приложению процесс тестирования казался бесконечным. Как результат — замкнутый круг, в котором сорванные сроки на тестирование, злой ПМ и уставшие от «глупостей» разработчики.

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

1. Изучение спецификации. Эта стадия самая важная, её ещё называют анализом дизайна и/или требований. Иногда применяют название «тестирование спецификации», чуть ниже мы поймём, почему именно «тестирование». Тут надо внимательно прочитать документацию (спецификацию) по приложению.
2. Дымовое тестирование. На этой стадии надо проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно).
3. «Позитивное» тестирование. На этой, третей стадии, надо проверить результат работы приложения при получении им «правильных» входных данных.
4. «Негативное» тестирование. Это четвертая, завершающая, стадия начального тестирования. Тут надо посмотреть, как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того, чтоб определить, как ведет себя приложение в таком случае. Если такой вариант описан в спецификации, а он должен быть описан, то сравнить ожидаемый результат с полученным результатом.

Итак, рассмотрим все по порядку.

Спецификация, требования, SRS.

Как определить когда и как должно работать само приложение, когда и как оно должно «ломаться» (то есть как система или её модуль должен реагировать на невалидные данные или неверное поведение пользователя)? Что должно быть в результате правильной отработки, при каких условиях и входных данных правильная отработка должна иметь место? Что должно быть в результате не правильной отработки тестируемого приложения, при каких условиях она должна иметь место?

На все эти вопросы есть ответ в документации тестируемого приложения. Во всяком случае, он, ответ, должен там быть, иначе документация не полная, что равняется ошибке в документации. Хочу оговориться, что уже на этой стадии могут возникать первые дефекты — дефект в спецификации (в требованиях) такой же по важности для системы (а порой и более высокий по приоритету!) дефект. Стоит также оговориться, что тестирование требований это такой полноценный же вид тестирования, которому незаслуженно уделяют мало внимания. Основными показателями успешного тестирования требований является достижение критериев полноты (тестопригодности) и непротиворечивости требований.

Документация дает возможность понять для себя основные ступеньки проверки приложения, где и как должно приложение работать, где «ломаться». И, что не мало важно, как ломаться. Что «говорить» при успешной отработке, какие сообщения на ошибку могут/должны появляться при отработке.

Поняв все «премудрости» требований к приложению и особенности реализации этих требований разработчиком, можно приступать к тестированию конечного результата.

Процесс тестирования

Этот процесс можно описать следующими шагами:

1. Проверить, как работает приложение, когда оно получает на вход «правильные» данные (чтоб узнать «что такое хорошо и что такое плохо» читаем документацию);
2. Если все работает и работает правильно (т.е. именно так как описано в спецификации), следующим шагом является проверка граничных значений (т.е. там, где начинаются «правильные» данные и там где они заканчиваются);
3. Проверка работы приложения при вводе данных, которые не входят в область допустимых значений (опять таки, смотрим спецификацию).

В первом и втором пункте описан процесс, который называется «позитивным» тестированием. «Позитивное» тестирование — это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению тестируемой системы.

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

Однако предшествовать «позитивному» и «негативному» тестированию должны работы по выполнению «дымового» тестирования.

Информационный словарь дает достаточно четкое определение термина «дымовое тестирование»:

• рудиментарная форма тестирования программного продукта после изменения его конфигурации либо после изменения его (программного продукта) самого. В процессе дымового тестирования тестировщик проверяет ПО на наличие «дыма», т.е. ищет какие-либо критические ошибки программы;
• первый запуск программы после её критического изменения или «сборки».

Приоритеты в тестировании

Почему «позитивное» тестирование считается на порядок более важным, чем «негативное»?

Предположим, что система не слишком устойчива к «плохим» вводимым данным. Это страшно? Зачастую не слишком. Пользователи рано или поздно научатся обходить «подводные камни», не будут делать «опасные» или «неразрешённые» действия, служба технической поддержки скоро запомнит, какие проблемы обычно возникают у пользователей и будет давать советы типа «ни в коем случае не оставляйте это поле пустым, а то ...».

Но — всего этого не будет вовсе, если система не выполняет свое основное предназначение, если пользователи (заказчики) не могут решить свои бизнес задачи, если они все делают правильно, вводят хорошие данные, но не получают результата. И посоветовать им ничего в этой ситуации нельзя. И они уходят...

Именно поэтому «позитивное» тестирование гораздо, гораздо важнее «негативного».

Впрочем, это не означает, что «негативными» тестами можно пренебречь, т.к. не на всех этапах жизненного цикла ПО приоритеты ценностей сохраняются неизменными.

Резюме

Теперь, сделав первые удачные шаги в тестировании приложения и получив положительный результат, можно думать о более мудреных способах протестировать приложение, как говорится: «Дальше — больше». Все зависит от глубины необходимого уровня тестирования, желания и возможности проверить приложение. Естественно, описанные выше четыре стадии не покрывают полного цикла тестирования приложения, однако являются обязательными для начального тестирования.

Желаю удачи.

Спасибо:

А. Баранцеву и В. Панкратову за консультации.