Зачем вообще нужно тестирование в команде

Как и зачем проводить тестирование персонала

Проверка знаний сотрудников является ключиком на пути к успеху во многих компаниях. Чаще всего для этого применяется система тестирования.

Как говорил один известный государственный руководитель, кадры решают всё. Тестирование сотрудников помогает понять, кто в компании знает, как правильно выполнять свои функции. А также гарантирует, что сотрудники будут читать регламенты более внимательно.

Расскажем зачем нужно тестирование знаний сотрудников и как его проводить.

Зачем тестировать персонал

Если обучение и тестирование персонала организованы эффективно, бизнес получает компетентную и мотивированную команду, которая приносит прибыль.

Рассмотрим какие задачи помогает решить тестирование сотрудников компании.

Контроль эффективности обучения

Организация тестирования сотрудников показывает как хорошо сотрудники усваивают материал и как хорошо организовано обучение. Тем более, что на него тратятся деньги и время время компании, а значит, хорошо бы понимать его эффективность.

Тест выявит, какой материал команда усвоила, а какой нужно повторить. Например, помнят или нет сотрудники отдела продаж, как работать с конкретными возражениями клиентов или как выходить из затруднительной ситуации.

Выполнение регламентов

Когда компания вводит обязательное тестирование сотрудников, то люди автоматически начинают изучать документы гораздо внимательнее и лучше запоминают инструкции. Если тестирование не проводить, то регламенты так и остаются лежать формальным цифровым грузом в базе знаний компании.

Повышение и ротация сотрудников

Перед тем, как повысить сотрудника или перевести его на другую должность, попробуйте его протестировать. Если вопросы для тестирования составлены правильно, вы получите цельную картину по компетенции и способностям. В зависимости от результатов руководитель сможет принять решение, основанное на реальных данных, а не на интуиции.

Как проводить тестирование персонала

Тестирование нужно организовать так, чтобы его результаты показали реальный уровень знаний команды. Рассказываем, как этого добиться.

Сформулировать задачи тестирования

Тестирование проводится под конкретные задачи. Например, если нужно оценить как хорошо копирайтеры понимают особенности продукта, чтобы писать о нем статьи. Или, знает ли HR-команда ценности компании и критерии найма.

Иногда тест проводят перед обучением, чтобы понять тот уровень знаний, которым уже обладает команда. Например, тренеров фитнес-центра проверяют, насколько они погружены в тему по спортивному питанию. Это позволит не объяснять азбучные истины.

Сформулированные задачи тестирования помогают задать вопросы, ответы на которые важны руководителю. Если клиенты автосалона регулярно жалуются на ремонт двигателей, то стоит проверить насколько хорошо автослесари разбираются в особенностях тех или иных моделей. Нет смысла перегружать этот же тест вопросами про тормозную систему.

Подготовить материалы для теста

Удобнее всего проводить тестирование на основе регламентов и инструкций. Например, в компании по производству мебели есть регламенты для работников цеха, где прописано, какие материалы нужно использовать для создания столов, стульев или диванов, а также какой обработке они подвергаются и как собираются.

Тестирование на основе регламентов не займёт много времени. Особенно если все процессы автоматизированы.

Автоматизировать тестирование

Удобно, когда регламенты и инструкции находятся в специальном сервисе. Тогда на их основе можно подготовить тестовые вопросы. Сотрудники изучают материалы регламентов и сразу проходят тест. А у сервиса Platrum есть ещё одна уникальная опция: спустя заданное время программа тестирования сотрудников автоматически генерирует тест на основе материалов, которые когда-то читали сотрудники и высылает его сотрудникам. Так команда всегда находится в тонусе и поддерживает актуальные знания.

Выбрать методику тестирования

Тесты могут быть в виде вопросов или решения рабочих задач. В тестах с вопросами можно выбрать один или несколько правильных ответов. Либо указать верно/неверно написанное утверждение.

Тесты в виде рабочих задач предлагают решить не типичные, сложные ситуации. Это может быть открытый вариант, когда сотрудник описывает, как бы он поступил в данной ситуации или варианты ответов. Например, специалисту по «холодным» звонкам, нужно выбрать, как нужно поступить, если клиент хамит.

Проводить тестирование регулярно

Тестирование нужно проводить не разово и не от случая к случаю. Чтобы поддерживать знания и компетенции сотрудников, проводите тесты регулярно. В зависимости от специфики их работы это может быть раз в неделю, месяц или в квартал. С таким подходам сотрудника не получится один раз изучить регламенты, а потом их успешно забыть. Придется как следует запоминать нюансы, связанные с работой.

Проводить пробное тестирование

Чтобы отработать методику тестирования, сначала проведите его для части сотрудников. Например, проверьте знание политики и миссии компании сначала в одном отделе. Посмотрите результаты, соберите обратную связь. Это позволит выявить недостатки системы тестирования и исправить их перед внедрением во всех отделах фирмы.

“Пропиарить” тестирование

Расскажите, почему в компании внедряют тестирование и почему это важно. Например, в компании упали продажи, что влияет на зарплату самих же сотрудников. Тестирование поможет выявить пробелы в знаниях менеджеров или упущения в скриптах продаж и исправить это.

Донесите до сотрудников выгоду тестирования. Например, увеличение зарплаты, если она привязана к продажам. Также это может быть бонус для сотрудников всего отдела, если они пройдут его первыми и с минимальным количеством ошибок.

По итогам тестов можно составлять рейтинги и поощрять лучших.

Когда сотрудник видит, что его коллеги успешно справились с тестом, он получает мотивацию и самому не отставать.

Тестируйте не только рядовых сотрудников, но и руководителей отделов и топ-менеджеров. Это покажет всей команде, что тестирование действительно важное дело.

Как выбрать сервис тестирования сотрудников

Проводить тестирование на бумаге конечно можно, но в век сервисов и платформ будет выглядеть немного странно. Хотя, уж лучше проводить его так, чем вообще никак.

Благо разработчики всех мастей предлагают разнообразные сервисов для обучения. При выборе такого сервиса изучите функционал. Например, в инструменте обучения и тестирования Platrum есть много “фишек”.

1. База хранения регламентов связана с системой обучения и тестирования. Поэтому тесты можно проходить сразу после прочтения регламентов и не нудно переходить в другую систему.

1. Онлайн тестирование можно автоматизировать, задав определенный промежуток времени. Например, все менеджеры по продажам проходят тест на знание скриптов каждые две недели.

1. Есть отчёты о результатах тестирования. Руководитель видит кто, когда и с какими результатами прошёл тесты, а кто их проигнорировал.

1. Система напоминает сотрудникам о непройденных ими тестах и даёт возможность руководителю устанавливать дедлайны.

1. Сервис заблокирует метрики сотрудника, если они не прошли тестирование. А как известно, показатели влияют на заработную плату.

1. Platrum не откроет для изучения новые материалы, пока сотрудники не справились с тестами по предыдущим. При этом даёт время снова изучить материал, по которому тест был провален, чтобы потом сдать его повторно.

Чтобы понимать как хорошо сотрудники знают особенности работы в компании, без тестирования не обойтись. Современные цифровые технологии помогут его и настроить, и провести. При этом выбирайте сервис с большим функционалом, чтобы на одной платформе можно было и хранить знания, и обучать и тестировать при полной автоматизации всех процессов.

Зачем вообще нужно тестирование в команде

