Home

Автор: Ольга Назина (Киселева)

Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

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

Если в приложении есть возможность открыть одну и ту же форму несколько раз — это обязательно надо проверить:

• Веб — открыть форму в нескольких вкладках браузера.

• Десктоп — там тоже иногда можно открыть в отдельной вкладке форму. Или запустить приложение несколько раз (имитируя разных пользователей).

• Мобилки — открыть с разных устройств.

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

Пройдемся по операциям CRUD (create, read, update, delete) и посмотрим на чек-листы для каждого типа:

1. Редактирование

2. Создание

3. Удаление

4. Итого

Редактирование (или другое действие)

Пробуем отредактировать в разных окнах:

• разные поля одного объекта (в одной вкладке имя, в другой — фамилию)

• одно и то же поле одного объекта

• удаленный объект

• изменивший состояние объект

• изменивший связи объект

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

У объекта могли измениться связи. Скажем, на карточке организации отражаются все сотрудники:

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

В итоге мы вроде не трогали ту сущность, которую сейчас меняем. Но при этом она изменилась! Как она отреагирует на это? Надо проверить...

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

• Перенести просто (базовый тест)

• Уже перенесенную

• Удаленную

• Из разных исходных состояний

• Измененную

• Измененную за счет связанных сущностей

Создание

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

• одинаковые объекты

• разные объекты

• много разных объектов (штук 20)

Как минимум надо проверить, что система позволяет создать 2 разные карточки. Какой тут может быть затуп? Допустим, в системе в URL хранится информация о сущности:

https://example.com/client/1

И когда вы его редактируете, то URL будет:

 https://example.com/client/edit/1

Тогда при нажатии на «Сохранить» система смотрит в URL — а кого ей сохранять то? И умеет обрабатывать страницы вида /edit/<id> или страницу вида /create

https://example.com/client/create

Возможно, она при этом считает create нулевым идентификатором. И тогда разные вкладки создания для неё будут одной и той же карточкой. И при создании в двух вкладках вы или получите ошибку во второй, или она обновит созданное в первой =)

А может, система более менее умеет обрабатывать такие вещи, но если её чуток нагрузить — уже не справиться. Тут я под нагрузкой понимаю «создать 20 карточек, а не 2», а не прям настоящее нагрузочное тестирование, его мы в этой книге рассматривать не будем. А вот с точки зрения тест-дизайна и 20 карточек бывает достаточно.

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

Я проверяла и так, и сяк. Что только не вбивала в поля, пытаясь воспроизвести ошибку — не получалось! У меня всё работает, а у неё — нет... Но нам повезло, команда маленькая и все сидят в одном кабинете. Так что мы с разработчиком просто встали у девочки за спиной и стали смотреть, что она делает.

А она зажала контрол и нажала на кнопку «создать» сразу раз 10, открыв кучу новых окон. И начала заполнять их по очереди:

— А зачем ты так делаешь?

— Ну... Мне так удобнее!

И вот именно такая параллельная работа всё и сломала!

Удаление

Ну и как обойти стороной удаление! Пытаемся удалить (сейчас именно чек-лист про разные вкладки):

• уже удаленный объект

• изменивший состояние объект

• изменивший связи объект

Итого

При тестировании не забывайте про одновременную работу с одним и тем же объектом (The TOGOF Tour в исследовательских турах).

Повторите любое действие с одним и тем же объектом в разных вкладках — это самый простой тест.

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

Статья написана для студентов курсов Ольги Назиной Школа для начинающих тестировщиков и Инженер по тестированию программного обеспечения.

См также:

Ролевая модель: чит-лист проверок

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале   

Обсудить в форуме