Сертификация qa специалиста по istqb. базовый уровень (ctfl)

Официальный тест на IQ

Международный IQ Test — это простая и элегантная система оценки, которую можно использовать
в режиме онлайн. Ее легко понять, весело принять и трудно освоить. Это связано с тем,
то что перед вами
настоящий тест,
который призван бросить вам вызов и дать точный результат.

Ответы на все вопросы позволят вам быстро определить текущий уровень вашего IQ. Ограничение по
времени составляет всего 24 минуты, чтобы ответить на все 35 вопросов. Вы заметите, что некоторые
вопросы будут легкими, а другие – почти невозможными, при этом, все полностью зависит от того,
как вы ответите на каждый вопрос.

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

Бесплатная версия

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

Платная версия

Заплатив всего $6.99 (USD), вы получите отчет в формате PDF, который включает в себя точный результат,
а также правильные ответы вместе с логическими объяснениями того, как решать головоломки.
Кроме того, вы сможете сравнить свой результат с данными жителей нашей планеты.

Что делает тестировщик

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

Само тестирование происходит по множеству разных сценариев. Например, так:

Тестировщик открывает продукт как пользователь и проходит все стандартные сценарии — как будет происходить у 80% всех людей. Все баги фиксирует.

Можно попробовать взломать продукт: вместо имени ввести код; добавить в корзину бесконечное количество товаров; добавить в корзину −1 (минус один) товар; добавить в корзину больше 40 тысяч товаров (и перегрузить переменную счётчика товаров); поискать в строке поиска «Войну и мир» (полный текст).

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

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

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

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

Принципы тестирования

Тестирование программного обеспечения – креативная и интеллектуальная работа. Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим руководством для тестирования в целом.

1. Тестирование показывает наличие дефектов

Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие

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

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

Тестирование должно начинаться как можно раньше в жизненном цикле разработки программного обеспечения и его усилия должны быть сконцентрированы на определенных целях.

4. Скопление дефектов

Разные модули системы могут содержать разное количество дефектов, то есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия по тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей. Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

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

Что нужно знать, чтобы стать тестировщиком QA?

QA-тестеру полагается:

• свободно читать по-английски;
• уметь работать с баг-трекером JIRA, Redmine, YouTrack или подобными;
• знать язык запросов SQL, чтобы писать запросы в базы данных;
• тому, кто собирается тестировать сайты, необходимо освоить HTML/CSS верстку, JavaScript, jQuery и HTTP, а тому, кому нравится работать с мобильными приложениями — системы Genymotion, VirtualBox и iOS Simulator;
• владеть приемами тест-дизайна;
• знать особенности клиент-серверного взаимодействия.

Это не все, что нужно освоить начинающему тестировщику: для успешного развития в профессии он должен обладать определенными навыками (Soft skills):

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

Из Телеграм-каналов для новичков будут полезными QA_ru (русскоязычный чат тестеров), QA Channel (общая разноплановая информация для QA специалистов) и Серьезный тестировщик (интересные статьи и забавные гифки по теме). Украинские QA специалисты и консультанты ведут каналы automation-remarks.com, BigQueryInsights и CatOps.

Тестирование методом черного и белого ящика

Наконец, третья широко распространенная классификация — разделение тестирования на два больших класса: тестирование методом черного ящика и тестирование методом белого ящика. Эта классификация связана с таким понятием как «полнота тестирования». Поэтому сначала мы поговорим именно о ней.

Полнота тестирования

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

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

Когда мы собираем полное собрание сочинений, то у нас нет цели скупить все книги, полностью весь тираж, нам нужно чтобы в нашу коллекцию попало по одной книжке каждого вида.

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

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

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

И вот это как раз и есть разница между тестированием методом черного ящика и тестированием методом белого ящика.

При тестировании методом черного ящика мы не видим, что внутри ящика, мы не принимаем во внимание внутреннее устройство программы.

При тестировании методом белого ящика, или правильнее говорить, наверное, «прозрачного ящика», мы смотрим, как программа устроена внутри, и эту информацию используем при выполнении и особенно при проектировании тестов.

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

То есть, при тестировании методом белого ящика нам, как правило, нужно просто больше тестов, потому что у нас есть больше информации о том, какие разные варианты поведения программы могут быть. Мы принимаем во внимание и ее внешнее поведение, и ее внутреннее устройство. Коллекция тестов увеличивается.

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

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

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