Чем занимаются тестировщики и почему они так нужны? Какой карьерный рост возможен для тех, кто выбрал эту специальность? Старший тестировщик Дмитрий Лебедев и выпускник тренинг-центра EPAM Александр Поздняков рассказывают о том, что такое тестирование на самом деле. Давайте разбираться!

Тестирование – это интересно?

Тестирование – многогранный и очень интересный процесс. У начинающего специалиста здесь есть большой выбор возможностей развития. Например, можно развиваться в направлении тестирования Backend’a, то есть скрытой от глаз пользователя части ПО. Или можно погрузиться в тестирование User Interface – той части системы, через которую пользователь взаимодействует с приложением. Может быть, вам больше нравится тестировать игры? А может, душа лежит к нагрузочному тестированию? Или хочется почувствовать себя «хакером» и уйти в тестирование безопасности? В тестировании возможно всё!

Почему тестировщики так нужны?

Допустим, мы разрабатываем приложение на основе E-learning для учащихся младших классов. Представьте, что будет, если мы пропустим этап тестирования и предоставим наше приложение школам «как есть». Школьники, вооружившись пытливым умом, будут испытывать приложение на прочность, кликая на все кнопки. Например, они заблокируют учителя в голосовом чате, что приведёт к срыву урока. Если бы мы более ответственно подошли к тестированию приложения с точки зрения функций, которые оно должно выполнять и заранее продумали ограничения, такого бы не случилось.

Что делает тестировщик на проекте?

Роль тестировщика на проекте заключается в том, что он проверяет результат работы всей команды (разработчиков, системных инженеров, бизнес-аналитиков). В частности, он проверяет соответствие разработанного программистами приложения предъявляемым требованиям. Иными словами, тестировщик – это условный «универсальный солдат», который должен понимать не только как работают отдельные части приложения, но и как система ведёт себя в целом; а также, как изменения в одном модуле могут повлиять на работу всего приложения. Не менее важная задача тестировщика – понимать и оценивать требования к приложению с точки зрения их реализуемости.

А можно поконкретнее?

Давайте представим гипотетическую ситуацию, что наша команда разрабатывает WEB-ориентированное приложение, нацеленное на продажи. У нашего приложения будет корзина, в которую пользователь должен иметь возможность добавить продукт. Как определить, что реализованный модуль соответствует нашим ожиданиям? Как понять, что пользователь действительно может добавить товар в корзину? Мало того, пользователь должен иметь возможность оплачивать товар, а значит, нам нужно взаимодействовать со сторонними сервисами, позволяющими проводить оплату. Как нам убедиться, что взаимодействие пройдёт успешно? Это всего лишь один сценарий взаимодействия с корзиной, а их должно быть значительно больше. Вот тут и проявляется наибольшая польза от работы тестировщика.

Пример из жизни: у всех дома есть ножницы и основная функция ножниц – разделять один объект из ткани или бумаги на два. Это ожидаемое поведение нашей системы. Смыкая лезвия ножниц, мы получаем реальное поведение системы. Если ножницы с момента выпуска с завода не режут бумагу, а только создают заломы, то они не выполняют свою функцию, а значит реальное поведение системы не соответствует ожидаемому.

Кто вы, мистер Тестировщик?

Тестировщик – это человек, который обеспечивает качество разрабатываемого продукта. Он сопоставляет требования и реализованное приложение, сравнивая их на предмет отклонений. Он может тестировать как целую систему, так и её малую часть.

Определения

Итак, мы переходим к обзору основных понятий, используемых в тестировании ПО. И начинается наш обзор, как ни странно, с вопроса «А что же такое тестирование ПО?

Тестирование ПО – это процесс исследования, испытания программного продукта, целью которого является проверка соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005).

Определений тестирования ПО существует много, рассмотрим ещё одно:

Тестирование ПО – это один из методов контроля качества, процесс анализа ПО, направленный на выявление степени соответствия ПО требованиям.

В свою очередь, контроль качества – это система мер для обеспечения соответствия требованиям и ожиданиям (ISO 9000:2005). Контроль качества включает в себя тестирование, прототипирование, инспектирование кода и некоторые другие методы.

Как вы можете заметить, во всех трёх определениях встречается такой термин, как «требования». Какие требования? Для чего они нужны? Зачем они вообще существуют? Если вкратце, то с точки зрения тестирования, требования помогают инженеру по качеству сосредоточиться на конкретных задачах. Отметим также, что тестирование – это бесконечный процесс, и протестировать всё физически невозможно.

Кому подходит тестирование?

В описании многочисленных вакансий (да-да, рыночный спрос здесь стабильно высокий) на позицию «Тестировщик ПО» всегда можно встретить «внимательность к деталям», «скрупулёзность», «ответственность» и т.д. Однозначно, это очень важные характеристики. Мы лишь дополним этот список ещё несколькими качествами, которые точно необходимы первоклассному специалисту в тестировании:

Хороший тестировщик – это тот, кто:

• умеет общаться с людьми и работать в команде;
• не боится уточнять детали, даже те, которые на первый взгляд кажутся очевидными;
• всегда готов разобраться в новой для себя предметной области.

Какие пути есть в тестировании?

Как уже было сказано выше, тестирование ПО – это многогранный процесс, и в нём всегда есть место развитию.

Например, если команда разрабатывает приложение под разные версии операционных систем, браузеров или иных платформ, то тестировщику необходимо обладать навыками тестирования совместимости (Compatibility testing). Или, например, команда разрабатывает мобильную версию приложения, тогда необходимо заняться Mobile testing. А возможно, вы умеете упрощать себе жизнь, оформляя рутинные задачи в коде? Тогда вам подойдет Automated testing.

А как же карьерный рост? Кем можно стать после уровня Junior?

Для тестировщиков (как и для разработчиков) есть много карьерных возможностей в компании. Он, как и любой другой технический специалист, может расти от Junior-специалиста до Lead-специалиста.

Например, в EPAM, можно стать и техническим лидом (Tech Lead), и Delivery Manager (DM), и ресурсным менеджером (RM). Опыт работы в тестировании будет значительным преимуществом, если развитие в одной из перечисленных ролей является для вас приоритетным. Более того, работа тестировщика не менее ответственная, чем работа разработчика, и оценивается она так же высоко.

Подводим итоги

Тестирование – это одно из стремительно развивающихся направлений с высоким спросом на рынке IT. Тестировщики востребованы в самых разных сферах бизнеса (автомобилестроение, E-learning, E-commerce, Life Sciences и т.д.), а внутри самого направления вы найдёте много разных возможностей для развития – от Mobile Testing до Data Quality. Таким образом, став специалистом по тестированию, вы сможете повышать свои компетенции в совершенно разных областях, выбирая подходящее направление для карьерного роста!

Тестирование — это не «простая точка входа в ИТ». Мифы разрушает Артём Русов

Меня зовут Артём, уже более трёх лет я занимаюсь обучением начинающих тестировщиков. Недавно у меня была установочная сессия с командой разработки, которая хотела взять моих студентов для тестирования своего пет-проекта. Проблема была в том, что продукт разрабатывался, но сама команда вообще не понимала, как его тестировать, потому что раньше они не сталкивались с QA-отделом и сами пилили автотесты. Это были простые высокоприоритетные позитивные и негативные кейсы, без применения тест-анализа и тест-дизайна.

Откуда взялся миф о «простой» профессии?

Думаю, многие из вас видели рекламные объявления очередного курса, где обязательно есть фраза: «Тестирование — это самая простая точка входа в айти».

