Тестовая документация помогает структурировать работу и фиксировать информацию, которая нужна заинтересованным сторонам на финальном этапе тестирования.
Тестовая документация нужна, чтобы:
- видеть уровень покрытия проекта тестами, не забывая про функционал;
- быстро привлечь к работе новые кадры, если тестировщик внезапно покидает проект – временно или навсегда;
- автоматизировать тестирование: писать скрипты по готовым тест-кейсам куда проще и быстрее.
Кроме того, документация позволяет оценить сроки и реальный объём работ.
Виды тестовой документации
1. Тест-план
Это документ, с которого всё начинается и где описан весь объём работ по тестированию. Удачный тест-план:
- помогает людям вне тестирования понять детали;
- устанавливает объект тестирования, график работы, критерии начала и окончания тестирования, стратегию, риски и список необходимых работ;
- выставляет приоритеты и подчёркивает важные аспекты.
Полноценным считается тест-план, в котором мы подробно прописали все вышеуказанные пункты. Составляет его либо тимлид, либо один из самых опытных тестировщиков, а после тест-план согласовывается со всей командой.
Создать тест-план можно на основе международного стандарта IEEE 829 или разработать документ, максимально исчерпывающе отвечающий на все важные вопросы. А именно:
- объект тестов, используемая веб-среда;
- полный перечень системных функций с указанием необходимого оборудования;
- типы проверок;
- процесс теста, анализ полученной информации по отношению к запланированным фазам разработки на проекте;
- риски и пути их разрешения.
Тест-план зачастую используется на долгосрочных проектах и помогает выстроить доверительные отношения с клиентом, показывая, что именно будет делать команда тестирования.
2. Тестовая стратегия
В целом определяет, как продукт будет тестироваться. Дополняет тест-план и содержит общий подход к тестированию. На краткосрочных проектах стратегия может заменить объёмный тест-план.
При формировании данного документа необходимо разложить весь процесс на следующие пункты:
- подготовка информации;
- разбор информации;
- вынесение решения;
- презентация.
По большому счёту правильная тестовая стратегия:
- обозначает цели;
- показывает, что нужно предпринять для достижения результата.
Тестовая стратегия помогает организовать процесс, понять, какими ресурсами мы обладаем, и как целесообразно ими распоряжаться даже в ограниченных условиях.
3. Тест-кейс
Это один из самых популярных артефактов (у нас в Qualitica уж точно). В нём описывается последовательность действий, как проверить определённую часть функционала и прийти к фактическому результату.
Тест-кейсы составляются, как только готов тест-план. Мы с коллегами всегда следим за актуальностью этой документации, так как благодаря тест-кейсам члены команды могут ознакомиться с программой, не изучая весь код.
Тест-кейсы можно разделить на позитивные и негативные. Позитивные проверяют правильность поведения функций, используя корректные данные. Негативный тест-кейс должен вмещать как минимум один некорректный параметр и проверяет чрезвычайные ситуации.
При написании тест-кейсов, мы, как правило, применяем следующие техники тест-дизайна:
- Эквивалентное разделение. Данный метод позволяет сократить число тестов. Так как для целого класса можно выбрать только одно значение, приняв, что для всех значений в группе результат будет аналогичным.
- Граничные значения. Эта техника тесно связана с предыдущей и основана на предположении, что многие ошибки могут возникать на границах эквивалентных классов.
- Матрица или таблица принятия решений. Эту технику мы применяем для более сложных систем. К примеру, двухфакторной аутентификации. Метод хорош тем, что показывает сразу все возможные сценарии.
- Попарное тестирование (Pairwise testing). Такие кейсы позволяют обнаружить большое количество ошибок при минимуме проверок, потому что мы убираем дублирующие друг друга тесты.
- Причина и следствие. Относится к проверке базовых действий и получению результата. Так мы проверяем все возможности системы, находим дефекты и делаем нашу техническую документацию ещё лучше.
Исчерпывающего тестирования не существует, но опытные тестировщики Qualitica вплотную приближаются к нему, применяя все вышеуказанные техники, потому что мы умеем верно подбирать и комбинировать необходимое в тест-дизайне.
4. Чек-лист
Список, содержащий ряд необходимых проверок для какой-либо работы. В плотной работе команды тестирования чек-лист помогает помнить о важных деталях. Создаём мы его на этапе готовности тест-плана и определения тестовой стратегии.
Он нужен, чтобы:
- организовать рабочий процесс;
- легко проверить выполненную работу.
5. Баг-репорт
Технический документ, без которого не обходится ни одна проверка. Он содержит полное описание дефекта. Включает информацию как о самом баге (короткое описание, серьёзность, приоритет и т. д.), так и об условиях его возникновения.
В зависимости от проекта баг-репорт может составляться в разных баг-трекинговых системах. В Qualitica мы чаще всего пользуемся Jira, Redmine, YouTrack, Trello или просто инструментами для работы с таблицами.
Баг-репорт помогает:
- отследить и описать ошибки в работе проекта;
- воспроизвести проблему;
- понять суть проблемы, её приоритет и важность;
- эффективно избавляться от багов.
6. Отчёт о результатах тестирования
Здесь обобщаются все результаты работ по тестированию. В том числе:
- наглядно показаны проблемы и достижения, дефекты и статистика;
- даются выводы и рекомендации.
Тестовая документация облегчает жизнь проектной команде, а также экономит время на этапах тестирования, сводя их к проверкам, анализу и передаче результатов. Благодаря этому клиенты быстро получают качественно работающий продукт.
Нужно тестирование, за которое можно не переживать? Пишите нам на hello@qualitica.ru, и мы подберём вам лучших специалистов команды. А ещё не забывайте читать блог Qualitica – с нами интересно!
-
Главная
-
Туториалы
-
Тестирование и обеспечение качества
- Тестирование ПО
Документация по тестированию включает документацию об артефактах, которые должны быть разработаны до или во время тестирования программного обеспечения.
Документация для тестирования программного обеспечения помогает оценить требуемые усилия по тестированию, охват тестирования, отслеживание / отслеживание потребности и т. д. В этом разделе описываются некоторые из часто используемых документированных артефактов, связанных с тестированием программного обеспечения, таких как:
- План тестирования
- Сценарий тестирования
- Прецедент
- Матрица прослеживаемости
План тестирования
В плане тестирования описывается стратегия, которая будет использоваться для тестирования приложения, ресурсов, которые будут использоваться, тестовой среды, в которой будет проводиться тестирование, а также ограничений тестирования и графика тестирования. Как правило, руководитель группы по обеспечению качества несет ответственность за составление плана тестирования.
План тестирования включает следующее:
- Введение в документ плана тестирования
- Предположения при тестировании приложения
- Список тестовых примеров, включенных в тестирование приложения
- Список функций для тестирования
- Какой подход к использованию при тестировании программного обеспечения
- Список результатов, которые необходимо проверить
- Ресурсы, выделенные для тестирования приложения
- Любые риски, связанные с процессом тестирования
- График задач и контрольных точек, которые должны быть достигнуты
Сценарий тестирования
Это однострочное заявление, которое уведомляет, какая область в приложении будет протестирована. Сценарии тестирования используются для проверки протекания всех потоков процессов из конца в конец. Отдельная область приложения может иметь всего лишь один тестовый сценарий для нескольких сотен сценариев в зависимости от величины и сложности приложения.
Термины «тестовый сценарий» и «тестовые примеры» используются взаимозаменяемо, однако тестовый сценарий имеет несколько этапов, тогда как тестовый пример имеет один шаг. С этой точки зрения сценарии тестирования являются тестовыми примерами, но они включают в себя несколько тестовых примеров и последовательность, в которой они должны выполняться. Кроме того, каждый тест зависит от результата предыдущего теста.
Прецедент
Тестовые примеры включают в себя набор шагов, условий и входов, которые могут использоваться при выполнении задач тестирования. Основной целью этой деятельности является обеспечение того, проходит ли программное обеспечение или не выполняется с точки зрения его функциональности и других аспектов. Существует множество типов тестовых примеров, таких как функциональные, отрицательные, ошибки, логические тестовые примеры, физические тестовые примеры, тесты пользовательского интерфейса и т. д.
Кроме того, тестовые примеры записываются для отслеживания охвата тестированием программного обеспечения. Как правило, нет формальных шаблонов, которые можно использовать во время написания тестового примера. Тем не менее, следующие компоненты всегда доступны и включены в каждый тестовый пример:
- Идентификатор теста
- Модуль продукта
- Версия продукта
- Лист регистраций изменений
- Цель
- Предположения
- Предпосылки
- Меры
- Ожидаемый результат
- Фактический результат
- Постусловий
Многие тестовые примеры могут быть получены из одного сценария тестирования. Кроме того, иногда несколько тестовых примеров написаны для одного программного обеспечения, которые все вместе называются наборами тестов.
Матрица прослеживаемости
Матрица прослеживания (также известная как матрица отслеживания требований — RTM) — это таблица, которая используется для отслеживания требований в течение жизненного цикла разработки программного обеспечения. Он может использоваться для прямой трассировки (т. е. От требований к дизайну или кодированию) или назад (т. е. От кодирования до требований). Для RTM существует множество пользовательских шаблонов.
Каждое требование в документе RTM связано со связанным с ним тестовым случаем, поэтому тестирование может быть выполнено в соответствии с указанными требованиями. Кроме того, идентификатор ошибок также включен и связан с соответствующими требованиями и тестовым случаем. Основными целями этой матрицы являются:
- Убедитесь, что программное обеспечение разработано в соответствии с указанными требованиями.
- Помогает найти основную причину любой ошибки.
- Помогает отслеживать разработанные документы на разных этапах SDLC.
Тестовая поставка (test deliverable): Любой тестовый (рабочий) продукт, который должен быть доставлен кому-то другому, кроме автора тестового (рабочего) продукта. (ISTQB)
Тестовое обеспечение (testware): Артефакты, создаваемые во время процесса тестирования и требующиеся для планирования, разработки и выполнения тестов. Например: документация, сценарии, входы, ожидаемые результаты, процедуры установки и удаления, файлы, базы данных, окружение и любое другое дополнительное программное обеспечение или инструменты, используемые в тестировании. (Fewster and Graham)
Артефакт (artifact) — это один из многих видов материальных побочных продуктов, возникающих в процессе STLC. Это не только документация, а в принципе всё, что создаётся для того, чтобы быть задействованным в тестировании.
Результаты тестирования (Test Deliverables) — это артефакты, которые передаются заинтересованным сторонам проекта программного обеспечения в течение жизненного цикла разработки программного обеспечения. На каждом этапе жизненного цикла разработки программного обеспечения существуют разные результаты тестирования. Некоторые результаты тестирования предоставляются до этапа тестирования, некоторые — на этапе тестирования, а некоторые — после завершения циклов тестирования.
Наличие или отсутствие документации, ее актуальность, как и используемые виды варьируются от компании к компании и даже от проекта к проекту. Создание и ведение документации требует весомого количества времени (и компетенций), а потому важно знать основные документы и их роль в процессах, учитывать требования всех заинтересованных лиц, нормативную и законодательную базу, политику и стандарты компании и особенности проекта чтобы понимать, какие из них необходимы (и обоснованны для бизнеса) в каждом случае. Существует огромное количество вариантов документов, часть из которых вы можете никогда и не встретить в реальной работе.
По Куликову документацию можно разделить на два больших вида в зависимости от времени и места ее использования:
-
Продуктная документация (product documentation, development documentation) используется проектной командой во время разработки и поддержки продукта. Она включает:
-
План проекта (project management plan) и в том числе тестовый план (test plan);
-
Требования к программному продукту (product requirements document, PRD) и функциональные спецификации (functional specifications document, FSD; software requirements specification, SRS);
-
Архитектуру и дизайн (architecture and design);
-
Тест-кейсы и наборы тест-кейсов (test cases, test suites);
-
Технические спецификации (technical specifications), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.;
-
-
Проектная документация (project documentation) включает в себя как продуктную документацию, так и некоторые дополнительные виды документации и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она включает:
-
Пользовательскую и сопроводительную документацию (user and accompanying documentation), такую как встроенная помощь, руководство по установке и использованию, лицензионные соглашения и т.д.;
-
Маркетинговую документацию (market requirements document, MRD), которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке).
-
Можно встретить и другие классификации.
-
Внутренняя документация подробно описывает процесс разработки продукта, например стандарты, проектную документацию, заметки о деловой переписке и т. д. Внешняя документация относится к документам, которые подробно описывают сам продукт, например, Системная документация и Пользовательская документация.
-
К внешней документации можно отнести Test policy, Test strategy, различные отчеты, Defect Report, Замечание, Запрос на изменение (улучшение), к внутренней всё от чеклиста до плана тестирования, тестовые данные и т.п. Пользовательская документация (User documentation) — это вся документация, которая будет передана конечному пользователю в комплекте с ПО.
-
Политика качества (Quality policy): отражает видение компании в отношении производства и поставки качественного продукта;
-
Политика тестирования (Test policy): документ высокого уровня, в котором описаны принципы, методы и все важные цели тестирования в организации;
-
Стратегия тестирования (Test strategy): статический документ документ высокого уровня (high-level), обычно разрабатываемый менеджером проекта (project manager). Это документ, который отражает подход к тестированию продукта и достижению целей. Обычно он выводится из Спецификации бизнес-требований (BRS — Business Requirement Specification). На основе стратегии тестирования готовится План тестирования;
-
План тестирования (Test plan): документ, который содержит план всех действий по тестированию, которые необходимо выполнить для получения качественного продукта. План тестирования является производным от описания продукта (Product Description), SRS (Software requirements specification) или сценариев использования (Use Case) для всех будущих действий проекта. Обычно его готовит руководитель тестирования или менеджер по тестированию (Test Lead or Test Manager);
-
Отчет об оценке усилий (Effort Estimation Report): в этом отчете группы тестирования оценивают усилия для завершения процесса тестирования;
-
Сценарий тестирования (Test Scenario): элемент или событие программной системы, которое может быть проверено одним или несколькими тестовыми случаями;
-
Тестовый набор/комплект (Test Suite): “Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего.” (ISTQB). Некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку;
-
Тестовый случай/пример (Test case): набор положительных и отрицательных исполняемых шагов тестового сценария, который имеет набор предварительных условий, тестовых данных, ожидаемого результата, пост-условий и фактических результатов;
-
Тест сурвей (Test Survey): в рунете только
один источник
о нем, но есть упоминания в истории чатов коммьюнити. Test Survey по детализации занимает место посередине между чек-листом и тест-кейсом, а именно содержит в себе только summary и expected result. Т.е. подробнее чек-листов, где только заголовки, но с ожидаемым результатом и без шагов и прочего как в тест-кейсах;
-
Чек-лист (Check List): перечень формализованных Test case в упрощенном виде удобном для проведения проверок, часто только список из заголовков кейсов;
-
Матрица прослеживаемости требований (Requirements Traceability Matrix): документ, который соотносит требования с тестовыми примерами;
-
Тестовые данные (Test Data): “данные, которые существуют (например, в базе данных) на начало выполнения теста и влияют на работу, или же испытывают влияние со стороны тестируемой системы или компонента.” (ISTQB). “Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования.” (ГОСТ 56920)
-
Отчет о дефектах (Defect Report): цель документа заключается в том, чтобы зафиксировать факт ошибки и передать разработчикам подробную информацию о ней;
-
Отчет о выполнении теста (Test Execution Report): содержит результаты тестирования и сводку действий по выполнению тестов;
-
Сводный отчет о тестировании (Test summary report): представляет собой документ высокого уровня, в котором резюмируются проведенные действия по тестированию, а также результаты тестирования;
-
Графики и метрики (Graphs and Metrics): предназначены для мониторинга и управления процессом и продуктом. Это помогает без отклонений вести проект к намеченным целям. Метрики отвечают на разные вопросы. Важно решить, на какие вопросы вы хотите получить ответы;
-
Отчет о тестовых инцидентах (Test incident report): содержит все инциденты, разрешенные или неразрешенные, обнаруженные во время тестирования;
-
Отчет о завершении тестирования (Test closure report): содержит подробный анализ обнаруженных ошибок, удаленных ошибок и несоответствий, обнаруженных в программном обеспечении;
-
Отчет о статусе тестирования (Test status report): предназначен для отслеживания статуса тестирования. Его готовят периодически или еженедельно. В нем указаны работы, выполненные до настоящего времени, и работы, которые еще не завершены;
-
Еженедельный отчет о статусе (менеджер проекта для клиента): Weekly status report похож на отчет о статусе тестирования, но генерируется еженедельно;
-
Отчет об улучшении (?Enhancement report): описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя;
-
Запрос на модификацию (Modification Request): запрос клиента на изменение существующей функциональности;
-
Примечания к выпуску (Release Note): примечания к выпуску будут отправлены клиенту, заказчику или заинтересованным сторонам вместе со сборкой. Он содержит список новых выпусков, исправления ошибок;
-
Руководство по установке / настройке (Installation/configuration guide): это руководство помогает установить или настроить компоненты, из которых состоит система, и ее аппаратные и программные требования;
-
Руководство пользователя (User guide): это руководство помогает конечному пользователю понять как пользоваться продуктом;
-
Различные документы требований.
https://api.docs.cntd.ru/img/12/00/13/49/98/1a71a934-c9ab-4de5-af4b-f4fa89eeb93d/P0020.png
Привет! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов.
ОСНОВНЫЕ ТЕРМИНЫ
Обеспечение качества (Quality Assurance) — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.
Контроль качества (Quality Control) — анализ результатов тестирования и качества новых версий выпускаемого продукта.
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом.
Это одна из техник QC, включающая в себя:
-
планирование работ (Test Management)
-
проектирование тестов (Test Design)
-
выполнение тестирования (Test Execution)
-
анализ результатов (Test Analysis)
Как взаимосвязаны выше указанные термины хорошо объясняется в статье Разница между тестированием, QC и QA. Здесь я не буду слишком останавливаться на этом, потому что эта статья больше про тестирование ПО.
Основные цели тестирования:
-
техническая
Предоставление актуальной информации о состоянии продукта на данный момент.
-
коммерческая
Повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
|
Верификация (verification) |
Валидация (validation) |
|
Соответствие продукта требованиям (спецификации) |
Соответствие продукта потребностям пользователей |
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
-
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
-
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
-
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Атрибуты дефекта
-
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
-
Blocker — ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
-
Крит (Critical) — неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути.
-
Major — часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути.
-
Minor — незначительная ошибка, не нарушающая бизнес-логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
-
Тривиальная (Trivial) — ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта.
-
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
Тест дизайн
Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Ответственные за тест дизайн:
-
Тест аналитик — определяет «ЧТО тестировать?»
-
Тест дизайнер — определяет «КАК тестировать?»
ТЕХНИКИ ТЕСТ-ДИЗАЙНА
-
Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
-
Анализ Граничных Значений (Boundary Value Analysis — BVA). Если брать пример выше, в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
-
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
-
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
-
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
-
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Используется для тестирования сущностей с большими наборами входных данных (например, фильтры, сортировки). Преимущество данной техники в том, что она сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Эта техника заслуживает отдельного внимания и более подробно рассматривается здесь. Также в конце данной статьи есть инструменты для автоматизации этой техники.
-
Таблица принятия решений (decision table) — инструмент для упорядочения сложных бизнес-требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
ВИДЫ ТЕСТИРОВАНИЯ
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом.
Нефункциональные виды тестирования
-
Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
-
Тестирование удобства пользования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс». -
Тестирование безопасности — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
-
Тестирование установки (Installation testing) направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
-
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
-
Тестирование взаимодействия (Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование
-
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
-
Нагрузочное тестирование — это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
-
Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
-
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
-
Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения
По виду Тестовых Сценариев:
-
Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
-
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
По Уровню Тестирования:
-
Модульное тестирование (Unit Testing) Компонентное — проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
-
Интеграционное тестирование (Integration Testing) Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
-
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
-
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
-
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
-
Системное тестирование (System Testing) Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д.
-
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Cтатическое и динамическое тестирование
Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестированию относится тестирования спецификации и прочей документации.
Исследовательское / ad-hoc тестирование
Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом.
Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками.
Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.
Тестирование сборки (Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.
Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В чем разница между regression testing и re-testing? Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.
Регрессионное тестирование — это вид тестирования направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. Регрессионными могут быть как функциональные, так и нефункциональные тесты.
Санитарное тестирование — это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
-
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
-
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
-
Недвусмысленность — требование должно содержать однозначные формулировки.
-
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
-
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию ( а также необходимое в процессе работы оборудование, специальные знания, оценки рисков с вариантами их разрешения). Отвечает на вопросы:
-
Что нужно тестировать?
-
Как будет тестироваться?
-
Когда будет тестироваться?
-
Критерии начала тестирования.
-
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для валидации покрытия продукта тестами.
|
Функциональные требования |
functional requirement 1 |
functional requirement 2 |
functional requirement 3 |
… |
|
Тестовые сценарии |
||||
|
test case 1 |
+ |
|||
|
test case 2 |
+ |
+ |
||
|
… |
Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий, ассоциируется с гибкими подходами в тестировании.
Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.
Тест-кейс состоит из:
-
Названия
-
Более подробного описания сути проводимого кейса (для более сложных кейсов)
-
Описания окружения
-
Указания тестируемого компонента приложения
-
Предусловия — PreConditions (не всегда используются) — действий, которые приводят систему к состоянию пригодному для проведения проверки, либо список условий, выполнение которых говорит о том, что система находится в нужном для состоянии основного теста
-
Шагов — Steps — cписок действий, переводящих систему из одного состояния в другое, для получения результата
-
Ожидаемый результат, на основании которого можно делать вывод о удовлетворении реализации, поставленным требованиям
-
и иногда Постусловия — PostConditions — для перевода системы в первоначальное состояние, как до проведения теста (initial state)
Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего — этоTest script), так и независимыми (Test suite).
Наиболее часто выделяются наборы для:
-
Smoke тестирования
-
приёмо-сдаточных испытаний.
Баг Репорт (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.
|
Шапка |
Название — Короткое описание (Summary), составляется по схеме WWW (What? Where? When?) или ЧТО ГДЕ КОГДА (при каких условиях) |
|
Автор (Author) баг репорта |
|
|
Назначен на (Assigned To) сотрудника, который будет с ним разбираться |
|
|
Статус (Status) бага в соответствии с workflow |
|
|
Проект (Project) |
|
|
Компонент приложения (Component) — название тестируемой функции или ее части |
|
|
Информация по сборке, на которой была найдена ошибка — Номер версии (Version) |
|
|
Информация об окружении — ОС + версия / и т.д… |
|
|
Серьезность (Severity) |
|
|
Приоритет (Priority) |
|
|
Описание |
Предусловия — PreConditions — действий, которые приводят систему к состоянию пригодному для проведения проверки (не всегда требуются) |
|
Шаги воспроизведения (Steps to Reproduce), по которым воспроизводится ситуация, приведшая к ошибке |
|
|
Фактический Результат (Result), полученный после прохождения шагов воспроизведения, часто = название (Summary) + расшифровка чего-либо (например, ошибки по коду), если нужно |
|
|
Ожидаемый результат (Expected Result) — который правильный |
|
|
Прикрепленные файлы |
(Attachment) Файл с логами, скриншот или видео каст либо их комбинация для прояснения причины ошибки |
Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.
UPD: статья пополняется. Спасибо @yakoeka
Перед тем, как выпустить тот или иной программный продукт, он проходит несколько этапов тестирования. Соответствующий процесс является крайне важным. Если неправильно организовать его, разработчики столкнутся с серьезными проблемами.
В данной статье будет рассказано о том, что собой представляет тестирование, каким оно бывает и как организовывается. Также предстоит выяснить, кто такие тестировщики, всегда ли они нужны компании, чем занимаются такие специалисты. Информация будет полезна каждому, кто заинтересован в IT.
Определение
Тестирование систем и программного обеспечения – процесс исследования, а также испытания приложений. Его цель – это проверка соответствия между реальным поведением ПО с выдвинутыми ранее ожиданиями на конечном наборе тестов. Они выбираются конкретным образом.
Системное тестирование – проверка работоспособности операционных систем. Больше относится к администрированию, чем к разработке контента. Важный процесс, без которого не состоится ни один релиз ОС.
Цели
Тестирование преследует определенные цели. К ним относят:
- Повышение вероятности того, что программный продукт будет при любых обстоятельствах функционировать «как надо».
- Проверка на факт соответствия итогового контента изначально выдвинутому набору требований.
- Предоставление актуальной информации о том, в каком состоянии программа находится на текущий момент.
Также специалисты стараются обнаружить ошибки, чтобы исправить их до непосредственного релиза. Особенно это касается критических неполадок. Они должны быть устранены до того, как пользователи начнут использование ПО или системы.
Для чего необходим
Тест – процесс проверки чего-либо. В разработке систем он очень важен. Помогает:
- найти ошибки в приложении и оперативно их исправить;
- получить программное обеспечение, удовлетворяющее запросы как пользователей, так и заказчика;
- скорректировать функции и возможности утилиты до ее релиза, если это необходимо – особенно на ранней стадии написания.
За счет соответствующего комплекса мероприятий удается повысить уровень доверия к компании-производителю. Выход на рынок качественной системы, лишенной ошибок и неполадок – это верный путь к повышению рейтинга предприятия.
Тестировщики способны перенести пользовательские взгляды (позиции) на итоговые продукты, чтобы посмотреть на них под новым углом. Таким, который ранее был немыслим.
Такая проверка помогает снизить стоимость итоговых работ. Связано это с тем, что на ранней стадии системы корректируются дешевле, быстрее и проще. Чем позже удалось найти ошибки, тем дороже обходится их устранение. Это касается даже самых простых программ.
Немного терминологии
Перед углубленным изучением тестирования программ необходимо запомнить несколько терминов и определений. Они помогут быстрее освоиться в соответствующем направлении:
- Качество ПО – совокупность характеристик системы, которые относятся к ее способности удовлетворять установленные и предполагаемые потребности. То, насколько контент соответствует изначальным критериям.
- Верификация – процесс оценки системы или ее компонентов. Делается это для того, чтобы проверить, насколько результаты разработки на заданном этапе удовлетворяют начальным требованиям. Показывает, выполняются ли цели и задачи организации на том или ином шаге программирования.
- Валидация – соответствие программного продукта или системы ожиданиям, желаниям, потребностям пользователя. То, насколько ПО соответствует явным требованиям (спецификациям).
Также стоит разобраться с фазами жизненного цикла. ЖЦ – это процедуры и процессы, с которыми сталкивается приложение/система на каждой стадии разработки от зарождения первоначальной идеи до релиза и поддержки. Жизненный цикл есть у любого программного обеспечения.
О качестве
Что собой представляет качество ПО, понятно. Данный процесс имеет несколько «видов» контроля (проверок). Каждый предусматривает свои ключевые особенности:
- QC – контроль качества продукта (системы). Представляет собой анализ результатов тестирования и качества новых версия проекта. К его задачам относят проверку: готовности приложения к релизу, соответствие требований и качества.
- QA – это обеспечение качества продукта. Отражает процесс изучения возможностей по внесению изменений и улучшению разработки. Позволяет делать связи в команде программистов лучше. Это помогает повысить эффективность тестирования. Среди своих задач выделяет: непосредственное тестирование, проверку технических характеристики, оценку возможных рисков, планирование задач для улучшения (ускорения) выпуска продукта. Предусматривает анализ полученных в ходе тестов результатов. За счет QA удается составить отчеты и другие документы по системе.
Выше – таблица, которая поможет лучше разобраться в соответствующих процессах.
Принципы организации
Рассматривая основы тестирования ПО и систем, нужно разобраться в принципах изучаемых комплексов мероприятий:
- Тестирование указывает на наличие дефектов. Оно может указать на то, что в процессе разработки присутствует тот или иной дефект. А вот доказать отсутствие таких неполадок – нет. Проверка ПО снижает вероятность наличия дефектов, но вот то, что их нет, гарантировать никак не может.
- Исчерпывающие проверки системе недостижимы. Полное тестирование с использованием всех комбинаций вводов и предусловий выполнить физически не получится. Исключение – нетривиальные задачи. Вместо исчерпывающего «анализа» нужно использовать оценивание рисков и расстановку приоритетов. Такой подход позволяет сконцентрироваться на более точном получении итогового результата.
- Раннее тестирование. Проверки должны начинаться как можно раньше в жизненном цикле программного обеспечения. Это помогает быстрее обнаружить неполадки. Фокусироваться такие тесты должны на конкретных целях.
- Скопление дефектов. Разные системные модули содержат различные дефекты – не только по типу, но и по количеству. Плотность скопления неполадок и сбоев в разных частых кода может варьироваться. Условия по тестированию систем должны распределяться пропорционально плотности обнаруженных дефектов. Основная часть критических ошибок приходится на ограниченное число модулей системы.
- «Пестицидный» парадокс. При прогоне одних и тех же тестов несколько раз, в конечном итоге набор тестовых сценарием перестанет находить новые дефекты. Чтобы избавиться от этого парадокса, сценарии должны регулярно рецензироваться и изменяться. Новые тесты, формируемые специалистами, обязательно становятся разносторонними. Это помогает охватить все компоненты системы с целью обнаружения большего количества дефектов.
- Зависимость от контекста. Тесты выполняются по-разному. Все зависит от того, какой контекст изначально заложен. Пример – программный продукт, для которого на передовой находится безопасность, будет проверяться на работоспособность иначе, чем обычный информационно-новостной портал.
- Заблуждение об отсутствии неполадок. При тестировании не всегда обнаруживаются неполадки и ошибки. Это не значит, что система подготовлена на все 100% к релизу. Может получиться так, что дефекты будут критическими и скрытыми. Проект должен не только не иметь неполадок (особенно если речь идет о масштабной разработке), но и быть удобным для использования потребителями.
После изучения принципов «анализа работоспособности» системы можно перейти к более сложным процессам. Пример – рассмотрение жизненного цикла, рассмотрение ключевых видов тестирования.
Этапы
Для выполнения тестов и отладки системы, нужно организовывать процессы правильно. Существует некий алгоритм, отражающий этапы тестирования:
- Анализ имеющегося продукта. Это – первоначальная идея (задумка) проекта.
- Работа с требованиями. На предыдущем этапе происходит формирование технического задания. Теперь предстоит изучить его и доработать, если это необходимо.
- Разработка стратегий тестирования и планирование процедур по контролю качества.
- Создание тестовой документации. Это – этап, на котором формируется «отчетность» для тестировщиков. Вспомогательные документы, опираясь на которые, специалисты будут грамотно выстраивать процессы.
- Тестирование прототипов.
- Основной этап проверок. Здесь выявляется полноценная работоспособность приложения, а также соответствие первоначальным требованиям заказчика.
- Стабилизация и отладка.
- Релиз и эксплуатация.
Именно такой алгоритм используется в системах и приложениях. Он помогает не сбиться с намеченного плана даже в самых крупных проектах.
Жизненный цикл
Стадии разработки программного обеспечения – это этапы (шаги), которые проходят команды разработчиков перед тем, как проект станет доступным для широкого круга пользователей. Разработка начинается с первоначального этапа процесса (пре-альфа), продолжается поэтапно. На каждом очередном «шаге» контент будет дорабатываться, модернизироваться. Финальная стадия – выпуск окончательной версии системы или ПО.
Жизненный цикл можно представить похожим на этапы тестирования. Он обычно включает в себя:
- непосредственный анализ требований к приложению или системе;
- проектирование;
- реализацию;
- тестирование;
- внедрение и поддержку.
Каждая стадия получает свое «имя» или порядковый номер: пре-альфа, альфа, бета, релиз-кандидат, релиз, а также пост-релиз.
Основные требования
Когда с общим представлением тестирования программ удалось ознакомиться, можно приступать к более сложным задачам. Рассматриваемые операции имеют требова ния. Это – спецификации (описания) того, что должно быть реализовано в ходе разработки системы/продукта. Описывают моменты, которые нужно воплотить в жизнь, не отражая техническую детализацию.
Сюда можно отнести следующие критерии:
- Корректность. Каждое требование обязательно точно описывает желаемые инструменты и функции.
- Проверяемость. Требование формулируется так, чтобы существовали способы однозадачной проверки на факт выполнения.
- Полнота. Каждое описание содержит информацию, которой достаточно разработчику для грамотной реализации того или иного функционала.
- Недвусмысленность. Сформулированные описания являются понятными. Они трактуются только одним способом. Неоднозначные аббревиатуры и выражения в них отсутствуют.
- Непротиворечивость. Описание не должно содержать внутренних противоречий. То же самое касается «несоответствий» техническому заданию и иным документам.
- Приоритетность. Приоритет требования представлен количественной оценкой степени важности.
- Атомарность. Описание нельзя разделить на более мелкие без потери завершенности. Каждое требование описывает всего одну ситуацию.
- Модифицируемость. Указывает на простоту внесения изменений в отдельные описания или их наборы.
- Возможность отслеживания. Каждое описание имеет уникальный идентификатор. Он помогает обнаружить требование при необходимости.
Описание не может быть необязательным. Это – явное противоречие самому замыслу требований к тестированию.
Виды
- Тестирование программ может быть разным. Классифицировать этот процесс можно по различным признакам. Ниже – основные варианты.
- Функциональные типы: функциональное тестирование, проверка пользовательского интерфейса, анализ систем безопасности, тестирование взаимодействия.
- Нефункциональное тестирование: все виды проверки производительности (нагрузочное, стрессовое, стабильности или надежности, объемное), проверка установок и удобства пользования, тестирование на отказ и восстановление. Сюда также относят конфигурационные проверки.
- Связанные с изменениями: дымовое, регрессионное, повторное тестирование. К данной категории относят проверку сборки и согласованности (исправности) системы.
Каждый вариант предусматривает свои нюансы и особенности. Зная о них, работа тестировщика будет организована максимально эффективно и грамотно.
Функциональное тестирование
Рассматривает заранее указанное поведение. Базируется на анализе спецификаций функциональности компонентом или систем. Позволяет проверить ключевые задачи проекта.
Проверка пользовательского интерфейса
Называется GUI Testing. Позволяет провести функциональную проверку интерфейса. Это – то, что позволяет понять, насколько получившийся контент соответствует изначальной задаче. Сюда относят анализ размера интерфейса, шрифтов, меню и других особенностей.
Тестирование безопасности
Проводится для того, чтобы понять, насколько системы безопасности в системе или проекте работают. Позволяет оценить риски, связанные с обеспечением целостного подхода к выстраиванию защиты контента, атакам хакеров и вирусов.
Проверка работоспособности
Процессы, направленные на анализ способности системы взаимодействовать с одним или несколькими приложениями (компонентами). Предусматривает дополнительно проверку совместимости, а также интеграционное тестирование.
Нагрузочные проверки
Нагрузочное тестирование. Базируется на автоматизации. Позволяет проверить автоматически, как бизнес-пользователи будут работать на том или ином ресурсе. Это – имитация поведения потенциальной целевой аудитории.
Стрессовые тесты
Проверка на факт того, что система может работать в условиях стресса. Позволяет оценивать способность систем в регенерации. Стресс – это повышение интенсивности выполнения операций до критически высоких значений или аварийные конфигурационные изменения на серверах. Сюда можно включить оценку деградации производительности.
Объемное тестирование
Это – получение оценки производительности. В основе заложено увеличение объемов обрабатываемой в БД информации программы.
Тест надежности
Проводится для того, чтобы удостовериться в работоспособности системы. Предусматриваются ситуации, при которых клиент использует проект длительно. Нагрузка здесь – средняя.
Проверка установок
Проверяется успешная установка и настройка. Данный вариант предусматривает анализ обновлений (насколько хорошо, быстро и точно они инициализируются), а также удаления проекта.
Удобство пользования
Метод, направленные на установку степени удобства системы, обучаемости и понятности. Показывает, насколько легко управляться с системой или программным продуктом в заданных условиях.
Отказ и восстановление
Проверяет:
- способность системы противостоять сбоям;
- насколько в случае неполадок проект способен восстанавливаться;
- будет ли оборудование отключаться при багах;
- какие могут быть неполадки (пример – сбой связи), к чему именно они приводят.
Данный тест позволяет продумать концепции, реализация которых сохранит при сбоях в системе ее работоспособность.
Конфигурационные проверки
Специальный вид «анализа». Он направлен на проверку работы системы при применении разного рода настроек системы. Пример – разнообразные ОС или драйверах.
Дымовые тесты
Это с точки зрения «анализа процессов» — короткие циклы тестов. Они помогают удостовериться в том, что после сборки код будет работать и выполнять заданные функции. В основном используется при обновлениях и доработках.
Регрессионные тесты
Направлены на проверку изменений, сделанных в приложении или среде. Помогают удостовериться в том, что прежние функции работают так, как было задумана изначально.
Повторные тесты
Тесты, во время которых исполняются тестовые сценарии, выявившие ошибки и неполадки последнего запуска. Данные процессы дают понять, удалось ли избавиться от ранее обнаруженных неполадок в системе.
Тесты сборок
Направлены на соответствие выпущенной версии критериям качества в начале тестирования. Это – аналог «дымового» подхода.
Санитарное тестирование
Узконаправленный «анализ». Его хватает для того, чтобы показать, что конкретная функция работает согласно задумке. Это – подмножество регрессионного тестирования. Позволяет понять, насколько определенная часть системы остается работоспособной после внедрения обновлений в коде или окружающей среде.
Иные виды
Каждый тестировщик говорит о том, что тестирование систем и ПО бывает разным. Способов классификации очень много. Кроме перечисленных вариантов можно выделить:
- Статическое тестирование. Код не будет выполняться. Все проверки осуществляются вручную. Направлено на повышение качества итогового продукта.
- Динамическое. Это – выполнение кода. Нацелено на функциональное поведение системы, использование памяти, общую производительность. Позволяет подтвердить то, что проект работает согласно задумке.
- Ручное тестирование систем. Начинать и организовывать анализ проекта придется вручную. Долгий и затратный процесс.
- Автоматизированный вариант. Хотя ручное тестирование до сих пор есть, на передовую выходить автоматизация. Это – проверка работоспособности ПО при помощи специальных приложений и функций.
- Позитивные тесты. Здесь применяются только корректные электронные материалы.
- Негативные тесты. Проверка системы, при которой используются некорректные данные. Выполнять будут «неправильные» операции.
- Модульный подход. Проверка логически выделенного и изолированного компонента системы.
- Интеграционный вариант. Проверяет, насколько несколько модулей системы хорошо взаимодействуют друг с другом и иными частями ПО.
Основы тестов изучены. Перед тем, как начать проверку работоспособности, нужно обратить внимание на типы «анализа». Без них специалисту не обойтись.
О типах
Существует тестирование белого ящика. Это – метод, который предполагает, что внутренняя структура, устройство и реализация известны специалисту. Сюда можно отнести проверки, базирующиеся на анализе внутренней структуры элемента/системы, а также тест-дизайн.
Есть тестирование серого ящика. Метод, предполагающий сочетание «черного» и «белого» ящиков. Внутреннее устройство программы будет известно лишь частично.
Тестирование черного ящика – тест, базирующийся на спецификации. Является тестированием поведения.
Как стать тестировщиком
Стадии тестирования ПО, его ключевые виды и иные особенности рассмотрены. Тестировщик – это специалист, которые проверяет системы и приложения. Обычно непосредственной разработкой такой человек не занимается.
Это важный специалист в любой команде. Чтобы стать тестировщиком, можно изучить специализированную литературу и попрактиковаться на различных мелких проектах. Но лучше всего завершить компьютерные онлайн курсы. Там в сжатые сроки дадут «базу» для погружения в IT-профессию, а также предоставят богатый практический опыт. В конце обучения выдается электронный сертификат, способный подтвердить документально приобретенный спектр знаний, навыков и умений.
P. S. Большой выбор курсов по тестированию есть и в Otus. Есть варианты как для продвинутых, так и для начинающих пользователей.