Дисклеймер. Данная статья появилась в результате записи диалога, поэтому в тексте могут встречаться просторечия и немного рекламы.
20-25 лет назад у профессии тестировщика на территории постсоветского пространства не было престижа от слова совсем. Тестировщиками брали тех, кого называли «уверенными пользователями компьютеров». В какой-то момент они были подобны «менеджерам по уборке помещений» — прибраться за разработчиками, рассказать, что вот тут они букву потеряли. Представления о качестве, процессах и разработке развивалось очень медленно. Впрочем, случались и исключения.
Со временем такое отношение сильно изменилось, и сейчас хороших, грамотных специалистов в тестировании расхватывают просто мгновенно. Но одновременно это повысило требования к ним. Прошли те времена, когда тестирование было лёгкой точкой входа в IT. Сейчас начинающему тестировщику нужно преодолеть технический барьер и многое изучить, чтобы войти в профессию. При всём этом, все еще нет единой системы обучения тестированию. Да, есть стандарты и курсы, однако, полной уверенности в получении работы они не дают. Более того, большая часть таких курсов заточена не на получение и закрепление данных, а на прохождение собеседования.
Современная ситуация, для желающих пойти в тестирование, стала сложнее. Многие компании поставили очень высокий барьер на вакансии джунов, и выбирают их очень придирчиво, поскольку количество резюме сильно превышает количество вакансий. При этом миддлов и синьоров в тестировании по-прежнему не хватает, а в автоматизации тестирования — тем более.
Сегодня тестировщик — это полноценный инженер, чья работа уважаема и очень востребована. Человек, который хочет развиваться в тестировании и карьерно расти, сейчас должен — и даже обязан — активно получать новые навыки, а затем развивать их. И этот набор не тот же самый, что был раньше. Мы видим, что в 2021 году есть новые тренды по сравнению с тем, что было 5-10 лет назад.
Современные тренды тестирования
Тестировщик — это уже программист?
Например, намечается тенденция, что разработчику проще перейти в автотестирование, потому что он уже умеет программировать. Требования к разработчикам постоянно растут, и не все успевают за ними по разным причинам. Кто-то работал раньше в другом направлении, ему тяжело перестраиваться, но опыт разработки есть. Кому-то просто надоело писать банальные CRUD из DB на фронт, ему хочется чего-то интересного.
При переходе в тестирование разработчику потребуется всего лишь разобраться с теорией, узнать подходы и проникнуться духом тестирования. Причем при переходе в автотестирование он даже может работать с тем же стеком, только с другой стороны.
Например, платформенная разработка требует от программиста существенного вложения времени, чтобы довести навыки до необходимого уровня. Но если вы возьметесь за задачи SDET, то фактически вы будете работать с теми же платформами, но даже на более глубоком техническом уровне, чем при автоматизации тестирования, и задачи будут более специализированы. Со временем можно дорасти и до продуктовой платформенной разработки, если такой целью задаться. Получается комфортный промежуточный этап.
С другой стороны, для инженера по ручному тестированию всё больше важны программистские навыки. Он всё больше и больше должен уметь писать и читать код как разработчик. QA-инженеры начинают изучать то, что делают программисты, разбираться в алгоритмах, библиотеках, фреймворках.
Такое смещение с обеих сторон сейчас проявляется всё чаще. Разработчику иной раз проще получить некую базу по тестированию и, исходя из этого, уже переходить в SDET, потому что это комплексная роль. И для нее есть очень интересные задачи на этом уровне. И в любом случае, разработчики начинают изучать и тренировать навыки тестирования, чтобы писать, например, юнит-тесты, а может и Agile-тестирование развивать в команде.
Это всё становится очень востребованным, и есть надежда, что качество софта в мире станет лучше. Давайте посмотрим, какие сейчас самые популярные, самые частые специализации в мире QA-инженеров и тестирования.
Интернет вещей
В интернете вещей каждый предмет достаточно уникален. Тулинг вроде бы есть, но по сути его нет. Под каждый телевизор, автомобиль и каждое что угодно вам надо всё делать самому. Похоже на 70-е годы прошлого века, поэтому трудно составить широкую специализацию.
Но всё идет к тому, что со временем это начнет превращаться в некое полноценное большое направление — так же как и аналитика. И, конечно, его тоже нужно тестировать. Но пока интернет вещей не сформировался в отдельную нишу, чтобы вакансии появлялись системно в России. За рубежом, где рынок IT традиционно обгоняет нас на пару лет, этот сегмент уже развивается.
Тестирование безопасности
Упомяну совершенно отдельное направление — тестирование безопасности. Все эти тесты, как будто из другого мира QA — это совсем иные инструменты, требования и критерии. Главное отличие — тестируются не требования для работы пользователя. Задачей тестирования безопасности является защита от намеренного повреждения сервиса или неавторизованного доступа к данным. Это поле постоянной войны — между теми кто ломает для интереса и получения незаконных бенефитов и теми, кто защищает информационные системы. Тем, кто интересуется этим направлением, стоит погуглить термины «этичный хакер» и «white hat».
Высокотехнологичное тестирование
Если говорить про высокотехнологичные направления, которые становятся всё сложнее, технологичнее и интереснее — то это, конечно, автоматизация, а также нагрузочное тестирование как совершенно отдельный сегмент. Происходит даже интересная история, когда нагрузочные тестировщики могут разговаривать вообще на другом языке, нежели обычные тестировщики. Потому что они работают с другими инструментами, метриками и задачами, заточенными в первую очередь на нефункциональные требования.
QAOps и SDET
Все больше требуется тестирования на стыке с другими техническими дисциплинами , так как тестировщики растут в разных направлениях.
QAOps — странный зверек, формирующийся в последнее время — тестировщик, работающий на поле между тестированием и DevOps. Это и архитектура, и какие-то платформенные вещи, и работа с тестовыми стендами, а также BVT тестирование.
Здесь требуется более низкоуровневый подход. Можно провести аналогию с DevOps — который не человек, а идеология. В DevOps есть видные идеологи, которые доказывают, что DevOps — это не человек, а способ взаимодействия разработчиков и эксплуататоров. И если у нас есть DevOps-инженеры, то внедрить DevOps в компании нам не удалось.
QAOps тоже про взаимодействие. Про то, чтобы не было отдельно выделенного QA и отдельно выделенного разработчика. Чтобы они работали в паре, чуть-чуть понимали стек каждого и грамотно передавали друг другу задачи. Двигались вместе, а не кидали через забор: «Нет, это ты плохо протестировал!» — «Нет, это ты плохо настроил базу!»
Или стенд плохо развернул. В рамках стандартных ролей здесь получается серая зона. Админы говорят: «У вас всё есть, вы можете всё сделать». Разработчики отвечают: «Я код пишу». Тестировщики вторят: «Я тестирую». Хорошо, а кто будет мякотку-то делать? Кто будет настраивать конфиги для пайплайнов и для автоматизаций?
Работа с CI/CD, процессами Continuous Delivery/Continuous Integration занимает довольно существенное время. Кто-то должен это делать. И QAOps — это мостик между тестированием, пайплайнами CI/CD и DevOps. По нему можно идти и со стороны QA, и со стороны DevOps. Важно, что двигаться должны обе стороны.
SDET (Software Development Engineer in Test), в свою очередь, стал мостиком между разработчиком и тестировщиком или автотестером. Этот термин пришел к нам из Microsoft, потом его переизобрели в Google. Есть любопытная книга «Как тестируют в Google». В ней красиво обозначили идею, что за качество кода отвечает разработчик. Только вот SDET, или точнее SET, в их терминологии, считаются тоже разработчиками, поэтому обычных тестировщиков у них почти нет, они могут себе позволить такой подход.
То есть лидирующие компании уже поняли, что им нужен инженер — человек, который разрабатывает что-то более сложное, чем просто тесты. Это приложения, фреймворки и инструменты для анализа качества продукта на разных уровнях и для разных компонентов системы. В целом это просто разработчик (или условный архитектор) — но в доменной модели тестирования.
Machine learning и Big data
Так как большие данные, машинное обучение и работа с этими моделями активно развиваются, то появилась и тема качества данных для Big Data и ML. Вся эта большая машина движется в сторону усложнения: больше, выше, дальше. И тестировщикам нужно быть профессиональнее, чтобы лучше понимать технологии и то, с чем ты работаешь.
Потому что систему, построенную с помощью машинного обучения, часто невозможно провалидировать каким-то фиксированным набором сценариев или строго предопределенными сценариями. Потому что такая система в одной и той же ситуации, но в разное время, может выдавать разный ответ. Во всех случаях этот ответ будет валидным. Какой-то чуть лучше, какой-то — чуть хуже, но это не баг.
Современные тестировщики используют всё более сложные и разветвленные способы валидировать качество таких систем. Например, используется статистическая оценка качества. А инженеры по тестированию таких систем должны уже знать многое про математику, а что-то — из статистики. Станет всё это частью обычных требований к специалистам тестирования или останется узко специализированной нишей, в которой надо будет отдельно развиваться и отдельно глубоко закапываться — покажет время.
На недавно появившейся конференции TestDriven Conf будут доклады про ML, качество данных и тестирование голосовых помощников, там как раз будут это все обсуждать. Приезжайте на конференцию — узнаем вместе, куда развитие пойдет.
Посмотрим теперь, какие навыки и какие специалисты нужны сегодняшнему рынку.
Куда развиваться тестировщику
Базовые вещи
Для начала важно понимать, как вообще работают информационные системы, какие ресурсы бывают в компьютере и как они связаны. А также —зачем нам ОС, как работает этот ваш интернет и как хранятся данные. Важно понимать какие-то стандартные архитектурные паттерны икакие бывают инструменты, которыми пользуются разработчики.
Сам тестирование начинается с того, что мы, собственно, тестируем. Есть web тестирование, десктоп и мобильные приложения. Отдельно стоит GameDev, хотя он, конечно, может в себя включать и мобилки, и браузер, и десктоп. Но прежде всего — это игра. В первую очередь в GameDev тестируют игровые механики, логику и функционал, проверяя то, насколько теоретическая модель соответствует её имплементации.
Есть базовые виды тестирования, такие как функциональное или E2E-тестирование, тест-дизайн и исследовательское тестирование. Есть функциональные и нефункциональные требования, и важно их различать между собой — чем они отличаются и зачем вообще нужны. Хорошо бы представлять себе, какие бывают стратегии тестирования, как они реализуются и почему — именно таким образом.
Тестировщику нужно хорошо разбираться в том, как работает цикл разработки. Представлять, как работает тестирование в форматах разработки: Agile, Scrum, Waterfall, Kanban, V-модель.
Вглубь или вширь?
Все знают, что совершенствоваться в своей профессиональной области можно, как минимум, в двух стратегиях. А Дэвид Гэст в конце прошлого века дал нам еще концепцию T-shaped специалиста.
/Если работа тестировщика усложняется, требования к нему повышаются и ему надо больше уметь делать, то, кажется, что специализация возникает естественным образом. То есть первое направление — это глубже копать в свою область, узнавать и овладевать новыми инструментами, интересоваться, что другие делают. Становиться I-специалистом или экспертом только в одной области.
Второй путь — дженералист. Это широта взглядов и общее понимание не только теории тестирования, но и всех смежных ролей — разработка, менеджмент проектов, аналитика, администрирование. Одно дело, когда вы умеете хорошо программировать скрипты для теста, а другое — когда вы в принципе понимаете, что они должны делать и для чего. Дженералист определяет, как решать задачу оптимальнее и с чьей помощью.
Баланс между обучением вглубь, в свою специализацию, и обучением вширь, в понимание общей теории тестирования, выглядит как T-shaped-специалист. Но является ли это балансом?
T-shaped могут быть и автоматизатор, и функциональный тестировщик, тестирующий вручную. Например, автоматизатору требуется не так много понимания языка программирования, потому что код для тестирования чаще всего несложный, хотя бывает по-разному, конечно. Для него важнее — хорошо разбираться во фреймворке, с которым он работает, и с той системой CI/CD, на базе которой реализуются автотесты.
История автоматизатора в том, чтобы хорошо, быстро и эффективно писать тесты, а ширина взглядов ему нужна, чтобы понимать продукт и уметь передавать тесты, в том числе — в команду. Иначе можно очень сильно обжечься. Например, полгода разрабатывать 500 тестов для продукта. А позже узнать, что их просто выкинули, потому что никто их не использует и не обновляет. Поэтому автотестировщик должен очень хорошо должен понимать, как работает команда, как работает сервис, и что на самом деле он тестирует, важно закрывать потребности команды, а не просто выдавать код.
Это приводит нас к тому, что знание своей предметной области, специфики компании — тоже необходимо.
Изучение предметной области
Тестировщикам важно не только понимать продукт в плане, как он разворачивается и ставится. Важно знать, зачем он вообще нужен, какие задачи решают пользователи этого продукта, какие у них есть проблемы и какие им нужны знания.
Это нужно, чтобы правильно интерпретировать формальные требования, с которыми человек сталкивается. Может быть, даже находить в этих требованиях ошибки, чтобы сразу сказать: «Ребята, мы это сделали, вроде бы формально правильно, но это не имеет смысла — вы уверены, что хотели именно это?»
Сейчас в ИТ-индустрии работу меняют часто. Но все же есть некие устоявшиеся нормы, что 2-3 года для смены вида деятельности, перехода на новую ступень, либо изменений направления развития — это нормальный срок. И 2-3 года — это достаточный срок, поэтому имеет смысл погрузиться в специфику, в которой вы работаете. К тому же на рынке в каждой специфике работает много компаний — вы всегда можете перейти в другую компанию, но заниматься той же самой предметной областью.
Если это рынок финансовых услуг или телеком, то вариантов, куда перейти, там даже больше, чем несколько. Компания с большей охотой примет на работу тестировщика со знанием ключевой области, так что это хорошее вложение времени и сил.
Управленческие амбиции
У тестировщика, как и любого другого человека, могут быть управленческие амбиции. Мы можем хотеть развиваться не только как технические специалисты, но и прокачивать навыки для управления командой, для технического лидерства над командой тестирования. Но что должны уметь руководители команд тестирования и чего от них спрашивают на собеседованиях? И где это все брать и изучать?
В первую очередь, руководители обязаны очень хорошо знать всю основу и теорию. Они должны уметь не просто рассказать теорию, а сделать это легко и понятно. Ричард Фейнман, американский физик сказал: «Если вы учёный, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан». Это применимо и к тестированию, и вообще к любой области знаний. Техническому лидеру и менеджеру нужно не просто хорошо знать, но и уметь очень хорошо доносить, объясняя простыми терминами довольно сложные концепции.
Руководитель должен хорошо понимать процессы, цикл разработки, а так же как в него должны включаться функциональное и автоматическое тестирование.
Административная менеджерская работа становится очень сложной именно потому, что к хорошим техническим навыкам в обязательном порядке добавляются софт-скиллы. Это хорошие навыки работы и с командой, и с мотивацией, и с управлением ожиданиями. Такое направление сейчас тоже уже появилось — это QA-лиды и QA-хэды.
То есть они могут фигачить конкретную техническую работу, но при этом они должны быть коммуникаторами, должны уметь слушать и рассказывать, команду продвигать и мотивировать, все процессы выстраивать. Это тот логичный набор софт-скиллов, который требуется, если у вас есть желание руководить.
Мы чуть-чуть коснулись, куда направлена общая тенденция рынка и каких навыков и специалистов он требует. Теперь посмотрим, где и как можно научиться тестированию.
Обучение тестировщиков
Фундаментальное образование
В прошлом веке, когда многие учились программированию, вообще не было курса по тестированию. Про юнит-тесты никто не думал, хотя мы и страдали от этого. Например, банально было трудно вносить изменения в то, что уже работало.
Но, к сожалению, нельзя с уверенностью сказать, что и сейчас появилось какое-то базовое образование по тестированию. Все продолжают затачиваться на программистов. Им могут дать факультативом какую-нибудь историю про Test-driven development, но на этом всё.
Да, юнит-тесты, TDD и иже с ними стали гораздо популярнее у разработчиков. Некоторые даже ими пользуются. Но отсутствие теоретической базы по тестированию очень заметно. Нахватавшись вершков на практических вещах на небольшом проекте, человек думает, что знает всё про тестирование. Он уверен, что представляет, как оно работает: «Я же тестировал, у меня были задачи, я их решал. Что тут сложного? Смотришь, переводишь».
К сожалению, системного подхода в индустрии тестирования всё еще нет. Могут помочь стандарты, но их мало.
QA-стандарты
Первый стандарт, который гарантирует нам некое обучение — это например ISTQB или аналоги. Им занимается некоммерческая организация, представленная восемью европейскими странами. Он позволяет инженерам по тестированию получить международный сертификат. Но в целом он закрытый, даже не в плане информации, а в плане подстройки под современные требования. Технологии развиваются быстрее, чем эти стандарты формируются и формализуются. Поэтому большие проекты и компании пока еще ставят задачи по-прежнему: «Забудьте всё, чему вас учили. Мы научим, как делать правильно».
В сообществах тестировщиков время от времени зарождаются дискуссии, которые могут перерастать в точки сборки для базы знаний по тестированию. Но это часто не про доступ для всего комьюнити тестировщиков. Главной базы знаний, чтобы всем сообществом тестировщиков ее обсуждать, обновлять и развивать — пока что нет.
Мы хотим попытаться собрать общедоступный roadmap, которым пользовался бы каждый тестировщик — как для самообучения и развития, так и для вхождения в специальность. Который расскажет про реальные потребности и навыки. Они пригодятся на практике, а не гипотетически в сферическом вакууме. Нужна такая теория, чтобы развивалось и углублялось наше понимание того, что мы делаем, и почему мы делаем именно так.
На этой основе можно будет уже разрабатывать таблицы компетенции для тестирования: куда может развиваться тестировщик и куда должен.
На TestDriven Conf пройдет круглый стол на эту тему. Представители QA-направления, кто давно занимается качеством на разных уровнях и в разных технических доменах, будут обсуждать тему, как сейчас учат тестировщиков и какие есть варианты обучения.
Затронем и тему изменений, что происходят сейчас в требованиях к навыкам, к софт- и хард-скиллам тестировщиков. Вся эта информация будет структурирована, чтобы появилась точка кристаллизации для создания основной базы знаний. В ней будет о том, как можно развиваться тестировщикам: куда что ведет, какие книги и статьи почитать, какие есть ресурсы по этому направлению. В итоге мы получим roadmap и материалы к нему. Примерный черновик такой общедоступной библиотеки уже существует.
Конференции вообще помогают получать инсайты, как совершенствовать свои скиллы и развиваться.
Заключение
Новая реальность в тестировании — это действительно сложный вопрос. Есть ощущение, что мы поскребли этот айсберг чуть-чуть сверху. Но в толще воды есть много конкретных деталей и скиллов, инструментов, книг и прочих вещей. И круглый стол, который будет на конференции TestDriven, и секции, и сама конференция должны дать образовательную повестку для зрителей — чтобы развить гораздо больше то, что у нас есть сейчас. Хочется, чтобы люди могли находить для себя ресурсы, направления и интересные области для развития.
TestDriven Conf 2021 пройдёт 1-2 ноября в Москве. Тезисы докладов, билеты и вся информация о конференции — всё здесь.
Автор: Закирьянов Даниил
