Тестирование программного обеспечения. Основы

Цель № 6. Обнаружение отказов и дефектов в ПО. В этом случае мы выявляем уже занесённые в результате разработки ПО дефекты. Это могут быть: дефекты в логике работы программы; ошибки в алгоритмах; дефекты в интерфейсе и взаимодействии с пользователем; дефекты в работе с внешними системами и базами данных; недочёты в документации и описании функционала. Проводится систематический поиск и выявление таких дефектов. Это позволяет устранить их до выхода в продуктивное окружение, чтобы обеспечить его корректную и безаварийную работу. В идеале, все дефекты должны быть найдены и исправлены на этапе тестирования, прежде чем программа будет поставлена пользователю.

Цель № 7. Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения в отношении уровня качества объекта тестирования. В ходе тестирования специалисты по тестированию проверяют соответствие программы требованиям, выявляют дефекты. На основании полученных результатов формируют отчёты, в которых указывают количество и критичность найденных дефектов, степень реализации функциональных и нефункциональных требований и другие показатели качества. Эта информация позволяет заинтересованным сторонам принять обоснованное решение о готовности программы: нужна ли доработка для устранения дефектов, возможен ли запуск в эксплуатацию или требуется ещё один цикл разработки и тестирования.

Цель № 8. Соблюдение договорных, правовых или нормативных требований, или стандартов и/или проверка соответствия объекта тестирования таким требованиям и стандартам. Специалисты по тестированию проверяют, что разрабатываемая программа соответствует государственным или международным стандартам, законодательству и т. д. Пример: программа работает с платёжными системами и должна соответствовать их стандартам и требованиям. При тестировании специалисты должны убедиться в этом, в противном случае данная программа не будет допущена к работе с платёжными системами.

Цели тестирования могут отличаться, в зависимости от этапа жизненного цикла программы, на котором проводится тестирование, а также в зависимости от назначения и типа тестируемого компонента или программы.

Верификация и валидация

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

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

Подтвердить, что заданные требования полностью реализованы в программе – означает необходимость убедиться, что программисты сделали то, что заказчик зафиксировал в требованиях. Рассмотрим на примере. У заказчика есть требование к программе по сложению чисел. Смотрите таблицу:

Верифицируя программу при проведении тестирования, мы должны проверить, что изложенные требования реализованы и всё сделано так, как требовалось. Мы проверяем, что можно вводить только положительные целые числа, что максимальное количество вводимых и отображаемых символов равно четырём, что в поле можно вводить информацию с клавиатуры, вставлять данные из буфера обмена и из поля можно копировать данные в буфер обмена. Если программа одну из проверок не пройдёт, к примеру, из поля нельзя будет копировать данные, то программа не она верификацию, так как не все требования реализованы. Если же все требования соблюдены, программа пройдёт верификацию. С этим разобрались.

Теперь рассмотрим валидацию.

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

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

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

Позитивное и негативное тестирование

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

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

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

Если в процессе позитивного тестирования мы не сможем ввести цифры в поле ввода, тест не пройден. Если сможем – тест пройден.

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

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

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

Ложноположительные и ложноотрицательные результаты тестирования

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

Ложноположительные результаты тестирования – во время проверки функционала программы принимаем неправильное поведение программы за её корректное поведение.

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

Ложноотрицательные результаты тестирования – во время проверки функционала программы, принимаем правильное поведение программы за её некорректное поведение.

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

Ручное и автоматизированное тестирование

Тестирование может проводиться как вручную, так и автоматизировано с помощью специализированных инструментов, которые позволяют выполнять тесты не вручную, а автоматизировано. Рассмотрим эти понятия.

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

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

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

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

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

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

Чтобы заниматься таким тестированием необходимо обладать специализированными навыками и знать языки программирования.

Какое тестирование можно автоматизировать?

– функциональное тестирование сайтов;

– функциональное тестирование настольных приложений;

– функциональное тестирование мобильных приложений;

– тестирование API информационных систем.

Есть и другие сферы применения автоматизированного тестирования. Некоторые ключевые характеристики автоматизированного тестирования:

– Можно запускать тесты регулярно и независимо от занятости человека. Это обеспечивает непрерывное тестирование.

– Ускоряет и упрощает процесс тестирования.

– Повышает надёжность тестирования благодаря исключению из процесса человеческого фактора.

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

Тестовое окружение и не только

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

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

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

Основные характеристики продуктивного окружения:

– в нём работает окончательная версия программы после всех тестов;

– в нём не разрабатывается и не тестируется программа;

– оно не используется для исправления дефектов;

– обеспечивает максимальную производительность и доступность;

– содержит реальные данные и учётные записи пользователей;

– настроена на безопасность и конфиденциальность данных;

– требует высокой доступности и производительности по сравнению с тестовым окружением.

Тестовое окружение – окружение, предназначенное для тестирования и отладки программ.

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

Основные характеристики тестового окружения:

– в нём разрабатывается и тестируется программа до выпуска в продуктивное окружение;

– используется для исправления дефектов и проверки функциональности до переноса в промышленное окружение;

– имитирует реальные условия работы, но может иметь меньшие мощности по сравнению с промышленным окружением;