В нулевые и в начале 10-х я бы мог поддержать это утверждение, так как раньше для того, чтобы найти работу тестировщиком, было достаточно прочитать научно-познавательную книгу Романа Савина, хорошо знать английский язык и уметь находить баги на графическом интерфейсе. Всему остальному учили уже на месте.

Думаю, именно тогда и зародился стереотип, который подхватили нерадивые маркетологи и стали активно использовать в рекламе известных, но бесполезных курсов.

Кто такой «тестировщик» на самом деле?

Времена меняются. Сегодня можно выделить далеко не одно направление в тестировании: ручное, автоматизированное, тестирование нагрузки и безопасности, SDET, embedded testing и другие. Большое количество возможностей для горизонтального и вертикального роста.

От соискателей ожидают увидеть типовой набор компетенций: фундаментальные основы тестирования, умение создавать эффективные кейсы, используя техники тест-дизайна, понимание аспектов тестирования WEB и Mobile, где дело не ограничивается только GUI, но также включает API (а это уже backend), тестирование баз данных и базовые навыки TestOPS.

Это работа с несколькими десятками инструментов, которые опытный специалист умеет использовать в разных условиях для разных видов тестирования.

Хороший тестировщик отлично разбирается в методологиях разработки, а главное в бизнес-логике самого продукта.

Он находится на стыке всех направлений: бизнес-анализ, дизайн, разработка, продуктовый менеджмент и ведёт большое количество коммуникаций с каждым из отделов.

И это мы говорим только про процессы тестирования и контроля качества, а ведь самое интересное начинается на этапе Quality Assurance, где QA Engineer начинает улучшать текущие процессы и предлагать эффективные методы повышения качества выпускаемого продукта, влияя не только на свой отдел, но и на всю команду и разработку. Ведь самое главное в обеспечении качества не нахождение багов, а их предупреждение.

Почему-то многие об этом забывают и создают очередной миф, где тестировщики только и делают, что находят ошибки в приложениях.

Особенно неприятно, когда тестировщиков называют monkey тестерами. Данный вид тестирования предполагает ввод случайных значений, нажатие случайных кнопок, без понимания того, как работает система.

Почему тестировщики, с которыми вы работаете не относятся к категории таких «специалистов»?

В реальности большинства компаний, тестировщик подключается к работе на этапе анализа требований, где досконально изучает работу приложения и на основании полученной информации создает тест-кейсы или чек-листы. И только после этого он приступает непосредственно к тестированию, где использует не только Frontend и открытую страницу в браузере, а отправляет запросы через API, проверяет данные внутри БД, перехватывает трафик и анализирует его, создает различные тестовые случаи, полагаясь на тест-дизайн и свой опыт работы с разными приложениями.

Почему для меня тестирование — не просто работа

Для меня тестирование — это скорее стиль жизни. Ты являешься флагманом качества на проекте, помогаешь, как команде в части улучшения продукта, так и клиенту, который хочет работать в жизнеспособном ПО.

Мне посчастливилось работать с людьми, которые прекрасно понимали, что все стереотипы и мифы о профессии «тестировщик» не имеют никакого смысла, поэтому в данной статье хотелось бы еще раз напомнить сообществу, что мы полноценная боевая единица, готовая помогать.

И да, возможно это признание и является ключевым фактором, почему я продолжаю работать и развиваться в этой сфере.

Если ваша команда не понимает, что делает тестировщик

Коллегам, которые сталкиваются с недопонимаем в команде их роли, я настоятельно рекомендую вводить в расписание встреч knowledge sharing meeting, где вы можете рассказать про:

• ключевые функции тестировщика;
• чем он занимается;
• почему важно всем включаться в процесс обеспечения качества;
• и как вы можете быть полезны команды.

Не бойтесь включаться в такие процессы, иначе мы будем продолжать встречаться со стереотипами о тестировании, которые нужно будет разрушать!

Мнение автора может не совпадать с позицией редакции.

dev.by, как и другим честным медиа, сегодня очень сложно: редакция работает за пределами страны, а наши рекламные доходы сократились в несколько раз. Но мы справляемся — с вашей помощью. Это вы делитесь с нами инфоповодами, мнениями, опытом, временем и вниманием. А 220 читателей поддерживают нас донатами.

В 2023 году мы хотим собрать 1000 читателей-подписчиков.

Что ещё почитать про стереотипы:

• Стереотипы о Польше, которые вам расскажет каждый, кто никогда здесь не жил;
• «Работа для девочек из иняза?» Бизнес-аналитик разбирает стереотипы о своей профессии;
• «Нет, я не кайфую от отказов». Рекрутер разбирает претензии айтишников.

Текст: Отдел новостей Теги: blog, стереотипы, тестирование

Нашли ошибку в тексте-выделите ее и нажмите Ctrl+Enter. Нашли ошибку в тексте-выделите ее и нажмите кнопку «Сообщить об ошибке».»

Читайте также
Какие курсы по тестированию пройти. Для новичков и специалистов (май, 2023)

Профессия тестировщика стала одной из самых востребованных для входа в IT в последние несколько лет. Поэтому мы собрали эту подборку, чтобы вы знали, где на какие курсы тестировщика пойти в 2023 году и какую образовательную платформу выбрать для обучения.

Как сделать тестовое и не стать бесплатной рабочей силой? Обсуждение

Работодатели отсеивают «пожилых» соискателей ещё на этапе составления вакансии — с помощью эйджистской лексики

Российская ОС «Фантом» через 12 лет разработки вышла на этап тестирования

Хотите сообщить важную новость? Пишите в Telegram-бот

Главные события и полезные ссылки в нашем Telegram-канале

Обсуждение
Комментируйте без ограничений

Релоцировались? Теперь вы можете комментировать без верификации аккаунта.

6 июля 2023, 20:39

Разработчики нашли к кому обращаться. Чувак сам курсы закончил только в 2018 году, года 3-4 прыгал из компании в компанию, таких прыгающих нанимать не любят, теперь преподает, сам не знает что такое анализ инфы (ну или просто ему деньги платят что б на компании наезжать) но учит других наверное, еще хуже если не учит, ) Другое дело Ксендзов, тот знает свое дело, я бы только к нему а не этих блохеров.. Анализируйте спецов к которым идете учиться и с которыми хотите сотрудничать

6 июля 2023, 21:14

Да Русова за эксперта никто не считает, в чем экспертность. сделать курс, каких сейчас сотни? Он даже в совем тг канале просто выкладывае постоянно чужие материалы, своего ничего не пишет и не делает

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 00:04

Очень громкие слова, которые было бы здорово подтвердить.

Я не буду здесь обсуждать деятельность Вадима и конкретно подходам к его обучению, все есть в открытом доступе в отзывах, поэтому все могут с ними ознакомиться. Есть куда более авторитетные ребята, на которых можно равняться.

Не стоит говорить за всех, кто не считает или считает меня экспертом. У меня достаточно большая аудитория, в том числе из нанимающих менеджеров, которые ценят вклад в собщество и приходят за рекомендациями. Я скорее буду доверять им, чем какому-то ноунейму из комментариев.

У меня больше сотни часов авторского видео-контента, свои статьи в социальных сетях и крупных изданиях из сферы. О каком использовании чужих материалов идет речь? У меня есть есть пару ТГ-каналов, в которых я собираю статьи и полезные ресурсы для подписчиков, которые использую сам. Это вполне нормальная практика делиться ими с сообществом.

