DOU Live про QA: Software Engineers in Test, проєкти без тестувальників та TestOps

Темою чергової live-дискусії на DOU стало тестування у сучасному ІТ. Ми поговорили з Мікалаєм Аліменковим, незалежним консультантом в XP Injection, Олегом Заревичем, DevOps/Test Automation Engineer в InterLogic, і Святославом Логіним, Head of gangsta QA.

Ви можете переглянути повний запис розмови або ж прочитати скорочені тези.

І не забудьте підписатись на YouTube-канал DOU!

Про шлях у тестування

Якби ви зараз починали свій шлях в ІТ, чи пішли б у тестування? Чому? І з чого починали б вчитися? (1:40)

Мікалай Аліменков: Я бы, наверное, не пошёл в тестирование, потому что у меня изначально был хороший девелоперский бэкграунд. Я бы шёл целенаправленно в разработку. Но в современное направление, которое считаю одним из самых приоритетных — инженерию, которая происходит вокруг обеспечения качества. Кто-то называет это Software Engineering in Test, кто-то иначе. Но иметь возможность влиять на качество продукта и при этом оставаться полноценным девелопером — это очень интересная область, но она требует серьезной подготовки. Поэтому с неё начинать тяжело.

Олег Заревич: На початку кар’єри тестувальника дехто думає, що у цій роботі багато рутини і мало цікавих технічних задач. Але через деякий час тестингу починають бачити чимало напрямів для розвитку: security, performance, QA... Я почав рухатися до DevOps Test Automation.

Святослав Логін: Перед QA я проходил курсы по программированию, мне не зашло. Пошёл в QA, поработал автоматизатором и понял, что автоматизация тоже не моё. Почему так? QA быть круто, когда ты влияешь на качество, плюс можешь заавтоматизировать, покрыть тестами безопасность. То есть если становишься General QA, который может покрыть полностью весь флоу.

Мікалай Аліменков: Мы все говорим об интересности и широте специализации QA-инженера. Не Manual-тестировщика, не чисто автоматизатора, а QA-инженера в широком смысле, потому что именно в таком случае ты можешь развиваться в эти соседние области. Если тебя наняли просто прокликивать сценарии, то вот там тяжело развиться, например, в Security. А полноценная роль QA-инженера — широкая и интересная специализация, которая востребована на рынке.

Про поріг входу

Які вимоги до тестувальника? Чи поріг входу високий? (6:31)

Мікалай Аліменков: Многие компании не настраивают у себя серьёзных Quality assurance процессов, и у них те основываются на костылях и подпорках. Поэтому им часто нужны рабочие руки, чтобы закрывать дыры в ручном тестировании. А для этого необходимо получать как можно более дешевые кадры, хотя эта работа и так самая базовая в ІТ. Поэтому много людей нашли простую лазейку, а компании начали повышать требования, чтобы отфильтровать гигантский поток желающих.

Святослав Логін: Компании пытаются сэкономить, берут джунов, которые не развиваются по разным причинам, а отсюда и берется нытьё «а куда дальше развиваться». В итоге человек сидит на мануале и дальше никуда не идёт, потому что нет ментора, который скажет, что сделать и подтянуть, чтобы дальше расти.

Мікалай Аліменков: Компании заинтересованы в кадрах, которые будут делать работу, и хотят за эти кадры платить как можно меньше. А компаниям, где не настроены процессы, и не особо нужны мидлы и сеньоры.

Software Engineering in Test

Чому в Україні майже немає попиту і вакансій на Software Engineering in Test? (не плутати з Ttest Automation) (16:12)

Мікалай Аліменков: Украинские реалии, к сожалению, таковы, что у нас большая часть это аутсорсинг, часть из которого — аутстаффинг. Такие компании практически не зарабатывают на синьор-стаффе. Вообще у многих модель аутсорсинга построена так, что синьоры работают в убыток, а это значит, что заработок аутсорсинговой компании построен на Middle и Junior, что рождает логичный вопрос: а откуда там возьмется продажа Software Developer in Test? Ведь это человек, который хорошо понимает, что такое качество, и умеет его настроить в процессах. Таких людей по умолчанию мало. И даже в продуктовых компаниях их не так много.

Олег Заревич: Переважно Software Developers in Test займаються розробкою інструментарію для тестування. І багатьом проєктам такої людини і не потрібно. Уявіть собі, що ви маєте автоматизацію і треба зробити репорт. Чи готова ваша компанія витратити ресурси на те, щоб ви кілька місяців розробляли лібу для спеціального репорту, чи, можливо, простіше взяти готовий інструментарій?

