на чем следует фокусироваться во время тестирования
Как научиться думать как тестировщик
Чтобы заниматься тестированием, не обязательно иметь какой-то врожденный талант, доступный только избранным. Но назвать это тривиальной деятельностью, которой может заняться абсолютно каждый, тоже нельзя. Представляем пять советов, как стать еще лучше в тестировании.
Умение тестировать — это не врожденный навык и не какой-то редкий ген, который наследуют редкие счастливчики. Тестировщиками не рождаются.
Но тестирование также и не примитивная последовательность шагов, которую можно изложить в инструкции и передать в работу любому человеку.
На самом деле, тестирование — это сложная и глубокая область, которая для успешного выполнения требует практики и опыта. Также это деятельность, с которой некоторые справляются лучше остальных — будто они обладают подходящим складом ума. «думают, как тестировщики».
Что представляет собой этот склад ума и как его развить в себе?
В этой статье я поделюсь с вами примерами пятью особенностей, которые я обнаружил на практике и которые отличают хороших тестировщиков. Все они просты для понимания, но сложны в освоении, и научиться им может любой, кто готов посвятить этому время и усилия.
Примечание: здесь я использую термин «тестировщик» в общем смысле, для обозначения каждого, кто занимается тестированием. Я не ставлю своей целью в этой статье защищать специально обученных специалистов, называемых «тестировщиками/QA-инженерами», или идею, что тестированием занимаются только тестировщики — это обсуждение пройдет в более широком ключе.
«Перевернутое» мышление и бремя доказывания
Мой первый руководитель сказал мне как-то: «когда тестируешь приложение, просто предположи, что баги есть. Если ты изначально отнесешься к приложению так, что оно работает правильно и без ошибок и попытаешься найти их, то много ошибок не найдешь. Ты будешь видеть то, что ожидаешь увидеть. И наоборот, если ты будешь предполагать, что баги есть, то внезапно заметишь их повсюду».
Этот небольшой совет идеально передает идею «перекладывания бремени доказывания». Начинать тестирование следует с предположения, что приложение не работает. Фактически, оно вероятно и не может работать. Даже помыслить нельзя, что оно работает. В нем не просто есть какие-то баги, оно совершенно полностью неправильное. Кто-то пытается надурить тебя, выдавая это приложение за «рабочее». Может, это вообще подстава.
Удерживая это в памяти, заставьте приложение доказать, что вы ошибаетесь. Заставьте его выполнять все действия и демонстрировать нужное поведение, пока ему не удастся убедить вас в обратном, что это никакая не подстава. Чудо из чудес, но это действительно работающий софт.
Сформулируем по-другому: приложение должно считаться виновным, пока не доказано обратного.
Хорошие тестировщики относятся к приложению «перевернутым» образом мышления — они изначально исходят из точки наихудших предположений. Можно назвать это здоровым скептицизмом, конструктивным пессимизмом, или иным термином, но суть в том, что изначально мы исходим из предположения, что приложение не работает. Когда мы стартуем из этой точки и фокусируемся на том, что приложение должно доказать нам обратное, это помогает преодолеть естественную предвзятость подтверждения и помогает хорошим тестировщикам обнаружить баги, которые могли остаться незамеченными для других.
Нельзя сказать, что инверсионное мышление является специфическим для тестирования, у него есть свои сторонники во всем, от математики до инвестирования. Этому может научиться каждый (даже самые оптимистичные разработчики!)
Эмпатия и ролевые игры
Способность видеть окружающий мир с разных точек зрения, понять чужой опыт и суметь почувствовать то, что чувствуют другие — не так просто. Это признаки хорошо развитого эмоционального интеллекта, и этот мягкий навык необходим в тестировании.
Хорошие тестировщики способны представить себя на месте пользователя, предсказать, какие действия он может совершать, где может испытывать трудности или неудобства, чем может быть разочарован и из-за чего раздражен. Благодаря глубокому пониманию поведения пользователя и подражанию ему, тестировщики обнаруживают баги до того, как они принесут проблемы настоящим пользователям.
Проявление эмпатии к пользователям — это нечто большее, чем просто подумать в ключе: «они хотят заказать книгу, поэтому я тоже закажу книгу». Это понимание образа мышления пользователя, их истории, стимулов и целей. Это обычно требует как воображения, так и исследований.
Самая близкая к этому активность, которую я встречал, это творческие «ролевые игры» (например, настольная ролевая игра Dungeon and Dragons — ДнД, актерская игра, импровизации и т.д.) Они все про «почувствовать себя в чужой шкуре», вообразить себя на месте другого человека и вести себя в соответствии с этим. Это всё, в каком-то смысле, практика эмпатии.
Сложные допущения
Эта фраза настолько часто используется, чтобы описать склад ума тестировщика, что уже стала клише и потеряла часть смысла. Сложные допущения — это не только про то, чтобы задаваться вопросом «Почему?» на все подряд, словно нетерпеливый пятилетний ребенок. Это предполагает нечто большее, и, как и всё остальное, это требует практики.
«Сложные допущения» не означает «оспаривай каждое допущение». Это также не значит «выброси все из окна и начни с нуля». Нам, тестировщикам, нет нужды быть Бертраном Расселом и расписывать на 360 страниц доказательство того, что 1 + 1 = 2.
На самом деле, для эффективного тестировщика критично важен навык определять и использовать допущения. Когда вы начинаете тестировать новую фичу непростого приложения, существует почти неограниченное количество возможных действий и путей тестирования, которые предположительно могут привести к обнаружению ошибки. Допущения — это именно то, что помогает сузить этот бесконечный набор возможных тестов до какого-то разумного числа, в рамках которого можно найти баги с высокой долей вероятности.
Допущения — это инструмент для сокращения проверок, допущения — полезны.
Важным навыком является способность точно оценить допущения, чтобы определить, корректно ли они влияют на ваше поведение, или они сбивают вас с пути. Являются ли они вредными или полезными; не позволяют ли они вам забывать про низкорисковые области в пользу более выгодного тестирования, или они прячут обоснованные опасения за мыслями вроде «нам не надо это тестировать» и «этого не могло произойти»?
Клише «сложные допущения» чрезмерно упрощает это — вы не оспариваете слепо допущения, вы используете все инструменты, которые есть в вашем распоряжении, чтобы лучше понять, какие допущения нужно оспорить, когда и как.
Например: «Наше приложение использует эту открытую библиотеку… Я не буду предполагать, что оно работает, я протестирую это тоже!» Скорее всего, это менее ценное допущение, которое можно оспорить, что будет тратой времени. Однако, немного поработать над этим вопросом будет вполне разумно (У нее уже миллионы пользователей или ее недавно создал какой-то студент? Есть ли у нее активное сообщество? Используете ли вы замороженную версию или она, возможно, будет расти в течение процесса разработки?)
Ум тестировщика находится в процессе постоянного распознавания и оценки допущений, с целью определить, являются ли они ценными, или вводят в заблуждение.
Тем не менее, не будьте уверенны, что вы все выяснили.
Интуитивное мышление и исследовательское поведение
Если тестирование можно было бы свести к простому списку действий, тестировщики были бы не нужны. И даже если бы оно могло быть сокращено до предсказуемого, предопределенного набора шагов, основанного на ограниченном наборе входных параметров (критерии приемки и SUT, например), необходимости в тестировщиках все равно не было бы. Тестирование — это нелинейная, непредсказуемая деятельность. Она требует развитого критического и креативного мышления и предполагает участие интуиции и чутья в той же мере, как и выполнение действий по алгоритму. Природа тестирования зачастую исследовательская — на старте вы не знаете точно, куда придете. Хорошие тестировщики принимают интуитивную и исследовательскую природу тестирования.
Чтобы лучше понять, что мы имеем в виду, приведем противоположное мнение, которое, к сожалению, до сих пор еще встречается в некоторых кругах: «Тестирование — это проверка приведенного списка приемочных критериев с помощью составления тест-кейсов с использованием техник граничного анализа, классов эквивалентности, комбинаторных техник и других формальных стратегий по созданию тест-кейсов. Как только готов полный список тест-кейсов, тестер прогоняет их и записывает, какие прошли, а какие нет.»
Для тех, кто придерживается подобного мнения, тестирование представляется простым и предсказуемым набором действий. Написание тест-кейсов еще требует каких-то навыков, но тестировать по этим пошаговым инструкциям сможет каждый. Однажды продумав тест-кейсы, вы точно знаете, что будете тестировать, еще до начала.
Как я сказал ранее, этого мнения до сих пор придерживаются некоторые представители индустрии. И я точно не знаю, почему, ведь большинство людей с реальным опытом тестирования совсем не поддерживают эту точку зрения. У меня есть догадка, что некоторым менеджерам это может нравиться потому, что так тестирование можно свести к деятельности, которую легко сделать общедоступной — что можно разделить на части и распределить между наименее «дорогими» участниками проекта.
Я мог бы еще страниц двадцать писать об исследовательской и интуитивной природе тестирования, но многие опытные тестировщики уже сделали это. Я горячо рекомендую «Исследуй это!» авторства Элизабет Хендриксон и «Исследовательское тестирование программного обеспечения» Джеймса А. Уиттакера. Лайза Кристин и Джанет Грегори тоже затрагивают эту тему в книгах «Гибкое тестирование» и «Еще более гибкое тестирование», но в рамках более широкого обсуждения роли тестировщика в Agile-командах. И, наконец, Майкл Болтон и Джеймс Бах часто пишут на эту тему с большим неравнодушием. В особенности рекомендую к прочтению вот эту статью.
Неважно, назовем мы это глубоким тестированием или структурированным исследовательским тестированием или любой другой фразой. Что действительно важно, так это то, что для тестирования требуется мышление в реальном времени, а направление и активности тестирования должны постоянно пересматриваться по мере поступления новой информации. Это не алгоритмическое экстраполирование критериев приемки и не может быть рассчитано заранее.
Как тестировщику, вам должно быть комфортно начинать свое путешествие без полной карты того, куда вы идете. Этот аспект непредсказуемости и неопределенности некоторых беспокоит, но я также обнаружил, что хорошие тестировщики, наоборот, добиваются результатов благодаря ему.
Признание человеческой природы
Как тестировщик, вы занимаетесь тестированием программного обеспечения, но не забывайте о том, что программное обеспечение — это конечный продукт длительного процесса. Это результат совместной работы группы людей с целью создания чего-то большего и сложного, чем любой из них смог бы сделать в одиночку.
Дефекты в ПО не появляются сами по себе, из вакуума, они являются симптомами проблем в процессе. Поэтому вам, как тестировщику, следует обращать внимание на процесс разработки ПО и поведение пользователей столько же, как и на конечный продукт.
Если изучать человеческую природу, то вскоре можно понять, что люди далеки от запрограммированных роботов с идеальной памятью, неизменной мотивацией и всегда высоким уровнем внимания. На самом деле, всё совсем наоборот.
Люди иногда отвлекаются, что-то забывают, начинают скучать. Люди также расстраиваются, раздражаются и устают. А еще иногда завидуют успехам других. У каждого свои планы и жизненные цели, из которых разработка этого конкретного модуля приложения для этой конкретной компании, возможно даже не входит в топ-10. Для кого-то мотивация лежит в области финансов, кто-то ориентируется на работу с крутыми технологиями, кого-то интересует определенная сфера, кто-то мотивируется признанием и социальным статусом, а ещё, по словам одного вымышленного персонажа, «Некоторые люди просто хотят наблюдать, как мир горит».
Кроме того, человеческое мышление является эвристическим и любит использовать короткие пути, а также имеет склонность придерживаться шаблонов, которые были полезны для выживания млекопитающих в Серенгети, но в меньшей степени для создания ПО. Бихевиористы называют это «когнитивными искажениями». Например, люди склонны видеть и принимать доказательства, которые согласуются с существующими убеждениями (предвзятость подтверждения, confirmation bias); если мы уже вложили свое время и другие ресурсы во что-то, нам трудно изменить направление или отказаться от этого (ошибка невозвратных затрат, sunk cost fallacy); мы переоцениваем факты, которые приходят в нашу голову просто (ошибка доступности, availability bias); и мы фокусируемся на первом доказательстве (эффект привязки, anchoring bias). И это далеко не все примеры когнитивных искажений, их гораздо больше.
Все эти несовершенства человеческого поведения дают о себе знать в процессе разработки программного обеспечения точно так же, как и в остальном жизненном опыте. Они присутствуют, когда разработчики разрабатывают, бизнес-аналитики анализируют, топ-менеджеры реализовывают корпоративную стратегию, и когда менеджеры среднего звена… ну, менеджерят.
Когда начинаете тестировать продукт, помните о том, что вы сейчас смотрите на конечный продукт человеческой деятельности, страдающей от этих когнитивных искажений и других несовершенств. Ошибки, поиском которых вы занимаетесь, чаще будут их симптомами, нежели чем того, что разработчик просто неправильно реализовал алгоритм или требование. Знание и понимание человеческой машины, создавшей это ПО, поможет вам их обнаружить.
Подходите к тестированию с такой мысленной установкой, что разработка ПО по сути своей является беспорядочным сотрудничеством разных людей и страдает от всех обычных ошибок.
Материал подготовлен в рамках курса «QA Engineer. Basic». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.
Теория тестирования ПО просто и понятно
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (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). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.