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

Дополнительные ссылки

Материалы по тестированию есть на http://www.protesting.ru/. Там много теории и немного практики. Можно найти базовую информацию о том, какие бывают виды тестирования, что такое тест-кейс, тест-план и т.п. Правда, ресурс этот развивается с 2000-х годов, поэтому некоторая информация успела устареть. Но по базе здесь можно найти ценные примеры.
Форум на ресурсе https://software-testing.ru/forum/ — это своего рода аналог Хабра для тестировщиков (по большей части для автоматизаторов). Там много полезной информации именно начального уровня — на Хабре в разделе тестирования больше более продвинутых статей, а тексты для новичков появляются все реже и принимаются аудиторией все хуже.
Еще два неплохих источника информации: https://tproger.ru/digest/free-software-testing-books/ и https://automation-remarks.com/.
Спасибо специалистам по тестированию нашей компании за помощь при подготовке статьи!
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

View the discussion thread.

blog comments powered by DISQUS

Agile

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

Узнайте больше об Agile (прим. — статья на английском языке).

QA ≠ QC: как их различить

QC: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Люди, которых называют тестировщиками, тождественны контролю качества QC. По логике вещей они на последнем этапе разработки проверяют качество продукта (любым видом и типом тестирования  —  ручным, автоматизированным, нагрузочным, тестированием безопасности и т.д.). Какая у них задача? Их задача — провести валидацию продукта и предоставить информацию бизнесу и разработчикам о соответствии продукта заявленным требованиям. Какие у них ограничения? Какие могут быть недостатки, если у вас все сотрудники проверяют продукт на соответствие:

• До взятия фичи в проверку такие сотрудники не влияют на процесс обеспечения качества и разработки, хотя их участие могло бы предотвратить некоторое количество багов и тем самым сократить затраты на тестирование.
• Зачастую такие сотрудники не могут давать рекомендации, как сделать продукт лучше. Потому что поезд ушёл и уже поздно. Им остаётся лишь сверять соответствие продукта требованиям. FYI: хотя на самом деле тестировщикам есть что сказать по поводу улучшений, которые необходимо сделать.
• Эти ребята чаще всего не видят полной картины процесса, поэтому искренне не понимают, почему разработчики дают им код, в котором приложение крашится при попытке запуститься. И, согласно п.1, ничего не могут с этим сделать. Даже если хотят. 
• Они не могут взять на себя полную ответственность за качество продукта.
• Очень часто между тестировщиками и разработчиками возникают конфликты. Так бывает, когда разработчики считают свой код самым лучшим и работающим, а в тестировщиках видят лишь попытки его сломать и показать, что код не работает. Такое положение дел порождает всем известные мемы «Это не баг, а фича».

QA: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Инженеры по обеспечению качества (QA) — это люди, которые помогают командам разработки выпускать качественный продукт, как можно быстрее за как можно меньшие деньги. Ведь все мы знаем, что чем раньше найден баг, тем дешевле его пофиксить. Лучше всего фиксить баги ещё на уровне идеи.
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это. Какая у них задача? Задача QA-инженера  —  не допустить несоответствия продукта предъявляемым требованиям. QA-инженер замеряет качество продукта, знает его актуальное состояние и что нужно сделать, чтобы его поднять не только на этапе тестирования, но и на этапе разработки, дизайна или составления требований.Какие у них ограничения? Сложно оценить качество работы QA-инженера, потому что если он хорошо выполняет свою работу, то до этапа тестирования будет доходить минимальное количество багов не влияющих на функциональность и запуск продукта в прод. 
В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.

Почему ручное тестирование не вымерло?

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

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

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

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

________________________________

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

________________________________

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

Нефункциональное тестирование

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

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

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

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

Лучше спешите с системными тестами!

Так что же я предлагаю? А предлагаю я взглянуть на старый рисунок по-новому:

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

Как я уже упоминал выше, системные тесты — это тесты программы в целом. При этом программа представляется именно в том виде, в котором её увидит пользователь. Фактически, системные тесты заставляют нас взглянуть на программу как на законченный продукт (хоть он таким сейчас и не является). Если другими словами, то вместо подхода от «от частного к общему» мы начинаем писать тесты «от общего к частному». А это позволяет нам убить сразу двух зайцев:

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

Звучит неплохо, не правда ли? Причём, системные тесты обладают ещё рядом очень приятных бонусов:

1. В условиях зафиксированных требований к программе системные тесты не могут сильно меняться. Это возможно благодаря самой природе системных тестов: они рассматривают программу как «черный ящик» — без какой-либо привязки к архитектуре и особенностям реализации. А это значит, что вы можете свободно менять архитектуру своей программы по первому требованию, и никакие тесты менять не придется! Ну, разве что, немного подкорректировать — если у вас добавилась новая зависимость или что-то в таком духе.
2. Системные тесты могут писать аналитики или даже тестировщики — не отнимая, таким образом, ценное время программистов. Также это позволяет аналитикам дать программистам более четкое понимание, что именно они хотят увидеть в программе. Программистам лишь останется добиться того, чтобы тесты проходили, не ломая голову над вопросом «чего же от меня хотят».
3. Системные тесты — это очень комплексный вид тестов. Если ваша программа проходит сложный комплексный тест — то вы уже с довольно высокой долей вероятности можете быть уверены, что «в целом, наверное, все компоненты нормально работают». В Unit-тестах наоборот — уверенность в одном классе не дает абсолютно никакой уверенности в работоспособности программы в целом.

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

Впрочем, сейчас на этом фронте не всё так уж и плохо — существует очень много коммерческих решений, которые позволяют в том или ином виде решить эту проблему: Testcomplete, Squish, Ranorex, Eggplant — это лишь самые известные примеры таких систем. У всех у них есть свои достоинства и недостатки, но в целом со своей задачей по автоматизации системных тестов они справляются (хоть и стоят очень немалых денег).

А вот среди бесплатных решений выбора особо нет. По крайней мере не было.

Совсем недавно я выпустил инструмент, который должен немного исправить вселенскую несправедливость и дать людям возможность бесплатно автоматизировать системные тесты. Этот инструмент называется платформой Testo — и поподробнее про него можно почитать тут.

Какие типы или виды тестирования используются в QA процессе?

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

Функциональные и нефункциональные тесты

Основные категории тестов — это функциональные и нефункциональные тесты.

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

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

Знание исходного кода

Если тестировщики знают исходный код до тестирования, речь идет о тестировании “белого ящика” (white box testing). В противном случае мы имеем дело с тестированием “черного ящика” (black box testing), когда тестировщики оценивают только поведение приложения, не зная его внутреннего устройства. Тестирование “серого ящика” (grey box testing) представляет собой комбинацию этих двух подходов. Тестировщикам предоставляется ограниченная информация о внутренней структуре системы.

Подход к выполнению тестов

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

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

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

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

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

Фаза разработки программного обеспечения

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

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

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

Регрессионные тесты (regression tests)  помогают проверить, работает ли приложение так, как оно должно работать, после внесения каких-либо изменений, например исправления дефектов.

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

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

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

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

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

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

Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.

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

Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов. 

Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта. 

Бета-тестирование проводится реальными пользователями системы.

Acceptance testing A test level that focuses on determining whether to accept the system.

User acceptance testing (UAT) A type of acceptance testing performed to determine if intended users accept the system.

Contractual acceptance testing A type of acceptance testing performed to verify whether a system satisfies its contractual requirements.

Alpha testing A type of acceptance testing performed in the developer’s test environment by roles outside the development organization.

Beta testing A type of acceptance testing performed at an external site to the developer’s test environment by roles outside the development organization.

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

Цель: проверка готовности системы

Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика

Базис: системные требования, бизнес требования, сценарии использования, User Stories

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

Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик

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

Приемочное тестирование системы Contact Us

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

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

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

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

Тестирование ПО. Основные виды

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

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

Автоматизированное тестирование проводится с использованием программных средств. Тестировщик или программист пишет специальный код для проверки ПО.

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

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

Тестирование безопасности — этот вид проверки определяет, насколько ПО защищено от любых атак, а также выясняет, находятся ли данные пользователей и системы в безопасности.

Тестирование удобства пользователя — в этом случае тестировщик становится пользователем и определяет, насколько удобно пользоваться программой.

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

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

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

Что такое A/B-тестирование

A/B-тестирование (англ. A/B testing), оно же Сплит-тестирование (англ. Split testing) – метод маркетингового исследования. Его суть заключается в том, что контрольная группа элементов сравнивается с набором тестовых групп, в которых один или несколько показателей были изменены для того, чтобы выяснить, какие из изменений улучшают целевой показатель. Таким образом, в ходе теста сравнивается вариант A и вариант B. Целью является определение лучшего из двух протестированных вариантов. 

Для чего нужен такой тест 

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

Ещё несколько полезных слов

Фиксить (от англ. to fix — исправлять) — вносить правки, исправлять ошибки.

Локаль (от англ. locale — место) — региональные настройки или параметры ПО.

Билд (от англ. to build — строить) — финальный вариант программного продукта или его элемента, который готов к тестированию.

Асайнить (от англ. to assign — назначать) — закреплять за кем-то задачу или часть работы.