Святослав Логін: Для аутсорса выгоднее продать отдельно автоматизатора-мидла, мануальщика-мидла и девелопера-мидла. Они заработают намного больше денег, чем один Software Developer in Test.

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

Мікалай Аліменков: Предположим, ты решил расти в компании X, а там как раз нужен Software Developer in Test. Ты начинаешь погружаться в девелоперские инструменты, чтобы лучше понять, где теряется качество. И есть такой принцип малинового варенья: чем больше пытаешься намазать широким слоем, тем тоньше получается сам слой. И начинаешь терять более глубокие навыки в инструментах по автоматизации, а при смене работы оказывается, что то, что ты делал ранее, никому на рынке не надо.

Есть и другой перекос в индустрии. Например, автоматизаторы, которые руками вообще не тестируют.

Manual QA

Чому в Україні не цінують роботу Manual QA? Чи є у 2021 році місце ручному тестуванню? (25:09)

Мікалай Аліменков: Ответ кроется в понимании, что есть Manual QA? Мы смешали всё в одно. Когда мы говорим про QA — это Quality Аssurance, процесс обеспечения качества, когда про Manual, то имеем в виду, что человек руками обеспечивает качество? Это полный абсурд. В эру автоматизации ручного тестирования должно становится всё меньше. Но если же мы говорим про обеспечение и контроль качества, то самая ценная характеристика этого процесса — это тест-дизайн. И никуда мы от него не ушли. Люди, которые умеют делать грамотный тест-дизайн, будут цениться в любое время, потому что их становится всё меньше.

Если бы ко мне пришёл человек на вакансию, связанную с QA, и сказал бы: «Я не напишу ни одной строчки кода, но сделаю так, чтобы ваша стратегия по автоматизации работала так, как вы её задизайнили, буду отвечать за то, чтобы у вас был правильный тест-дизайн, чтобы потом этот дизайн раскладывался по тем уровням тестов, которые вы договорились между собой писать, чтобы разработчики их действительно писали, чтобы мы замеряли все нужные метрики и так далее», то это был бы идеальный кандидат, который получил бы сразу топовую зарплату и был нанят в тот же день.

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

Мікалай Аліменков: Говоря про наш рынок, где большая часть аутсорсинга, давайте подумаем, а выгодно ли аутсорсингу всё автоматизировать? Выгодно ли сказать заказчику: «Смотрите, мы сэкономим вам время и деньги, сейчас внедрим автоматизацию, и уже через три спринта вы будете экономить кучу времени на регрессию»?

Як продати автоматизоване тестування замовнику

Як перекнати замовника, що йому потрібні автотести? (33:18)

Олег Заревич: Треба підходити з позиції, а чи справді замовнику треба автоматизація? Яку проблему ми хочемо вирішити? Поставте це питання собі, потім запитайте замовника, чи він готовий цю проблему вирішувати. Продавайте йому не код, а гроші, які він зможе зекономити і заробити. Якщо ви зможете показати метрики, скільки, де і коли зекономите автотестами, порівняти з manual-кейсами, це може допомогти.

Святослав Логін: Нужно оценить, сколько времени уходит на тестирование на проекте. Если же все покрывается ручным тестированием, то какой смысл в автоматизации? А если вы реально понимаете, что не успеваете проверить всю логику, новые задачи и не задеть старые, то нужно сказать заказчику: с автотестами обновление займет столько-то времени, а если будем это проклацивать ручками — столько-то.

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

Мікалай Аліменков: Давайте посмотрим на сторону заказчика. Там часто не технические люди. Им говорят: «Уважаемый клиент, мы дадим вам Senior Developers, а еще нужен тестировщик». Клиенты не понимают для чего: «А нельзя ли, чтобы разработчики сразу писали хорошо?» А в ответ слышат: «В индустрии так не бывает, но есть оптимизация. Можно платить за мануального тестировщика каждый раз, а можно же написать автотесты».

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

Фриланс для QA

Яка ваша думка щодо фрилансу професії QA-інженера? (40:34)

Святослав Логін: Я думаю, что если ты устроился на проект и не получаешь новые задания, где мог бы прокачаться, то фриланс — это классная возможность найти тот, на котором можешь получить новые скилы.

Мікалай Аліменков: Какие проекты могут сработать на фрилансе? Если мы ищем временных тестировщиков, чтобы прокликать уже заготовленные сценарии, то в принципе такой вариант может работать. Была одна смешная компания, в которой рассылали на трёх разных людей один и тот же тестовый сценарий. Эти три человека проходили каждый тестовый сценарий и присылали свои результаты. И если у двух из трёх результат совпадал, то компания его считала за верный. И таким образом они строили свою мини-автоматизацию на ферме ручных людей. И почему нет? Такое может временно сработать.

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

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

