ISTQB (International Software Testing Qualifications Board) это международно признанная программа сертификации специалистов по тестированию. Для получения сертификата ISTQB необходимо успешно сдать экзамен, организованный уполномоченным провайдером.
image
На сегодня существует три уровня сертификации: базовый (Foundation), продвинутый (Advanced) и экспертный (Expert), причем наличие соответствующего сертификата предшествующего уровня является одним из условий для прохождения сертификации последующего уровня. Продвинутый уровень разделен на несколько модулей, об одном из которых пойдет речь в данной статье — Test Manager.
Дабы не уходить далеко в оффтоп, подробнее со схемой доступных квалификаций можно ознакомиться на официальном сайте www.istqb.org.

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

Как проходит экзамен


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

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

Экзамен длится 225 минут, из которых 45 — добавочные для тех, кто сдает экзамен не на родном языке. Бонусное время приходится очень кстати, так как, в отличии от Foundation Level Exam, в качестве вопросов вас ждет около 50 страниц текста, чтение которого и займет большую часть выделенного времени.

Для успешной сдачи достаточно набрать 65% баллов (не путать с количеством правильных ответов). Разные категории вопросов имеют свой вес, например, ситуационные вопросы, как правило, дают больше баллов, чем прямые вопросы по терминологии и определениям.

Собственно, о подготовке


Исчерпывающий материал для подготовки я получила из книги ex-президента ISTQB Рекса Блэка — Advanced Software Testing — volume II. Там же, в конце каждой главы, приводятся примеры вопросов, в дополнение к тем, которые даны на офицальном сайте www.istqb.org (раздел Exam Documents).

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

Testing Process & Test Management


На эти два тесно связанных пункта приходится около половины всех баллов, поэтому есть смысл сфокусироваться именно на них.
Вопросы теста в основном следуют risk-based подходу в тестировании. Концепция данного подхода заключается в распределении QA ресурсов исходя из вероятности возникновения дефектов и критичности той или иной функциональности. Под риском в данном контексте подразумевается quality risk, который, в случае своего осуществления, снижает качество ПО, а процесс тестирования определяется как прямой способ сокращения рисков.

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

Reviews


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

Defect Management


Для ответа на вопросы, которые попались мне, было достаточно опыта работы с баг-трекером и здравого смысла.
Вопросы касаются жизненного цикла дефекта, его атрибутов и использования статистики для оценки и улучшения процесса тестирования и разработки. Например, может быть полезна такая информация, как фазы внедрения и обнаружения дефектов (phases of introduction and detection), причины возникновения (root cause), затронутые компонент или функциональность (для выявления defect clusters).

Improving the Testing Process


В рамках этого раздела предлагается изучить и запомнить такие понятия, как TMMi (Testing Maturity Model integration), TPI Next (Test Process Improvement Next), CTP (Critical Testing Processes), STEP (Systematic Test and Evaluation Process), а также IDEAL model (Initiate — Diagnose — Establish — Act — Learn) и некоторые другие аббревиатуры, их расшифровки и принципы. Это все — промышленные стандарты или фреймворки по улучшению процесса тестирования.

Test Tools and Automation


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

People Skills


Хотя человеческий фактор — один из основных аспектов успешной и производительной команды, тема построения и мотивации такой команды в материалах модуля ISTQB Test Manager покрывается весьма поверхностно.
Данный факт упрощает подготовку к экзамену, однако в целях личного развития имеет смысл обратиться к другим источникам (пример из собственных предпочтений — leadership и мотивационный team management от Брайана Трейси).
Вопросы теста по этой теме предполагают оценку сильных и слабых сторон команды тестирования на довольно простом уровне в разрезе требуемых навыков, составление плана восполнения выявленных пробелов с помощью обучения сотрудников или расширения команды.

Зачем всё это?


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

Практическую пользу данной сертификации можно сравнить с прочтением хорошей книги по тест-менеджменту. В материалах экзамена подробно рассматриваются темы планирования, тест мониторинга, отчетности, оптимизации процессов контроля качества на разных этапах SDLC в концепции авторского risk-based подхода, что, как правило, сопоставимо с обязанностями QA специалистов уровня Senior/Lead. Кроме этого, автор книги, рекомендованной выше, в процессе повествования часто обращается к своему опыту работы консультантом в области тестирования и обеспечения качества ПО, предоставляя возможность ознакомиться с альтернативными решениями спорных вопросов на примерах из опыта зарубежных коллег, что также представляет определенный интерес. Хотя сдавать сам экзамен при этом, конечно, не обязательно.

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

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

Полезные ресурсы


  • www.istqb.org — общая информация, силлабус, примеры вопросов;
  • www.rstqb.org — представительство ISTQB в России;
  • Rex Black Advanced Software Testing — volume II, 2014 — подробное руководство по подготовке к сертификации;
  • www.gasq.org/en/certification/sample-exam.html — пробный экзамен онлайн;
  • Rex Black Critical Testing Processes, 2003 — об организации risk-based процесса тестирования, есть в переводе;
  • Brian Tracy Full Engagement, 2011 — о мотивации сотрудников, есть в переводе.

Комментарии (3)


  1. lxsmkv
    12.12.2017 03:44

    Будешь знать пару красивых словечек, чтобы писать в отчетах ;)

    Не знаю, у меня хоть и есть сертификат, и я по началу даже немножко гордился им, через три года понял, что только мозги, твои собственные, и твое желание быть полезным делают из тебя годного тестировщика. Ты перестанешь на собраниях говорить умные словечки из сертифката, а начнешь изьясняться так чтобы тебя поняли.
    Вот пару типичных фраз из собраний:
    «А какое мы делаем тестирование функциональное или регрессионное?»
    «Нам нужно определиться со стратегией тестирования.»
    «А что мы вообще хотим тестировать?»
    «Тесты должны быть независимыми»
    «UI тестирование должно опираться на модульное тестирование» (намек на пирамиду)

    А на деле все это бесполезные рассуждения. В жизни все иначе.
    У тебя есть «драйвер» для доступа в систему, какое-то знание системы, (а еще больше незнание), пишешь код, который говорит тебе да или нет, ну или зеленый и красный (желтый — от лукавого). Либо он попадает в проблемное место либо нет, если нет, увеличиваешь покрытие или усиливаешь тест пока не станет попадать. Нашел проблему — задокументируй ее тестом. В коде теста указывай ссылку на багрепорт. Узнал что-то новое о поведении системы — задокументируй это тестом, если некогда — поставь таск. Если за тестами не следить они отстанут от приложения, если не заводить репорты на найденные ошибки — тестирование бессмысленно. Если тест красный, прежде чем адаптировать скрипт под приложение — дважды подумай, выпей чаю и спроси техлида. В багрепорте только сухие факты и кратчайший способ воспроизведения.
    Вот и вся теория которой я пользуюсь.

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

    Но foundation level стоит сделать, особенно если его оплачивает фирма. Хуже точно не будет. Во всяком случае когда не хватает систематичности, можно покопаться в теории — немного полегчает, потом убедиться, что для практического применения этой методики просто нет ни ресурсов ни входных условий (как например, нормальной документации) и пойти опять делать исследовательское тестирование и автоматизировать «на глаз».

    Для тех кто дочитал — бонус-трек:
    Журнал «Тестировщик-автоматизатор», из рубрики «Это интересно»:

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


  1. barsovichok
    13.12.2017 22:44

    Интересно, а насколько он нужен не в российских реалиях?


    1. SheWolf Автор
      13.12.2017 23:14
      +1

      Популярное требование в EU и US, варьируется от конкурентного преимущества до must have