Мой опыт открыт и понятен. Я более 8 лет работаю в области обеспечения качества, 4 из которых занимаюсь тестированием. У меня есть высшее образование, которое в том числе дает мне право преподавать.

С чем я точно согласен, так это с тем, что преподавателя и школу нужно выбирать, изучать профили в LinkedIn, не идти к первому встречному. У меня все открыто и прозрачно для аудитории.

Дмитрий Иванов ФРилансер в Global Freelance
7 июля 2023, 12:25

А чего? Нормально. Я через 3 года работы стал сеньором, мог бы через год свои курсы открыть. Чувак просто взял и сделал.

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 14:58

Так я и не открывал курсы, что самое интересное. Фактчекинга в комментарии выше нет никакого. Полноценные коммерческие курсы у меня появились в конце 2022 года, а это спустя три года моего старта в профессии.

Тот же Вадим начал обучать людей на курсах, имея за плечами 2 года опыта. В общем, странный тейк.

7 июля 2023, 14:58

хахах, боже какая дичь, чего собственно ожидать от, [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] сразу стал придумывать про людей которые к нему за рекомендациями приходят, любой толковый менеджер откроет твое резюме, поржет и скажет [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] тебе ничего не остается как выдумывать истории несуществующие и вывозить какие-то щит новости и лезть в чужое белье [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] но знай, чел, тебя никто никогда не признавал никаким гуру тестировщиков, [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement], лучшеб тестировать научился а не заводить пыль людям в глаза

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 15:03

чел. ты смешон) сколько тебе лет?

7 июля 2023, 15:08

отдыхай хлопчик, я думаю сообщество таких как ты и так выдавит, [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]

7 июля 2023, 19:17

«Я более 8 лет работаю в области обеспечения качества» — я тогда когда бутылки собирать буду, тоже припишу себе опыт к коллекционеру это же из 1 места да? Как и ты 8 лет в обеспечении качества, зачем врать и трактовать инфу как себе удобно, зачем пороть чушь людям и откровенно врать, позор тебе и твоим словам, просто фу!

mishka dev в Galera
8 июля 2023, 00:25
7 июля 2023, 14:53

Да какие 2018, чекните хистори изм его резюме, этот чел 20 раз менял данные о себе, у него 3 года опыта ну может чуть более и 3 года он кого-тот учит переведенными статьями с разных форумов, это просто сюр читать эту литературу чела который абсолютно ничего сам своими руками не сделал кроме как начитался литературы легаси и подумал, что он гуру тестирования и что-то может пояснять от лица тестирования

8 июля 2023, 08:22

Кто работать умеет, тот работает. А кто не умеет — тот только других учит. Ничего нового.

8 июля 2023, 09:40
7 июля 2023, 14:45

У чела 3 года опыта, он 3 года занимается обучением челов чему сам еще не силен, что за waaat, просто дев бай на [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] собирает просмотры

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 14:55

Если для обучения новичков, вам нужен послужной список в 5+ лет опыт и более, то у меня для вас новость: менторы в большинстве компаниях, которые приставлены за джунами и интернами имеют опыт от одного года.

Да и коммерческим обучением я занялся только с опытом в 3 года. До этого просто пилил видосики на ютуб, которые помогли многим ребятам разобраться в фундаментальных знаниях для освоения этой профессии.

7 июля 2023, 15:01

Можешь маме рассказать кому ты и чем помог, а в профессиональное сообщество приходи с фактами и реальными статьями которые помогут, [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]

7 июля 2023, 14:48

Когда меня представили, один из разработчиков сказал: «А зачем нам вообще тестировщики? Ведь они просто нажимают на кнопки и ничего полезного не делают». — челы на опыте которые залетят после этого [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] тупо не будут читать этот щит, чел не позорь плиз нашу профессию, лучше иди про обезьяний жир там пиши статьи или про муровьев, что угодно, но то, что ты делаешь это просто оскорбление всего QA сообщества [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] который выдумывает несуществующие проблемы для самопиара

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 14:59

Ничего не понял, но очень интересно 🙂 Удачи вашему выдуманному сообществу тестировщиков, частью которого, видимо, я не являюсь, так как у меня абсолютно другой круг общения 🙂

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 14:53

Я думал, что такое количество токсиков можно встретить только на Хабре.

Пользователь отредактировал комментарий 7 июля 2023, 14:53

7 июля 2023, 14:59

какой круг общения, [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]?))

7 июля 2023, 15:02

ну посмотрим сколько ты тут «токсиков» встретишь к своему «творчеству» краденой инфы)

7 июля 2023, 18:49

Неприятненько оказалось получить настоящий фидбек о всей этой псевдодеятельности и обозвать всех «токсиками», это ведь не закрытые комменты на ютубе и ограниченные положительные реакции в тг канале��

7 июля 2023, 19:15

Вы вообще видите что он пишет «Я более 8 лет работаю в области обеспечения качества» — это на столько оскорбительно, что он работал на хайнакене просто проверятелем бутылок и он это записывает в 1 шлейф с «обеспечением качества» и он сам в это верит

keep-walking
7 июля 2023, 18:52

То чувство, когда помнишь этого парня со сцены биотеатра..

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 21:02

Было дело 🙂 Хорошее время

7 июля 2023, 21:38

Комментарий скрыт за нарушение правил комментирования.
[censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]

7 июля 2023, 20:06

«Деды в курятнике начали возмущаться — а что, так можно было?»

Артём и не утверждает, что он эксперт.

Если кому-то его курсы помогли разобраться в теме тестирования ПО (получить начальные знания) и даже найти работу, то в чём тут проблема Артёма?

Я вижу что Артём как минимум делает эти вещи:
1)делится знаниями с другими (преимущественно с новичками, которые хотят войти в ИТ)
2)создаёт комьюнити для тех кто интересуется темой тестирования ПО
3)повышает visability себя на рынке как специалиста (это просто значительно облегчает найм самого себя в какую-нибудь контору при нормальном рынке труда и при условии, что собеседующий не идиот)
4)ну и наконец курсы самого себя намного-намного лучше чем дополнительно преподавать в какой-нибудь ИТ школе (во первых заработок намного больше; во вторых нет смысла развивать чужой образовательный бренд и работать/подрабатывать на дядю, когда всё то же самое можно делать работая на себя; в третьях учитывая, что образование с очных классов сместилось в онлайн формат, разницы между работой на дядю и на себя почти нет; в четвёртых нужно и можно развивать в себе качества продажника, переговорщика, PR и так далее, при работе в ИТ школе этого не будет)

Всё это намного лучше чем хейтить других в интернете.

Пользователь отредактировал комментарий 7 июля 2023, 20:06

7 июля 2023, 21:37

Вы выгораживаете откровенного лжеца который врет про свой опыт и просто переводит статьи с другого языка, просто включите крит мышление и холодно посмотрите на ситуацию. А еще вы видимо мало знакомы с его последними статьями где он совсем не о тестировании башляет и использует просто чужие статьи, Вопросов вцелом если башлять и просто молча это делать нет, но он выплескивает свое абстрактное мышление в сеть, где люди имеют свое мнение, а как бы мнение данные [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] не особо любит поэтому крайне ограничивает его на любом пространстве, да я даже не удивился бы если он сам и написал бы себе этот коммент

7 июля 2023, 21:50