– содержит не реальные данные, а тестовые.

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

В различных компаниях могут использоваться и другие окружения. Примеры названий: dev (дев), test (тест), qa (кью-эй), preprod (препрод), stage (стейдж), preview (превью) и т. д. То, какие окружения используются, зависит от специфики работы организации и разрабатываемых программ, поэтому мы не будем их рассматривать. Но вы должны знать, что кроме продуктивного и тестового окружения в ряде организаций существуют и другие окружения.

Тестовая документация и артефакты

В процессе работы специалисты по тестированию создают различные артефакты[11] и документы. Кстати, дефект – это один из артефактов работы тестировщика. Познакомимся поближе с документами и артефактами, которые могут создавать и с которыми могут работать специалисты по тестированию.

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

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

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

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

В плане тестирования фиксируется следующая информация:

– Цели и задачи тестирования. Здесь определяется, что именно нужно проверить в программном обеспечении.

– Объекты тестирования[12]. Какие модули, функциональные возможности, интерфейсы и т. д. будут тестироваться.

– Уровни, типы и виды тестов. Например, функциональное тестирование, нефункциональное тестирование, тестирование производительности, и т. д.

– Приоритеты тестов. В какой последовательности будут выполняться тесты.

– Ответственные за тестирование. Кто конкретно будет разрабатывать, выполнять и отслеживать результаты тестов.

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

– Тестовое окружение. Какое тестовое окружение будет использоваться в тестах.

– Риски. Что может увеличить сроки тестирования или блокировать тестирование и как эти риски нивелировать.

– Критерии успешности тестирования. Что считать успешным тестированием и какие условия должны выполняться.

В зависимости от организации в план тестирования могут включать и другую информацию, которую посчитают важной. С примером плана тестирования вы можете ознакомиться на сайте автора[13].

Разработку планов тестирования проводят опытные специалисты по тестированию или руководители и менеджеры по тестированию.

Функциональная карта

Функциональную карту ещё называют «интеллектуальной картой», «диаграммой связей», «ассоциативной картой» и т. д. Мы её называем «функциональной», так как на ней отражены функциональные области программы, которые необходимо тестировать.

Функциональная карта программы – схема, которая визуально отображает основные функциональные возможности программы и позволяет быстро понять её назначение и принцип работы.

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

Как функциональные карты применяются специалистами по тестированию в работе? Создавая функциональную карту программы, специалист разбивает программу на логические функциональные блоки и описывает её ветвлениями. Рассмотрим на простом примере, взяв за основу программу «Блокнот», которая имеется в операционной системе Windows:

У программы «Блокнот» есть «Заголовок» (1), «Строка меню» (2), «Форма ввода данных» (3). Названные блоки (элементы) в свою очередь делятся на дополнительные элементы.

Заголовок (1) имеет:

– название программы в заголовке;

– кнопка «Свернуть»;

– кнопка «Развернуть»;

– кнопка «Закрыть».

Строка меню (2) имеет:

– пункт меню «Файл»;

– пункт меню «Правка»;

– пункт меню «Формат»;

– пункт меню «Вид»;

– пункт меню «Справка».

Форма ввода данных (3) имеет:

– поле ввода текста;

– полоса прокрутки.

Всё перечисленное можно отобразить на функциональной карте:

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

– синий круг – это значит ветвление будет дальше продолжаться;

– зелёный круг с галочкой – это является конечной проверкой.

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

Пункт меню «Справка» имеет пункты:

– просмотреть справку.

– отправить отзыв.

– о программе.

Функциональная карта получит следующее продолжение:

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

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

Тест-кейс

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

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

Тест-кейс – это чёткое описание действий, которые необходимо выполнить, чтобы проверить работу программы (поля для ввода, кнопки и т. д.). Данное описание содержит: действия, которые надо выполнить до начала проверки – предусловия; действия, которые надо выполнить для проверки – шаги проверки; описание того, что должно произойти, после выполнения действий для проверки – ожидаемый результат; действия, которые необходимо выполнить в самом конце, чтобы привести систему в первоначальное состояние, сбросив все внесённые нами изменения – постусловия.

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

Тест-кейс – это описание того, что надо сделать, чтобы проверить определённый функционал программы и что должно произойти после того, как мы выполним описанные действия.

Почему здесь приведено так много определений? Для того, чтобы вы чётко осознали, что такое тест-кейс, так как в своей работе специалист по тестированию очень много времени уделяет работе с тест-кейсами: написание, правка, проверка программ по тест-кейсам и т. д.

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

Рассмотрим основные атрибуты, из которых состоит тест-кейс и которые используются в большинстве организаций:

1) Номер тест-кейса – уникальный идентификатор тест-кейса. Если у вас тысячи тест-кейсов, то при общении с коллегами вам будет проще сообщить номер тест-кейса, ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.

2) Заголовок – краткое, понятное и ёмкое описание сути проверки.

3) Предусловия – описание действий, которые необходимо предварительно выполнить или учесть перед началом проведения проверок.

4) Шаги проверки – описание последовательности действий, которые надо выполнить для проверки.

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

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

Рассмотрим тест-кейс на примере программы для сложения чисел:

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

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