Что является требованиями в тестировании

Чек-лист тестирования требований

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

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

Конечно, их может быть и больше. Кто-то использует мнемонику CIRCUS MATTA, кто-то расширяет список под себя и команду. Но эти шесть характеристик — основные. О них и в книгах по тестированию пишут, и в самых разных статьях.

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

1. Полнота

Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода?

Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.

Как-то раз мне прислали на проверку ТЗ на новый функционал. Да, по хорошему надо сразу прикинуть тесты, которые буду писать. А это надо взять ручку, блокнот и начать тест-дизайнить. Но я занималась другой задачей, а ТЗ надо проверить «сегодня», чтобы отправить оценку заказчику.

Поэтому решила проверить «мысленно». Читаю пункт ТЗ, прикидываю, какие могут быть тесты. В итоге задала парочку уточняющих вопросов:

У Заказчика уточнили, документацию пополнили! В остальном меня всё устроило, вроде нормально описано, всё учтено.

Заказчик согласовал ТЗ, разработчик сделал. Пришло время тестировать. Начинаю писать автотесты и. Да, разумеется, сразу получаю еще 5-10 дополнительных вопросов. В ТЗ не были предусмотрены все сценарии, и я о них тоже не подумала, пока прикидывала тесты мысленно.

А как только стала расписывать план автотестов, сразу увидела «белые пятна». При этом у меня 10 лет опыта в тестировании. Не полагайтесь на память и «быстренько мысленно прикину», выделите полчаса и распишите чек-лист проверок подробно.

Чем плохо отложить вопросы на потом? Не слишком профессионально согласовать требования, которые написала твоя команда, а через пару недель задавать уточняющие вопросы. Заказчик подумает: а чего сразу не спросили?

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

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

2. Однозначность

Требования должны трактоваться всеми одинаково.

«Отчет должен загружаться быстро» → что значит «быстро»?

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

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

Налицо конфликт интересов. И ведь каждый будет тыкать в ТЗ для отстаивания своей позиции. Лучше конкретизировать:

Отчет за год должен загружаться не более секунды.

Отчет за весь период времени должен загружаться не более 5 секунд.

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

Аналитик будет думать, что там будет значение 0. Деньги же, цифра!

Разработчик сделает пустое поле, не указано ведь ничего! А это что-то сломает.

Если в требованиях не указано, как обработать ошибочный сценарий, разработчик может:

Не подумать о нем и никак не обработать — пользователь может огрести страшную ошибку.

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

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

Если это внутренний документ, а у вас сильная команда — можно не расписывать подробно.

Если этот документ отправят заказчику, надо расписать вообще всё — потому что у заказчика свои тестировщики, и они обязательно зададут кучу «а что, если. ». Если они хорошие тестировщики, разумеется. Это вы знаете свою программу и представляете, как она реагирует на ошибки или что-то такое. Тестировщик заказчика этого не знает, он будет уточнять.

3. Непротиворечивость

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

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

Если заказчик найдет первый раздел документации, он будет требовать именно такую скорость. И будет прав, кто же хочет ждать?)

4. Необходимость

Помните главный принцип: «Кратко, но емко»? Он действует и в документации тоже.

Круто, когда документация полная. Но это не значит, что простой функционал надо растечь на 10 листов А4. Когда документации много, сложно проверить полноту, сложно удержать в голове, о чем уже говорил, не повторяться и не противоречить самому себе.

Подумайте, так ли уж нужно описывать каждую кнопочку интерфейса? Это правда актуально? Пользователи правда не догадаются, что фильтры по строковым колонкам работают одинаково?

Пишите только то, что необходимо:

В ТЗ — функционал, основной сценарий и альтернативы, типы ошибок.

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

5. Осуществимость

А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?

Этот пункт обычно проверяют разработчики. Они остужают буйные фантазии из серии «загружать миллионы данных за 0,1 секунду» или что-то архитектурно сложное. Бывает такое, что на бумаге всё звучит просто, а вот сделать это займет человеко-месяц в лучшем случае.

В одной из систем, с которыми я работала, был точечный поиск. Не просто «найди мне все данные, где встречается «Ленина», а именно «найди мне адреса, у которых улица Ленина». Это отсеет фамилию Ленина, комментарий к телефону и другие нерелевантные данные.

