Организация тестирования

Организация тестирования

Тестирование начинается   как только было решено , что команда будет работать над проектом .

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

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

В случае если " smoke test failed !!!", вы отправляете приложение на доработку.

Если же " smoke test passed !!!", то нужно перейти к следующему виду тестирования -  регрессионное тестирование  ( Regression testing ).

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

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

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

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

Тестовые работы

Планирование(Разработка тест – плана)

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

• координацию персонала
• управление оборудованием и другими средствами, необходимыми для организации тестирования
• планирование обработки нежелательных результатов (т.е. является управлением определенными видами рисков)

Разработка сценариев тестирования

Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования.

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

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

результаты тестирования.

• Разработка тестового окружения

Используемое для тестирования окружение должно быть

совместимо с инструментами программной инженерии.

Это окружение должно обеспечивать разработку и

контроль тестовых сценариев, ведение журнала

тестирования, и возможности восстановления ожидаемых

и отслеживаемых результатов тестирования.

4. Выполнение тестов

Выполнение тестов должно содержать основные

принципы ведения научного эксперимента:

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

Ряд вопросов выполнения тестов и других работ по тестированию освещен в стандарте IEEE 1008-87.

5. Анализ результатов тестирования

Для определения успешности тестов их результаты должны оцениваться и анализироваться.

Успешность тестирования подразумевает, что тестируемое

программное обеспечение функционирует так, как

ожидалось и в процессе работы не приводит к

непредусмотренным последствиям. Не все такие

последствия обязательно являются сбоями, они могут

восприниматься как “помехи”.

Перед устранением обнаруженного сбоя, необходимо

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

отладки и устранения.

Это позволит обеспечить б о льшую глубину измерений

и иметь возможность улучшения самого процесса

тестирования.

В тех случаях, когда результаты тестирования особенно

важны, например, в силу критичности обнаруженного сбоя,

может быть сформирована специальная группа анализа

• Отчёты о проблемах/журнал тестирования

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

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

Кроме того, аномалии (помехи), которые нельзя идентифицировать как сбои, также могут фиксироваться в журнале и/или системе ведения отчетности по сбоям.

Документирование аномалий снижает риски процесса тестирования и помогает решать вопросы повышения надежности самой тестируемой системы .

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

7. Отслеживание дефектов

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

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

Верификация и валидация в процессе тестирования

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

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

Пример типичной верификации:  процесс проведения тестирования системного компонента. Оперируя определенными требованиями, мы проводим процесс тестирования и документируем, соблюдены ли требования. В конце верификации мы получаем ответ на вопрос: «Отвечает ли продукт заявленным требованиям?».

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

В случае верификации это: что было сделано; отвечает ли система озвученным клиентским ожиданиям.

Валидация – сделано именно то, что требовалось или всецело ли данная система соответствует тем ожиданиям заказчика, что были ранее заявлены?

Различия между верификацией и валидацией

Верификация

Валидация

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

Отвечает на вопрос, создается ли продукт правильно с точки зрения ожиданий клиента.

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

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

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

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

Верификация

Валидация

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

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

Пример использования верификации и валидации

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

Для этого есть определенная форма с полями, которые необходимо заполнить.

Сначала выполним верификацию:

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

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

После этого происходит валидация:

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

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

При верификации проверяется наличие в продукте этой логики (параметров взаимодействия компонентов).

Дополнительно про эти два понятия можно найти на сайте

http://www.protesting.ru/testing/testtypes.html