Проєкти без тестувальників

Існують проєкти без тестувальників. Як ви вважаєте, коли такий підхід може працювати, а коли ні? І взагалі, як ви ставитесь до такого підходу? (49:11)

Мікалай Аліменков: Самое главное, чтобы в вашей команде кто-то выполнял роль тестировщика. Если никто не заботится об обеспечении качества, не строит процесс качества и не следит за ним, вряд ли оно само собой появится. Это может быть техлид, Senior Developer, у которого есть хороший бэкграунд... То есть, кто это будет — большой вопрос, и самое забавное, что во многих командах роль настоящего QA-инженера выполняет совершенно не тестировщик. Он, например, умеет делать тест-дизайн и кликать. Где здесь Quality Аssurance? Как тест-дизайн и кликанье поможет нам достичь качества? Тут очень важна роль, а не тайтлы.

Святослав Логін: У нас много раз проводились эксперименты, чтобы убрать отдельную роль QA и переложить это всё на девелопера, но от неопытности провести полноценное Quality Assurance на своём проекте не получалось. И это приводило к тому, что у проектов увеличилось количество багов. И в итоге всё равно возвращались на отдельные роли Quality Assurance, которые выделяли время на то, чтобы полноценно протестировать продукт.

Нужен ли вам Quality Assurance как отдельная роль зависит еще от того, насколько огромный у вас проект. Если это сайт-визитка, то можно обойтись, а если под капотом огромная логика, то без отдельной роли хорошего QA, который возьмёт на себя ответственность построить процесс тестирования и выкатки этого проекта, тут не обойтись.

Мікалай Аліменков: Иногда правда нет потребности. Предположим, вы формируете небольшую команду, в которую приходит грамотный техлид и нанимает под себя три-четыре разработчика определенного уровня. Какая потребность в QA-инженере? Не очень большая, возможно, команде понадобится QA-инженер, когда она выйдет за рамки того масштаба, в котором умела работать. Но не «бытовой» QA-инженер, а который придёт и скажет: «Чтобы масштабироваться и выводить качество на микросервисной архитектуре на адекватный уровень, нам надо позаботиться о circuit breaker-ах, о хаус-инжиниринге и так далее», который будет заниматься нетривиальными задачами.

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

Олег Заревич: Треба також пам’ятати про ціну помилки. Якщо у вас вилазить дефект на продакшені і він зачіпає багатьох користувачів, ви втрачаєте тисячі доларів кожної хвилини, то дуже важливо вибудувати якість зсередини.

Тестування на проєкті з частими релізами

Яким є ідеально налаштований процес QA Аutomation на проєкті з частими релізами? (1:10:26)

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

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

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

Святослав Логін: Недостаточно настроить автотесты. Должен быть выработанный процесс и понимание, как вы будете действовать в обратном порядке. Допустим, тесты пробежали, всё хорошо, обновляетесь, но что-то пошло не так на продакшене — вы должны знать, как вести себя в той или иной ситуации, при каждом обновлении.

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

Олег Заревич: У мене був досвід, коли будували мікросервісну архітектуру з частими релізами і великим навантаженням на тести. У нас було мало ...тестів, але вони були надійними. Ми тісно співпрацювали з розробником, могли одночасно взяти бренчу, в якій він працює, підняти код і вже разом внести зміни в тести. Була сильна комунікація. Але я часто бачу такі проєкти, де Аutomation перебуває окремо від команди, має якісь свої тести, сам їх запускає і фіксить, і ніхто не знає, чим він займається. Цього треба уникати. Треба, щоб усі розуміли, для чого тести, яку цінність приносять.

Про сертифікації

Чи є сенс у ISTQB сертифікатах? І, окрім теорії, чи розвивають вони навички? (1:18:39)

Мікалай Аліменков: У меня нет ни одного сертификата, потому что единственная польза от них — это систематизация знаний. Желание получить сертификат заставляет поднять свою задницу и пойти что-то почитать, попробовать. То есть это такой мотиватор разобраться в какой-то теме. Некоторые используют для этого другой мотиватор: пытаются объяснить тему кому-то другому.

Олег Заревич: А що ви очікуєте, маючи сертифікати? Що до вас одразу прибіжать рекрутери і запропонують +1000 баксів? Так не буде. Усе, що ви можете отримати від такої сертифікації, — у книжках з тестування.