Особенно интересное visability получается, когда знаешь результаты одного из его собеседований от шаряшего лида, которое до сих пор обсуждается в кругах, где не ограничивают комменты и реакции))

Пользователь отредактировал комментарий 7 июля 2023, 21:50

Артем Русов QA Tutor в Artsiom Rusau QA Life
7 июля 2023, 22:48

Было бы здорово увидеть:

А. Контакты лида, который это рассказывал. Буду рад еще раз пройти с ним интервью, если он захочет и будет установлено, что мы с ним общались. Последние интервью я проходил в 2021 году и почти все они заканчивались оффером.
Б. Оригиналы статей, которые я оказывается перевожу и выдаю за свой контент. Если вы их найдете, то без проблем обсудим.
В. Доказательство того, что я вру про свой опыт. Я могу подтвердить все места работы, если нужно с рекомендациями 🙂
Г. Доказательство того, что комментарии, которые якобы есть моих соцсетях закрыты, хотя они и открыты для всех желающих. Не помню там ваши изречения, а если они были в ключе жирного кабана, то обычно они удаляются, так как оскорблять других людей никто не имеет права.

Если захотите это обсудить, то мои контакты можно найти в любых соцсетях, где вещаю.

А пока это просто слова очередного тролля из интернета, который надеется быть услышанным.

Ладно, я могу представить себе ситуацию, когда могут быть причины не любить меня из-за того, что кому-то кажется, что у меня недостаточно опыта или из-за личной неприязни.

Но тратить весь день, здесь в комментариях, перевирая факты и делая акцент на моей внешности, это дорогого стоит.

Надеюсь, что это приносит вам только позитивные эмоции и вы себя самоудовлетворили, используя комментарии, которые мало кто прочитает.

А пока я продолжу заниматься своим контентом, для аудитории, которая считает его полезным.

8 июля 2023, 09:31

Почитал твой комментарий и очередной раз убедился какой ты ребенок ))
Доказательство того, что я вру про свой опыт. Я могу подтвердить все места работы, если нужно с рекомендациями 🙂 —- дичь))) я тебе могу сказать только, что на ляпос ты точно тут написал вранья, [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement]

Артем Русов QA Tutor в Artsiom Rusau QA Life
8 июля 2023, 12:42

Слился значит) Ну ок)

8 июля 2023, 14:13

слился, эмм, с чего? ты что с утра сегодня эликсира храбрости матанул?)) Чел тут не с чего сливаться, ты [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] пиариться на грязных историях и копипасте чужих статей, мне бы и дела не было до тебя если б ты эту чухню не пускал в свет и не позорил мою профессию

mishka dev в Galera
8 июля 2023, 00:29

Поржал со статьи ��
Да лучше уж на каком питоне писать начать, чем в куА на аутсорс. Где вершина развития — щелканье кнопок на юайке и отправка скл квери к бд.
А сколько пафоса, сколько бисера ��

8 июля 2023, 03:44

Все зависит. Если постоянно расти над собой, знать иностранный и обладать неплохими софтскиллами, то через пару лет можно работать напрямую на иностранную компанию и получать на уровне девов в РБ.

mishka dev в Galera
8 июля 2023, 08:06

Ага, и в БигТех возьмут. Юайку тестить��

8 июля 2023, 14:38

Бэкэнд тестить часто приходиться, особенно если продукт, а иногда и авто тесты писать. Это весьма далеко от обычных кликов по юайке)
Меня взяли в бигтех европейский без бэкэнд тестирования навыков и даже БД. Думаю, за счет авто тестов выехал. (Я мануальщик, если что)

8 июля 2023, 14:40

Развитие есть, либо по ветке менеджера и будешь способен только юайку тестить. Либо по авто тестам в general qa/automation qa , а там уже до СДЕТа в теории. Либо можно в безопасность/нагрузку уйти.
А можно вообще всего понемногу, и жнец, и на дуде игрец )

Пользователь отредактировал комментарий 8 июля 2023, 14:40

8 июля 2023, 14:41

Пользователь отредактировал комментарий 8 июля 2023, 14:41

yaninochka
8 июля 2023, 12:06

Налетели! Мне в том числе и его бесплатные видео на ютубе помогли войти в эту профессию. А что еще требовалось для новичка от человека, который обучает чему-то? А как он пиарится меня мало интересует. Меня интересовала информация, я у него ее нашла.

8 июля 2023, 14:15

да мы рады, что у вас все получилось, вы так же могли просто прочитать любую изи книгу и так же попасть в профессию, это же сугубо ваши амбиции и склад ума, сугубо вы сами попали куда хотели, а не этот [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] вам показал дорогу.
Данный персонаж постит давно несвязаные вещи с тестированием, а если и постит тестирования, то никак не свое а чужое, почитайте или последите за его постами, это же просто [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] который ворует чужую инфу и предоставляет от своего лица)

Артем Русов QA Tutor в Artsiom Rusau QA Life
8 июля 2023, 14:50

А чего добился ты, котик?) Мне вот даже интересно послушать хоть здесь про твои заслуги и поддержать этот жирный троллинг. Так как мы все равно не получили ни ссылок, ни доказательств твоих пустых слов

8 июля 2023, 16:58

В чем троллинг, если вы ни разу не указали авторов статей и материалов, которые постоянно постите от своего лица?
И вроде как вчера «ушли» отсюда обозвав критику «токсиками».

Пользователь отредактировал комментарий 8 июля 2023, 16:58

Артем Русов QA Tutor в Artsiom Rusau QA Life
8 июля 2023, 17:44

Так мне еще не показали ни одну статью, которую я якобы использую. С удовольствием обсужу здесь, если вы это сделаете. Конкретный пример первоисточника, конкретная ссылка на мою статью, в которой я это повторяю.

Иначе так можно писать о ком угодно. Я здесь и открыт к диалогу. В отличие от тех, кто уже комментариев 10-15 написали об одном и том же без каких-либо подтверждений своих слов.

Я не люблю, когда людей обвиняют просто так и не несут ответственности за свои слова.

8 июля 2023, 21:00

Я не особо пиарюсь за счет своих заслуг, но раз ты спросил, то я вырастил несколько команд тестировщиков, имею опыта более 10 лет в тестировании, написал не 1 десяток статей на тему тестирования с которых ты кстати скопировал не мало, как, удивил? 🙂

8 июля 2023, 21:01

И нет, очередной [censored — П. 4.1.2. Пользовательского соглашения — https://dev.by/pages/agreement] для твоей след статьи я не выпущу, поэтому я останусь инкогнито

Артем Русов QA Tutor в Artsiom Rusau QA Life
8 июля 2023, 22:32

К сожалению, я не склонен доверять людям, которые не могут отвечать за свои слова и решили остаться инкогнито за плашкой ноунейма, когда заявляют о таких обвинениях) Но все выводы читатели комментариев сделаю сами. Я за свои слова и действия готов ответить.

8 июля 2023, 13:51

Классика просто. Кто умеет делать — делает. Кто не умеет — управляет. Кто не умеет ни управлять, ни делать, учит других как надо управлять и/или делать.

9 июля 2023, 13:14

Госпаде, воспринимайте его просто как видео-конспект для учебы/повторения информации перед собеседованием

Пользователь отредактировал комментарий 9 июля 2023, 13:14

mysh-krodetsya Quality Engineering Manager в EPAM
14 июля 2023, 11:01

