Как инженеры a1qa проводили приёмо-сдаточные испытания ПО: Часть 1. Теоретическая
Вот уже более двух лет команда a1qa работает на проекте по созданию платежной системы для одного крупного банка. Поначалу задачи нашей команды сводились только к тестированию системы, однако через некоторое время заказчик поручил нам подготовку и проведение приёмо-сдаточных испытаний.
Задача эта нетипичная для тестировщиков. Поэтому мы решили поделиться своим опытом и рассказать, как её грамотно выполнить, оправдав доверие заказчика.
Что такое приёмо-сдаточные испытания (ПСИ)?
Прежде чем выпускать продукт на рынок, заказчик должен убедиться в возможности использования разработанного решения, в его безопасности, надёжности, корректном функционировании и проверить другие характеристики, описанные в требованиях к продукту.
ПСИ особенно актуальны для проектов, на которых выпуск некачественного продукта может привести к значительным финансовым потерям (к слову, наш проект именно к таким и относится).
Итак, цели проведения ПСИ:
Избежать хаоса в подготовке и проведении ПСИ, развеять сомнения в методах убеждения и их эффективности помогают различные нормативно-правовые документы, которые стандартизируют процессы разработки и тестирования.
Один из таких документов, обязательный для любых приёмо-сдаточных испытаний, – это «Программа и методика испытаний».
Документ «Программа и методика испытаний»: что нужно знать тестировщику
Написанием и форматированием данного документа обычно занимаются специально обученные люди, например, технические писатели.
Однако знать, из чего состоит документ, тестировщику не помешает. Кроме того, подготовка одного из разделов может быть поручена именно тестировщикам.
Обратимся к официальной документации. Согласно межгосударственному стандарту ГОСТ 19.301-79, документ «Программа и методика испытаний» должен иметь следующую структуру:
Какой из разделов под силу подготовить функциональному тестировщику? Конечно же, «Методы испытаний». Об этом поговорим позже, а пока ещё немного теории.
Критерии успешности приёмо-сдаточных испытаний
Как правило, успешность ПСИ определяется на этапе заключения контракта. Одним из таких критериев может быть процент успешно пройденных во время демонстрации проверок. Например, если на проверку выносятся 100 тест-кейсов и критерий pass-rate составляет 80%, то 80 тест-кейсов должно быть успешно пройдено, иначе считается, что продукт приёмку не прошел, а значит, не может быть допущен к опытной и промышленной эксплуатации.
На практике же успешность приёмо-сдаточных испытаний чаще определяется не одним критерием, а совокупностью нескольких. Например, учитывается процент реализованных требований от общего числа и ограничение по количеству дефектов того или иного приоритета. Оперируя данными по этим критериям, принимается решение об успешности ПСИ.
На этом необходимая теория заканчивается. В следующей части расскажем, как приёмо-сдаточные испытания проводила команда a1qa и какие трудности ей пришлось преодолеть.
Корпоративный троллинг — 3, или сдача работ без лишних забот
В предыдущих статьях (первая, вторая) мы бегло и в шутливой форме прошлись по примерам противодействия, которое оказывают нам сотрудники заказчика на различных этапах проекта. Сегодня предметом рассмотрения будет сдача работ, и мы подойдем к этому этапу во всеоружии, чтобы ни один тролль не прорвался. Получилось много букв, но, надеюсь оно того стоит.
Сдача результатов работы является одним из самых драматических этапов проекта. Человеко-месяцы, потраченные на разработку, отладку, тестирование и внедрение вашего решения, не должны быть потрачены зря. Если сдача работ поручена вам, то ваша роль в команде весьма значительна, а доверие руководства велико, даже если начальники вам этого никогда не говорили. Облажаться на сдаче работ иногда означает конец вашей блистательной карьеры. Так что лучше этого не делать.
Процесс приемо-сдаточных испытаний должен быть строго формализован. Всем понятно, что в конце этого процесса должен появиться протокол и акт, на основании которого выпускается приказ о переводе системы в опытную или промышленную эксплуатацию. Акт также является формальным поводом для выставления счета на оплату очередного этапа проекта.
В этой статье я без лишних шуток (какие уж тут шутки!) и максимально последовательно (ну, для блога, конечно) опишу процесс сдачи проектных работ. Разумеется, многие вещи опытным коллегам покажутся очевидными. Пусть. Зато менее опытные коллеги или желающие примерить ответственную роль сдающего на себя найдут эту публикацию полезной и познавательной.
Направления троллинга в ходе испытаний
Программа и методика испытаний
Документ ПМИ, или программа и методика испытаний, на мой взгляд, более важен, чем даже ТЗ. От качества этого документа зависит половина, если не две третьих успеха испытаний.
Протокол испытаний
На основе тестов ПМИ вы должны подготовить протокол испытаний. Протокол будет являться документом, подтверждающим то, что ваша система выполнена в соответствии с ТЗ, о чем делается соответствующая запись в акте. Не доверяйте подготовку протокола никому другому, если не хотите иметь бледный вид перед комиссией. Обычно протокол является «копипастом» из ПМИ, так что его подготовка много времени у вас не займет.
Протокол испытаний состоит из общей части, таблицы тестов и списка замечаний.
Генеральная репетиция
Без нее нельзя. Только так вы можете отловить все шероховатости в тестах, выявить тесты, крадущие время и тесты, результаты которых сомнительны. Помните, что визуальная составляющая должна быть безупречна. Постарайтесь забить в систему данные, которые выглядят натурально и похожи на то, с чем имеет дело клиент. Проследите, чтобы имена пользователей и другие поля не содержали ненормативную лексику (любимая шутка внедренцев и программеров). Эти «шуточки» иногда действуют на комиссию как красная тряпка на быка.
Не бойтесь переписать ПМИ с нуля. Один раз мы пожалели время и перекомпоновали тесты вместо того, чтобы переписать их. В итоге мы просто успокоили сами себя, не изменив общей плачевной картины. За что и огребли.
Если вы сдаете вдвоем, гоняйте тесты вместе. Приглашайте коллег, пусть они придираются, изображая из себя комиссию. Потраченное на эти игры время в итоге позволит всем вам получить деньги от довольного заказчика.
Эффективный дуэт
Оптимальной командой для сдачи является пара из внедренца (или программиста) и бизнес-аналитика (консультанта).
Точно так же, если консультант скажет глупость, а заказчик нахмурится в ответ, программист может с лицом оскорбленной невинности продемонстрировать очередную фишку системы и тогда заказчик проникнется к нему симпатией, так как поймет, кто тут настоящий профи, а кто клоун в галстуке.
В особенно напряженные моменты можно устроить дружескую перепалку, разрядив тем самым обстановку и отведя внимание аудитории от не совсем корректной работы системы.
Не зря же западные «айтишные евангелисты» любят работать парами.
Процесс пошел!
Когда вы приступили к испытаниям, не смейте лезть в систему сразу! Постарайтесь пройти сначала всю формальную часть. Сверьте коды документации, носителей информации, откройте ТЗ, положите на стол Руководство пользователя. Пройдитесь по нефункциональным требованиям. ОС Windows — галочка. Поддерживаемые версии браузеров — раз, два, три, галочка. Язык разработки, архитектура, база данных, да мало ли что там в ТЗ понаписано! Все нужно показать в документации. Хотя бы там всего лишь одно предложение, оно обязано там быть! Не пренебрегайте этой бюрократией, тролли только этого и ждут. Вам хочется получить в протоколе, что «Исполнитель не продемонстрировал, что язык java является кроссплатформенным языком высокого уровня. Требования ТЗ 1.2.3 и 3.2.1 не выполнены»? А ведь это не придуманный маразм, это сама жизнь.
Когда вы закончили с формальной стороной дела, тоже не спешите лезть в систему! Следующая группа тестов заключается во включении монитора и демонстрации рабочего стола, иконок и запуска программы (если запуск нужно тестировать). Вход в систему с неправильным паролем, галочка, вход с правильным — опять галочка, галочка, галочка. Меню — эка невидаль! Главная форма, список чего-нибудь. Галочка.
Когда дойдет дело до нажатия кнопок в системе, комиссия уже порядком устанет и проголодается. А вы в первый день сможете проскочить, к примеру, основные справочники и базовые функции. А на другой день оставить бекапирование, администрирование и еще какую-нибудь ерунду.
Замечания
Они будут, можете не сомневаться. Нет такой системы, к которой не было бы замечаний. Ваша задача — заставить заказчика поделить все замечания на критические и не критические. Первые должны быть исправлены для успешного перевода в опытную эксплуатацию. Вторые могут быть исправлены в ходе опытной эксплуатации. Соответственно, лучше, чтобы первых вообще не было или были только те, исправить которые не представляет особого труда.
Когда заказчик делает замечание, вы фиксируете его формулировку в протоколе. Обязательно проговорите записанные слова, убедитесь, что вы друг друга поняли. Будет лучше, если в ходе испытаний будет работать диктофон. Постарайтесь сделать так, чтобы формулировка замечания была конструктивной, то есть, было понятно, что нужно сделать, чтобы замечание было снято. Слов «все», «ничего», «каждый», «любой», а также неизмеряемых качественных оценок «плохо», «медленно», «слишком быстро» и т.п. в замечании быть не должно! Если «система работает медленно», то должно быть написано «запрошенная форма должна отображаться в течении 5 сек». Если «символы на схеме плохо различимы», то должно быть написано «увеличить символы на схеме до 18 пунктов». И так далее.
Конкретизация позволит минимизировать возможность необоснованного перетаскивания того или иного замечания в ранг критического. Заказчик может утверждать, что отработка запроса за 6 секунд для него неприемлема, а за 5 секунд — в самый раз. Пусть это появится в протоколе! Но что-то мне подсказывает, что не появится. Или замечание будет признано некритическим.
Все замечания, признанные критическим фиксируются в акте: «Комиссия постановила, что система соответствует ТЗ и рекомендует принять ее в опытную эксплуатацию при условиях отработки следующих замечаний. » При этом список некритических замечаний лучше непосредственно в акт не включать. Их обычно много и они могут напугать ответственного сотрудника, ставящего подпись. Если заказчик беспокоится, что вы не будете отрабатывать некритические замечания, успокойте его при помощи документа «Методика проведения опытной эксплуатации», котрый настоятельно рекомендуется подготовить. Там вы в простой и доступной форме должны описать как будет проходить опытная эксплуатация, как будут отрабатываться найденные баги и как будет заполняться журнал опытной эксплуатации, являющийся гарантом безболезненного окончания ОЭ, ввода системы в промышленную эксплуатацию и салюта с шампанским по причине окончания проекта.
Что делать, если все пропало
Когда вы понимаете, что испытания идут неудовлетворительно, система безобразно глючит, а заказчик уже исчерпал запас ругательств, не нужно сдаваться! Караван должен продолжать идти вперед, будет новый релиз, новые испытания. И даже если проект будет завален, ничего в этом страшного для вас нет. В условиях острого дефицита толковых исполнителей вы быстро найдете работу, тем более, что я бы на вашем месте не стал бы работать в компании, допускающей подобные ситуации.
Чтобы не терять время в бесплотных препирательствах, я бы рекомендовал применить тактику «бей своих, чтобы чужие боялись». Начните вместе с заказчиком ругать «этих криворуких программеров», «жадное руководство», а когда накал страстей уменьшится, предложите заказчику собрать максимум багов «этого глюкалова», чтобы показать этим нехорошим людям какие они нехорошие.
Тогда активные сотрудники заказчика во главе с троллем-киллером начнут собирать баги и радостно наполнять протокол сотнями замечаний. Фактически, за свои собственные деньги они проведут вам высокоуровневое функциональное тестирование, на которое, судя по результатам испытаний, ваши разработчики так и не сподобились.
По хорошему, описанной безобразной ситуации вообще быть не должно. Но проектный бизнес отличается иногда странными флуктуациями, когда первый прототип пытаются сдать как полноценную систему, начальство врет подчиненным и самим себе, все вокруг делают хорошую мину при плохой игре и уверяют друг друга в обязательном и непременном успехе.
Вторым советом в подобной ситуации было бы, как я уже говорил, сразу уволиться из конторы, допускающей подобные «косяки». Потому что по всем меркам настоящему профессионалу не стоит портить свою репутацию подобным образом.
Заключение
Итак, коллеги, на этом я спешу завершить трилогию о корпоративных троллях, которых не нужно бояться, а нужно уважать и даже некоторым образом любить, так как они не дают ленивым обезьянам ИТ бизнеса падать от обжорства с деревьев, держат нас в тонусе и даже привносят некоторый интерес в безумно скучные, но крайне необходимые проектные работы.
UPD от 23.06.2011. Пользователь igendo добавляет в комментариях, что неплохо бы уже на этапе заключения договора утвердить формы официальных документов проекта.
Добавлю, что очень помогает в работе, когда формы актов, протоколов и прочих формальных документов зафиксированы в контракте. Дабы не было необходимости их предварительно согласовывать, пересогласовывать и переделывать\переподписывать в середине проекта.
От себя тоже могу добавить, что в совсем уж тяжелых и масштабных проектах принято составлять устав проекта, некий документ о глубинном смысле которого можно говорить часами. Там, кроме всего прочего, можно обговорить и формы документов проекта, и процедуры контроля хода проекта, и высокоуровневые бизнес-задачи. Но это, опять же, тема для другого поста.
Пользователь ЖЖ ryzhij_papa Добавляет, что существует практика ранжирования замечаний по степени их влияния на бизнес, методика ранжирования также заносится в ПМИ.
Нужно формально описать что является замечаниями крического, высокого, среднего и низкого приоритета. Описание делается в терминах бизнеса. Если утрировать, то так: критический приоритет при потере 1000$, высокий если 100$, средний когда сотрудники в мыле, но убытков у нас нет, низкий — возможны случаи легкого умопомрачения на 5-6 году жизни с такой багой.
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
планированием работ (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). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.