Совет от тестировщика 49/∞ : Граничные значения не только про поле ввода
Когда мы слышим про классы эквивалентности и граничные значения, мозг сразу рисует поля ввода возраста или цены. Но эти техники работают вообще везде, где есть лимиты.
Размер загружаемого файла, количество символов в названии статьи, дата окончания подписки. Всегда ищите границы в бизнес-логике, именно там система ломается чаще всего.
Совет от тестировщика 45/∞ : Оперируйте цифрами
Собирайте метрики качества. Бизнес и менеджеры понимают язык цифр, графиков и денег, а не ваши эмоции про "у нас тут все криво работает".
Придите с отчетом, где видно количество багов по модулям и общее качество продукта – и к вам прислушаются.
Совет от тестировщика 43/∞ : Не спорьте ради спора
Ваша общая цель с разработчиком и менеджером – выпустить качественный продукт, а не доказать, кто тут умнее. Если баг минорный и никак не влияет на юзеров, умейте уступать.
Токсичные воины за идеальный код только удлиняют процесс разработки и оттянивают решение действительно важных проблем.
Формулировки вроде «пользователи должны легко управлять настройками» или «система должна обеспечивать бесшовный онбординг» не проходят проверку на качество требования: нельзя понаблюдать за действием пользователя и понять, сработала ли функция. Из-за этого инженеры трактуют требование по-разному, QA не может написать тест-кейсы, а метрик для оценки результата просто нет.
Подход CRISPi вместо расплывчатых формулировок">i (Кокберн) заменяет расплывчатые формулировки структурированным сценарием из пяти элементов: Context (Контекст), Role (Роль), Intent (Цель), Steps (Шаги), Postcondition (Пост-состояние). Ключевой приём — писать Postcondition раньше Steps: если постусловие не сформулировать до шагов, значит продакт не знает, что строит, а просто рисует интерфейс.
Совет от тестировщика 42/∞ : Помните про пирамиду тестирования
Не пытайтесь покрыть UI-тестами каждую кнопку, это долго, дорого и нестабильно. Основная масса проверок должна лежать на уровне API и юнитов.
Совет от тестировщика 41/∞ : Пишите понятно
Суть проверки, шаги воспроизведения, результаты, должны быть понятны даже стажеру в его первый рабочий день. Избегайте сленга, который понятен только вам и паре старичков на проекте.
Баг-репорт, чек-лист, тест-кейсы - это документ, а не личная переписка лучших друзей.
Совет от тестировщика 40/∞ : Удаляйте мусор
Не привязывайтесь к старым проверкам. Регулярно удаляйте неактуальные тесты, которые дублируются или проверяют фичи, отключенные год назад.
Чистая база тестов это залог быстрого регресса. Не копите хлам.
Совет от тестировщика 39/∞ : Прикладывайте видео, скрины и другие вложения
Запись экрана или скриншот с выделенной проблемой, список логов, дефектные тестовые данные экономят часы пустых споров. Разработчику проще один раз увидеть, чем вчитываться в ваши формулировки.
Самое важное в баге: понятный заголовок и вложение с доказательством дефекта.
Совет от тестировщика 38/∞ : Сужайте локализацию дефекта
Прежде чем завести баг, найдите минимальный набор шагов для его воспроизведения. Не пишите 15 шагов, если ошибку можно повторить за три. Не записывайте 5минутное видео, а только ту часть, которая важная для воспроизведения бага.
Разработчик не должен тратить полчаса, чтобы просто понять, как добраться до проблемы. Уважайте чужое время.
Совет от тестировщика 37/∞ : Фиксируйте договоренности
Любое устное изменение требований должно быть записано в тикете. Поговорили у кулера или на созвоне: зафиксируйте это в комментариях к задаче.
Слова к делу не пришьешь, а когда придет время релиза, никто и не вспомнит, о чем вы там договорились месяц назад.
Особенно это важно для багов, они всегда должны быть в системе, а не в переписках с разработчиками. Спросят в первую очередь с вас.
Совет от тестировщика 36/∞ : Дробите сложные задачи и декомпозируйте
Разделяйте объемные требования на атомарные проверки. Тест-кейс на 40 шагов никто никогда не дочитает до конца, да и поддерживать его сущий ад.
Маленькие и понятные проверки легко переиспользовать и проще автоматизировать в будущем.
Коллеги, как там дела на рынке? ИИ уже "убил" тестировщиков?
Сейчас активно веду в тредс и там, что ни день, то боль про найти работу.
Все реально так плохо или есть еще способы ее найти?
Интересно послушать тех, кто в поиске последний год, кто с опытом или без него.
Что сработало, что нет? Какие технологии сейчас просто мастхэв в резюме?
Просто пост, чтобы подарить хоть какую-то надежду, но желательно не убить ее.
Совет от тестировщика 35/∞ : Изучайте доменную область
Понимание того, как пользователи зарабатывают деньги с помощью вашего продукта или какую проблему он решает, делает из вас крутого инженера. Именно это в первую очередь ценят в тестировщике, а не в его умении придумать 100 кейсов с напитками, когда он заходит в бар.
Тестировщик, который понимает домен, всегда найдет более критичные баги, чем тот, кто просто идет по шагам тест-кейса.
Совет от тестировщика 34/∞ : Обновляйте тестовую модель
Поменяли требования в Jira - сразу идите и правьте свои тест-кейсы. Не оставляйте это на "потом", потому что это "потом" никогда не наступит, а документация превратится в тыкву.
Актуальные тесты это гарантия того, что регресс пройдет гладко, а новый сотрудник не сойдет с ума, пытаясь понять, как должна работать система.
Совет от тестировщика 33/∞ : Не додумывайте за бизнес
Если требование можно понять двояко, идите к аналитику или продакту. Не берите на себя ответственность за реализацию фичи, это не ваша зона компетенции.
Ваша задача подсветить нестыковку, а не придумать, как бизнесу будет лучше. Иначе прилетит по шапке именно вам, когда окажется, что задумывалось вообще другое.
Совет от тестировщика 32/∞ : Визуализируйте
Составляйте интеллектуальные карты для запутанных бизнес-процессов, используйте диаграммы переходов и состояний. Сплошной текст в требованиях воспринимается мозгом гораздо хуже, чем наглядная схема со стрелочками.
К тому же, по майндмапу намного проще писать тест-кейсы и чеклисты. Один раз нарисовали, и потом говорите себе спасибо.
Совет от тестировщика 31/∞ : Задавайте глупые вопросы
Лучше показаться навязчивым на уточнении требований, чем пропустить критический дефект в рабочем приложении. Никто не ждет, что вы с первого раза поймете запутанную фичу, которую аналитик готовил три месяца.
Не бойтесь переспрашивать "а что будет, если пользователь нажмет сюда?". Чаще всего именно на таких очевидных вопросах система и сыплется.
Совет от тестировщика 30/∞ : Ведите свою личную базу знаний. Записывайте туда полезные скрипты, сложные селекты в БД, особенности вашего проекта.
Документация на проекте – это хорошо, но своя документация – еще лучше.
Совет от тестировщика 28/∞ : Тестируйте на реальных девайсах, когда это возможно.
Эмуляторы – это замечательно, но все равно не 100% гарантия, что поведение приложения будет таким же на реальном смартфоне.
В вашей лаборатории всегда должны быть устройства для тестирования самых важных функций и их влияния на телефон.