Мой рабочий день
09:00-11:00 - Начинаю работать по принципу “чем раньше начнешь - тем раньше закончишь” (работает, как вы понимаете, не всегда). Утренние часы - самые спокойные.
Делаю обычно вот что:
- завожу не очень критичные баги (если не успел завести их вчера)
- собираю статус готовности релизов
- занимаюсь одной из активностей: проверяю новые задачки, делаю регресс или занимаюсь исследовательским тестированием.
11:00 - Священный ритуал для всей нашей команды - происходит созвон (morning call, morning meet-up - везде это обзывают по-разному).
Без созвона жизнь тестировщика очень тосклива: откуда иначе можно узнать, что все планы переигрались и тестировать нужно теперь не релиз, а хотфикс? Или еще какие-нибудь новости. Когда-то они оч хорошие (например, в команде появился новый человек), а когда-то, мягко говоря, не очень - что-то сломалось в приложении и юзеры потихоньку начинают свирепеть (а если юзеры себя плохо чувствуют, то тестеры себя чувствуют тоже неважно).
Что обычно делаем на morning call?
- решаем текущие небольшие вопросы с dev-командой
- актуализируем приоритеты по задачам, если требуется
- слушаем: разработчики и менеджеры могут рассказывать о каких-то проблемах, мы же мотаем это на ус, и прикидываем, как это потом может повлиять на тестирование.
11:30 и до конца рабочего дня - ну, тут всё: темп ускоряется, летят задачи, патчи, какие-то задачи не получается протестить (но нельзя про них забыть!), решаются какие-то проблемы со стендами, куча вопросов, короткие созвоны с коллегами и сюда же вклинивается обед, перекусы и короткие разминки, иногда поход в магазин. У нас QA-команда небольшая - загрузка высокая.
Я много что пытался сделать, чтобы как-то сбалансировать день (Pomodoro, например), но есть такое личное ощущение, что день только растягивается от этого. Но вы попробуйте..
Ну и немножко полезной серьёзной инфы:
Как правило, к моменту выпуска релиза весь этот хаос превращается в порядок и участвует в этом вся команда, но у тестеров есть свое понимание порядка и свои инструменты для этого (и это тоже обеспечение качества):
- трекер задач (обычно это Jira, актуальные статусы задач - это must have, а после тестирования задачу лучше всего закрывать с мини-отчетом/скриншотами/скринкастами о проделанной работе - это точно поможет при возникновении каких-либо проблем + будет видно, что проверялось, а что не проверялось. Есть различные расширения для баг-трекеров, которые могут этот процесс сделать более приятным (Zephyr или обычный to-do list хотя бы). Закрыть задачу с комментом “Проверено” или “ОК” - плохая практика, но можно в редких случаях. Закрыть задачу без коммента - это уже преступление :)
- тест-анализ (определяем, ЧТО тестируем) и тест-дизайн (думаем, КАК протестировать). Это огромная тема, поговорим об этом как-нибудь позже. Если коротко - думаем, как ломать, желательно как-нибудь "поизощрённее"
- чек-листы, тест-кейсы - результат тест-дизайна, эти штуки очень близки к промышленному производству - в какой-то степени аналоги технологических процессов, карт измерений, технологических инструкций, но если посмотреть на это с другой точки зрения - это как список покупок в магазине - купил колбасу - молодец, тест прошел :)
- автотесты, созданные на базе тест-кейсов или BDD-сценариев - оч важная штука, снижающая нагрузку на QA-команду и реально повышающая качество продукта. Буквально сегодня коллега таким образом нашел несколько критичных багов. Искать такое вручную - это как найти иголку в стоге сена
- тестовые отчеты - это обычно результаты работы автотестов и результаты регрессионного тестирования - повышают прозрачность работы QA-команды и тоже способствуют повышению качества продукта