Как описать тестирование программы

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

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

Тест-стратегия включает в себя список тестовых случаев (Test Cases). В средах Microsoft Visual Studio 2010 Ultimate и Microsoft Test Manager 2010 тестовый случай – это рабочий элемент, состоящий из совокупности шагов, условий, а также параметров, необходимых для проверки корректности работы тестируемой функции.

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

Лекция 113: Тестирование программ

2. Тест-план

Тест-план составляется менеджером проекта. Тест-план должен включать в себя ответы на следующие вопросы:

§ Что представляет собой система (сведения о продукте, его назначение)?

§ Какие части продукта будут протестированы?

§ Потенциальные риски продукта (какие слабые места могут быть у продукта).

§ В какие сроки пройдет тестирование? (Указывается, какие виды тестирования (см. описание тест-стратегии) будут проходить на той или иной стадии (итерации) разработки продукта).

§ Кто будет тестировать?

Как правило, ответственным за проведение тестирования по тестовым случаям (конфигурационное и интеграционное), Usability- и Exploratory-тестирование назначается тестировщик.

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

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

§ Критерии окончания тестирования.

Составим тест-план для тестирования программы, разработанной в процессе выполнения лабораторной работы № 13.

Пример тест-плана для программы «Алгоритм Rijndael»:

1. Что представляет из себя система (сведения о продукте, его назначение)?

Программа «Алгоритм Rijndael» представляет собой WinForms-приложение, предназначенное для шифрования данных. Данное приложение может использоваться двумя типами пользователей – это человек, который зашифровывает данные (Шифровщик), и человек, который расшифровывает данные (Дешифровщик). Шифровщик может с помощью программы зашифровать данные. Дешифровщик может с помощью программы расшифровать уже зашифрованные с помощью алгоритма Rijndael данные.

2. Какие части продукта будут протестированы?

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

Тестирование Программного Обеспечения — урок №1 — Введение

3. Потенциальные риски продукта (какие слабые места могут быть у продукта).

Основным риском тестируемой системы является риск некорректной зашифровки и расшифровки данных.

4. В какие сроки пройдет тестирование?

После завершения разработки программы необходимо провести конфигурационное тестирование, usability-тестирование, exploratory-тестирование и приемочное тестирование. В связи с малым масштабом и низкой сложностью системы на процесс тестирования отводится 1 час 30 минут.

5. Кто будет тестировать?

Ответственным за проведение тестирования назначается тестировщик.

6. Критерии окончания тестирования.

Тестирование считается завершенным, если были проведены и успешно завершены все предусмотренные тест-стратегией виды тестирования.

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Наглядный пример из жизни

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

Обычно, процесс сборки игрушки выглядит так:

1. Берем детали и инструкцию по сборке, и проверяем, что все на месте (детали правильной формы / размера / цвета)
2. Собираем детали в «блоки». Если игрушка — это машинка, то мы соберем несколько блоков: двери, колеса, салон, корпус машины, подвеску и т.п.
3. «Блоки» собираем в части побольше (если нужно), а уже из них складываем готовую машинку
4. Проверяем, что машинка ездит, двери открывается, ничего от нее не отпадает и т.п.
5. В конце мы проверяем, что машинка соответствует изображению и это то, что мы покупали

Программное обеспечение очень похоже на такой конструктор.

Но оно намного круче, ведь мы сами можем создавать любые детали и использовать детали (и даже блоки), созданные другими людьми (привет Open Source)

Если посмотреть на процесс сборки с точки зрения тестирования, его можно описать так:

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

Собранная игрушка — это именно та игрушка, которую мы хотели = Приемочное тестирование

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

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

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

Что такое уровень тестирования?

Уровень тестирования — активности тестирования, объединенные в группу исходя из общих характеристик, связанных с SDLC.

К характеристикам относятся:

1. Цели тестирования (Для чего мы проводим тестирование?)
2. Объект тестирования (Что мы тестируем? Модуль / компонент / под-систему / систему?)
3. Базис тестирования (Что нам необходимо, чтоб провести тестирование? Объект тестирования, спецификации, требования, ТЗ)
4. Типичные дефекты, которые мы планируем найти
5. Зоны ответственности (Кто чем занимается и кто за что отвечает?)
6. Окружение (Где проводится тестирование, локально или на production сервере?)

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

Пример реальной задачи по разработке

Предположим, перед вашей командой ставят задачу:

Создать страницу “Contact Us” на сайте Х. После отправки формы отдел поддержки должен получить Email, содержащий введенные данные и контактную информацию клиента.

Этап разработки требований и критериев приемки завершен, команда может приступать к реализации, задача переходит на этап дизайна (см. SDLC)

Первым делом разработчики прорабатывают дизайн системы.

Он может представлять собой следующую схему:

Далее, разработчики детализируют схему добавляя описание шагов:

1. Клиент заполняет форму Contact Us и нажимает кнопку «Отправить»
2. Frontend проверяет введенные значения*
3. Frontend отправляет данные на Backend
4. Contact Us Controller проверяет данные и формирует запрос на отправку письма*
5. Contact Us Controller передает данные для отправки письма в Email Sender
6. Email Sender получает данные, проверяет их, формирует письмо и отправляет его**
7. Email Sender отвечает Contact Us Controller, что письмо отправлено
8. Contact Us Controller формирует ответ для Frontend
9. Backend отправляет данные об успешной отправке письма на Frontend
10. Frontend получает данные, понимает, что отправка была успешной и показывает клиенту сообщение

логика проверки (валидации данных) опущена для упрощения; но, это не означает, что ее нет!

логика отправки Email опущена для упрощения схемы

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

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

1. Модульное / Компонентное / Unit тестирование

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

Module / Component / Unit testing: A test level that focuses on individual hardware or software components [ISTQB Glossary]

Характеристики модульного тестирования

Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок

• Объект: модуль / компонент / unit
• Базис: дизайн системы, код, спецификация компонента
• Типичные ошибки: ошибка в реализации требований, ошибка в коде
• Ответственный: разработчик (редко тестировщик)

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

Unit тесты, кроме поиска ошибок, также помогают оценивать качество кода, измерять покрытие кода тестами, сокращать время и затраты на тестирование.

Продолжая рассмотрение примера со страницей сайта, мы можем выделить следующие модули:

1. Страница Contact Us отвечает за показ формы Contact Us
2. Форма Contact Us отвечает за проверку и отправку данных на Backend
3. Contact Us Controller является частью API и отвечает за обработку запросов с формы Contact Us
4. Email Sender отвечает за отправку Email

Для примера, рассмотрим модуль «страница Contact Us».

1. Открываться в браузере по указанному URL
2. Содержать правильную информацию и тексты
3. Содержать форму Contact Us (содержать, но не отвечать за ее работоспособность!)
4. …

В свою очередь, требования к модулю «Contact Us Controller»:

1. Принимать данные по указанному URL (API endpoint)
2. Проверять полученные данные
3. Правильно формировать данные для компонента Email Sender (без фактической отправки)
4. Возвращать правильные HTTP ответы в случае успешной отправки Email И (. ) в случае возникновения ошибки
5. …

Все описанные выше требования должны проверяться Unit тестами.

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

2. Интеграционное тестирование

Интеграционное тестирование фокусируется на взаимодействии между компонентами / модулями / под-системами / системами.

Выделяют 2 подтипа:

• Компонентное интеграционное тестирование — проверяет связи между компонентами. Может быть автоматизировано.
• Системное интеграционное тестирование — проверяет связи между под-системами / системами. Не всегда можно автоматизировать, так как часто интеграция происходит с внешним сервисом, к которому мы не имеем доступа.

Характеристики интеграционного тестирования

• Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы
• Объект: модули, состоящие из нескольких компонентов; под-системы, API, микросервисы
• Базис: дизайн системы, архитектура системы, описание связей компонентов
• Типичные ошибки: отсутствие / неправильные связи между элементами системы, неправильные передаваемые данные, отсутствие обработки ошибок, отказы и падения при обращениях к API
• Ответственный: разработчик и тестировщик

Системные интеграционные тесты выполняются дольше (несколько десятков в минуту), чем модульные интеграционные тесты (несколько сотен-тысяч в минуту) и являются более творческими.

Продолжим рассмотрение примера.

Теперь, обратим внимание на связи между компонентами / под-системами:

Начнем с компонентного интеграционного тестирования.

Обрати внимание на стрелки 5 и 7.

Они описывают связь между компонентами Contact Us Controller и Email Sender внутри под-системы Backend.

Contact Us Controller обращается к Email Sender с запросом для отправки Email сообщения (5), Email Sender отправляет письмо (6) и отвечает Contact Us Controller что все прошло удачно (7). Если при отправке (6) произошла ошибка, в ответе (7) вернется информация об ошибке.

В нашем случае интеграционные тесты проверят, что описанный выше процесс работает и что модуль Contact Us Controller инициирует отправку Email сообщения, а не SMS.

Тестирование интерфейсов (частично) и тестирование API являются примерами интеграционного компонентного тестирования.

В случае с тестированием API мы «имитируем» запрос от клиента — (3) и анализируем ответ сервера — (9), таким образом проверяя интеграцию всех задействованных модулей для конкретного API Endpoint внутри Backend.

Далее посмотрим на системное интеграционное тестирование.

Обрати внимание на стрелки 3 и 9.

Они описывают связь между двумя под-системами: Frontend, который формирует и отправляет запрос со страницы Contact Us с данными формы, и Backend, который обрабатывает и реагирует на запрос.

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

