Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 <a>#статьи</a>

2 <ul><li>22 июн 2023</li>

3 <li>0</li>

4 </ul><h2>Почему и как нужно адаптировать тест-кейсы перед автоматизацией тестирования</h2>

5 Или как сохранить деньги, время и нервы, ускорив при этом выпуск новых фич.

6 Фото: Martin Barraud / Getty Images

7 Компании ежегодно увеличивают затраты на обслуживание IT-инфраструктуры и инвестируют в сотрудников. Что неудивительно: ведь ожидания потребителей от сервисов постоянно растут и все новинки нужно тщательно тестировать.

8 И здесь на помощь приходит автоматизация, важную роль в которой играют тест-кейсы. Анастасия Леонтьева из SimbirSoft рассказала, как адаптировать их перед автоматизацией, и поделилась примером подготовленного кейса.

9 Руководитель направления тестирования и обеспечения качества в <a>SimbirSoft</a>. Имеет степень MBA, Six Sigma Yellow Belt, опыт работы в IT более шести лет.

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

11 <ul><li>Снижаются затраты на тестирование.</li>

12 <li>Снижается вероятность пропуска ошибки из-за человеческого фактора.</li>

13 <li>Увеличивается скорость доставки новых фич.</li>

14 </ul>Согласно<a>исследованию practitest.com</a>, более 45% респондентов утверждают, что автоматизация снизила их затраты на тестирование в два раза. Эта статистика<a>подтверждается</a>и нашей практикой. Однако автоматизировать следует тест-кейсы только по той функциональности, в которой не планируется глобальных изменений. Иначе есть риск, наоборот, повысить затраты - так как придётся переписывать автотесты.

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

16 Представим, что к действующему долгосрочному проекту подключается SDET‑специалист. До того как начнётся написание автотестов, у него могут возникнуть вопросы к QA-инженерам: про объём тестов для автоматизации, приоритеты выбора проверок, набор доступов и так далее.

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

18 Поэтому при подготовке тест-кейса для автоматизации важно проработать следующие моменты:

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

20 2.Подробно указывать путь "до места назначения": если нужно протестировать некую форму, важно расписать все шаги до её открытия. Часть описания можно вынести в предусловие.

21 3.Рационально подходить к процессу передачи тест-кейсов под автоматизацию. Нужно чётко понимать, что можно реализовать, а что нет. Если же возникли вопросы, то лучше заранее проконсультироваться со SDET-специалистом.

22 Кадр: фильм "Звёздные войны: Эпизод 3 - Месть ситхов" / Lucasfilm Ltd.4.Включить в тест-кейс все необходимые данные. А именно: информацию об окружении, специфике тестирования на разных платформах, параметры настройки, а также необходимое время для применения в системе тех или иных настроек, если это требуется.

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

24 6. Обращать внимание на тестовые данные. Если, например, требуется авторизация и учётные записи имеют разные уровни доступа, обязательно нужно прикрепить информацию о необходимом уровне доступа или сразу указать данные учёток, в которых уже есть необходимые сведения (документы, поля и прочее).

25 7.Отражать в кейсах тестовые сценарии использования системы. То есть последовательность запросов и ответов API, в которой заложен путь пользователя, а также чётко прописать ожидаемый результат.

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

27 9.Если рассматривать мобильную UI-автоматизацию, в тест-кейсе нужно включить моки и скриншоты для snapshot-тестов.

28 10.Чётко обозначить в тест-кейсе приоритетные проверки, критичные для корректной и стабильной работы системы.

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

30 Чтобы прийти к совместному решению, необходимо определить правила взаимодействия, зафиксировать их и продемонстрировать команде.

31 Давайте на примере разберём, как можно улучшить кейсы под автоматизацию. Возьмём интернет-магазин, у которого есть API для совершения CRUD-операций с карточкой товара:

32 <ul><li>Создание.</li>

33 <li>Просмотр.</li>

34 <li>Редактирование.</li>

35 <li>Удаление.</li>

36 </ul>Мы будем использовать открытый API<a>shop.bugred.ru</a>. Предварительно в нём необходимо будет авторизоваться. Это можно вынести в предусловие, так как оно не требует описания шагов или тела запроса, а лишь указывает на необходимость того или иного действия перед выполнением шагов. Ссылку на документацию, а также доступы можно найти на главной странице.

37 Несколько допущений в рамках нашего тест-кейса:

38 <ul><li>Мы будем рассматривать только взаимодействие через API.</li>

39 <li>В базу данных вынесены настройки, позволяющие включать или отключать возможность создания товара пользователем.</li>

40 <li>В системе может быть несколько тестовых сред со своей базой данных.</li>

