Многие IT специалисты, особенно те, которые только находятся в начале  карьерного пути, часто задаются вопросом: “А какие сертификаты котируются / ценятся при устройстве на работу?”. Этот вопрос можно переформулировать так: “Какую бумажку мне надо получить, чтобы взяли на работу без собеседования или  не задавали сложные технические вопросы?”. К сожалению, за 10 лет  опыта работы в IT я так и не нашел такую волшебную грамоту, которая могла бы удовлетворить и тех, кто собеседует меня, и тех, кого собеседую я. Однако, это не значит, что все они бесполезны. В цикле “Сертифицированный тестировщик” я хочу разобрать, какие сертификаты и экзамены бывают в мире обеспечения качества, а также поделиться своим опытом их сдачи, и что из этого мне пригодилось. Первая часть будет включать только общий обзор различных типов сертификатов и выводы о мотивации их получения без привязки к тестированию. В следующих же частях мы  рассмотрим конкретные примеры сертификатов, которые могут быть полезны и интересны тестировщикам.

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

Для начала дам немного контекста, чтобы вы поняли  мой предыдущий бэкграунд. Я работаю в IT на позициях QA Lead / SDET в зарубежных компаниях уже более 7 лет. Как и большинство из нас изучал язык еще в школе, но делал это крайне неохотно, давалось через силу. Скажу кое-что страшное  для лингвистов: транскрипцию я так и не запомнил. Но в целом на 4 из 5 баллов в обычной ГОУ СОШ вытягивал. Все шло гладко и после поступления в технический институт. Первые два года английский был насыщенный, но спрашивали не строго. Была возможность изучать язык в растяжку для зачета, опять же  без сильного рвения. Начиная с третьего курса мир перевернулся. 

Наш вуз подписал партнерское соглашение с IELTS, и тогда мы в обязательном порядке должны были его сдать к концу четвертого курса хотя бы на 4.5 балла (из 9). Для тех кто не в курсе: IELTS – это один из двух самых популярных экзаменов для поступления в зарубежные вузы наравне с  TOEFL. Кажется, что 4.5 балла из 9 это не так уж и много, но когда я впервые погрузился в секции reading и listening, то понял, что дела плохи, ведь IELTS прежде всего заточен, прежде всего, на академический английский, где приходится читать тексты и писать эссе не про “курочку Рябу”, а про  глобализацию, сельское хозяйство, астрономию и прочее. Тогда было довольно страшно, а сейчас я благодарен своему вузу (привет, МИСиС) за такую инициативу. Ведь хочешь не хочешь, а надо было получить зачет. Пришлось основательно погрузиться в язык, качественно делать домашнюю работу, регулярно учить новые слова на незнакомые темы. Помимо трех занятий в неделю в вузе, я еще посещал курсы английского в школе BKC. 

Одной из очень спорных и обсуждаемых тем в автоматизации тестирования является выбор языка программирования. Особенно, когда речь идет о связке с самым популярным инструментом автоматизации – Selenium WebDriver, ведь он  имеет официальную поддержку пяти языков: Java, C#, Python, JavaScript и Ruby. В дополнении к этому существует большое количество реализаций на других языках. Так что же нам  лучше выбрать?

Опытный автоматизатор, хоть раз программирующий с использованием более чем одного языка, без сомнения  скажет, что важна задача, а не инструмент. В этом и состоит большая разница, когда мы говорим “программированием на языке” или “программируем с использование языка.” При программировани с использование языка мы отталкиваемся от цели, для которой мы выбрали какой-либо язык программирования. Приведу пример: мы не хотим программировать на языке Swift,  а хотим разрабатывать IOS приложения (это цель) и тогда, конечно же, мы должны освоить Swift, а не Java. Когда же мы говорим про автоматизацию тестирования,  нашей целью может быть уменьшение времени ручного регресса за счет написания автотестов. Оно  включает разработку многоуровневого фреймворка, подключение сторонних библиотек, оберток для интеграции вспомогательных инструментов, написание PageObjects для декомпозиции и инкапсуляции работы с элементами страницы / экрана приложения. Как видите, эти задачи не привязаны к платформе, технологии и какому-либо языку программирования. Именно поэтому в большинстве случаев в работе тестировщика-автоматизатора язык программирования является вспомогательным фактором.

В прошлых частях серии “QA Lead и точка: Часть 3”  и “QA Lead и точка: Часть 4”  мы говорили о возможных ролях лида. Пришло время перейти к вопросу формированию нашей команды.

Для начала разберемся какие бывают команды. Два самых популярных подхода, которые применяются в большинстве компаний, это “функциональный” и “кросс-функциональный”. Подход с функциональными командами более классический. Такие команды состоят из сотрудников одного направления (QA,  Frontend разработчики, Backend разработчики итд) и лида (руководителя команды). Современный и “модный” кросс-функциональный подход подразумевает наличие разных специализаций в рамках одной команды. А если быть точным, то должно быть наличие всех необходимых навыков внутри команды для успешного выполнения работ над проектом, так как кросс-функциональная команда независима и самодостаточна. Также в некоторых компаниях комбинируют оба подхода. В таком случае один и тот же сотрудник в рамках кросс-функциональной команды занимается продуктовыми задачами, а в контексте своей функциональной команды выполняет технические улучшения,  влияющие на всю организацию и ускоряющие работу нескольких кросс-функциональной команд.