Крім того, будь-яка сертифікація — це тест, до якого можна підготуватися, зазубривши питання і відповіді. У мене була така історія зі співбесіди: прийшов кандидат із сертифікатом Advanced Test Analyst, що базується на техніках дизайну, і каже: «Що таке техніки тест-дизайну? Я ходив на курси, нас такого не вчили». Просто в сертифікації це якось по-іншому називалось.

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

TestOps

Хто такий TestOps? (1:25:06)

Мікалай Аліменков: TestOps — это подход или культура, при которой тестировщик тесно взаимодействует с другими IT-ролями, девелоперами и инфраструктурными инженерами. Серьёзно? Они должны взаимодействовать? Да ладно?! А как же они раньше могли обеспечивать качество? Я слышал такие мысли, что TestOps — это такой QA-инженер, который еще и умеет в инфраструктуру. Хотя в определении этого совершенно нет.

Но я хочу поговорить про TestOps-платформы, которые объединяет инфраструктурные компоненты, уровни и инструменты по контролю качества и, скажем так, закладыванию этого качества внутрь кода. Это такая агрегация тест-менеджмента, Test execution и Test reporting, статического анализа и прочих вещей, которые используете для того, чтобы убедиться, что у вас всё хорошо настроено и работает. За такими платформами большое будущее.

Олег Заревич: Якщо TestOps вирішують лише проблему комунікації, то вам треба спілкуватися, а не шукати окрему людину, яка буде спілкуватися за вас.

Святослав Логін: Мне кажется, TestOps — это сильно размытое понятие, все выполняют эти обязанности. Те же самые DevOps ранее выполняли свои обязанности как сисадмины. Чтобы работала огромная платформа, нужна командная работа. Каждый вносит какую-то частицу для того. Я считаю, что это выдуманные дополнительные роли.

То же самое с SecurityOps. Не может человек охватывать такой огромный спектр, он знает всего по чуть-чуть, всё равно нужен человек, который может пойти глубже.

Вимоги до початківців

Що порадите початківцям? (1:38:23)

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

Олег Заревич: Зараз є багато ресурсів, статей, відео, що вчать, як стати QA. Спробуйте розібратися з тим, чого ви хочете.

Святослав Логін: Когда к нам приходят на собеседования, то я никогда не спрашиваю теорию, а только практические задания. Я смотрю на то, как человек действует в той или иной ситуации, как думает и промышляет. Я могу закрыть глаза на то, что недостаточно hard skills, мне важно, мотивирован ли он этой профессией.

Навчальні ресурси

Які книги, курси, ресурси ви можете порекомендувати? (1:45:46)

Олег Заревич: Мені подобається книжка з тест-дизайну Лі Коупленда «Практичний гайд із тестування ПЗ», в Україні її важко буде купити, декілька магазинів її продають. Але на Amazon ви можете її знайти, класно, що вони там бувають дешеві. Також подобається книжка «Як тестує Microsoft», там багато інформації для початківців.

Якщо говорити про курси, є український Prometheus, безкоштовний курс з основ тестування.

Мікалай Аліменков: Я бы порекомендовал книги «Agile Testing» и «Как тестируют в Google».

Майбутнє тестування

Що буде з тестуванням через 5 років? Які тренди? Які прогнози? (1:51:21)

Святослав Логін: Ручное тестирование будет оставаться, но будут расти требования к этой должности. А вообще тестирование никуда не денется.

Олег Заревич: Зараз є нова, доволі популярна течія, про яку у нас мало говорять, — chaos engineering. Усі розуміють, що великі системи і ще під навантаженням завжди матимуть багато фейлів та проблем. Питання в тому, як відреагує ваша система? Інструменти хауз-інжинірингу допомагають покласти якийсь шматочок системи, відреагувати за допомогою моніторингу, зрозуміти, на якій ви стадії.

Netflix — одна з тих компаній, яка просуває цей підхід. За їхніми заявами, вони валять цілий регіон і дивляться з моніторингу, чи їхні метрики не падають і чи користувачі отримують те, що вони хочуть.

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

Мікалай Аліменков: В ближайшие лет пять будут мегапопулярны и очень цениться узкопрофильные специалисты по таким направлениям, как Security testing, специалисты по тестированию распределенных систем. Потому что чем дальше мы идём в мир микросервисов, распределенных фреймворков и так далее, тем больше изменяется подход к обеспечению качества, появляются совершенно новые типы проблем.

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

И наконец, медленно будет умирать ручной труд.