В нашем случае для проверки правильности достаточно написать 1 тест: отправить форму Contact Us с ожидаемым результатом в виде показанного сообщения об успешной отправке — (10) и полученного Email сообщения с данными, оставленными с формы Contact Us.

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

3. Системное тестирование

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

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

Системное тестирование может проверять выполнение стандартов или законодательных / нормативных требований.

Тестовая среда для системного тестирования должна быть максимально приближенной (в идеальном варианте — идентичной) к окружению для эксплуатации (production).

Характеристики системного тестирования

• Цель: проверка работы системы в целом
• Объект: система, конфигурации системы, рабочее окружение
• Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции
• Типичные ошибки: невозможность выполнять функциональные задачи, для которых создавалась система, неправильная передача данных внутри системы, неспособность системы работать правильно в среде эксплуатации, нефункциональные сбои (уязвимости, зависания, выключения)
• Ответственный: тестировщик

Системное тестирование для нашего примера может включать в себя такие типы тестирования:

слово «тестирование» — убрано с изображения для упрощения

Помимо проверки отправки формы Contact Us, получения Email сообщения на почту суппорта и показа Success сообщения, в ходе системного тестирования мы должны ответить на вопросы:

1. Работает ли форма Contact Us во всех поддерживаемых браузерах?
2. Удобно ли ей пользоваться? Все ли понятно? Насколько осмысленны сообщения об ошибках?
3. Что произойдет, если кто-то отправит 1,000 запросов Contact Us в секунду? (DDOS)
4. Какое максимальное количество запросов можно отправить, чтобы сайт работал без сбоев? (Load testing)
5. Насколько читабельным является Email, который получит поддержка? (весь текст в одну строку или письмо оформлено красиво)
6. Не попадает ли письмо в Spam?
7. Сохраняются ли данные клиента, который отправляет форму? Если «да» — насколько безопасно место хранения? Существует ли способ получения списка отправленных Email-ов?
8. Знает ли суппорт о почтовом ящике, куда попадет письмо? Знает ли он, как реагировать на такие письма?
9. и много, много других …

На этом уровне тестирования создаются end-to-end тесты, имитирующие бизнес процессы, Use Cases и Use Stories от начала до конца.

Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п. — все здесь).

“End to end“ / E2E тесты очень медленные (обычно 5-10 тестов в минуту) и коварные, с их автоматизацией нужно быть очень осторожным

Системное тестирование — одна из самых творческих и объемных областей тестирования. Кроме end-to-end тестирования, к этому уровню относятся все виды нефункционального тестирования.

Очень часто начинающие тестировщики видят только одно направление развития: автоматизация.

Но на самом деле направлений много.

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

После завершения тестирования всей системы нас ждет последняя проверка перед сдачей работы.

4. Приемочное тестирование

Приемочное тестирование фокусируется на готовности всей системы в целом.

Существуют несколько форм приемочного тестирования:

• Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.
• Контрактное приемочное тестирование — проводится в соответствии с критериями, указанными в контракте приемки специального ПО.
• Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов. Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.
• Бета-тестирование проводится реальными пользователями системы.

Характеристики приемочного тестирования

• Цель: проверка готовности системы
• Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика
• Базис: системные требования, бизнес требования, сценарии использования, User Stories
• Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта
• Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик

Завершая рассмотрение примера можем написать приемочный тест, который выполнит заказчик:

1. Заказчик заполняет форму, нажимает на кнопку «Отправить»
2. Через 1 секунду он видит сообщение об успешной отправке формы
3. В течении минуты на почту поддержки приходит письмо содержащее данные отправленные с формы

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

В Agile разработке, конкретно в Scrum, для всех User Stories обязательно прописываются Acceptance Criteria. Именно они являются основой для приемочных тестов и показывают, что команда сделала именно то, что было нужно.

После завершения приемочного тестирования задача передается клиенту.

Резюме

• В этой статье мы описали, что такое уровни тестирования, зачем они нужны и что собой представляет каждый из них.
• Мы рассмотрели пример тестирования формы Contact Us.
• Мы поняли, что тестирование нужно начинать с самых маленьких частей системы — компонентов / модулей.
• Далее стоит проверить взаимосвязи между компонентами и всю систему в целом.
• А завершает тестирование — заказчик, выполняя приемочное тестирование.

Источник: nujensait.ru

Home

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

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

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

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

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

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

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

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

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

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

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

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

Документацию всегда полезно держать перед глазами.

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

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

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

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

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

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

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

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

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

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

«Дымовое» тестирование — это быстрое, неглубокое, на наиболее простых или типичных сценариях, с минимумом проверок (чтобы только дыма не было). Оно может выполняться как на «позитивных», так и на «негативных» данных.

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

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

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

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

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

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

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

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

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

Резюме

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

Спасибо:

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

• начинающему тестировщику
• общие вопросы

Источник: www.software-testing.ru