Чаще всего, когда мы употребляем сочетание team lead команды, мы имеем в виду лида кросс-функциональной продуктовой команды. Но, так как наша  серия статей связана с позицией QA Lead, рассмотрим дизайн функциональной QA  команды.

В прошлой статье “QA Lead и точка: Часть 3”  мы рассмотрели список ролей, в которых может участвовать QA Lead и любой руководитель подразделения. Это роли наставника, эксперта, ментора, коуча и процессного управленца. Все они,  разве что за исключением последней, связаны с взаимодействием вас, как более опытного сотрудника, с другими участниками команды и нацелены на получение каких-либо знаний от вас или выход на путь к достижению целей самостоятельно. Этот список был бы не полный без таких двух важных ролей как фасилитатор и амбассадор. В большинстве компаний это то, что ожидается от опытного сотрудника на руководящей позиции. Рассмотрим каждую из них в отдельности.

В прошлой статье QA Lead и точка: Часть 2 мы обсуждали, как QA лиду оставаться на пике формы и какие способы обучения  для этого выбрать. В  третьей части, мы поговорим про гибкость, а именно про возможность и готовность примерить на себе разные роли, которые, в зависимости от контекста, так или иначе возлагаются на руководителей команд и подразделений.

Все мы знакомы с термином “DevOps”.  Для кого-то это смежный отдел в компании, а для кого-то – коллега из соседней комнаты. Но в первую очередь это методология, которая меняет и проходит через  множество процессов разработки. Автоматизация тестирования здесь не является исключением. Автотесты неразрывно связаны с такими понятиями как «непрерывная интеграция», «непрерывное развертывание», “pipelines”, ведь тесты мы пишем не для себя и не для запуска  на нашей локальной машине. Для автоматического запуска тестов всей командой необходимо настроить приличное количество компонентов, тут мы и обращаемся за помощью к DevOps отделу. В этой статье мы рассмотрим базовые технологии и инструменты из мира DevOps, необходимые для запуска E2E тестов, написанных с помощью Selenium для Web и Appium для mobile.

В IT индустрии используется большое разнообразие инженерных культур и практик, таких как Agile, бережливое производство (lean software development), DevOps. Все они так или иначе нацелены на бесперебойную доставку ценности за счет повторяемых коротких итераций. Неотъемлемой частью такого подхода является конвейерный подход или по-английски – pipelines. Подразумевается, что в идеальном мире разработчик заливает код на сервер и дальше происходит магия, состоящая из автоматизированных этапов сборки проекта, контроля качества кода, запуска тестов и сбора метрики. На рынке существует большое количество платных и бесплатных инструментов для настройки такого процесса, который мы называем “процессом непрерывной интеграции” или CI/CD (Jenkins, GitLab CI, Teamcity и д.р.). Однако для построения действительно зрелого процесса недостаточно просто установить инструмент. За каждым этапом конвейера стоит сложная логика того, что должно быть запущено, на каких вычислительных ресурсах и как эти ресурсы используются.

На собеседовании кандидаты очень часто гордо говорят, что знают CI/CD. Но знать можно по-разному. Одно дело нажимать кнопку запуска и смотреть, какой цвет получился: красный или зеленый. И совсем другое дело настраивать весь флоу от и до самостоятельно, чем обычно и занимаются DevOps инженеры. Для проверки глубины знаний я задаю базовый вопрос, на который очень редко получаю ответ: “А в чем разница между CI и CD ?”. Далее я хочу поделиться своим пониманием отличий CI от CD и от еще одного CD на примере запуска автотестов. Заранее предупрежу, что мое видение может частично отличаться от вашего. Ведь у всех нас немного разный опыт, разные проекты и источники для изучения, которые могут расходиться. Главное, что какое-то видение у вас есть!

В прошлой статье: QA Lead и точка: Часть 1 мы обсуждали, что QA лиду необходимо развивать T-shape компетенции для комфортного взаимодействия с другими отделами. Более того, важно не забывать про актуальность навыков, связанных с основной специализацией, ведь, как мы знаем, в IT информация устаревает очень быстро и нужно быть готовым к регулярному обучению длиною в жизнь. В то же время было упомянуто, что QA Lead много времени посвящает коммуникациям, планированию, менторингу. Встает вопрос: «как и когда развивать свои основные технические навыки, не говоря уже о развитии в ширину по смежным направлениям?». В этой статье обсудим, какие форматы обучения бывают, и сопоставим их с широко известными четырьмя этапами обучения.

Представьте ситуацию: вы Senior QA Engineer, давно работаете в компании, хорошо знаете ее внутреннюю кухню, стек технологий, все темные уголки продукта. Неожиданно к вам приходит руководитель или руководитель вашего руководителя и сообщает новость, что текущий QA Lead команды уходит, а, как известно, «свято место пусто не бывает», и кто-то это самое место должен занять. Как раз вы являетесь тем самым классным специалистом, который может претендовать на новую должность с последующим увеличением компенсации в случае успеха. Знакомая картина? По моему личному опыту и опыту моих коллег именно так и становятся впервые лидами. Но, как мы знаем, «с великой силой приходит великая ответственность». Уже недостаточно быть просто продвинутым инженером и разбираться в своей области. Серия статей «QA Lead и точка» должна помочь сориентироваться в будущих обязанностях и ожиданиях от вас.

Часть 1: Web / Android