41 </ul>А вот, собственно, и сценарий: пользователь (например, менеджер) заходит в административную панель магазина, создаёт товар, обновляет информацию о нём (правит цвет, размер и так далее), проверяет, что данные изменились, и потом удаляет товар.

42 Наименование:"Проверка удаления созданного товара".

43 Предусловия теста:

44 <ul><li>Пользователь авторизован.</li>

45 <li>Значение ITEMS_CREATE.ENABLE равняется true</li>

46 </ul>ШагиОжидаемый результат1.Создать товар в магазине{

47 "name": "Шортики",

48 "section": "Платья",

49 "description": "Модное платье из новой коллекции!",

50 "color": "RED",

51 "size": 44,

52 "price": 666,

53 "params": "dress"

54 }

55 Товар создан. Получить код200{

56 "method": "/items/create",

57 "status": "ok",

58 "result": {

59 "id": "76",

60 "name": "Шортики",

61 "section": "Платья",

62 "description": "Модное платье из новой коллекции!",

63 "color": "RED",

64 "price": 666,

65 "params": "dress"

66 }

67 }

68 2. Обновить созданный товар<request>

69 76

70 <name>Шортики</name>

71 Платья

72 <description>Модное красное платье</description>

73 48

74 RED

75 678

76 dress

77 </request>

78 Товар обновлён. Получить код200{

79 "method": "/items/update",

80 "status": "ok",

81 "result": "Товар обновлён!"

82 }

83 3. Получить данные о товаре{

84 "id": 76

85 }"

86 Товар найден. Получить код200{

87 "method": "/items/update",

88 "status": "ok",

89 "result": {

90 "id": "76",

91 "name": "Шортики",

92 "section": "Платья",

93 "description": "Модное платье",

94 "color": "RED",

95 "size": "48",

96 "price": 666,

97 "params": " ",

98 "photo": "http://shop.bugred.ruhttps://via.place.com/300x300"

99 }

100 }

101 4. Удалить товар из БД DELETE FROM items WHERE items.id = 76Запись удаленаТеперь скорректируем наш кейс, учитывая вышеописанные рекомендации.

102 Наименование:"Проверка удаления созданного товара".

103 ПредусловияОжидаемый результат1. Тестовые базы:БД Preprod: preprod.shop_bugred_r_db

104 БД Test: test.shop_bugred_r_db

105 Выполнить SQL-запрос:

106 UPDATE{БД}.SETTINGS_CUSTOMIZE SET ITEMS_CREATE.ENABLE=true

107 Время переключения настроек: от 10 минут

108 В таблице{БД}.SETTINGS_CUSTOMIZE обновилось значение ITEMS_CREATE.ENABLE2. Подготовитьтестового клиентаБД Preprod: preprod.shop_bugred_r_db

109 БД Test: test.shop_bugred_r_db

110 В таблице{БД}.items.user найти запись не удалённого пользователя c помощью запроса SQL:SELECT method ,sessionId FROM{БД}.users WHERE user.remote <>true

111 Запись найдена. Значениеmethodзаписать в переменную{{method}},значениеsessionIdзаписать в переменную{{sessionId}}

112 3. Получитьтокенвыполнив метод GET api/v1.0/shop/test/auth/tokenВ параметрах указать:

113 method ={{method}},sessionId ={{sessionId}}

114 Получить код200иBody:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG

115 Получить из ответа одну переменную:{{Token}}

116 ШагиОжидаемый результат1. Выполнить POST-запрос http://shop.bugred.ru/api/items/create/ c параметрами:Header:Content-Type:application/json

117 Authorization: Bearer{{Token}}

118 Передать тело запроса:

119 {

120 "name": "Шортики",

121 "section": "Платья",

122 "description":"Модное платье из новой коллекции!",

123 "color":"RED",

124 "size": 44,

125 "price": 666,

126 "params":"dress"

127 }

128 Товар создан. Получить код200и тело ответа:{

129 "method": "/items/create",

130 "status": "ok",

131 "result": {

132 "id": "76",

133 "name": "Шортики",

134 "section": "Платья",

135 "description": "Модное платье из новой коллекции!",

136 "color": "RED",

137 "price": 666,

138 "params": "dress"

139 }

140 }

141 Проверить, что выделенные поля присутствуют в ответе. Получить из ответа две переменные:{{id}}и{{name}}

142 2. Выполнить POST-запрос http://shop.bugred.ru/api/items/update/ c параметрами:Header:Content-Type:application/json

143 Authorization: Bearer{{Token}}

144 Передать тело запроса:

145 <request>

146 <id>{{id}}</id>

147 <name>{{name}}</name>

148 <section>Платья</section>

149 <description>Модное красное платье</description>

150 <size>48</size>

151 <color>RED</color>

