Недавно я рассказывала историю про мышей, планшеты и субботний хотфикс. Если коротко: я выполнила всё строго по требованиям, но пользователям было неудобно, и баг ушел на прод. Знакомая ситуация?
👉 Вот та самая история, если пропустили.
После того случая я задумалась: как сделать так, чтобы глупые ошибки не повторялись? Как научиться видеть не только то, что написано в требованиях, но и то, что за ними стоит?
Так появился этот чек-лист. Сейчас перед каждой задачей я мысленно прохожу по пяти пунктам. Это занимает несколько минут, но спасает от переделок и хотфиксов.
1. Кто будет этим пользоваться?
Кажется, что ответ очевиден. Но часто мы представляем себе абстрактного «пользователя», хотя на деле за этим словом могут скрываться разные люди:
- Биолог в лаборатории, у которого руки в перчатках
- Бухгалтер за старым монитором
- Курьер, который смотрит в телефон на бегу
- Человек, который не привык к сложным интерфейсам
Что делать: Перед тем как писать тесты, попробуйте представить конкретного человека. Если в требованиях этого нет — спросите у аналитика или владельца продукта. Держите этот образ в голове на протяжении всей работы.
2. В каких условиях это будут использовать?
Пользователи редко сидят в тихом офисе с идеальным интернетом и новым айпадом.
- В лаборатории — с толстыми защитными чехлами на планшетах
- На улице — при ярком солнце, где ничего не видно
- В метро — с обрывающимся соединением
- Ночью — в темноте, без звука
Что делать: Спросите себя: где будет жить эта функция? Если есть сомнения — поговорите с теми, кто знает реальные сценарии. Иногда одна деталь вроде «чехла на планшете» меняет всё.
3. Что может пойти не так?
Этот вопрос — один из самых полезных в работе тестировщика. Стоит добавить его к любому пункту требований — и открываются сценарии, о которых никто не подумал.
- Что, если пользователь нажмет не туда?
- Что, если сеть пропадет в середине операции?
- Что, если придут некорректные данные?
- Что, если нажать кнопку дважды?
- Что, если открыть в другом браузере?
Что делать: Пройдитесь по требованиям и к каждому пункту задайте этот вопрос. Ответы часто становятся новыми тест-кейсами. А иногда — вопросами к команде, потому что в требованиях про это просто забыли.
4. Что здесь можно понять по-разному?
В требованиях любят красивые формулировки: «система должна быстро загружаться», «интерфейс должен быть удобным», «приложение должно быть отзывчивым».
Это ловушка. Быстро — это сколько секунд? Удобный — для кого? Отзывчивый — при какой нагрузке?
Что делать: Каждое размытое слово превращайте в конкретику. Если формулировку можно трактовать по-разному — уточняйте, пока не стало поздно. Разработчик поймет одно, заказчик — другое, а конечный пользователь третье.
5. Будет ли этому удобно пользоваться?
Самый сложный вопрос. Потому что требования могут быть выполнены идеально: кнопки работают, данные грузятся, ошибки не падают. Но человеку все равно может быть непонятно как работать с системой.
Удобство редко прописывают в техническом задании. Но именно за это люди любят продукты.
Что делать: Включите режим обычного человека. Не тестировщика, который проверяет требования, а живого пользователя, который просто хочет решить свою задачу. Пройдите сценарий от начала до конца и прислушайтесь к ощущениям. Где стало неудобно? Где пришлось задуматься? Где захотелось бросить?
Если внутри появилось сомнение — скорее всего, где-то есть проблема.
Как я применяю этот чек-лист сейчас
Перед каждой новой задачей я открываю этот список и честно отвечаю на каждый пункт. Даже если кажется, что всё очевидно. История с мышами научила: очевидное часто оказывается самым опасным.
Иногда ответы рождают новые тесты. Иногда — вопросы к аналитику. Иногда — просто спокойствие, что я ничего не упустила.
Чек-лист не спасает от всех багов. Но он точно спасает от глупых багов. А глупые баги — самые обидные.
Если эта статья была полезной — забирайте чек-лист в работу, адаптируйте под себя и сохраняйте в заметки. И заходите в Telegram — там делюсь короткими лайфхаками и разборами.
🦊 Telegram-канал «Территория тестирования»: t.me/qa_territory