Привет, Хабр! Меня зовут Егор, я руководитель Центра компетенций обеспечения качества SM Lab. И именно про наш центр компетенция я и хочу рассказать. Статья пригодится не только тестировщикам, но и разработчикам и аналитикам. Ведь тестирование — это не только поиск багов, но и создание культуры качества.
Обсудим состав и механику работы нашего ЦК, продуктовые команды, а также немного подискутируем на тему тестирования в целом — каким оно будет в будущем, как на него повлияет ИИ и автоматизация.
Из чего состоит центр компетенций и для чего он нужен
Центр компетенций (далее ЦК) — это прежде всего люди, технологии и стандарты. В нашем ЦК сейчас работают 140+ человек:
инженеры из продуктовых команд, обеспечивающие качество наших продуктов;
эксперты, развивающие наш технологический стек;
кураторы, помогающие командам внедрять лучшие практики.
Кураторы не всегда входят в классический ЦК, так что расскажу, чем они занимаются у нас.Их работа затрагивает несколько областей:
взаимодействие с процессами и сотрудниками своей компетенции в конкретной команде;
работа внутри нашего департамента, которая позволяет нам двигаться в нужном направлении и развиваться как центр компетенции.
Нужность кураторов в нашем случае подчеркивается и тем, что у нас есть Кафедра — мы набираем на нее молодых специалистов, это возможность для новичков войти в IT с нуля под руководством экспертов.
В ЦК есть инженеры, которые занимаются мобильным тестированием, тестированием веба, десктопа, баз данных и 1С-систем. Соответственно, для каждого направления у нас есть свой инструментарий, который отражен в нашем техрадаре. Есть собственные фреймворки для автоматизации тестирования веба и мобильных приложений, чтобы нашим сотрудникам было легче стартовать автоматизацию на своих продуктах, не изобретая каждый раз что-то новое. Также у нас есть ферма физических устройств, эмуляторов для тестирования наших мобильных приложений.
Кроме Кафедры, внутри ЦК есть своя Јаѵа-школа (это наш основной стек). Сотрудники могут пойти учиться в нее, чтобы начать свой путь в автоматизации. Первые два потока прошли очно, но сейчас мы перешли к видеоформату обучения и мини-курсам.
Стандарты и цели центра компетенций
У нас в ЦК описано достаточно много разных практик и подходов, но я всегда всем говорю, что стандарта именно как регламентов у нас их всего лишь два:
Положение о работе с дефектами, где мы регламентируем, как команда должна работать с возвратами и дефектами, найденными на разных этапах создания продукта;
Паспорт качества – это документ, в котором описаны и зафиксированы все договоренности команды.
Перед ЦК стоят четыре главные цели:
Обеспечение команд кадрами — найм или ротация подходящего кандидата.
Развитие и поддержка инструментов, практик и стандартов для обеспечения
качества. Регулярный мониторинг отрасли, проведение R&D.Обучение и развитие наших сотрудников. База знаний по инструментам и практикам, индивидуальные планы развития, one-to-one c сотрудником.
Кураторская экспертная поддержка команд. Конкретно сейчас — развитие нашей основной системы для ведения тестовой документации, регрессионное тестирование, создание методики по работе с регрессом, а также дашбордов с метриками.
Что там вообще в мире тестирования
Чтобы узнать о трендах в отрасли, достаточно открыть сайт любой профильной конференции профильной из SQA, Гайзенбаг и посмотреть на какие темы там разбиваются там доклады. Обычно вы там найдете применение лучших практик (best practices), автоматизацию, безопасность, нагрузку, как узконаправленные треки.
Эти тренды еще будут долгое время актуальными просто потому, что практики и процессы люди могут использовать немного иначе и получать немного другой результат, о которых тоже хочется людям порассказывать.
Лично я бы выделил следующие:
ИИ. Он, кстати, сейчас тоже появился как отдельный трек на многих профильных конференциях. Например, тестирование с автоматизацией как-то отпочковалось в отдельный тренд. Сначала тема выглядела хайпово, даже очень хайпово. Но сейчас кажется, что технологии начали догонять вот эту вот шумиху. Да, модели ошибаются, они решают далеко не все задачи, результаты их нужно верифицировать. Но если отмечать тот прогресс, который произошел в последнее время — это довольно мощный инструмент, который на многие индустрии повлияет.
Информационная безопасность. Кибератаки у нас становятся частым явлением, даже регулярным, то видно, что компании стали уделять больше фокус на безопасности. То есть стали уделять больше внимания таким аспектам, как тестирование приложений на проникновение, анализ уязвимостей, работа с безопасностью данных. То есть в компаниях идет планомерная работа над культурой безопасности и соответствием неким требованиям и стандартам этой самой безопасности.
Shift left и shift right подходы. Shift left – раннее вовлечение тестировщиков в процесс разработки, то есть тестируем требования, код, архитектуру до этапа реализации. А shift right – фокус на постпродакшене, где мы мониторим работу продукта, анализируем различные метрики.
Какой будет автоматизация в тестировании в ближайшие годы
Думаю, грань между ручным тестированием и автоматизацией будет понемногу стираться — этому будет способствовать ИИ. Уже сейчас мы видим, что он вполне может выполнить действие в браузере от начала до конца (например, выбрать товар, положить в корзину, оформить заказ).
В этом году мы в ЦК строим цифровой Дневник по автоматизации. Это дашборды в Графане, у нас туда подключены все команды, где автоматизацией занимаются тестировщики. Мы можем наблюдать результаты прогонов тестов за конкретный период, их длительность, прирост тестов. И на основе этого мы можем понимать, что в команде происходит автоматизация и как команде можно помочь со строением автоматизации.
До конца года мы планируем туда подтянуть метрики по юнит-тестам, чтобы все, что касается тестирования, мы могли видеть в одном пространстве.
Важно: чтобы тесты приносили реальную пользу, чтобы автотесты не писались ради автотестов, не жили отдельно от команды, регулярно запускались, команда должна доверять этим автотестам. То же самое и с юнит-тестами: хочется, чтобы они приносили пользу, а не становились со временем неподдерживаемой обузой, которую могут и отключить. На юнит-тесты мы тоже обратили внимание, смотрим за взаимодействием разработчиков и тестировщиков. У нас появился отдельный чат и курс для разработчиков по юнит-тестированию.
Три типа самых важных метрик
Если говорить именно про оценку качества как один из критериев успешности проектов, то заказчик обычно это самое качество ожидает. И оценивает он уже его не столько сам, сколько со слов пользователей — насколько продукт безопасен, прост в использовании, надежен, удобен.
При оценке же качества тестирования мы ориентируемся на три типа метрик (не на три метрики, а именно на три типа):
test coverage, или покрытие тестами, т.е. мы смотрим, как у нас покрыты критические пути тестовыми кейсами;
количество дефектов — сколько нашли, а сколько прилетело в команду от службы эксплуатации уже инцидентами. То есть мы стараемся оценивать соотношение, например, сколько багов мы нашли внутри команды и сколько пропустили на продакшн за определенный промежуток времени;
Ну и третий тип метрики — это время, затраченное на тестирование.
Они дают нам основу, куда копать дальше. Потому что метрики – это всего лишь индикаторы, и они полезны в комплексе. Это просто инструмент в помощь.
Когда аналитики сами проводят тестирование
Иногда бывает и такое, и вот почему.
Последние два года наш ЦК рос на 35-40% от года к году. Когда другие компетенции разбирали сотрудников команд, которые до этого работали в отделах, то есть другие ЦК фактически пополняли сотрудниками из отделов, то там тестировщиков просто не было. Поэтому ЦК рост только за счет найма с рынка — мы просто не успели нанять во все команды, как пример, банальные зоны логистики. Туда мы продолжаем искать и переводить сотрудников.
А ещё в некоторые команды просто нет целесообразности нанимать тестировщиков — у них там не будет работы на полную ставку, поэтому проверки по критическим путям и ассертным критериям обычно делает аналитик (а в некоторых командах еще и разработчики помогают автоматизировать).
Мне кажется, что обеспечение качества — это задача всей команды. Поэтому в тех командах, куда еще не пришел тестировщик, спасибо аналитикам, что на этапе тестирования они занимаются обеспечением качества и, собственно, самим тестированием. Если коллегам нужна методологическая помощь, они всегда могут обратиться за ней в наш ЦК.
Планы на будущее
Всё просто — следим за трендами и делаем ставку на постепенные и устойчивые улучшения. Но если говорить про ближайшие шаги, то мы будем фокусироваться на эволюционном развитии, то есть повышать экспертизу сотрудников через общие клубы, воркшопы по автоматизации, внедрять технологии и автоматизацию, которые будут так или иначе снижать долю рутины у нас в командах, развивать процессы внутри команд, чтобы помогать командам делать свою работу быстрее.
Может, немного расширим Кафедру и сможем туда принимать большее количество талантливых коллег.
Кстати, отмечу занятный тренд — раньше часто попадали в ІТ именно через тестирование. При поступлении к нам на кафедру опыта тестирования у кандидата может и не быть, но базовые знания IT у кандидатов мы хотим видеть.
Будем развивать наши внутренние библиотеки, которые помогают писать автотесты. Уже в этом году мы будем делать вторую версию фреймворка GEFEST для автоматизации веба, куда войдут различные улучшения. Вторая история — сейчас в одной из десктопных команд проходят исследования и разработки по автоматизированному тестированию десктопа. Пытаемся мы это сделать при помощи инструмента Appium, если оно будет успешным, мы попробуем в следующем финансовом году ее тиражировать уже на другие десктопные команды.