зачем нужно тестировать по
Что такое тестирование программ и зачем оно нужно
Оказывается, 75% времени при создании программ уходит вовсе не на программирование. Разбираемся, чем же занимаются тестировщики.
Вероятно, ни одну вещь в мире нельзя сделать без ошибок, и программы не исключение. Допустим, вы написали код и не видите в нём явных багов. Как узнать, что будет при реальном использовании: поведёт ли себя программа так, как от неё ожидают?
Почему тестирование — это так важно
Вот типичные программные баги:
Прежде чем новая версия компьютерной программы, сайта или мобильного приложения попадает к пользователю, она должна пройти через руки инженеров-тестировщиков. Они ищут места в коде, где программа работает не так, как задумано. Чтобы найти как можно больше ошибок, тестировщики моделируют разные ситуации, которые могут возникнуть при использовании приложения.
Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.
Профессия Тестировщик
Вы научитесь тестировать сайты, мобильные приложения и другое ПО. Узнаете, как устроена работа IT-компаний, и сможете понять, как вы хотите развиваться в профессии. Гарантированно получите работу. Уже джуниоры очень востребованы рынком, а наш курс позволит достичь middle-уровня.
Какие виды тестирования существуют
Пользователи непредсказуемы. Они могут делать не только то, что предусмотрено программой, но и то, что ею категорически не предусмотрено. Тестировщик должен проверить все возможные и невозможные сценарии их поведения и убедиться, что программа продолжает работать.
Вообще, у тестирования есть философия, которая строится на том, что в любой программе по определению есть ошибки и найти их все невозможно. А если вы почему-то не нашли ошибку, значит, просто плохо искали. Удачный тест для тестировщика — тот, при котором нашли баг. А если всё нормально работало, значит, тест неудачный и свою задачу не выполняет.
Ошибки возникают не только при кодировании, но и при проектировании системы, и даже на этапе разработки технического задания. Поэтому и тестируют код не только в самом конце работы, а на разных этапах.
Есть несколько видов тестирования:
Что тестируют на разных этапах разработки
Есть несколько уровней тестирования. Их проводят в разное время:
В зависимости от этапа разработки перед тестировщиками стоят разные цели:
Не бывает идеального тестирования: в принципе невозможно доказать, что программа работает правильно при любых условиях. Но тестировщики могут найти и уточнить, в каких условиях она работает неправильно.
Как обычно проходит тестирование
Как правило, тестировщики начинают работать с программой сразу после начала проекта:
После выхода каждой новой сборки программы сначала делают дымовое тестирование — проверяют, что приложение запускается и выполняет основные функции. Если всё в порядке, программу передают на дальнейшее тестирование. Если нет — сразу возвращают на доработку.
Следующий этап — регрессионное тестирование. Тестировщики ищут баги в новых участках кода и в тех местах, где исправляли ранее найденные ошибки.
После этого программу проверяют в разных уровнях: испытывают её функциональность, производительность, работу с окружением. Это можно делать вручную или с помощью автоматических тестов-кейсов.
Автоматизированное тестирование облегчает проверку и экономит время. Лучше всего это работает в сложных приложениях с большой функциональностью.
Когда есть результат, инженеры-тестировщики готовят отчёт по тестированию и отправляют его разработчикам, чтобы те исправили найденные баги. Так происходит от версии к версии, пока результаты не будут удовлетворять критериям, описанным в тест-плане.
Кто всё это делает: немного о профессии
Если проект большой, над ним работает целая команда: одни тестировщики готовят тесты, другие проверяют их полноту и логику, третьи занимаются непосредственно тестированием. Над небольшими задачами может работать один специалист, причём удалённо.
Тестировщики — среди самых востребованных сейчас специалистов-айтишников. Появляется множество новых программ, и каждой из них нужен контроль качества. QA-специалистов нанимают крупные компании-разработчики ПО, они могут стать фрилансерами и работать сразу на несколько фирм.
Как показывает статистика работных сайтов, на рынке не хватает разработчиков автотестов, а специалистов ручного тестирования достаточно. Средняя зарплата тестировщика в Москве больше 120 тысяч рублей, а по регионам —
примерно 55–60.
На скриншотах ниже — данные с HeadHunter. В сентябре 2020 года там было 3000 открытых вакансий тестировщика.
Что такое тестирование и почему мы должны его делать?
В первой статье в этой серии из пяти частей о тестировании в JavaScript мы рассмотрим, что такое тестирование и почему мы должны это делать. Если вас интересует тестирование в контексте Vue.js, то обратите внимание на книгу «Тестирование компонентов Vue.js с помощью Jest».
Тестирование в области разработки программного обеспечения — это процесс оценки того, что все части приложения ведут себя так, как ожидалось.
Тесты выполняют проверки программного обеспечения, проверяя, что полученный результат соответствует спецификациям, учитывая разные входные данные. Каждая из этих проверок называется тестовым сценарием (test case). В рабочем процессе agile каждая пользовательская история должна иметь набор тестовых сценариев. Простой пример:
В тестовых сценариях проверяются требования и характеристики конкретной функциональной возможности (функционала). Они могут предоставлять определённые детали или шаги, чтобы их можно было воспроизвести.
Скорее всего, если вы читаете эту статью, вы знаете, что такое тестирование и TDD, но если вы новичок в тестировании, у вас может возникнуть вопрос, который был в своё время у всех нас:
Не занимает ли тестирование слишком много времени? Нужно ли мне тестировать всё?
В этой статье мы поговорим о плюсах и минусах тестирования, о типах тестирования, и что ещё есть кроме тестирования для обеспечения качества приложения.
Зачем писать тесты?
Говоря о том, зачем нужно тестирование, можно упомянуть следующие его преимущества:
Надеюсь, что на данном этапе вы убедились, почему тестирование полезно для вас, вашего приложения и компании, в которой вы работаете.
Типы тестов
Тесты делятся на разные типы. Каждый тип теста имеет свою цель (назначение) и область действия, и вам следует знать об этом. Каждый разработчик в какой-то момент пишет тест, который тестирует то, чего он не должен.
У нас есть три основных типа тестов:
Пирамида описывает баланс различных типов тестов. Нижняя часть — это самые быстрые, простые и самые изолированные тесты, а верхние — самые дорогие, самые медленные и охватывают всё приложение в целом.
Интеграционный слой можно даже разделить на ещё большее количество слоёв:
Хотя есть несколько разногласий по поводу количества типов тестов и их имён, наиболее распространёнными являются тесты компонентов и API. Это всего лишь особые типы интеграционных тестов. В частности, тесты компонентов — это тесты, которые мы пишем на стороне фронтенда при тестировании приложения на Vue.js.
Статический анализ
Тесты — не единственный инструмент для обеспечения качества кода. В наше время для JavaScript также есть инструменты статической типизации и утилиты для проверки кода ( linters, далее — линтеры). Они выполняют статический анализ вашего кода для поиска несоответствий выбранному стилю кода, неправильного использования языка, ненадлежащей и плохой практики, ошибок в контракте данных и многое другое.
Контракт данных — формат данных, который будет использоваться некоторой частью приложения, например функцией. Обычно под этим понимается в каком виде будут представлены данные, например, тип входных и возвращаемых данных.
Статическая типизация делает ваш код более безопасным на основе каждого контракта. Такие инструменты, как TypeScript или Flow, позволяют определять переменные, параметры и типы возвращаемых значений. Они гарантируют, что ваши классы, функции и методы имеют определённую структуру, а остальная часть вашего кода хорошо работает в соответствии с этим. Многие компании, принявшие статическую типизацию, сразу же поймали несколько ошибок.
Давайте сравним типизированную версию и не типизированную версию функции sum :
Линтеры — это специальные программы, цель которых анализ и проверка различных аспектов кода во время компиляции. JavaScript не имеет преимуществ компилятора, поэтому подвержен ошибкам во время выполнения по сравнению с другими языками, где об ошибках будет сообщено на стадии компиляции. ESLint стал линтером де-факто в JavaScript, а TSLint — в сообществе TypeScript.
Линтер пытается заполнить пробел, предоставляя правила проверки ошибок синтаксиса, стиля кода и неправильного использования (проблемных паттернов). В результате он уменьшает количество ошибок и повышает качество и корректность вашего кода.
В качестве примера, если вы используете правило no-var в ESLint и напишите следующий код:
Вы получите ошибку Unexpected var, используйте let или const вместо (no-var) ( Неожиданный var, используйте let или const вместо него (no-var)).
В пирамиде статический анализ ещё точнее определён и проверяется быстрее (почти в режиме реального времени), чем модульные тесты, что делает его основой пирамиды:
Тестирование ПО: суть профессии, требования и заработная плата
Разработка программного обеспечения — сфера, которая будет в ближайшее время только расти, несмотря ни на эпидемию, ни на экономический кризис. Соответственно, будет увеличиваться дефицит технических специальностей, связанных с разработкой.
Одна из них — тестирование ПО. Забегая наперед, скажем, что в тестировщиках нуждаются практически все компании, которые занимаются созданием программного обеспечения и сервисов. Что касается порога входа, требований, которые предъявляются к разработке ПО и размере заработной платы тестировщиков, то в этом вопросе поможет разобраться преподаватель курса GeekBrains «Тестирование ПО» Максим Засецкий.
QA, QC и тестирование
Тестирование программного обеспечения — обширное понятие, которое включает планирование, проектирование и, собственно, выполнение тестов.
Из чего состоит сфера тестирования ПО
QA (Quality Assurance) — обеспечение качества продукта. QA-специалист контролирует и обеспечивает качество работы продукта компании. Он отвечает и за отдельные этапы разработки софта. В частности, за выбор инструментов для разработки, предотвращение возможных проблем. Еще он участвует в процессе совершенствования продукта. QA охватывает все этапы разработки, включая описание проекта, собственно, тестирование, релиз и, зачастую, пост-релизный этап.
QC (Quality Control) — контроль качества продукта. Задача QC-специалиста — проверка конкретного продукта, что включает анализ кода продукта, дизайна, плюс тестирование. QC-инженер разрабатывает стратегию тестирование вполне определенного тестирования, взаимодействует с разработчиками и организует само тестирование.
Специалист по тестированию занимается выполнением тестов. Тестированием называют проверку соответствия результатов работы программного продукта на соответствие заданным критериям. Тестировщики занимаются тестированием всего продукта в целом или же отдельных компонентов. Тестирование играет важнейшую роль в обеспечении качества продукта.
Кстати, есть внешнее ответвление — современное направление тестирования Developer in test. Специалисты этого направления — вроде как и разработчики, но занимаются они обеспечением качества разрабатываемого продукта.
Что должен знать и уметь хороший тестировщик?
Исходя из всего, что сказано выше, сложно выделить конкретные знания или умения. Все сильно зависит от проекта, на котором работает специалист, соответственно, и от стека технологий, которые на этом проекте используются.
Если говорить о джуниорах, то здесь можно выделить общие навыки:
Хорошие знания в клиент-серверной архитектуре.
Хороший тестировщик должен понимать механизм взаимодействия веб-приложений, уметь локализовать проблему вне зависимости от того, возникла ли она на фронтэнде или бэкенде.
Специалисту необходимо иметь базовые навыки использования специализированного софта, уметь использовать инструменты devTools, иметь представление о работе снифферов, знать базовые команды консоли Windows.
Крайне важны soft-скиллы:
Умение общаться с коллегами.
Умение ясно излагать мысли.
Способность четко описать проблему разработчику.
Умение работать с документацией.
Понимание стандартов разработки ПО.
Готовность доказать и отстоять свою позицию, основываясь на документации или здравом смысле.
Существует мнение, что профессионалом в сфере тестирования можно стать через 3 года, при условии наличия технического бэкграунда. В первый год молодой специалист начинает понимать, что от него требуют, во второй год — понимает, как нужно выполнять то, что от него требуют, на третий — пытается улучшить выстроенный процесс, добавляя свое видение.
Что касается тестировщиков с большим опытом и обширными знаниями, то им крайне необходимо постоянно расширять навыки, следить за тенденциями в мире IT, искать новые подходы к решению вчерашних задач и всегда быть «на волне».
В разных компаниях требования к тестировщиком отличаются. Кому-то нужны Developer in test, а для кого-то важнейшую роль играют софт-скиллы специалистов.
Мифы о тестировании ПО и тестировщиках
Почему-то все более распространенным становится заблуждение, согласно которому тестировщики занимаются тем, что просто нажимают на кнопки и вводят рандомную информацию в разные поля программы. На самом деле это не так, если бы тестировщики хаотично нажимали на кнопки и вводили случайные данные, то результаты тестирования никакой ценности для разработчика не принесли бы. Результаты представляли бы собой неструктурированную информацию из которой невозможно получить представление о том, насколько качественным получился продукт и насколько удобен он для пользователей. У тестировщиков всегда есть стратегия работы, план, который позволяет получить объективное описание актуального состояния продукта.
Второй миф заключается в утверждении, что тестировщики ответственны за качество ПО. На самом деле, ответственность за качество разработки продукта несет вся команда. Тестировщики же помогают улучшать качество разработки, а также выявляют проблемы на ранних стадиях.
Третий миф — тестировщиков очень много. На самом деле хороших специалистов на рынке мало. Много тех, кто выкладывает резюме с пометкой «тестировщик», не понимая сути тестирования ПО.
Востребованность профессии и доходы тестировщиков ПО
По данным зарплатного калькулятора Хабр Карьеры, средний размер заработной платы тестировщика составляет чуть больше 96 тысяч рублей в месяц. Конечно, это среднее значение. Есть те, кто зарабатывает значительно меньше, скажем, тысяч 30, а есть и те, кто получает в 10 раз больше — около 300 тысяч рублей.
Средняя з/п тестировщика ПО в первом полугодии 2020 года
Профессионалы примерно одного уровня, выполняющие один и тот же пул задач в столице и в регионе могут получать сильно отличающуюся зарплату. В Москве это 100+ тысяч рублей, в регионах — 40-50 тысяч рублей, а в некоторых случаях и вовсе 20-30 тысяч.
Если сравнивать уровень зарплаты тестировщиков в РФ и за рубежом, то разница в среднем 30-50%.
Источник картинки https://habr.com/ru/post/446650/
Плюс можно сравнить еще разброс уровня заработной платы в зависимости от региона — Евросоюз, СНГ, США и Канада, РФ.
Источник картинки https://habr.com/ru/post/446650
Наш зарплатный калькулятор показывает и список навыков, которыми владеют тестировщики ПО:
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов.
ОСНОВНЫЕ ТЕРМИНЫ
Обеспечение качества (Quality Assurance) — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.
Контроль качества (Quality Control) — анализ результатов тестирования и качества новых версий выпускаемого продукта.
планирование работ (Test Management)
проектирование тестов (Test Design)
Тест дизайн — это этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.
анализ результатов (Test Analysis)
Основные цели тестирования
техническая: предоставление актуальной информации о состоянии продукта на данный момент.
коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. Как пример, есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать пример выше, в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).
Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Классификация по целям
Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректности работы функциональности приложения.
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).
Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.
Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.
Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.
Классификация по знанию системы
Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.
Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.
Классификация по исполнителям тестирования
Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.
Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.
Классификация по уровню тестирования
Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Классификация по исполнению кода
Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа программного (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.
Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.
Классификация по хронологии выполнения
Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.
Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.
Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
Недвусмысленность — требование должно содержать однозначные формулировки.
Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию (а также необходимое в процессе работы оборудование, специальные знания, оценки рисков с вариантами их разрешения). Отвечает на вопросы:
Что нужно тестировать?
Как будет тестироваться?
Когда будет тестироваться?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для валидации покрытия продукта тестами.