В аттаче (от англ. to attach — приложить) — добавлять к письму или сообщению документ. Например, отправить на почту письмо с CV в аттаче означает, что было отправлено письмо с приложенным к нему резюме.

Букать (от англ. to book — бронировать) — резервировать.

Бэкапить (от англ. backup — дублирование) — создавать резервные копии документов или данных на случай их потери или удаления.

Дебаджить, дебажить (от англ. to debug — отлаживать) — настраивать или регулировать работу.

Тул (от англ. tool — инструмент) — программа, которая используется при тестировании.

Фича (от англ. feature — особенность) — некий аспект ПО, который служит его характерной особенностью.

Словарь тестировщика

Термины идут не по алфавиту, а по смыслу. Сначала база, а потом, те, что на неё опираются.

Объективное доказательство

(Objective Evidence)

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

Объективные доказательства должны содержать достаточные данные, чтобы рецензент мог доказать их
соответствие критериям приёмки (Acceptance Criteria) теста.

Сравнение объективных доказательств с критериями приёмки приводит к прохождению или провалу теста.

Следует иметь в виду, что такие утверждения, как Пройдено (Passed), Провал (Failed) и как ожидалось (As Expected), никогда не
рассматриваются как объективное свидетельство выполненного теста.

Верификация дизайна

(Design Verification)

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

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

Деятельность по проверке может включать испытания, инспекции/обзоры и анализы.

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

Валидация дизайна

(Design Validation)

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

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

Видите, какие скучные и не до конца внятные определения даны выше?

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

Выбор фич для следущего релиза, подробности

здесь

Фото: freepik.com

Результат теста

Должен включать в себя:

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

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

Дату проведения теста.

Описание тестового окружения, использованного во время тестирования. Например, тип компьютера.

Заключение об Успехе/Провале теста. Так называемое Pass/Fail statement

Объективное доказательство (Objective Evidence)

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

Любой долгосрочный проект без надлежащего покрытия тестами обречен рано или поздно быть переписанным с нуля

• Без покрытия тестами. Обычно такие системы сопровождаются спагетти-кодом и уволившимися ведущими разработчиками. Никто в компании не знает, как именно все это работает. Да и что оно в конечном итоге должно делать, сотрудники представляют весьма отдаленно.
• С тестами, которые никто не запускает и не поддерживает. Тесты в системе есть, но что они тестируют, и какой от них ожидается результат, неизвестно. Ситуация уже лучше. Присутствует какая-никакая архитектура, есть понимание, что такое слабая связанность. Можно отыскать некоторые документы. Скорее всего, в компании еще работает главный разработчик системы, который держит в голове особенности и хитросплетения кода.
• С серьезным покрытием. Все тесты проходят. Если тесты в проекте действительно запускаются, то их много. Гораздо больше, чем в системах из предыдущей группы. И теперь каждый из них – атомарный: один тест проверяет только одну вещь. Тест является спецификацией метода класса, контрактом: какие входные параметры ожидает этот метод, и что остальные компоненты системы ждут от него на выходе. Таких систем гораздо меньше. В них присутствует актуальная спецификация. Текста немного: обычно пара страниц, с описанием основных фич, схем серверов и getting started guide’ом. В этом случае проект не зависит от людей. Разработчики могут приходить и уходить. Система надежно протестирована и сама рассказывает о себе путем тестов.

QA, QC и тестирование

Так в чем же разница между QA и тестированием и что такое Quality Control?

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

Можно оформить их соотношение в виде таблицы:

Таким образом, мы можем построить модель иерархии процессов обеспечения качества: Тестирование – часть QC. QC – часть QA.

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

Если провести аналогию с процессом конструирования, скажем, велосипеда, то получим такую картину:

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

То есть качеству объекта внимание уделяется еще до создания самого объекта.

Функциональное тестирование

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

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

Для проведения функционального тестирования персоналом отдела технического контроля разрабатывается документ программа и методика испытаний функционала приложения (ПМИ). Документ ПМИ содержит перечень сценариев тестирования программного продукта (test cases) с подробным описанием шагов. Каждый шаг сценария тестирования характеризуется действиями пользователя (специалиста по тестированию) и ожидаемыми результатами – ответной реакции программы на эти действия. Программа и методика испытаний обязана имитировать эксплуатацию программного продукта в реальном режиме. Это означает, что сценарий тестирования должен быть построен на основе анализа операций, которые будут выполнять будущие пользователи системы, а не быть искусственно составленной последовательностью понятных только разработчику манипуляций.

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

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

Заключение

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

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

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

The following two tabs change content below.

Светлана Савастюк

QA cпециалист XB Softaware. Любимое изречение, которое она использует в каждодневной работе: «мы верим в Бога, а все остальное тестируем».