Господи, больше митингов богу митингов! Простите, когда работать? Если и скрам церемонии все посети, и 3 Amigos посети, и на всякие остальные созвоны сходи, так тут еще и KT сессии по поводу «кто ж такие тестировщики и что они делают» нам настоятельно рекомендуют (с)
Если ваша команда не понимает, что делает тестировщик (с) — то значит, такой ты тестировщик. И тут не митинги надо ставить дополнительные, чтобы только еще больше всех раздражать и на которые с большой вероятностью мало кто придет, а если и придет, то будет мультитаскать на фоне, а нужно делать свою работу и особенно ее результаты прозрачными для всех. Спросите как? Их есть у меня:

первое, если команда не понимает, для чего «тестировщику» нужно столько времени на тестирование — создай таски в Джире/АДО или что там пользуют на проекте, напиши в них, что входит в рамки этой таски и на что тебе там нужно Х часов, после выполнения таски приаттачь результаты — тестовую документацию ли или что-то другое, что будет видимым доказательством, что было сделано и на что ушло столько времени + с ростом опыта должен расти и перформанс, т.е. как минимум скорость выполнения тасок при сохранении/повышении уровня их качества. В результате любой человек, у которого вопросики к тебе, сможет зайти и увидеть, что ты там делал второе, если команда не понимает ценности тестирования, возможно, качество работы такого «тестировщика» соответствующее. Находи валидные серьезные баги, если не можешь найти, улучшай тестовую стратегию, предотвращай критические ситуации, улучшай качество приложения — разработчики только спасибо скажут! третье, что мешает во время sprint review, особенно если девы проводят демо, проводить QA демо в том числе, на котором можно показывать всей команде репорт с результатами тестирования за спринт, где будет видно, сколько чего было сделано и самое главное — какие результаты это дало в виде метрик и пояснений по ним И помните, за качество отвечает ВСЯ команда, а не только «тестировщики»

Полгода без тестировщика

Тестировщики нужны, чтобы не было багов. Тестировщик спасает софт от погружения в пучину безумия, без него не построить качественный продукт. Без тестировщика команда обречена постоянно тушить пожары на проде, софт будет глючным. Один человек спасает команде много времени и нервов, а компании экономит кучу денег.

Мы провели эксперимент и проверили это на практике. Больше полугода мы проработали без тестировщика в команде, и сейчас пора посмотреть, что из этого получилось.

Кто мы такие? Мы — команда в крупной финтех-компании, отвечаем за небольшую часть сервисов, на которых работают продукты с миллиардным оборотом. Из фронтенда у нас только админка, остальные фронты живут в других командах и вызывают наши сервисы через REST API или асинхронно. Я — не очень опытный тимлид команды.

Это лонгрид, время чтения ~15 минут, часть подробностей убрал под спойлеры, чтобы сэкономить время тем, кому захочется побыстрее добраться до комментов 🙂

Были длинные проблемные релизы, раз в 1–2 месяца, Continuous Delivery и не пахло. Было больно. Убрали тестировщика вообще, регресс заменили тестами: Unit + Integration и end‑to‑end автотестами. Теперь регресс делается быстро, код всегда готов к релизу, релизы соседних сервисов теперь независимы друг от друга, а все изменения между релизами обратно совместимы. Релизим часто, качество не просело, команда в целом довольна. Есть и неудобства, поэтому сейчас хотим себе фуллстек‑QA с упором на автотесты.

Как мы жили, от чего страдали

Давайте сначала расскажу, чего нам спокойно не сиделось и зачем мы вообще затеяли наш эксперимент.

Как мы релизили

До начала эксперимента мы релизили софт так, как в 2010-е было мейнстримом в средних и крупных компаниях. Опишу в двух словах для понимания.

• Релиз планируем заранее, составляем список задач на релиз, и по мере выполнения задач тестировщик проверяет их на тестовом стенде.
• Когда сделали все задачи, входящие в релиз, делаем код фриз — например, в виде релизной ветки. В неё перестаёт попадать код по более новым задачам.
• Чтобы выкатить релиз, тестировщик делает регресс, фиксятся найденные баги.
• После выкатки тестировщик делает смоук тесты, а остальные сидят наготове, чтобы фиксить проблемы, возникающие после релиза.

Релиз у нас был каждые 1-2 месяца.

Что с этим было не так

Узнаёте ли вы проблемы своих прошлых или текущих проектов в этих мини-историях, состоящих из потока мысли разработчика?

пара зарисовок из нашей жизни тогда

История 1:

Релиз застревает в тестировании, в итоге дата релиза сдвигается на неделю-две

После релиза вы находите баг на проде

И надо снова делать релиз

И опять надо нести его в тестирование

А тут ещё из другого сервиса срочно просят докинуть фичу в API, там делов на 2 часа

И опять на регресс

История 2:

Сделал задачу, залил код

Взял в работу следующую

Через 3 дня приходит тестировщик — в задаче баг

Через день приходит тестировщик с другим багом

Через день снова приходит

Смотришь постановку – ничего не понятно

Идёшь разбираться — выясняется, что это и не баг вовсе, или баг, но не в той задаче

И через 2 недели снова приходит – завтра релиз, делали регресс, нашли на препроде баг.

В каждый релиз входит много изменений, поэтому релиз надо тщательно проверить. А после релиза часто находятся баги, которые надо пофиксить и… выпустить ещё один релиз с фиксами.

Выпуск релиза — это танцы с бубнами на несколько дней, в которых участвует вся команда. Кто-то второпях доделывает последние задачи релиза, кто-то спешно фиксит баги по сделанным задачам, тестировщик оперативно всё это успевает проверять и после этого уходит делать регресс всей системы.

Релизиться часто не хочется — много накладных расходов. Поэтому заказчик задачи частенько ждёт несколько недель релиза, вместо того, чтобы пользоваться фичой, которая уже готова.

Код может висеть месяцами, не добираясь до прода. Висят как не очень востребованные фичи, так и некритичные фиксы. Например, один раз я разбирал проблему на проде и увидел, что в логах не хватает информации, чтобы понять, что происходит. Добавил логов, залил. Через месяц делаю разбор похожей проблемы — а нужных логов до сих пор нет.

Часто релизы задерживаются. Сначала определяют дату релиза, но по мере её приближения релиз несколько раз сдвигается — на день, потом ещё на 2, потом ещё…

Просто кто-то не успел сделать свою задачу в срок, заболел или взял отгул на пару дней. А кто-то никак не может перекинуть свою задачу через тестирование, потому что она постоянно возвращается с новыми и новыми багами.

Релизы задач, затрагивающих несколько сервисов сразу

Если в релиз вошла задача, где есть изменения сразу по нескольким сервисам, то тут вообще пиши пропало. Чаще всего изменения по таким задачам не обратно совместимы — новая версия одного сервиса не будет работать со старой версией другого. Поэтому требуется релизить несколько сервисов одновременно. Чаще всего для этого сервисы гасят, обновляют и синхронно стартуют на обновлённой версии. То есть появляется даунтайм, и это нифига не круто.

Если перед релизом такой задачи во время регресса в одном (или не одном) из сервисов нашли баг, то блокируются релизы всех этих сервисов.

Если мы находим баг в одном из сервисов уже после релиза, то откатить мы можем либо все сервисы сразу, либо никого. Часто остаётся только героически фиксить проблему за минимально возможный срок, оставаясь после работы. И каждую минуту, пока баг не исправлен, растёт ущерб пользователям и компании, а давление на команду ощущается прямо физически. Команда, понятно дело, стрессует, и это негативно влияет на мораль и производительность как на ближайшие дни, так и в долгосрок.

