Как устроено наше тестирование и почему QA участвует в постановке задач нашим разработчикам
Добрый день!
Меня зовут Евгений, я руководитель тестирования облачных решений Acronis, и я хочу рассказать вам о том, как у нас всё это устроено.
Вообще, QA — это почти как КГБ: нас не всегда видно, но мы есть везде. Мы участвуем в процессах, начиная с самых ранних этапов, когда ещё идёт обсуждение техтребований, их доработка, черновое прототипирование фич. QA не имеет права голоса, но обязательно объясняет девлиду и программ-менеджеру багоопасные места на основе своего опыта. И, как правило, это объяснение влияет на требования к фиче.
Процесс по шагам
Первый этап: дизайнер, который рисовал фичу в интерфейсе, разработчик, ПМ и QA садятся в одной комнате и обсуждают, как оно должно работать. В самом начале мы выступаем с позиции «А что будет, если…» — мы же думаем, что случится с продуктом при реализации и какие подводные камни в этом процессе могут вылезти. Продуктолог редко оценивает фичу именно с точки зрения стабильности — его задача думать, как она поможет конечному пользователю, а наша — как она может навредить. Например, как-то мы хотели добавить пару настроек, а чтобы обеспечить доступ к ним — ещё одну роль для пользователей чуть ниже админа. Мы как представители обычных пользователей выступили против, потому что это усложняло интерфейс и понимание того, что происходит. Вместо этого решили сделать фичу по-другому, разгрузив GUI, но зато добавив эти параметры как скрытые сущности в консоли.
Второй этап: QA смотрит на техзадание и показывает багоопасные места (как правило, это касается системных вещей — вроде того, что на текущей архитектуре лучше делать иначе или с пониманием новой архитектуры, к которой идём).
По готовности начинается «продажа фичи»: разработчик собирает дизайнера, ПМа и представителя QA. Дизайнер проверяет, что она сделана так, как он задумал, ПМ смотрит на функционал, а QA соглашается, что фичу можно в таком виде тестировать.
Дальше фича возвращается в QA уже от разработчика после реализации и получает уровень качества. Конечно, разработчик до этого сам тестирует её, как может и умеет. Если фича приезжает в QA сырая, то мы выставляем ей низкий уровень, и она сразу же, без дальнейшего рассмотрения, уезжает обратно в разработку со списком открытых багов.
Если же фича «продана» успешно и выполняет свою функцию, то начинается работа. Первый этап — доуточняется тест-план. Вообще, мы начинаем писать тест-план сразу после того, как согласованы и зафиксированы требования по фиче. Автотесты могут писаться сразу или же добавиться со средним и низким приоритетом. Бывает, что фича будет протестирована автотестом только в критических местах, а потом постепенно войдёт в план прогона на роботах полнее. В кандидаты на автоматизацию попадают не все фичи, естественно. Например, в Enterprise-сегменте зачастую много одноразовых мелких вещей, которые нужны буквально паре компаний-заказчиков. Они чаще всего проверяются вручную, как и минорные фичи в консьюмерских продуктах. А вот всё то, что отвечает за прямую функциональность продукта, покрывается автотестами почти всегда полностью, но не всегда за один проход. Для написания тестов у нас свой фреймворк на Python.
Дальше выполняется ручное и автоматическое тестирование по плану. Результат этого этапа — оценка по уровню качества. Чтобы фича вошла в релиз, ей нужно получить »4» или »5» по пятибалльной шкале. С пятёркой (придирки, пожелания к улучшению) проходит без вопросов, с четвёркой (пара не очень значительных major-багов) включается в релиз только по решению продукт-менеджера. В целом: 1 — фича вообще не работает, 2 — работает, но большая часть её функционала не выполняется, 3 — работает значительная часть, но есть очень неприятные критичные баги, 4 — работает практически полностью, но есть небольшие нарекания. 5 — фича работает идеально, и багов на ней либо нет вообще, либо они очень незначительные. Пару раз за год мы включаем нужный функционал с оценкой чуть ниже четвёрки, но всегда отмечаем его как бету для конечного клиента.
Если баг влияет на базовый функционал, то он критикал по важности, если он при этом еще и часто стреляет, то у него очень высокий приоритет в срочности.
Баги на ручном тестировании заводятся в Джире руками. Баги автотестов — автоматически, причём наш фреймворк проверяет, нет ли уже такого бага, не имеет ли смысл переоткрыть его. Критичность и приоритет багу назначается специалистом QA вручную.
Что бывает, когда разработчик не согласен с мнением QA по оценке бага? Тогда все вместе садимся и разбираемся. Надо сказать, что около трех лет назад такая проблема действительно была, но сейчас мы выделили QA в отдельное подразделение и прописали довольно много признаков и свойств бага, не допускающих двояких толкований. Вообще, у нас вся разработка — в России, большая часть людей — в Москве. Весь QA сидит в одном офисе и рядом, поэтому никаких проблем с уточнением и взаимодействием нет. Дошел быстро ногами и все оперативно обсудил. Это очень помогает.
Сначала мы проверяем билды на локальных стендах. Если все ок, то выкладываем данный билд на препродакшн, развернутый на инфраструктуре продакшена, где лежит последний зарелиженный билд. Таким образом, мы еще раз проверяем апдейт в максимально приближенных к реальному продакшену условиях.
После — выкладываем билд на бета-сервер. У нас есть портал, где можно поиграться с новой версией (как правило, наши проверенные и самые активные партнеры имеют туда доступ и дают довольно обширный фидбек). Кстати, если хотите получить приглашение на данный сервер — можно написать коллегам, и они все организуют (diana.kruglova@acronis.com).
Люди
Требования к QA почти такие же, как к разработчикам, но с учётом того, что писать придётся в основном автотесты. Плюс, мы отбираем людей, которые разбираются в основах UI/UX (и дообучаем, если надо), потому что большая доля фич сейчас на стыке с интерфейсом.
К нам в команду попадают специалисты технически грамотные, обязательно — сообразительные и с развитой логикой. Время тестировщиков, как обезьянок, тупо повторяющих тесты, уже давно прошло. Вместо обезьянок у нас модули автотестов, которые сами разворачивают инфраструктуру из примерно 30 типовых окружений, сами приводят её в нужное состояние, ставят беты и гоняют их по программе теста, попутно записывая лог и снимая скриншоты.
Хотя, конечно, ручного труда у нас всё ещё довольно много.
Обычно распределение рабочего времени такое: 30% уходит на общение с разработчиками и выяснение техтребований, дальше примерно пополам — на ручную работу и написание автотестов в нашем фреймворке. Естественно, есть люди, которые чаще и больше делают руками, и есть те, кто почти всегда пишет код.
Говоря о развитии тестировщика как профессии, могу сказать, что автоматизаторам часто хочется попробовать себя в роли разработчика. Почему? Потому что все еще существует стереотип, что в разработке ты делаешь свой продукт, а в тестах — обслуживаешь чужой.
У нас путь немного отличается от такого стандартного — дело в том, что задачи в автоматизации часто интереснее задач разработки. Большая часть разработки в стабильных многолетних проектах — это поддержка. А у нас, так уж получилось, последние несколько лет развитие шло довольно бурно: мы как раз поднимали rocket science по тестированию. Я до этого работал в компании Parallels, и мы там пять лет развивали систему, которая автоматизировала всё. От виртуальных машин до железа, где разворот софта, запуска, отправки багов и отметок проверенных багов уже. У нас, думаю, ещё пару лет будет бурно.
Поэтому наши лучшие специалисты часто вырастают в продукт-менеджеров. Поскольку квалификация предполагает думание на несколько шагов вперёд плюс общение, плюс знание продукта целиком, плюс желание улучшать продукт и понимание, что в нем стоит улучшить в первую очередь, получается почти готовый ПМ через 2–3 года работы в QA.
Рекурсия
Тестирует автотесты тот, кто их писал. Иначе нам бы потребовался ещё один QA.
Старые мелкие баги
Почти в каждом трекере многолетних проектов накапливается группа несрочных, несерьёзных или вообще странных редких багов с самым низким приоритетом, которые тащатся, как хвост, из года в год. По ним мы приблизительно раз в году делаем процедуру переоценки и решаем, нужно ли тащить хвосты. Чаще всего — не надо. Закрываем усилием воли и «отрезаем» хвост.
«Внешние» баги
После релизов баги приходят к нам из поддержки или от команды поиска отзывов в соцсетях (от них больше подозрения, нежели готовые симптомы). До третьей линии доезжают иногда совершенно волшебные вещи. Например, клиент (Тайвань, источник — англоязычная поддержка) установил продукт на ОС Win8.1 Pro и с его помощью создал «защищённую область на диске», затем перезагрузил свой ПК 750 раз. И после это у него начал мерцать экран. По настоятельному запросу пользователя данный сценарий тестировался по нескольку раз на разных машинах.
Или вот история из Гонконга:
SCENARIO:
1) Create backup of a disk which has an old OS like Win98 or DOS in current case (unsupported by UR) and Windows 7.
2) Boot the same system using ABR 11 bootable media with Universal Restore.
3) Create a recovery task and select above mentioned disk backup.
4) Select the disk/partitions for recovery
ACTUAL RESULT:
Universal Restore not offered during disk/partition recovery.
EXPECTED RESULT:
Universal Restore option should be available and should recover Windows 7 properly. Older OS might not be bootable but should get recovered.
Environment: RAID controller (LSI 9260–8i)
ORIGINAL SETUP:
4×640GB in RAID 5 level, Partition –>
C: (1st partition, FAT32),
D: (2nd partition, Window 7 system, NTFS),
E: (3rd partition for data storage, NTFS),
F: (4th partition for data storage, NTFS),
N: (5th partition for data storage, NTFS)
Кончилась эта история тем, что удалось разобраться, в чём причина сбоев в загрузке клиентской ОС, и, конечно, успешно загрузиться. Ошибки в продукте не было.
Сроки релизов
Вообще, за каждым семейством продуктов закреплены конкретные специалисты. Когда образуется новый продукт — добираем людей на него, бывает, назначаем их руководителем кого-то из «ветеранов». Если продукт небольшой — поначалу он тестируется на базе родительского и на его инфраструктуре, а потом отделяется.
Вот как-то так. Меня можно спрашивать по процессу, а мой коллега, который занимался автоматизацией автоматизации тестирования, как раз пишет про то, как организовать всё это правильно с точки зрения ПО.
