что такое атомарное требование
Качественные требования к ПО | часть 3
Jan 3, 2019 · 3 min read
Как можно определить (и улучшить) качество требований?
В части 2 мы разобрались откуда берутся требования, узнали что они отличаются (в зависимости от их уровня), и разобрали типы требований.
Осталось понять – что же такое качественное требование, и какими свойствами оно должно обладать, чтоб всем было максимально удобно с ним работать.
Свойства качественных требований
Качественными можно называть требования, которые соответствует перечисленным ниже свойствам:
Писать качественные требования, будучи не знакомым с этими характеристиками— не возможно. Для того, чтоб было проще — можно создать чек-лист с перечнем всех свойств и перепроверять себя по нему.
По началу — б удут ошибки и это нормально. Исправляя их вы будете учиться и каждый раз писать все лучше и лучше 🙂
Такой чек-лист поможет вам:
Это завершающая статья о требованиях, самая короткая, но как по мне — самая важная! Надеюсь после прочтения у всех появилось базовое понимание что такое требования, зачем они нужны и как и ними можно работать 🙂
Но не забывайте — это ведь только начало!
В интернете есть множество интересных статей, книг, приложений для работы с требованиями — не бойтесь изучать это тему 🙂 Она очень интересная!
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
Что такое атомарное требование
Атомарные проверки
Привет, народ! В эфире #радиоСаня и сегодня мы поговорим с вами про атомарные проверки.
Но для начала давайте вспомним про цели тест-дизайна, их всего две:
1. Надизайнить (написать) тесты, которые обнаружат самые серьезные (критичные) ошибки продукта.
2. Уменьшить число тестов, необходимых для нахождения большинства серьезных ошибок.
Вы думаете, что тестов много не бывает? Еще как бывает. Бывает столько, что вы не успеваете их пройти.
То есть, наша с вами задача — написать как можно меньше лучших тестов, которые бы ловили как можно больше серьезных ошибок. Ага, а причем тут “атомарки”?
“Атомарки” или атомарные проверки — это одна из техник тест-дизайна. Она (техника) позволяет делать тесты умными, уменьшая их количество. Атомарное условие — такое условие, над которым невозможно провести дальнейшую декомпозицию (кстати про декомпозицию прикольно рассказывает Нина в своем третьем вебинаре на курсе ПОИНТ. Например, условие, которое не содержит два или более одинарных условия, соединенных логическим оператором (И, ИЛИ, Исключающее ИЛИ).
Как это работает?
— выписываем действия, их параметры и значения (со значениями очень хорошо помогают техники классов эквивалентности и граничных значений);
— не забывайте, что для каждого действия будет свой отдельный “тестовый набор” с параметрами и значениями;
— собираем все выписанное в табличку для наглядности.
Давайте возьмем чего-нибудь для примера. Ну, скажем, какой-нибудь загрузчик фотографий.
Что нам важно выписать? Действия продукта, параметры их действий и значения параметров.
И давайте работать с действием “загружает фотографии” и его параметрами и значениями. Получается, у нас три параметра и восемь значений, отменно.
Собираем таблицу, сначала выписывая самый рабочий, самый стандартный или часто используемый набор значений, приближенный к нашей жизни, посмотрите на нулевую строку в табличке.
И если эта проверка с этим тестовым набором не работает, то, котаны, алес, надизайнились, у нас какая-то очень серьезная ошибка и дальнейшее тестирование этого функционала даже проводить бессмысленно. А если работает, то продолжаем создавать следующий набор, меняя ОДНО значение одного параметра! Посмотрите на первую строку в таблице, затем — на вторую и третью, чувствуете нашу любовь разницу?
Если “нулевой” и первые два теста прошли успешно, а третий зафейлился, вы сразу поймете, в чем ошибка, потому что третий тест относительно четвертого изменился ровно на одно значение. Элементарнейшая локализация, котаны.
Кстати, общее количество атомарных тестов считается по формуле: сумма значений минус количество параметров. Значений — восемь, параметров — три, в итоге — пять проверок. Особняком стоит наш “нулевой” тест, которым мы проверяем работоспособность тестируемой функциональности.
“Атомарки” — весьма удобная техника, чтобы тестировать нестабильные “сырые” продукты, потому что все причины ошибок мы видим сразу же.
Если ваш тестируемый продукт более зрелый, используйте деревья решений, S&T — based testing (тестирование на основании состояний и переходов) или pairwise. Но это уже совсем другая история, а пока хочу поделиться с вами одним лайфхаком…))
Лайфхак, котаны! В нашем разобранном примере все очень просто: и параметров мало, и их значений не много, но что делать, если у вас 15, 20 или 30 значений? Не паникуйте, также формируйте табличку, также выписывайте “нулевой тест”, а потом составляйте наборы, сначала перебирая все значения первого параметра, затем — все значения второго параметра и так далее. Таким образом, вам не придется “скакать” глазами по лесенкам таблицы и бояться, что вы что-то да пропустили.
Статья написана в соавторстве с Агеевой Ниной.
Атомарность в тестировании для новичков
(Время чтения — 6 минут)
Привет всем читателям этой статьи! Меня зовут Кирилл. Я помогаю в обучении студентов тестированию, а так же веду свой телеграм-канал @aboutqa (можете подписаться, если интересно). Через меня проходит много новичков в IT, желающих познать тайны этой профессии — профессии QA специалиста. И я заметил, что они часто путаются в понимании принципа тест-дизайна — атомарности тестов. Того, что матёрые тестировщики называют: «Один тест — одна проверка».
Опытным тестировщикам эта статья может не зайти, поэтому не удивляйтесь, что для вас тут кругом будут капитаны Очевидность. Поверьте моему педагогическому опыту — новичкам это вообще не очевидно!
Итак. Откуда вообще ноги растут?
Давайте ответим на следующие вопросы:
Ради чего вообще придумали тест-дизайн? Какие цели мы преследуем? И почему многие называют тест-дизайн важнейшим навыком тестировщика?
Сложность тест-дизайна не в самой методологии, а в большой ситуативности её применения. При тест-дизайне надо отталкиваться от здравого смысла и текущих условий на проекте, баланса формализованности проверок и доступных временных и человеческих ресурсов.
При написании тест-кейсов надо учитывать цель написания этих самых кейсов (спасибо кэп). Ответьте для себя на следующие вопросы.
Почему именно кейсы, а не чек-лист? Потому что заказчик требует, чтобы на проекте были кейсы; потому что кейсы будут выполнять роль отсутствующей/неполной документации; потому что проходить кейсы будут неопытные студенты и т.п.
Что вам в итоге этими кейсами надо проверить? Функциональность, логику, «формочки», интеграционные проверки или все вместе.
Кто будет пользоваться этими тест-кейсами? Новичок мало-понимающий в тестировании; коллега из саппорта; опытный профессионал, знающий продукт; автоматизатор; заказчики во время приемочного тестирования.
Большой ли и долгосрочный ли проект? На огромных проектах если расписывать тест-кейсы подробно, их будет очень-очень много, в то же время детальные тесты являются хорошей инвестицией в будущее для длительных проектов; в каких-то маленьких проектах возможно имеет смысл расписывать отдельно каждую проверку, чтобы убедиться, что проверили всё от и до.
Какая область деятельности компании и цена ошибки? Если вы делаете приложение для общения, обмена фоточек с котиками и монетизируетесь за счет рекламы — это одно; а если вы работаете в медицине, банковской сфере или тяжелой промышленности — это совершенно другое.
При написании тест-кейсов надо учитывать цель написания этих самых кейсов.
Как это ни парадоксально, но атомарные проверки (одна из техник тест-дизайна) позволяет уменьшить кол-во тестов.
Атомарное условие — это такое условие, которое нельзя более декомпозировать на более мелкие условия. И хотя умение декомпозировать функциональность и условия работы ПО — это практически предмет целого небольшого семинара, тем не менее основная суть вот в чем. Попробую объяснить на примере.
Мы всегда тестируем в неком наборе конфигураций. Предположим мы проверяем загрузку контакта клиента в нашу систему. Пусть у клиента четыре поля:
Первым делом мы проверим положительный и самый близкий к жизни вариант.
Атомарное условие — это такое условие, которое нельзя более декомпозировать на более мелкие условия.
Иван Иванов 12.10.1988 +79123456789, который покажет нам принципиальную работоспособность программы. Дальше мы будем менять одно поле, оставляя другие принципиально правильными.
Зачем это сделано? Всё просто — это элементарная локализация. Похоже на то, как мы исследуем потенциальный дефект, только превентивно. В примере выше мы получили 5 проверок (1 супер-позитивная и 4 вариации по числу параметров).
Мы могли бы сделать два теста:
Но тогда, в случае если второй тест упадёт — мы так и не поймем какое именно поле вызвало ошибку. На самом деле кол-во тестов значительно больше за счет вариативности самих параметров. Например «имя» и «фамилия» надо протестировать на пустое значение, спецсимволы, чувствительность к регистру и прочему. Телефон и дата рождения имеют свой специфичный набор классических негативных проверок. Так что тестов получается очень дофига (для нашего примера
Зачем нужна атомарность проверок, думаю понятно. Отсюда же и понятно, почему каждый уважающий себя наставник, тренер и просто руководитель тестирования «кричит» о том, что тесты должны быть атомарны. Но проблема вот в чем. Я начал с того, что многие начинающие тестировщики (кандидаты в джуны) путают смысл атомарности с. (не знаю с чем) с желанием сделать как можно больше тестов. Давайте снова вернемся к нашему примеру.
Мы обсудили только входные данные. Но как правило тестирование подразумевает сравнение фактического результата (ФР) с ожидаемым результатом (ОР). Вот ввели мы в нашу форму тестовые данные. А дальше что? Дальше, допустим, нам нужно зайти в систему, проверить, что создался новый клиент. Затем зайти в карточку клиента и посмотреть там в пяти местах. Потом мы идём в смежную систему и проверяем, как данные осели в базе данных. Может еще дёргаем какую-нибудь API между делом. И вот многие (я сейчас на полном серьезе, не кидайте в меня помидорами) создают 6+ тестов, которые делают одно и то же (то есть сценарий тестирования-то один), но «проверки», то есть валидация результатов разная. И вот у нас и так было
720 тестов из-за комбинаторики и атомарности, теперь их стало в 6 раз больше.
Какой вывод можно вывести из этого? Атомарность тестов — это про проверку условий. Про декомпозицию и перебор входных воздействий. Но ни в коем случае не про результат.
В жизни многие на это забивают.
Начну с того, что, конечно, 720 ручных тестов одной формочки редко кто делает. Решают проблему методикой Pairwise (алгоритм all pairs) и вместо 720 тестов вот у нас уже всего 36 (да, эта черная магия работает именно так). В интернете много интересных видео про pairwise, не буду останавливаться на этом.
Даже имея 36 тестов просто на форму, жизнь вносит немного коррективов. Вот, например, надо вам проверить функционал покупки в онлайн-магазине. Он состоит из нескольких крупных шагов: добавлении в корзину товара, логина в систему, оформления покупки.
По идее, если тест не пройдет — нам будет трудно понять в чем причина: у нас добавление товара не работает, логин или оформление покупки (собственно то, что мы проверяем). Логично создать отдельный тест на логин. Убедиться, что логин работает. Потом на работу с корзиной (добавление, удаление), а потом оформление покупки.
Так и происходит. Просто мы делаем не по одному тесту, а целые тестовые наборы — много тестов на логин (в т.ч. позитивные), много тестов для работы с корзиной, а после, фиксируя позитивные элементы двух шагов мы перебираем разные вариации оформления покупки. Именно поэтому эти тест-кейсы объединяются в тест-сьют «Оформление покупки», хотя по сути своей, они косвенно проверяют и логин и добавление товаров в корзину. Если мы будем выполнять тесты непоследовательно, мы не заметим проблемы с логином. Но если мы будем спускаться по логике работы приложения, мы сможем выявлять проблемы намного раньше.
Как-то уж очень жестоко получается, да? 100500 проверок для какого-то кусочка функционала.Только представьте: 36 тестов на логин, 15 тестов на корзину и еще 50 на оформление товара. Может ну их атомарные проверки?
И да, иногда «ну их» — это рабочая стратегия.
Если скорость важнее качества, то многие проверки объединяют. Обычно так делают, когда проект уже устоявшийся, всё проверено было раз 100 и вероятно 101й прогон атомарных тестов не выявит проблем. Тогда негативные проверки объединяют. И вот если уже какая-то комбо-проверка вызовет ошибку — начнут разворачивать этот «тест» в последовательность атомарных тестов.
Если скорость важнее качества, то многие проверки объединяют
Добавлю, что смысл атомарных проверок крайне актуален в автоматизации. Когда мы хотим из отчета об автоматизации в случае падения теста понять что произошло. Согласитесь, что падения атомарного теста с именем digitsInSurname (цифры в фамилии) намного понятнее, чем общего теста wrongClientData (неправильные данные клиента). Именно поэтому умение декомпозировать проверки важно для автоматизаторов тестирования.
Затронув тему автоматизации мы подходим к еще одному боевому рубежу. Он называется «Один тест — один assert». То есть переводя на язык ручного тестировщика — «Один тест — один ожидаемый результат».
Но я же выше говорил, что плохо повторять одни и те же тесты, если можно выполнить один сценарий и в рамках его проверить в 5 местах данные. А тут получается, что нужно работать не так? Не совсем. Смотрите, многие раздвигают понятие атомарности ручного тестирования в автоматизации до трёх условий:
1. один тест — одна логическая проверка
2. работа тестов не зависит от порядка их запуска
3. до начала и после завершения теста система находиться в одинаковом состоянии
Это правило связано с особенностями прохождения тестов программой. Если программа выявляет ошибку на первом из 5 ассертов (то есть сравнений ОР и ФР), то 4 других проверены не будут и возможные баги будут скрыты. Это основная проблема автоматизации. Однако я всё равно придерживаюсь мнения о том, что лучше в один сценарий (тест-кейс) добавить несколько проверок-сравнений, чем гонять однотипные тесты для разных проверок.
Что до атомарности. За красивой фразой «Один тест — одна проверка» скрывается факт, что в жизни мало кто пользуется этим правилом. Однако, даже полностью атомарные тесты не преследуют своей целью наплодить миллионы однотипных проверок.
Автоматизаторы должны больше внимания уделять понятию атомарности, т.к. скорость выполнения и легкость покрытия тестовыми данными позволяет развязать им руки. В то же время атомарность автотестов позволяет предоставить точный и детальный отчет об автоматизации.
Как обычно. Хотел вбросить немножко про то, что атомарность, это не дробление тестов по принципу «чем больше, тем лучше», а в итоге написал целый трактат.
SkillsCup.com
Сайт переехал сюда: SkillsCup.com
Требования к системе: характеристики хороших требований
Требования к разрабатываемой системе должны обладать следующими характеристиками:
Подробнее перечисленные характеристики требований и характеристики, которыми должен обладать набор требований, описаны ниже.
1. Недвусмысленность – должна существовать только одна трактовка требования. Так, например, следует избегать в тексте требования сокращений.
Пример плохого требования: REQ1 Система не должна принимать пароль длиннее 15 символов.
Данное требование не проясняет что же должна делать система:
Пример хорошего требования: REQ1 Система не должна принимать пароль длиннее 15 символов. Если пользователь введет больше 15 символов, система должна отобрать сообщение об ошибке с просьбой исправить пароль.
2. Проверяемое – тестировщики должны иметь возможность проверить правильно ли требование реализовано в системе. Для этого требование должно быть четким, точным, недвусмысленным.
Пример плохого требования: REQ1 Поиск в системе должен осуществляться по имени, фамилии пользователя и т.д.
В данном примере критерии поиска должны быть раскрыты полностью. Иначе нельзя проверить выполняется ли требование в системе.
3. Четкое (краткое) – требование не должно содержать лишней информации. Оно должно быть изложено четко и просто.
Пример плохого требования: REQ1 Пользователь иногда может вводить код аэропорта, который должен определяться системой. Но также иногда код аэропорта должен заменяться названием ближайшего города, таким образом пользователю не требуется знать код аэропорта, но система по прежнему должна знать код аэропорта.
Это требование может быть изменено следующим образом: REQ1 Система должна определять аэропорт как по коду аэропорта так и по названию города.
4. Точное – требование должно содержать в себе истинные факты.
5. Понятное – требование не должно содержать грамматических ошибок, должно быть изложено последовательно.
6. Осуществимое – требование должно быть выполнимо в рамках существующих ограничений (время, деньги, существующие ресурсы)
7. Независимое – для понимания требование не нужно знать других требований.
Пример плохого требования: REQ1 Список доступных рейсов должен содержать информация о номере полета, времени посадки и приземления. REQ2 Они должны быть отсортированы по цене.
8. Атомарное – требование должно содержать одну связанную сущность. Пример плохого требования: REQ1 В системе должна быть предусмотрена возможность забронировать полет, купить билет, зарезервировать номер в отеле, арендовать машину.
9. Необходимое – заинтересованные лица должны нуждаться в данном требовании.
10. Абстрактное – в требовании не должно содержаться информации о том как оно будет реализовано.
Также существуют определенные характеристики, которыми должен обладать набор требований:
а. Постоянное – не должно быть конфликтов между требованиями.
b. Неизбыточное – каждое требование должно быть описано один раз и не должно содержать в себе других требований.
c. Полное – требование должно быть определено для всех возможных ситуаций.
Существуют дополнительные критерии, но они содержат в себе описанные выше, например:
Модифицируемость – если требование атомарно и полное, оно модифицируемо.
Трассировка (прослеживаемость) – если требование атомарно и имеет уникальный идентификатор, оно прослеживаемо.
Тестирование документации
Документация– это еще одна составляющая программного продукта любой уважающей себя организации, занимающейся разработкой программного обеспечения. Но не все организации уделяют достаточное количество времени разработке стоящей документации. Очень часто нам приходится иметь дело с толковым программным продуктом и невзрачным, непонятным и беспомощным документным сопровождением.
Попробуем собрать воедино критерии тестирования, образующие квинтэссенцию качественной документации. Думаю, будет справедливым, если мы опустим такое всем понятное правило, как грамматика, так как не в ней одной таится успешный релиз.
В целом, документация создается для возможности грамотно и без паники найти выход или решение из любой возникшей проблемной ситуации человеку из самым низким знанием принципов разработки программного обеспечения. От этого принципа необходимо отталкиваться, продумывая содержание и структуру наших мануалов.
• Полнота и соответствие действительности. Любая документация должна содержать описание именно той функциональности, которая присутствует в приложении. И данное описание должно касаться абсолютно всей функциональности, а не только наиболее значимой.
• Навигация. И не просто навигация, а удобная навигация. У пользователя никогда не должно возникать проблем с поиском необходимой ему информации. Древовидная структура файлов, закладки и прочее должны быть на видном месте сразу, как пользователь открывает документ. Алфавитный указатель, поиск – должно присутствовать все, что поможет найти решение или описание проблемы.
• Из пункта выше вытекает структурированность документации. Все документы должны находится в полном порядке, по разделам. Также, текст должен быть с четкой структурой, чтобы можно было в любой момент вспомнить, где остановился или понять, в каком абзаце содержится именно та информация, которая нам необходима.
• Инструкции должны присутствовать везде. Даже при выполнении абсолютно одинаковых манипуляций с программой необходимо пошаговое описание действий во всех случаях. Это может быть как прямое повторение инструкций, так и ссылка на уже существующие.
• Термины и их значение. В любой документации может использоваться масса терминов, аббревиатур и сокращений. Каждый из них должен иметь свое значение и расшифровку.
• Доступность пользователю. Документация должна быть максимально понятной для любой целевой аудитории.
• Если документация создана и для иностранных пользователей,то необходимо привлечение специалистов данного лингвистического сектора, вплоть до носителей языка.
Основные принципы тестирования требований
Существует еще много требований к составлению и тестированию документации. Сегодня мы рассмотрели основные положения. Но главное правило, которое поможет нам – это умение ставить себя на место пользователя, попавшего в определенную проблемную ситуацию.
Свойства качественных требований
В процессе тестирования требований проверяется их соответствие определённому набору свойств:
Техники тестирования требований
Тестирование документации и требований относится к разряду нефункционального тестирования (non-functional testing). Основные техники такого тестирования в контексте требований таковы:
Для запоминания: аналог беглого просмотра — это ситуация, когда вы в школе с одноклассниками проверяли перед сдачей сочинения друг друга, чтобы найти описки и ошибки.
Для запоминания: аналог технического просмотра — это ситуация, когда некий договор визирует юридический отдел, бухгалтерия и т.д.
Для запоминания: аналог формальной инспекции — это ситуация генеральной уборки квартиры (включая содержимое всех шкафов, холодильника, кладовки и т.д.).