Тестирование и QA: интервью с Натальей Руколь

О работе тестеров программного обеспечения рассказывает Наталья Руколь, за спиной которой — огромный опыт выстраивания процессов QA. С её участием выполнено более 10 крупных проектов по разработке ПО, включая крупномасштабные решения по резервному копированию данных True Image, коммерческую операционную систему Lynx OS, системы документооборота крупных правительственных организаций России и США, антивирус Касперского.

Начало карьеры

Я очень долго искала себя: чувствовала интерес к ИТ-отрасли, но своё признание в ней никак не находила. Я успела поработать системным администратором, разработчиком сайтов, аналитиком, прежде чем абсолютно случайно столкнулась с тестированием.

Хорошо помню, как мне трепетно передали синенькую потрёпанную книжечку и сказали: «Это — Библия». Так я прочитала Сэма Канера.

В его книге было описано столько интересного и на тот момент не очень понятного, что я перечитала её дважды. В компании, в которой я на тот момент работала, я увидела все описанные им проблемы, недоработки. Ужаснулась: как можно знать об этом и не исправлять, не улучшать, не совершенствовать? Тогда я и почувствовала, что преодолеть это и прийти к идеальному тестированию — возможно, и есть моё призвание.

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

Переход на руководящую должность сместил ориентиры: я почувствовала необходимость развивать абсолютно новые навыки. Один из моих друзей и наставников, Дима Обрезков, принёс мне тогда 10 книг и сказал: «У тебя есть две недели. Читай!».

Я очень боялась допустить какие-то ошибки, поэтому внимательно всё читала и тренировалась. Управление проектами, персоналом, постановка задач, делегирование, мотивация…

Голова от массы новой информации шла кругом, но всё надо было усвоить: чтобы попрактиковаться, я составила по этим книгам карту мотиваторов моей мамы и устроила собеседования всем друзьям!

С управлением непосредственно тестированием было сложнее: информации на русском языке тогда почти не было, и приходилось самой экспериментировать и учиться на боевых задачах: как оценить качество? почему мы пропустили ошибку? как помирить разработчиков и тестировщиков? как успеть выполнить все задачи вовремя? До этого стояла простая и понятная цель: найти максимум ошибок. А тут вдруг оказалось, что целей значительно больше, и поиск ошибок — только средство для их достижения.

Сейчас я нахожусь «в свободном плавании» — провожу тренинги, консультирую, пишу статьи. Очень много читаю англоязычной литературы по тестированию: в Америке эта отрасль находится в значительно более развитом состоянии. Ищу интересные подходы, разрабатываю новые, адаптирую их для наших условий. Это безумно интересно — видеть своё влияние на отрасль, предугадывать её развитие.

У меня два повода для гордости. Во-первых, это множество выпущенных качественных программных продуктов, зачастую с мировым именем (Paragon, Acronis, Kaspersky и т. д.), ежедневно помогающих миллионам пользователей. Я очень горжусь, что участвовала в их создании и способствовала их высокому качеству: процесс выпуска ПО — это процесс материализации идей и мыслей, и мне посчастливилось работать во многих компаниях с по-настоящему смелыми, иногда даже дерзкими идеями!

Второе и, возможно, самое важное для меня — это сформированные команды. Вкладывая душу в развитие сотрудников, помогая им понять себя и формируя действительно успешные мотивированные команды, я развиваю и отрасль в целом и помогаю многим людям найти себя. Разве не повод гордиться?

Работа QA

Следует разделить понятия QA и тестирования. Тестирование — процесс оценки качества продукта, а QA — это формирование процессов, которые обеспечивают высокое качество ПО (в том числе и процессов разработки, аналитики, документирования).

В основном, когда говорят о QA, имеют в виду тестирование: во многом потому, что процессное управление пока что не очень распространено в России, многое делается по интуиции.

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

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

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

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

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

Тест-инженеры же либо проверяют предварительно спроектированные тест-дизайнером тесты, либо, при использовании так называемого исследовательского тестирования, изучают продукт, проектируют тесты и тестируют его одновременно! Но вне зависимости от роли, тестировщики каждый день стоят на страже качества ПО, много и часто используют свой продукт, придумывают способы его «сломать», и всё это идёт продукту на благо!

