Что нужно для работы в тестировании?
Вы можете замечательно играть на музыкальных инструментах, быть отличным математиком, программировать на десятках языков, быть полиглотом, разбираться в алгоритмах и структурах данных, кататься на сноуборде, НО для тестирования важно только ОДНО - РЕЗУЛЬТАТ.
Не пролистывая ниже - попробуйте ответить на вопрос ЧТО ЖЕ ЭТО ЗА РЕЗУЛЬТАТ? (в чем он заключается?) КАКОЙ РЕЗУЛЬТАТ ОЖИДАЮТ ОТ РАБОТЫ ТЕСТИРОВЩИКА?
результат работы тестировщика - это счастье/удовольствие конечного пользователя. Да, так просто.
Например:
некто Ольга Синицына вечером после работы открывает приложение доставки, потому что дома закончился кофе. Она находит «зерно 1 кг», добавляет в корзину, выбирает адрес, время и нажимает «Оформить заказ». Если
на следующем экране написано: «Ольга, заказ №142857 принят, курьер будет с 19:00 до 20:00», и
в 19:35 курьер действительно привозит ровно тот кофе, в нужном количестве, по нужному адресу,
то честь и хвала вам как тестировщикам.
Если же
на следующем экране появляется «Что-то пошло не так. Попробуйте позже»
то несмотря ни на какие тест-кейсы, чеклисты, отчеты о тестировании, даже возможно покрытие сценария автотестами - ваша работа как тестировщика имеет ОТРИЦАТЕЛЬНЫЙ результат.
Тестировщик - это тот кто принимает окончательное решение - допустить ли обновление/выпуск продукта в продакшн или нет. Поэтому личное качество без которого невозможно работать в этой должности - это честность.
Если вы что-то не проверили, не сказали об этом и "зарелизили" продукт - клиент может быть разочарован, компания может получить убытки, а вам придется краснеть на ежедневном дейли митинге.
Но давайте перейдем к конкретике.
Что же такое тестирование?
Любое тестирование - это поиск багов.
Что такое баг?
Баг - это отклонение фактического результата от ожидаемого результата.
Что это значит?
Например:
Вы заказали на Озон игровую приставку (Play Station), а пришло фото игровой приставки.
Это баг.
Почему?
Ожидаемый результат: игровая приставка и как следствие возможность поиграть.
Фактический результат: фото игровой приставки и как следствие испорченные выходные.
Как начать тестировать?
Окей, а как тестировать на практике?
Если упростить до формулы, тестирование — это всегда 3 шага:
1) Находим ожидаемый результат (что должно быть)
2) Смотрим фактический результат (что получилось)
3) Сверяем и честно фиксируем вывод: совпало / не совпало / не можем проверить (и почему)
1) Где брать ожидаемый результат (источники «как должно быть»)
Ожидаемый результат почти никогда не живёт в одном месте. Нормальная работа тестировщика — уметь доставать “expected” из разных источников и понимать, какой из них главный.
Вот основные источники:
1. Требования и документация
- user story, описание задачи, acceptance criteria
- макеты/прототипы (Figma), спецификации API
- Confluence/README/документы по бизнес-логике
Плюс: формально и “официально”.
Минус: часто неполно, устаревает или написано «как-нибудь».
2. Договорённости с командой
- обсуждения с аналитиком/продактом/разработчиком
- комментарии в задаче, уточнения на созвоне
Плюс: быстро снимает неопределённость.
Минус: если не зафиксировать, завтра все “вспомнят иначе”.
Важный момент - в работе тестировщика нельзя "стесняться" спрашивать у разработчиков, аналитиков и прочих участников команды любые вопросы по задаче которую вы тестируете. Как минимум по тому, что разработчики / аналитики и заказчики "продукта" могут это понимать по-разному. Спрашивайте много, часто, подробно. Задавайте уточняющие вопросы - это позволит вам находить "баги" еще до тестирования продукта.
3. Текущее поведение системы (если мы меняем уже существующий продукт)
- то, как работает прод сейчас
- поведение в предыдущей версии
- “как было до изменения”
Важно: «как было» — это не всегда «как должно быть», но это отличный ориентир, чтобы поймать регрессии.
4. Внешние правила и ограничения
- законы/регуляторика, договоры, политика безопасности
- требования платёжных систем, App Store/Google Play, стандарты доступности
5. Здравый смысл и пользовательские ожидания
Да, это тоже источник. Например: “кнопка «Оплатить» не должна молча ничего не делать”.
Но тут осторожно: здравый смысл — не замена требованиям, а сигнал “тут надо уточнить”.
Итого: тестировщик сначала отвечает себе на вопрос:
«Откуда я знаю, как должно быть?»
Если ответ “ну кажется” — лучше остановиться и уточнить.
2) Как смотреть фактический результат (что получилось)
Фактический результат — это не только “на экране то/не то”.
Что обычно проверяют как «actual»:
- UI: тексты, состояния, ошибки, валидация, доступность
- данные: что записалось/не записалось (БД, кэш, очередь, аналитика событий)
- интеграции: ушёл ли запрос, какой ответ вернулся, что залогировалось
- нефункциональное: скорость, стабильность, безопасность, корректность при нагрузке
Практический навык тестировщика — уметь собирать факты:
- скрин/видео
- логи (клиент/сервер)
- HAR/Network в браузере
- запрос/ответ API (curl/Postman)
- точные шаги и входные данные
3) Сверяем: что считается багом, а что — “неясно”
Теперь сравниваем expected и actual.
- Если expected известен и actual отличается → это баг.
- Если expected непонятен/неполон → это баг требований - и их необходимо уточнить.
Где и как фиксировать?
И что именно проверять?
На эти вопросы мы с вами ответим на следующем уроке.
А пока домашнее задание (да, оно необходимо для закрепления материала):
1) Прочтите первые 3 главы книги Р. Савин "Тестирование дот ком"
2) Найдите любой баг в любом из IT продуктов которыми вы пользуетесь. Источником ожидаемого результата можно взять здравый смысл (если доступ к другим источникам закрыт).
Следите за новым разделом — уроки по тестированию. Он подойдёт тем, кто учится на QA с нуля, и тем, кто уже работает, но хочет систематизировать знания: тест-дизайн, API, автотесты, SQL/данные, CI/CD и практики командной разработки.
Подписывайтесь, добавляйте в закладки в браузере, чтобы ничего не пропустить: QA Helper - справочник тестировщика
