Всем привет!
Постановка проблемы
У вас есть задача или проект на тестировании. Вы читали требования или описание, но ничего не поняли. Так бывает.
Времени нет. Проект горит. Дедлайн вот-вот накроет, а в голове пусто.
- Что делать?
- Как во всем разобраться?
- Как понять, что тестировать?
У меня есть 2 простых правила.
- Используем технику Диаграмма состояний и переходов.
- Делим задачу на два куска: логическая часть и техническая часть.
Эта статья - первая вводная часть большой истории. Я расскажу, как сама тестирую задачи со сложными длинными требованиями или вообще без документации.
Как выглядят требования?
Черно-белый текст. Много букв. Много условий и пунктов.
А иногда требований нет.
Наш мозг имеет ограниченный запас сил для обработки информации. Человек может прочитать 1-2 абзаца, а затем мозг устает, теряет фокус и хочет смотреть мемы, а не вот это вот все.
Причина в зрительной коре мозга. С рождения мы получаем информацию глазами: различаем цвета и формы, а уже после учимся читать.
К чему я веду? Да к тому, что в здравом уме любому человеку, в особенности начинающему инженеру по тестированию, легко заблудиться в диаграммах, требованиях, ссылках. А в конце можно заплакать и поехать к маме в Елец.
Задача на тестирование:
Для сайта Pinterest протестировать процесс “Регистрация”
На этом из требований у нас все. Аналитик ушел в майский трип, а разработчик не отвечает на сообщения. Разбираемся самостоятельно.
Вернемся к нашим правилам.
Правило N1. Диаграмма состояний и переходов.
Диаграмма состояний и переходов - вспомогательный инструмент, который поможет задать нужные вопросы к вашему процессу и не потерять смысл при тестировании.
Есть два объекта: круг и стрелочка. Больше никаких правил запоминать не надо.
- Быстро.
- Просто.
- Эффективно.
Погнали разбираться.
Диаграмма состояний и переходов
Кружочки - состояние системы. Ничего не происходит. Система ждет, что вы на что-то жмакните и будет происходить магия.
Стрелочки - ваши действия: кликаете на кнопки, заполняете поля, листаете страницу и так далее.
сейчас я рассказала как принято говорить научно и технично о тестировании. Если бы вы без опыта тестирования читали учебник или проходили бы курс, на любом простом примере из ИТ разобраться трудно.
Про правило N1. Логика и техника.
О логической части:
В логической части мы всегда фокусируемся на пользователях вашего приложения.
Ваше приложение должно быть полезно для пользователей.
Вы должны составить предложение, четко и ясно формулирующее пожелание пользователя:
🏃🏻 Я, как пользователь, хочу зарегистрироваться на сайте, чтобы сохранять красивые картиночки.
Представьте, что вы и есть пользователь. Какие шаги вам нужно сделать, чтобы достигнуть желаемого результата? Фокусируйтесь как раз на ответах.
Рисуем ДСП.
- Кружок ”Открыта ‘Главная страница’” - начало процесса
- Стрелочка “Нажать ‘Регистрация’” - это действие пользователя
- Кружок “Открыта ‘Страница регистрации’”
- Стрелочка “Заполнить данные” - пользователь заполняет данные.
- Кружок “Открыта ‘Страница приветствия’”- добро пожаловать в мир кека и флекса.
О технической части:
В технической части мы говорим о том, какие технические слои нашего приложения были изменены. Если понимаешь архитектуру своего приложения, то быстро разберешься что и как тестировать.
Я приоткрою завесу архитектуры приложений, но постараюсь, чтобы все было понятно.
Что нам известно ?
- Мы знаем, что у нас есть интерфейс - мобильное приложение, сайт и что угодно еще. Ваш пользователь видит как раз именно фронтовую часть, поэтому frontend.
2. Где-то в глубине души мы понимаем, что все наши действия на сайте обращаются к какому-то далекому большому серверу, который как-то обрабатывает наши действия. Это некая подкапотная часть нашего приложения, до которой моей бабулите вообще все равно было бы, лишь бы работало. Часть приложения, которая получает запросы от фронта и как-то их обрабатывает - backend.
3. Сервер общается с хранилищем информации - базой данных. Представьте сейчас это как огромную свалку с информацией. Это наш третий слой. О базах данных я могу рассуждать вечно, но пока что это просто коробок для нашей информации.
Вот и все. мы нарисовали картиночку для нашей технической части.
После того как вам стал понять путь клиента, архитектура вашего приложения - самое время подробно исследовать каждую из частей вашего приложения. Как я работаю с логической и технической частью приложения я расскажу в следующих статьях.
План выхода статей.
- Вводное видео. О логической и технической частях проекта. Теория Диаграмм состояний и переходов. (вы находитесь здесь)
- Логическая часть. Подробный анализ бизнес-логики и построение Диаграммы состояний и переходов.
- Техническая часть. Архитектура проекта. Диаграмма состояний и переходов.
- Оформление тестовой документации