Но вот беда — нельзя поискать по двум параметрам ОДНОГО атрибута. Если сказать «Найди мне домашний адрес с улицей Ленина», система вернет:

1. Васю: домашний адрес с улицей Ленина.

2. Петю: домашний адрес с переулком Турчанинов и рабочий с улицей Ленина.

Это баг в системе? Или просто нельзя сделать такой поиск, это неосуществимо? Нужно смотреть по коду.

В той системе для поиска использовали Lucene. Его можно настроить по-разному:

o поиск по любому полю;

o поиск по конкретному полю;

o множественный поиск по конкретному атрибуту (в одном адресе проверить и тип, и улицу);

Но! Чем сложнее сценарий поиска, тем медленнее он работает. Дольше сохраняет данные (потому что структура внутри усложняется), дольше ищет — или потребляет больше ресурсов для той же скорости.

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

Осуществимо желание отсеять Петю? Да. Но это просто не нужно. Потому что вреда принесет больше, чем пользы. Ради того, чтобы в выборку из 1000 человек не попали 10 лишних, платить несколько миллионов за дополнительные мощности серверов смысла просто нет.

6. Тестируемость

Можно ли протестировать этот функционал?

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

Если в компании принято все покрывать автотестами, то это станет проблемой. Может, разработчик прочитает ТЗ и сам поймет, что ещё фреймворк тестов дорабатывать надо. А может, он не вспомнит об этом. И тогда ваша задача — вспомнить. Чтобы сразу заложить время на доработки.

У меня бывали ситуации, когда мы делали задачу в текущем релизе, а потом ставили новую «Доработать фреймворк автоматизации, чтобы поддержать изменения» в следующий. Иногда забывали про фреймворк, а потом времени в релизе уже не оставалось. А иногда сразу понимали, что всё сразу сделать не успеем.

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

Сначала я не подумала о доработке автотестов — ведь возможность проверить «что ушло» есть! А когда добралась до тестирования, пошла к разработчику:

— А как мне указать вторую очередь? Или папка jms — это то, что в обе уйдет?

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

Ну и ничего, доделали, написала тестов!

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

При этом бывает и так, что тестировать все равно придется разработчику. Скажем, когда делают рефакторинг, что может проверить тестировщик? Только регресс провести, посмотреть, что ничего не отломалось. А если есть автотесты, то это проверят они =)

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

И именно это и надо проверить! А проверить это может только разработчик. Он и выполняет тестирование в данном случае.

Бонус: мнемоника CIRCUS MATTA и другие доп материалы

CIRCUS MATTA — мнемоника для ревью пользовательских историй. Это как раз про тестирование требований! Истории должны обладать качествами:

Completeness — полнота

Independent — независимость

Realisable — реализуемость

Consistency — консистентность

Unambiguity — однозначность

Specific — специфика заказчика

Measurable — измеримая

Acceptable — приемлемая

Testable — тестируемая

Traceable — трассируемая (можно проставить взаимосвязи)

Achievable — достижимая

Вон сколько пунктов получилось! Мне особенно импонируют пункты «специфика заказчика» и «трассируемость». Это и правда важно. Если у вас коробочный продукт, который кастомизируется под заказчика, обязательно смотрите на пункт «Specific». А трассируемость — очень хороший бонус, облегчающий поддержку документации в актуальном состоянии!

Источник

Тестирование данных: требования и уровни

Меня зовут Алексей Чумагин, я тестировщик в Provectus. В этой статье я расскажу, как формируются требования к качеству данных и какие могут быть уровни тестирования данных.

Upd:
В статье речь идет о больших (или не очень) данных, на основе анализа и агрегации, которых строятся разные процессы, выводятся закономерности для использования в дальнейшем анализе или для принятия решений. Данные могут быть собраны под конкретный проект с нуля, либо могут использоваться базы, собранные ранее для других проектов либо в коммерческих целях. Источники этих данных разнообразны и включают не только ввод операторами, но и автоматизированные и/или автоматические измерения, сохраняемые в базы системно или бессистемно (кучей, “потом придумаем что с этим делать”).

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

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

Что это за данные? Например, история вашего браузера, транзакции по вашей карте, точки перемещения какого-то девайса. Они обезличены, но эти данные все равно принадлежат определенному устройству. Если их собрать и обработать, то можно получить довольно интересную информацию о хозяине этого девайса. Например, куда он любит ходить, какой у него пол и возраст. Так постепенно мы «очеловечиваем» устройство и наделяем его какими-то характеристиками.

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

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

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