И, кстати, не стоит считать, что тестирование — отличная работа для социофобов: тестировщики не сидят круглые сутки, упёршись в монитор и пытаясь напакостить разработчикам.

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

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

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

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

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

Движущие силы

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

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

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

А вообще, что касается двигателя, один очень мудрый человек мне однажды посоветовал почаще делать то, чего я боюсь — почти как в фильме «Всегда говори „Да“!» Постепенно это входит в привычку, в итоге не бывает какого-то жизненного «застоя»: рядом всегда есть что то, что пока что кажется недостижимым и потому страшным — движение в эту сторону обычно и ведёт к развитию, привносит интерес, драйв и уважение к себе.

Путь тестировщика

В тестировании ни в коем случае нельзя полагаться на теорию. Она важна, но мало что дает без дополнения практикой. Поэтому самое главное — эксперименты! Исследовать себя, чтобы понять, чем больше всего хочется заниматься. Опробовать методики, чтобы действительно уметь их использовать. Поработать в разных компаниях и проектах, чтобы понять, какие окружения в работе больше «Не верь — проверь!» — девиз тестировщика, и в карьере это так же важно, как и в тестировании.

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

Хороших специалистов в тестировании очень мало, а истинных джедаев-профи ещё меньше.

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

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

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

От компании зависит очень многое: не рекомендую в начале карьеры формировать своё мнение обо всей отрасли по первому опыту. Многое зависит от уровня зрелости процессов, многое от приоритетов — есть компании, нацеленные на выпуск качественных продуктов, а другие готовы выпустить чего угодно, лишь бы вовремя. В разных компаниях и продукты, и задачи, и атмосфера разная, классифицировать сложно, важно искать то, что по душе. Один мой бывший коллега поменял за пару лет, наверное, мест десять работы, и для HR’ов казался «летуном». А года два назад он устроился в крохотную компанию, занимающуюся веб-разработкой, и даже мысли не держит менять работу: наконец-то ему всё понравилось.

Что касается заинтересованности в наших специалистах за рубежом — это, к сожалению, не про тестирование.

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

Зато некоторые русские глобализованные компании предлагают перспективы работы в других странах: к примеру, россиийский NetCracker помогает своим сотрудникам с переездом в страны внедрения проектов, а это Австралия, Германия, Канада и другие.

Напутствие начинающим

Не бойтесь неудач! Мне часто было сложно, иногда что-то не получалось, но я ни в коей мере не могу назвать что-либо неудачей. Каждый полученный опыт — это осознание правильности тех или иных действий, обратная связь, которая позволяет совершенствоваться. Весь мир — тестирование, и когда у нас что-то не получается — это заведённая ошибка, которую мы можем исправить. Допускать ошибки не страшно, главное — исправлять их!

Куда копать?

Тестировщикам, в первую очередь, необходим опыт. Локализация и заведение ошибок, генерация тестов на лету, «понимание» продукта — это непросто и изучить по книжкам невозможно! Но методологическая подготовка тоже необходима, для её получения помогут чтение книг и развивающихся в последнее время блогов по тестированию.

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

Изучение тест-дизайна ещё сложнее, чем освоение тестирования: профильной литературы на русском языке нет вообще. Зато на английском есть настоящая библия тест-дизайнеров, написанная Ли Копландом. Кстати, тестерам она тоже будет очень полезна.

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

Выбор инструментов огромный: IBM (Rational), Segue Silk Test, HP QTP, Test Complete, Selenium — лишь основные из них.

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

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

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

Я приведу некий минимальный набор литературы, которую, на мой взгляд, должен прочитать любой уважающий себя тест-менеджер — не вся она про тестирование и не вся доступна на русском языке, но, тем не менее, эти книги я считаю самыми необходимыми: Процессы тестирования Подбор и управление персоналом Мотивация команды Управление проектами Коммуникации в ИТ Управление рисками