На сегодняшний день все QA-специалисты хорошо знакомы с актуальными теоретическими ограничениями тестирования ПО. В реальности на решение этих задач тратится очень много времени и сил.

При этом все хорошо понимают, что полностью отказываться от процесса тестирования глупо и нецелесообразно.

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

Это означает, что нужно понимать, [highlight dark=”no”]какая именно сфера действия и ограничения тестирования ПО бывает, и как нужно выполнять проверки.[/highlight]

Все далее изложенные наработки и принципы тестирования ПО основаны на опыте теоретического и практического исследования работоспособности веб-продуктов и их сопутствующих компонентов.

Принцип 1 – Обозначение

Чтобы протестировать программное обеспечение, необходимо заставить его функционировать некорректно.

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

Все умозаключения касательно качества продукта относятся к пониманию того, что тестирование, в отличие от процесса отладки, напрямую не связано с редактированием дефектов. Оно основано исключительно на их обнаружении.

Тестирование и технические спецификации

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

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

Принцип 2 – Тестирование или спецификация

Проверки не способны заменить спецификацию.

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

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

В некоторых случаях спецификации могут применяться для создания необходимого количества тестов, даже в автоматическом порядке. Но обратный процесс, без человеческого вмешательства, невозможен в принципе.

Регрессионные тесты

Спецификой тестирования, если анализировать особенности создания ПО, является постоянная склонность к возникновению ранее исправленных дефектов. Это, как головы гидры, которые после отсечения вновь вырастают на своих местах.

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

Принцип 3 – Регрессионное тестирование

Любое некорректное выполнение чего-то должно создавать тестовый случай, который навсегда станет элементом тестового пакета на проекте.

Этот принцип относится ко всем дефектам, которые могут возникать в процессе тестирования и создания ПО. Отсюда следует острая необходимость в использовании инструментария, который позволяет превращать неудачное выполнение в воспроизводимый тестовый случай.

Предсказания

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

Если у пользователя есть несколько сотен тестов или более, он может проверить их отдельно друг от друга. Но с ростом их суммы это превращается в крайне маловероятный сценарий.

Подобная задача потребует от человека навыков автоматизации тестирования ПО.

Принцип 4 – Применение предсказаний

Определение успеха или неудачи тестов должно выполняться в автоматическом порядке

Подобная формулировка оставляет данный вопрос открытым относительно формы подобных предсказаний. Иногда предсказания специфицируются по отдельности.

В некоторых исследованиях они встроенные, так как анализируемое ПО по умолчанию должно состоять из контрактов, на основе которых тесты используются как предсказание.

Тестовые ситуации, анализируемые вручную и автоматически

Больше половины тестовых случаев проверяются вручную. QA-специалисты самостоятельно додумывают интересные сценарии осуществления проверок и подготавливают соответствующие тесты.

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

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

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

Принцип 5 – Тестовые случаи, выполняемые вручную или автоматически

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

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

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

Тактика тестирования

Теперь нужно перейти от практики тестирования к процессу изучения новых технологий тестирования ПО, которые в некоторой степени уязвимы риском для мыслительного процесса.

Человек может сгенерировать идею, которая, как ему покажется, обещает усовершенствоваться и в дальнейшем верифицируется его интуицией.

Тестирование ПО – крайне сложный процесс и после анализа не все идеи могут быть полезными на практике.

Яркий тому пример – случайное тестирование. С позиции интуиции кажется, что все стратегии, применяющие данные о продукте, должны быть максимально полезными, по сравнению со случайным вводом данных. Но объективные показатели, такие как сумма найденных багов, говорят о том, что случайное тестирование ПО иногда превосходит разумные идеи.

Принцип 6 – Эмпирические оценки тактики тестирования

Всегда давайте оценку любой стратегии тестирования. Но какой бы интересной она не казалась сначала, оценивайте ее только с объективной точки зрения, применяя точные критерии в процессе поиска багов.

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

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

Тестировщик должен находить все дефекты, а не только один, даже наиболее важный.

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

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

Более правильным показателем считается время тестирования, которое необходимо для нахождения дефектов.

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

Принцип 7 – Критерии оценивания

Важная особенность стратегии тестирования – это сумма найденных ошибок как функция времени.

Функция поиска, то есть сумма дефектов, зависящая от времени, крайне полезная вещь.

Применяя программную базу с распространенными дефектами, можно легко оценить стратегию, проанализировав, сколько дефектов база позволит найти за определенный отрезок времени.

Выводы

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