А давайте как в гугле

Говорят, в гугле большинство команд работают без тестировщиков. Сервисы проверяются автоматическими тестами, а если баг проскакивает на прод, то его просто исправляют и дописывают тесты. Релизы делают чуть ли не на каждую задачу, и выпуск релиза не требует участия человека, всё делается в пайплайне.

Получается, если у вас нет тестировщика, то вы не обязательно отсталая компания с ужасным качеством и плохими процессами. Может быть наоборот — вы передовая компания с самыми современными подходами 🙂

Мы подумали: “А чем мы хуже гугла?” И решили тоже так попробовать.

Отдали тестировщика в другую команду

Взяли план регресса, который делал тестировщик, и реализовали end-to-end автотесты на большинство кейсов. То есть регресс из ручного стал автоматическим.

Дописали интеграционных тестов, чтобы в рамках каждого сервиса была надёжно покрыта вся основная функциональность. В этом нам помогли testcontainers.

Плюс мы договорились, что теперь, делая задачу, разработчик покрывает её тестами, проверяя весь свой код. Ведь теперь между его задачей и продом не будет ничего, кроме тестов, которые написал он сам и другие разработчики.

Решили, что релизить можно каждый день, каждый релиз обратно-совместим с предыдущим, и релизы сервисов не зависят друг от друга.

И конечно же наш SRE-инженер собрал нам CI/CD пайплайны, которые воплотили всё это в жизнь. Автотесты стали запускаться после каждой сделанной задачи и проверять, что всё работает. Релизы мы стали выпускать на основе тега в гите в любое время дня и ночи, и разрешили делать это всем в команде.

Мы представляли, что заменить на автомат хочется главным образом регресс.

Но тестировщик делает не только регресс!

Иногда потестировать что-то руками – это лучшее решение:

• одноразовые вещи;
• задачи с очень большими изменениями, например новые продукты;
• фичи с UI;
• фичи на несколько систем, включая сторонние.

На такие случаи, и вообще для подстраховки, договорились, что тестировщика сможем иногда призывать к себе в команду, чтоб потестировать что-то конкретное.

Ну вы ребята крейзи

У вас, наверное, сразу возникли возражения и вопросы, примерно такие:

• Писать тесты — это не задача разработчика! Разработчик должен код писать, а сидеть и проверять, как он работает, порочит честь и славу мундира!
• Разработчик же всё равно не протестирует сам свой код нормально, проверит только happy path, и всё равно будет куча багов!
• А кто будет баги заводить? Тоже разработчики? За зарплату 300к/наносек сидеть и формочки заполнять?
• Автотесты писать долго и дорого, будете постоянно тратить на них кучу времени.
• Да у вас каждую неделю релизы будут валить прод! Инцидентов не разгребёте!
• Короче код в итоге будет писаться еще дольше, а работать будет некачественно!

У нас у самих возникали все эти мысли. Нам как раз было интересно проверить, оправданы ли эти опасения на самом деле, или это всё шаблоны и обычный страх неизвестного.

В противовес у нас были и положительные гипотезы:

• может быть разработчики станут больше уделять внимания качеству, раз за ними – только релиз;
• станет больше тестовое покрытие, и это повысит общую устойчивость кода к изменениям;
• может быть без ручного тестирования мы по крайней мере сможем быстро катить изменения от кода до прода, а снижение накладных расходов и рост скорости поставки уже дадут ценность;
• разработчиков не будет вырывать из потока тестировщик, и им не придётся постоянно возвращаться к задачам, которые они уже отпустили несколько дней или недель назад, будет лучше фокус на текущей задаче;
• и просто, это офигенно!

В общем, мы были готовы к разному эффекту.

Мы договорились об изменениях и попробовали. Что у нас получилось на самом деле?

Результаты

Мнение команды

Давайте сначала послушаем, как это пережили в команде и какие у ребят впечатления.

Я задал команде 4 вопроса:

1. Как оно вам, понравилось ли без тестировщика (чисто на уровне восприятия и эмоций)?
2. Какие изменения заметили, что стало лучше-хуже в плане работы?
3. Как вам кажется, поменялось ли качество продукта, стало ли оно лучше/хуже?
4. Хотели бы жить так и дальше и рекомендовать другим?

И получил вот такие ответы:

развёрнутые ответы для любопытных

1. По ощущению процесс стал проще и стал сжигать меньше ресурсов.
2. Кажется, что разработчики стали ответственней относиться к реализации задач, стали продумываться негативные сценарии — что делать, если твой код что-то поломает после релиза.
3. Отсутствие тестировщика никак не понизило качество продукта, зато увеличило скорость прохождения pipeline, что позитивно сказывается на разработке.
4. Практика однозначно хорошая, но для идеала нужен еще ручной тестировщик, который будет искать неавтоматизированные сценарии и баги на постоянной основе, не вмешиваясь при этом в прохождение pipeline.

1. Прикольно было попробовать, раньше не думал, что такое может быть ок.
2. На первых порах ручное тестирование поразмазалось по команде, сейчас как будто такого стало меньше. Иногда параноить начинает, что заливаешь опасный функционал.
3. Тут трудно. Как-то странно мало багов выскакивает по ощущениям. Надеюсь, что это действительно так.
4. Хотел бы работающую (!) систему с призывным тестировщиком.

1. Не привычно, требует больше внимания от разработчика, задачи тестировщика ложатся на плечи разработчика.
2. Пока не могу сказать, единственно, что заметил, это большие временные затраты по проверке написанного/измененного кода.
3. Увеличилось время прохождения пайплайна.
4. Мне все равно не хватает ручного тестировщика на некоторые кейсы.

Ещё свеже-нанятый разработчик:

1. Есть некая прозрачность в том, что должно быть на выходе, и нет постоянных синков, что и как работает и почему.
2. Тяжело сказать только придя, но в сравнении с предыдущим опытом явно большее погружение в требования к коду, что должно при написании его обогащать качеством. Обычно идет условная конфронтация между qa и разработкой. Тут больше чувствуешь ответственности за продукт.
3. Пока не могу ничего сказать.
4. Ручная тестировка всё равно кажется необходима, но для исключительных кейсов.

1. По тривиальным задачам, регрессу и т.п. — жить стало приятнее.
   По сложным задачам с множеством кейсов хотелось бы, чтобы кто-то проверил не только, соответствует ли реализация требованиям, но и насколько полны требования (но этого не было и при наличии тестировщика).
2. Процесс доставки явно ускорился.
3. Судя по отсутствию негатива и метрикам — хуже точно не стало.
4. Я плюсану за то, что хочется иметь «своего» погруженного тестировщика с творческим мышлением для нестандартных кейсов. Возможно, на парт-тайм.

В среднем получается:

• Как минимум опыт для команды был прикольным.
• Процесс поставки кода стал проще и прозрачней, код стал попадать на прод быстрее.
• Качество субъективно не просело.
• Есть небольшой стресс от отсутствия “анти-баг стены”, разработчики чувствуют больше ответственности, но в целом это скорее позитив.
• В целом потребность в тестировщике значительно снизилась, но частично осталась, в основном не для регресса, а для нестандартных тестов.

Мнение лида (моё)