Нерешительность и страх перемен

В 2016 году я, будучи студентом 3-го курса технического университета, решил искать работу, которая как-то связана с ИТ. Друг предложил пойти с ним в техподдержку Skyeng. Честно говоря, я не сразу согласился: мне сложно коммуницировать с людьми, обычно боюсь первым начать разговор и чувствую себя неловко при общении с незнакомыми. Но затем рискнул и прошёл собеседование.

Уже через 3-4 месяца я точно понял, что мне нужно расти над собой и пойти во что-то более айтишное. Мой друг тогда перешёл в отдел QA. Общаясь с ним, я открыл для себя совершенно новую область в разработке — тестирование ПО! С первого взгляда это было именно то, что мне нужно: я хотел набраться опыта, залезть с головой в программную часть и расти дальше — ведь учился я на разработчика.

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

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

Решение мне далось не сразу. Около месяца я взвешивал все за и против. Руководить отделом в 22 и иметь долгосрочную стабильность (мне даже родные говорили: «Да зачем тебе этот айти? Вон, начальником, может, будешь!») — ну разве не кайф?

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

Сотрудник техподдержки постоянно будет сотрудником техподдержки, как его не назови. Мануальный тестировщик — это только начало пути. Человек осваивается в ИТ-среде, понимает возможные точки роста: хард-скиллы ручного тестирования, автоматизация тестирования, проектный менеджмент, менеджмент QA, аналитика, разработка и многое другое. Часто бывает, что зарплата начинающего QA равна зарплате сотрудника техподдержки, но при этом ты работаешь на перспективу и повышаешь свою стоимость, получая опыт на боевых задачах и качая скиллы. «Движовое» окружение, интересные и сложные задачи, возможности роста в любую сторону — это склонило чашу весов.

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

О ролях

В отделе качества каждый выполняет свою роль и, если расставить роли по сложности функционала и уровню ответственности, это выглядит так:

• Тестировщик отвечает за прохождение чек-листов, тест-кейсов, проверку и документирование дефектов, разработку документации;
• Quality Control, в дополнение к обязанностям тестировщика, анализирует результаты тестирования и качество билдов, выявляет причины отклонений;
• Quality Assurance анализирует весь проект и процессы, ищет решения, превентивно работает над улучшением качества продукта.

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

Пример “Проект “Коробка”:

Почему тестировщик и QA не одно и то же

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

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

QA — в первую очередь инженер

Для многих это звучит непривычно и вызывает небольшое сопротивление. Не стоит нервничать 🙂 Специалист каждый новый таск воспринимает, как челлендж, рвется его преодолеть с помощью имеющегося тулсета? Поздравляем, Вы нашли идеального QA. Столкнувшись с незнакомой задачей, тестировщик скажет: «Я такого не умею. Найдите того, кто умеет», а инженер ответит: «Дайте я разберусь и объясню, как могу решить эту задачу». В моей команде есть несколько специалистов, которые постепенно начали разделять и поддерживать этот подход. В тот момент, когда они приняли новые правила игры, когда страха неудачи не существует, а очередная задача — это всегда увлекательный и посильный челлендж — они стали получать от работы больше удовольствия и постоянный респект от коллег. Ребятам достаются новые, «непонятные» таски и в них они находят для себя постоянный рост.

Какие активности доступны с описанным выше складом ума? Любые! Ограничений практически нет. За любую задачу можно взяться, почерпнув из нее что-то новое. Например, виды тестирования, помимо простого мануального, это же кладезь интересных задач:

• автоматизация функциональных проверок;

• перформанс;

• секьюрити;

• аксессибилити.

Среди других активностей, могу выделить такие:

• вникание в код приложения для поиска новых вариантов проверок или отсечения дубликатных;

• применение новых техник тест-дизайна к существующим проверкам;

• построение новых пайплайнов тестирования.

Этот список можно продолжать. Каждый специалист найдет что-нибудь полезное для профессионального роста, руководствуясь своими навыками и интересами. Чтобы получать доступ ко все новым активностям и таскам. Крутой инженер умеет все, а с чем еще не знаком, разберется и сделает самостоятельно.

Ресурсы для подготовки к собеседованию

Подготовка к собеседованию

• Собеседование для собеседующих (Хабр)
• Погружение в Charles Proxy (Хабр)
• Образ современного тестировщика. Что нужно знать и уметь (Хабр)
• Что должен знать тестировщик бэкенда (Хабр)
• Обратное собеседование (Github)