Что такое качество

Мне нравится такое определение: качество продукта — это мера удовлетворенности пользователя. Понятно, что всё зависит от контекста использования продукта. Если вы пользуетесь каким-нибудь известным продуктом, например, Facebook или Skype, то у вас одни требования к качеству. Вы будете мириться с какими-то ошибками, но всё равно продолжите пользоваться этим продуктом. А если вы являетесь заказчиком какой-то программы и заплатили за нее деньги, то требования к качеству будут выше. Вы будете придираться, смотреть какие-то мелочи. У разных людей разные представления о качестве, и у разных программ тоже свои требования к качеству.

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

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

Как формируются требования к качеству данных

Тестировщик начинает выяснять, что ему непонятно и что он хотел бы узнать об объекте тестирования. Тестировщик составляет список вопросов и начинает брать «интервью» у заказчика. Он, по идее, должен знать, какими должны быть данные. Например, я спрашиваю: допустимы ли пустые ячейки или повторяющиеся строки.

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

Дальше мы начинаем спрашивать о формате данных в определенной ячейке. Например, в номере телефона должно быть 12 цифр, в номере банковской карты — 16. У нас может быть критерий, что не всякая последовательность этих знаков является номером банковской карты. Или мы понимаем, что в фамилии могут быть только буквы. У нас может возникнуть много вопросов по поводу формата данных. Таким образом, мы выясняем всё, что нам нужно знать о предмете тестирования.

Что такое качественные данные

Качественные данные должны обладать несколькими характеристиками.

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

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

Источник

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

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

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

Тестирование программного обеспечения (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) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

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

Источник

Что является требованиями в тестировании

Что пишут в блогах

2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA

Привет! В блоге появляется мало новостей, потому что все переехало в telegram.

Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Автор: Александр Филиппов, ведущий тестировщик компании «Лаборатория качества»

Введение

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

Отношение к тестированию требований на проектах

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

1. Группа А: лучшие практики в деле

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

2. Группа Б: успеть все

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

3. Группа В: все усилия на разработку

Если указаны требования трехлетней давности – ты счастливчик, даже если этот функционал менялся уже 3 раза; у команды есть хоть какое-то понимание, как должна работать система. Большую же часть требований, раскиданных по чатам, приходится долго и упорно их искать (при этом со временем и сообщения из чата теряются, особенно при использовании бесплатной версии Slack). Зачастую при нахождении очередного дефекта отсутствует понимание того, как на самом деле все должно работать, кто должен править, и дефект ли это вообще. В таком случае все спорные вопросы адресуются аналитику или и без того загруженному менеджеру проекта. Ответ может занимать от часа до недели. Соответственно, в случае любой спорной ситуации тестирование останавливается на неопределенный срок.

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

Параметры тестирования документации

1. Четкость и ясность

Начать тестирование требований можно с поверхностного осмотра документации. Это сложно назвать именно тестированием, но нередко уже на данном этапе выявляется немало недочетов. Начнем с обычного сценария. Вы начали читать требования, и уже с первых строк у Вас возникает масса вопросов к автору (например, «Каков ожидаемый результат после нажатия на эту кнопку?» или «Что будет, если я отменю заказ?»). Это плохо. После прочтения документации не должно быть вопросов. Совсем. Требования – это как свод законов для продукта, а законы не допускают двусмысленность, «воду» и неточности. Документация должна давать предельно ясную информацию о том, как должен работать каждый отдельный модуль и весь продукт в целом. К сожалению, после прочтения большинства требований остается целый ряд вопросов.

Дальнейшее («более глубокое») исследование требует гораздо больших временных затрат.

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

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

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

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

4. Возможные сценарии
В документации должны быть подробно описаны как очевидные, так и неочевидные варианты использования системы. К очевидным (позитивным) вариантам, например, можно отнести ввод корректной пары логин/пароль. К неочевидным (негативным) – ввод некорректной пары логин/ пароль или отсутствие этих данных вовсе.

Пример. Часто из виду упускаются такие моменты, как тексты ошибок, поведение системы при потере связи, а также обработка ошибок, связанных со сторонними сервисами (например, с оплатой).

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

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

Основные принципы тестирования требований

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

Источник