Мы не увидели просадки в качестве. Метрики показывают, что количество багов на проде осталось таким же, а число багов, найденных на тестовых средах, неожиданно сократилось в 2 раза. Скорее всего багов тестирования стало меньше, потому что разработчики стали, во-первых, находить большую часть багов во время разработки задачи, а во-вторых, потому что разработчики не всегда заводят баги, когда замечают проблему самостоятельно на тестовом стенде до релиза в прод.

Тем не менее, качество работы прода нас устроило, по нашей оценке оно не снизилось. За полгода у нас было 2 блокер-инцидента, но они произошли бы даже при наличии тестировщика, их причина была в изменении конфигурации инфраструктуры в облаке.

Что касается скорости разработки, то она понизилась, по моим оценкам процентов на 20. Это если мерять по времени нахождения тикета в статусах “разработка” и “ревью”. Но здесь надо учитывать ещё и другие затраты времени, которые раньше случались уже после окончания разработки: тестировщик теперь не приходит к разработчикам с вопросами и багами дни и недели спустя после того, как задача залита в мастер. Цикл обратной связи теперь короче за счёт хорошего покрытия тестами, плюс разработчик хорошо покрывает ими и свою текущую задачу, что сразу подсвечивает большинство проблем и позволяет их исправить ещё до того, как код уйдёт дальше.

В целом такой подход к тестированию мне показался более технологичным и интересным, и в нём определённо есть полезное зерно.

Но не все эффекты, которые мы пронаблюдали, были классными. Хотелось бы скорректировать нашу работу по итогу — оставить всё, что нам понравилось, и постараться убрать то, что мешает. Обсудили и пришли примерно к таким вещам:

• Процесс поставки на прод стал гораздо понятней, он более объективен и формализован, меньше зависит от бас-фактора или личности кого-то из команды.
• Повысилась скорость доставки кода на прод и частота релизов. Хочется, чтоб так было и дальше.
• Разработчики внимательней готовят код к интеграции с главной веткой. Они понимают, что после них нет человека, который найдёт очевидные ошибки и проверит корректность работы, и поэтому сами лучше погружаются в требования, держат в голове смысл и цель своих изменений и покрывают это тестами.
• На код ревью становится более важным сделать ревью не только кода, но и тестов: посмотреть, достаточно ли их, какие сценарии они покрывают.

Что хотим поменять:

• Некому выполнять ручное тестирование время от времени. Команда чувствует себя неуверенно, когда нужно выкатить фичу, где требуется нормальный ручной тест. У членов команды не хватает на это квалификации в тестировании, а внешним тестировщикам не хватает погружения в требования, контекст продукта и команды, предсказуемости ресурса занятости.
• Автоматические тесты хочется развивать, повышать культуру, улучшать подходы. Хочется, чтобы кто-то в команде целенаправленно этим занимался и обменивался опытом с другими командами.
• Всё-таки разработчики больше склонны проверять хэппи вэй, а не думать о том, как маленьким щелчком пальца в нужном месте можно свалить весь карточный домик. Разработчик сам пишет тесты на свой код, и нет никого с альтернативным мнением, кто специально хотел бы найти проблемы в реализации. Код ревью это делает до определённой степени, но там это далеко не главный фокус.

Так мы поняли, что нам в команде всё-таки нужен тестировщик. Просто ручным регрессом он заниматься практически не должен, не больше пары-тройки дней в месяц. А в чём он реально был бы полезен, так это в исследовательском тестировании, чтобы помочь выявить те проблемы, которые не так очевидны. И очень мог бы помочь прокачать автотесты, чтобы у них росло покрытие, но они оставались при этом быстрыми и гибкими.

Возможно уже на следующей неделе к нам выйдет тестировщик, которого мы и позвали в команду помочь с этими вещами.

Кстати, насчёт найма

Через какое-то время после начала эксперимента мне нужно было усилить команду разработчиками. Нет, не из-за того, что половина разработчиков уволились после таких изменений 🙂 Вакансии были предусмотрены ещё до начала эксперимента, никто не увольнялся 🙂

Так вот, я оказался в интересной ситуации. На собесах кандидаты спрашивают: “Расскажите про состав команды, про процессы”. А я отвечаю: “Кстати да, мы живём без тестировщика, но это не плохо, это мы сами от него отказались, и вообще это не баг а фича, и мы не отсталые, а наоборот такие прогрессивные”.

Мне самому казалось, что потенциальных разработчиков будет отпугивать отсутствие тестировщика, а идея, что можно жить и без него, ассоциируется скорее с отсталыми конторами, где говнокод, авралы, нет кофе-машины в офисе и всё остальное 🙂

Мне казалось, что слишком мало разработчиков на текущий момент пробовали жить так, как живём мы, и я сомневался, воспримут ли они это с позитивом.

Тем не менее, я закрыл все вакансии классными спецами. И решил спросить их о том, какое впечатление на собеседовании производила наша схема работы:

1. Когда узнавали на собеседовании, что в команде нет тестировщика, то как это влияло на привлекательность позиции?
2. Как ощущается теперь спустя месяц работы?

Ответы были такие:

развёрнутые ответы разработчиков-новичков

1. Тут скорее не про команду без тестировщика (таких много), а вот команд, пишущих устойчивые тесты это да.) Это дополнительный опыт, и крутой по своей природе. Скорее захотелось поучаствовать в таком проекте.
2. Чувствуется спокойствие в команде и сам себя постепенно начинаю приводить к тому, что можно деплоиться и ночью, не просыпаться проверить логи)

1. «ВАУ, я хочу это увидеть. » Привлекательность сильно повысилась, появилось желание это опробовать.
2. Ещё не могу привыкнуть к долгим пайплайнам.

В целом получается, что привлекательность вакансии может быть даже выросла. Влияние на онбординг противоречивое, нужно больше точек данных 🙂

Тут конечно стоит учитывать ошибку выжившего — те, кто “не купил” идею, что работать как мы — это круто, наверное просто не пошёл на наши позиции.

Итоги

Суммируя наш опыт, вам стоит пробовать перейти на автоматический регресс, если:

• У вас мало UI, или вы хорошо умеете его тестировать автоматически.
• Вы хотите иметь быструю доставку изменений на прод, часто релизить (continuous deployment) или хотя бы всегда иметь код, готовый к релизу (continuous delivery).
• Ваша команда достаточно прокачана, чтобы держать планку качества в таких условиях, и готова подписаться на такой эксперимент.
• У вас прямо сейчас уже неплохое покрытие тестами. Если это не так, лучше сначала его нарастить.
• У вас нет кучи легаси. Но тут см. пункт выше — возможно, если вы покроете ваше легаси тестами, оно перестанет быть таковым ;).

И да, совсем прощаться с тестировщиком не обязательно, это, наоборот, хорошая возможность вытащить его из бесконечного регресса и дать возможность прокачать скилы в автоматизации.

P. S. Многие вещи я упомянул в статье только вскользь, иначе она была бы ещё в 3 раза больше. Если интересно о чём-то узнать подробнее, спрашивайте в коментах. Отвечу на что смогу, или сделаю мини-статью, если тема большая. Мне интересно делиться опытом и сравнивать его с вашим, так можно узнать много интересного.

P. P. S. Привет всем из команды и компании, кому история из статьи уже знакома 🙂 Я специально не стал указывать, о какой компании речь, ибо пишу не чтобы попиарить компанию, а просто от себя, чтобы поделиться практикой и обсудить впечатления от такого подхода. Велкам в комменты!