Telegram-каналы

• https://t.me/qa_ru
• https://t.me/qa_bad_company
• https://t.me/qaevents
• https://t.me/yetanotherqa
• https://t.me/radioqa

Книги

• Тестирование Дот Ком или Пособие по жестокому обращению с багами в интернет-стартапах, Роман Савин
• Тестирование программного обеспечения. Базовый курс
• 5 лучших книг по тестированию ПО от Натальи Руколь
• Книга для начинающих тестировщиков

Основные задачи тестирования

Еще несколько терминов, которые связаны с упомянутыми двумя задачами, которыми занимается тестировщик, это стимулы, реакции и оракул.

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

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

• Пользовательский интерфейс (UI)
• Программный интерфейс (API)
• Сетевой протокол
• Файловая система
• Состояние окружения
• События

Наиболее распространенные интерфейсы это

• графический,
• текстовый,
• консольный,
• и речевой.

Через пользовательский интерфейс компьютер взаимодействует с человеком, с пользователем.

Через программный интерфейс программы взаимодействуют друг с другом (человек тут не нужен).

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

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

Это состояние окружения, которое могут программы модифицировать и, соответственно, тоже читать.

Это события, в частности, таймер. То есть некоторые механизмы отслеживания времени.

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

Другие классификации видов тестирования

Чаще всего используется разбиение на три уровня, это

1. модульное тестирование,
2. интеграционное тестирование,
3. системное тестирование.

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

Под системным тестированием подразумевается тестирование на уровне пользовательского интерфейса.

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

Если посмотреть на какое-нибудь типичное веб-приложение, то можно заметить, что оно представляет собой своеобразную матрешку.

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

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

Библиотеки состоят из классов, классы состоят из методов, на стороне баз данных тоже есть пакеты, состоящие из хранимых процедур.

Само по себе приложение тоже может являться частью какой-то более крупной информационной системы.

В этой матрешке мы должны понять, где, на каком уровне у нас должно находиться модульное тестирование, а на каком должно находиться системное тестирование. И найти еще место для интеграционного.

Глядя на эту матрешку мы можем понять, что разделение на системное и модульное тестирование является чисто условным.

То есть у нас система состоит из каких-то модулей. Модули в свою очередь состоят из других более мелких модулей. Эти мелкие модули состоят еще из более мелких, и так далее.

 И так, получаем в результате:

Классификацию по целям удобно выполнять с использованием «магического квадрата», который был изначально придуман Брайаном Мариком и потом улучшен Эри Тенненом.

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

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

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

В частности, в этот квадрат можно легко вписать такие термины как приемочное тестирование, Acceptance Testing, модульное тестирование именно в том понимании, в котором оно чаще всего употребляется в литературе. Это низкоуровневое тестирование с большой, с подавляющей долей программирования

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

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

Так вот, исходя из классификации по целям, модульное тестирование у нас оказывается в левом нижнем квадранте, а все остальные квадранты — это системное тестирование.

Знания и умения

Что нужно знать будущему QA-инженеру для успешной работы? Прежде всего ему понадобится теория. Кандидат на эту должность может подробно рассказать:

• что собой представляет тестирование ПО и зачем его применяют;
• о существующих разновидностях тестирования;
• о баге и его жизненном цикле;
• о документации, которая заполняется в процессе выполнения тестов.

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

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

Кроме того, инженер должен уметь видеть создаваемое ПО глазами конечного потребителя. Это помогает повысить удобство его использования (юзабилити), а значит и качество.

Необходимость знания иностранных языков

• очень много статей и методик переведено на русский язык;
• часто объём знаний языка обусловлен именно особенностями продукта и компании — соответственно, если компания работает на англоязычный рынок, уровень нужен (например, чтобы тестировать документацию или общаться с интернациональной командой и клиентами), а если на российский рынок, то требования к языку практически нулевые.

У меня был пример, когда понадобился тестировщик со знанием японского и отдельно — со знанием немецкого в том числе для работы с клиентами (удалённо). Так вот, нашли, обучили и дали зарплату выше разработчиков в компании. Потому что специалисты уникальные. Они и сейчас не пропали 🙂

Вывод

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

Это человек, который проверяет на прочность всё вокруг: процесс планирования и его контроль, архитектуру, тестовые окружения, релизы и действия на проде, инциденты, тестирования на проде, health monitoring и многое другое.

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

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