На входе в проект существует несколько неочевидных аспектов. О подходах к знакомству с продуктом и старте работы QA много полезного рассказал в этой статье мой коллега, QA Lead Александр Фиалка. Кое в чем наши мысли пересекаются, но я все равно рекомендую прочитать его материал — там много полезных советов для мануальных тестировщиков. А этот текст больше заинтересует автоматизаторов.
Первая часть статьи посвящена начинающим QA. Рассмотрим моменты, которые помогут лучше понимать особенности тестирования вашего продукта и научиться смотреть на проект шире. Продолжим тему советами для техлидов. Опытные специалисты узнают, с чего начать работу над проектом и как построить процессы QA эффективно и удобно для всей команды.
Основным источником информации о проекте для вас должен стать техлид. Иногда он тоже может не до конца понимать все нюансы, потому что сам только пришел или в принципе не разбирается в процессах… Но надеюсь, у вас ситуация лучше, и от своего техлида вы сможете узнать следующее:
Если вы пришли в уже существующий проект, то стратегия тестирования готова. В противном случае советую попытаться присоединиться к написанию и корректировке стратегии хотя бы на уровне деталей.
В качестве автоматизатора вы можете помочь техлиду в нескольких моментах:
С этого момента начинается основная работа автоматизатора, запасайтесь энергетиками! Ваша работа состоит из двух ключевых задач:
Неважно, заходите ли вы на нулевой или действующий проект. В любом случае ваша первая задача — как можно больше узнать о разработке. Особенно если она такая же непонятная на первый взгляд, как вот эта вещь из мультсериала «Рик и Морти»:
Подробно изучив проект, переходите к написанию черновика стратегии тестирования. Даже от опытных автоматизаторов иногда можно узнать, что без тестовой стратегии или тест-плана можно прожить. Причем люди ссылаются на реальные проекты, где все обходились без документации. Мол, она нужна только для чего-то большого и мощного, как Звезда смерти из «Звездных войн».
Стратегия — это общие подходы к тому, что вы будете делать на проекте. В ней нет названий конкретных фреймворков, тасков, функциональностей или ответственных за таск. В стратегии показаны ориентиры в тестировании и их автоматизации. Тест-план — это уже детализированный документ, которому вы с командой будете следовать для обеспечения качества «здесь и сейчас». Этакая пошаговая инструкция.
Обращусь к личному опыту. Первую тестовую стратегию я написал в какой-то степени случайно. Меня пригласили в один смежный проект, где в команде не хватало опытных людей. Когда клиент попросил команду подготовить тест-стратегию, коллеги обратились ко мне. Я раньше этого не делал, но в общем понимал процессы на проекте и был готов немного погуглить. Почитал, что такое тестовая стратегия, что в ней должно быть, и принялся писать. Шаблоны из интернета помогли мне правильно сформулировать структуру. И буквально через день у нас уже был рабочий документ.
В небольшом проекте, где тесты просты, стратегия может и не пригодиться. Иногда достаточно на словах передать коллегам или стейкхолдерам, куда вы двигаетесь. И все равно я советую иметь задокументированную стратегию. Как минимум, вы сэкономите время на разъяснениях. Проще подготовить документ — а дальше он будет помогать и даже в чем-то защищать вас. Например, от менеджмента, который может регулярно интересоваться целями того или иного тестирования. В ответ вы спокойно сможете ссылаться на утвержденную руководством стратегию. С течением времени что-то может меняться, но заапрувленный документ снимает с вас часть ответственности и дает простор для маневра.
При разработке автомейшен-стратегии ответьте на следующие вопросы:
Начальная стратегия позволит лучше осознать направления движения. Опираясь на этот документ, постепенно вы сможете кое-чем упростить и улучшить работу всех тестировщиков на проекте.
Имея драфт стратегии, можно присматриваться к конкретным инструментам и программам для запуска тестов. По-моему, этот этап самый интересный.
Ведь нам, автоматизаторам, всегда полезно изучить и испытать на практике что-нибудь незнакомое.
При заходе на проект сценарии инвестигейта инструментов могут отличаться в зависимости от состояния проекта — он стартует или уже какое-то время продолжается. В целом порядок действий таков:
Можно инвестировать абсолютно незнакомые, но интересные и по-своему эффективные инструменты. Такая любознательность может повысить вашу экспертность. Но на старте все же лучше попробовать хорошо знакомые тулзы. Это упростит процесс вхождения в проект. Так же проще будет начать работу и другим QA, которых вы будете привлекать в команду.
Возможно, кому-то из автоматизаторов хотелось бы только копаться в коде. Но роль техлида подразумевает регулярное общение со всеми участниками процесса.
Коммуникация в проекте происходит по трем направлениям:
Итак, у нас есть четкое понимание стратегии тестирования. Самое время поведать все команде.
Расскажите, что и зачем будут делать ваши специалисты. Инженеры должны знать конечную цель своей работы. Поделитесь с ними черновиком стратегии и обсудите, согласны ли все с описанными действиями и поставленными задачами. Будьте открыты к разным мнениям и предложениям. Если кто-то не согласен с планом, обязательно обсудите это. Помните: ошибиться может даже опытный техлид. Так же, как и время от времени правым может оказаться джун.
Автоматизаторы должны уметь запускать ваши тесты, знать, когда это делать и какой результат ожидать.
Стратегия должна стать основным ориентиром в работе автоматизаторов. Прежде чем перейти к написанию окончательного документа, получите апрувы от тестовой и проектной команд, от менеджмента и заказчика. Все правки и пожелания должны быть учтены. Готовый документ опубликуйте на вашем рабочем спейсе и предоставьте доступ всем задействованным в проекте людям: от QA и разработчиков до аналитиков и заказчика.
Приведу несколько вопросов, которые помогут вам понять ситуацию на проекте:
Регулярный мониторинг позволяет видеть, в правильном ли направлении движется ваша команда и вообще проект. Раз все хорошо, можно только порадоваться. Если же возникли проблемы, анализируйте их и вводите изменения.
Вы инвестировали в ее создание много усилий. Все согласились работать согласно документу. Но если команда в какой-то момент изменит траекторию работы, это может привести к негативным последствиям. Вы ожидаете одних результатов, а на самом деле все происходит по другому сценарию. В результате клиент может указать на стремительный рост количества багов на продакшене. А причина может быть в том, что один автоматизатор почему-то решил писать тесты по-своему, другой инженер покрывает тестами незапланированные функциональности и так далее. Поэтому обязательно следите за тем, как команда реализует стратегию.
При необходимости в стратегию можно и нужно вносить поправки. Ведь любой проект — это как живой организм. Со временем он растет, меняется. Соответственно, процессы в нем тоже. Важно отражать эти изменения и в стратегии, чтобы документ не терял актуальности.
Обратная связь очень ценна. Он помогает корректировать процессы со стратегией тестирования и в конечном итоге улучшать продукт.
Обычно автоматизаторов, приходящих на проект в первой волне, учит лично техлид. Это традиционная практика. Техлид лучше других знает продукт и их тестовую стратегию. Поэтому этот специалист может передать свои знания инженерам, которые будут воплощать его идеи в жизнь. Чем подробнее он расскажет обо всех нюансах, тем эффективнее будет работать вся команда QA.
Ни один техлид не может постоянно заниматься исключительно обучением новых людей. Потом придется искать ресурс для стратегических задач. Поэтому параллельно с предыдущим пунктом техлид должен научить того, кто будет потом обучать других. Сначала вам может показаться, что только вы знаете, как правильно учить людей работать с конкретным проектом. Вы ведь его чуть ли не сами строили! Но будем откровенны: качество обучения и эффективность работы команды никак не проседает, если в ней будут другие менторы, такие же, как вы, квалифицированные специалисты. Здесь следует научиться делегировать обязанности и дать возможность другим членам команды профессионально расти.
В завершение скажу еще одну важную задачу техлида — сбор репортов. Они должны были быть полными и поступать в нужный момент времени.
А для этого вам нужно не гоняться за командой с угрозами, а позаботиться об автоматизации процесса.
Вы можете сами придумать, как автоматизировать сбор репортов, или обсудить разные способы с командой. Это может оказаться классной технической задачей «со звездочкой». Настройка процесса займет некоторое время, но инвестиция вполне оправдана. А потом инженеры будут нажимать условно одну кнопку раз в неделю — и репорт будет готов. Если же автоматизация невозможна, попробуйте хотя бы упростить этот момент. Предложите команде собирать короткие репорты — быстро и вручную. Только обратите внимание: информации в собранных метриках должно быть достаточно для менеджеров.тест
Читайте также: Поздравляю, вы тест-лид: как зайти на новый проект и не упустить ничего важного (удобный чек-лист)
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…