на чем следует фокусироваться во время тестирования

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

Принципы тестирования

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

Этапы тестирования:

Программный продукт проходит следующие стадии:

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

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

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Источник

Пользовательское приемочное тестирование: руководство по успешному запуску новых продуктов

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

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

Именно здесь вам может пригодиться пользовательское приемочное тестирование (User Acceptance Testing, UAT). В сегодняшней статье мы расскажем вам, что это такое, когда и как вам следует использовать данный метод и почему он играет столь важную роль при выводе продукта на рынок.

Содержание статьи

Что такое пользовательское приемочное тестирование?

Пользовательское приемочное тестирование — процесс, в ходе которого вы просите группу людей использовать продукт, сервис или часть софта с его полным функционалом.

Известное также как бета-тестирование, UAT служит трем основным целям:

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

5 типов пользовательского приемочного тестирования

1. Первый тип, на котором мы и будем фокусироваться в этом посте, — альфа/бета-тестирование. При альфа-тесте роль пользователей на себя берут штатные сотрудники и члены команды разработчиков. А вот бета-тест проводится с участием реальных, специально отобранных пользователей. Ниже — пример лендинга с предложением зарегистрироваться для бета-тестирования Division 2, анонсированного на E3:

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

2. Контрактное приемочное тестирование (contractual acceptance testing) нацелено на то, чтобы проверить, соответствует ли разработанный продукт контрактным требованиям, согласованным всеми заинтересованными сторонами. Обычно такое тестирование используют, дабы убедиться в том, что сторонняя команда разработчиков выполнила свои договорные обязательства.

3. Законодательное приемочное тестирование (regulation acceptance testing) позволяет убедиться в том, что продукт соответствует всем законам и предписаниям своей отрасли и юрисдикции. Такое тестирование следует проводить в сферах здравоохранения и финансов, кроме того, с внедрением GDPR на нем должны акцентировать внимание все европейские компании.

4. Операционное приемочное тестирование (operational acceptance testing) сосредоточено на определении эффективности закулисных процессов внутри организации, которые гарантируют людям полноценное использование продукта. С помощью этого типа тестирования оцениваются такие процессы, как онбординг, сбор данных и защитные механизмы.

5. Тестирование по стратегии черного ящика (black box testing) ориентировано на анализ причинно-следственной связи между взаимодействием пользователя с продуктом и результатом, полученным за счет этого взаимодействия. Этот тип тестирования связан с UAT тем, что здесь людям говорят, для чего предназначен продукт, но изучать, как именно он работает, они могут самостоятельно.

Почему пользовательское приемочное тестирование играет столь важную роль

Итак, UAT является неотъемлемой частью процесса создания продукта. Тем не менее, вы должны фокусироваться на таких тестах не только при их фактическом проведении, но и на всех этапах разработки:

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

Думайте о конечном пользователе

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

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

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

Кроме того, это поможет вам сделать процесс разработки менее произвольным, поскольку каждое изменение или улучшение будет сопровождаться вопросом: «Как эта функция поведет себя в ходе пользовательского приемочного тестирования?».

Подтвердите product/market fit

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

Когда продукт готов к проведению UAT?

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

Остановимся на этих критериях более подробно.

Бизнес-требования должны быть готовы

Согласно iSixSigma, главным образом документы по бизнес-требованиям создаются, чтобы:

Продукт должен функционировать на своих предельных возможностях

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

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

Проблемы должны фиксироваться, исправляться и тестироваться

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

Этот лог-файл должен содержать следующую информацию:

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

Команда по тестированию системы должна дать добро

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

Зачем нужно пользовательское тестирование: кейс от Feedly

6 шагов успешного пользовательского приемочного тестирования

Процесс UAT включает в себя следующие этапы:

1. Проанализируйте бизнес-требования

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

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

2. Разработайте UAT план

На этой стадии вы определяете такие логистические критерии UAT, как:

3. Определите тестовые сценарии и кейсы

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

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

4. Подготовьте тестовые данные

Разумеется, вы также должны наладить процесс, который бы позволял вам эффективно собирать и подготавливать тестовые данные. Кроме этого, вам нужно быть уверенными в том, что используемая вами информация всегда будет оставаться конфиденциальной (особенно учитывая то, что GDPR уже вступил в силу в Европе).

5. Проведите тест

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

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

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

6. Подтвердите достижение бизнес-целей

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

Эта документация включает:

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

Источник

В поисках самого лучшего способа тестирования системы

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

В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.

Почему существуют разные подходы к тестированию?

Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).

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

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

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

Основные подходы к тестированию

Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).

Основная особенность сценарного тестирования в том, что вы начинаете с того, что делите задачу на этапы (подготовка, выполнение, завершение и пр.) и затем стараетесь производить все действия согласно этим этапам. То есть этот подход можно охарактеризовать как «я думаю на этим заранее и затем выполняю».

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

Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Я думаю, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.

Промежуточные подходы к тестированию

Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.

Почему я расположил их в таком порядке? Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.

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

Подробное сценарное и общее сценарное тестирование (Detailed Scripting & Global scripting)

В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.

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

Сессионное тестирование и поиск багов (Session Based Testing & Bug Hunts)

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

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

Сессионное тестирование предусматривает наличие:

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

Исследовательское тестирование и туры (Exploratory Testing & Test Tours)

В интернете можно прочитать, что исследовательское тестирование – это такой прием тестирования. На самом деле это не просто прием, а полноценный подход к тестированию, позволяющий выполнить полное тестирование систем.

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

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

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

В этой связи я хотел бы привести цитату Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».

В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:

Основные различия методов тестирования и сравнение их эффективности

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

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

Как решить, какой метод тестирования подходит лучше

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

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

Вместо заключения

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

Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:

Источник