152 <price>678</price>

153 <params>dress</params>

154 </request>

155 Товар обновлен. Получить код200и тело ответа:{

156 "method": "/items/update",

157 "status": "ok",

158 "result": "Товар обновлён!"

159 }

160 Проверить значение выделенных полей

161 3. Выполнить запрос POST http://shop.bugred.ru/api/items/update/ c параметрами:Header:Content-Type:application/json

162 Authorization: Bearer{{Token}}

163 Передать тело запроса:

164 {

165 "id":{{id}}

166 }

167 Товар найден. Получить код200и тело ответа:{

168 "method": "/items/update",

169 "status": "ok",

170 "result": {

171 "id": "76"

172 "name": "Шортики",

173 "section": "Платья",

174 "description": "Модное платье",

175 "color": "RED",

176 "size": "48",

177 "price": 666,

178 "params": " ",

179 "photo": "http://shop.bugred.ruhttps://via.placeholder.com/300x300"

180 }

181 }

182 Проверитьзначение выделенных полей(пояснить, что за значение ожидается)

183 4. Выполнить SQL-запрос:DELETE FROM items WHERE items.id ={{id}}Товар удалёнПостусловияОжидаемый результатВернутьпервоначальныенастройки в БД. Выполнить SQL-запрос:UPDATE {БД}.SETTINGS_CUSTOMIZE SET ITEMS_CREATE.ENABLE=false

184 В таблице{БД}.SETTINGS_CUSTOMIZE обновилось значение ITEMS_CREATE.ENABLEПосле правок тест-кейс стал выглядеть более продуманным, понятным, структурированным. В нём учтены ожидания SDET-специалиста, которые до этого требовали бы излишней коммуникации между ним и QA. Если в инструментах хранения тестовой документации добавить теги, приоритетность и статус (например, требует корректировки, ожидает автоматизации, автоматизирован и так далее), это также сократит количество вопросов к QA-специалисту.

185 Проверки после каждого шага уместно использовать только при автоматизации длинных пользовательских Е2Е-сценариев, когда в один тест приходится вмещать большое количество проверок. Иначе проверки будут дублироваться, что приведёт к увеличению времени прохождения автотеста.

186 Каждый запрос к API или БД, скорее всего, будет написан и представлен в коде проекта автотестов как отдельный метод с передаваемыми в него параметрами. Этот метод будет использоваться в кейсах. Тело запроса будет описано всего в одном месте, благодаря чему очень удобно вносить правки в код.

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

188 В рамках написания автотеста можно придерживаться правила: автотест должен сам создать себе необходимые тестовые данные.

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

190 И последнее наблюдение. Явно указывать значения полей в тест-кейсе, с одной стороны, очень удобно: это сокращает время на разработку и снижает риск пропуска ошибки. С другой стороны, это может привести к эффекту пестицида - когда ошибки в тестовых сценариях, при регулярном их выполнении, перестают находиться. Исходя из нашей практики, можно не указывать конкретные значения полей, при этом кратко указав допустимые. Что касается автотестов, то в вышеприведённом примере как минимум поля name и description будут генерироваться автотестом, указанные значения не будут использоваться постоянно.

191 Лайфхак:на автоматизацию можно передать коллекции, которые QA-инженер написал сам, например, в Postman. Но перед этим важно создать кейс с шагами, условиями, настройками и приложить коллекцию.

192 Кадр: сериал "Парки и зоны отдыха" / NBCУ адаптации тест-кейсов под автоматизацию есть ряд преимуществ:

193 <ul><li>На автоматизацию SDET-специалисту попадают более читабельные кейсы, в которых обозначена цель проверки, информация об окружении, настройках, тестовых данных и прочее. Это экономит время разработчиков на написание кода.</li>

194 <li>В процессе адаптации QA-инженер обновляет версии кейсов и поддерживает их в актуальном состоянии.</li>

195 <li>Специалистам нужно меньше времени на коммуникацию.</li>

196 <li>Повышение качества тестирования и производительности команды, благодаря единому взгляду QA и SDET на процесс выстраивания автоматизации на основе тестовых сценариев.</li>

197 </ul>В этой статье мы поделились собственными рекомендациями и наблюдениями по адаптации тест-кейсов под автоматизацию. Надеемся, наш опыт был вам полезен.

198 Оптимизировать затраты на IT-разработку можно и <a>другими способами</a>, например с помощью аудита и услуг на аутсорсе. Но это - тема для новой статьи.

199 <a>Бесплатный курс по Python ➞Мини-курс для новичков и для опытных кодеров. 4 крутых проекта в портфолио, живое общение со спикером. Кликните и узнайте, чему можно научиться на курсе. Смотреть программу</a>