Кто отвечает за качество по

Кто отвечает за качество по

1. Что такое качество в разработке ПО?
2. Во сколько нам обходится некачественное ПО?
3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

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

Что такое качество в разработке ПО?

На вопрос что такое качество в разработке ПО можно ответить с разных точек зрения. Свои ответы буду формулировать с точки зрения Пользователя-Заказчика и Руководителя компании.

С позиции Пользователя высокое качество ПО — это полное отсутствие ошибок и решение им задачи ради которого оно создавалось.

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

Средний уровень качества — всё что выше + отсутствие ошибок, которые существенно влияют на опыт использования ПО (Обязательные к устранению), при этом присутствуют ошибки, которые никак не влияют на решение бизнес-задачи: орфография, разные шрифты там где должен быть один и т.д. (Желательные к устранению).

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

Во сколько обходится нам некачественное ПО?

Часть 1: Подтверждение Дефекта

Когда Пользователь находит дефект он обращается к инженеру службы поддержки. Инженер СП пытается его воспроизвести и подтвердить что это дефект производства. Здесь возникают первые затраты из которых начинается складываться стоимость качества:

• Затраты времени Пользователя — 1 ед.
• Затраты времени Инженера СП — 1 ед.

Если ошибка системная, то всё очевидно, а если она связана с работой функционала по определенной логике?

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

Отсутствие документации особенно часто встречается когда практикуется быстрая разработка. Все помнят о «Работающий продукт важнее исчерпывающей документации», но забывают про то что ниже написано «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева».

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

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

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

Если им повезло найти ответ на свой вопрос, то всё заканчивается следующими затратами:

• Владельца Продукта — 1 ед.
• Инженер-Разработчик — 1 ед.
• Заказчик — 1 ед.
• Затраты времени Инженера СП — 1 ед.

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

• Ухудшение репутации — 1 ед. (за счёт того, что Дефект и что пришлось привлечь Заказчика к расследованию)
• Пока затраты на устранение дефекта здесь не учитываю, так как они добавятся чуть позже.

1. Затраты времени Пользователя — 1 ед.
2. Затраты времени Инженера СП — 2 ед.
3. Затраты времени Владельца Продукта — 1 ед.
4. Затраты времени Инженера-Разработчика — 1 ед.
5. Затраты времени Заказчика — 1 ед.
6. Ухудшение репутации — 1 ед.

Стоимость качества — 7 единиц

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

1. Затраты времени Пользователя — 1 ед.
2. Затраты времени Инженера СП — 1 ед.
3. Затраты времени Тех.Писателя-Аналитика — 1 ед.
4. Ухудшение репутации — 0,5 ед. (Потому что Дефект)

Стоимость качества — 3,5 единицы

Чтобы понять момент, когда Тех.Писатель-Аналитик нужен, нужно начать вести учёт ситуаций, когда для расследования привлекались дополнительные лица помимо Инженера СП и сколько времени они на это потратили, сколько таких спорных ситуаций превратилось в Дефекты и во сколько обошлось их устранение. Когда сумма этих затрат становится больше зарплаты Тех.Писателя самое время его вводить.

Часть №2: Устранение Дефектов

Каждая «Блокирующая ошибка» порождает выпуск отдельного устраняющего патча-обновления. Это обновление проходит через стандартные процедуры тестирования, дабы не породить новых ошибок. Передаётся Инженеру СП для распространения среди Клиентов, которые пользуются версией ПО, в которой была найдена эта ошибка, и закрытия «тикета» дефекта. Затраты:

• Инженер-Разработчик — 1 ед.
• Инженер-Тестировщик — 1 ед.
• Инженер СП — 1 ед.

«Обязательная к устранению ошибка» устраняется в следующим плановом релизе (версии), поэтому затраты на устранение ниже, так как затраты на сборку релиза и регрессионное тестирование ложатся на новые функции и не попадают в стоимость устранения ошибки. Дополнительных затрат на работу Инженера СП также нет кроме закрытия «тикета». Затраты:

• Инженер-Разработчик — 0,5 ед.
• Инженер-Тестировщик — 0,5 ед.

Затраты в обоих случаях оплачиваются из прибыли компании.
Стоимость качества — 4 единицы.

Часть №3: Недопущение Дефектов (Качество основанное на контроле)

Чтобы Пользователи не находили Дефекты для этого есть собственные Инженеры по тестированию. Для них критерий эффективности 100% ошибок — 0% дефектов.

Информация о найденном дефекте передается Инженеру по тестированию для анализа причин пропуска дефекта при тестировании и внесения изменений в методики и инструменты тестирования. Затраты:

• Инженера-Тестировщик — 1 ед.

Эффективная работа здесь сводит на нет следующие затраты времени
Части 1:

1. Пользователя — 1 ед.
2. Инженера СП — 1 ед.
3. Ухудшение репутации — 0,5 ед.

1. Инженер-Разработчика — 1,5 ед.
2. Инженер-Тестировщика — 1,5 ед.
3. Инженер СП — 1 ед.

Стоимость — 6,5 ед. Вложения — 1 ед. Экономия — 5,5 единиц.

Часть №4: Устранение Ошибок

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

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

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

1. Ухудшение репутации — 1 ед.
2. Инженер-Разработчик — 1 ед.
3. Инженер-Тестировщик — 1 ед.
4. Потерянный доход — 2 ед. (п.2 + п.3)

Стоимость качества — 5 единиц.

Часть №5: Недопущение Ошибок (Качество основанное на развитии производственного процесса)

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

Допущенные ошибки передаются на анализ Руководителю Разработки (Тим-Лиду) для выявления причин, сотрудников, которые их чаще допускают, и чаще «болеющих» продуктов. Эта работа выливается в ряд мероприятий по код-ревью, дополнительному обучению Инженеров-Разработчиков по темам где недостаёт квалификации и т.д.

• Затраты Руководителя-Разработки — 1 ед.
• Затраты Инженера-Разработчика — 1 ед.

Эффективная работа здесь сводит на нет следующие затраты Части 4:

1. Инженер-Разработчик — 1 ед.
2. Инженер-Тестировщик — 1 ед.
3. Потерянный доход — 2 ед.
4. Ухудшение репутации — 1 ед.

Стоимость — 5 ед. Вложения — 2 ед. Экономия — 3 единицы.

Общий расчёт стоимости качества

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

Вид затрат	Часть 1	Часть 2	Часть 4	Итого
Затраты времени Пользователя	1	—	—	1
Затраты времени Инженера СП	2	1	—	3
Затраты времени Владельца Продукта	1	—	—	1
Затраты времени Инженера-Разработчика	1	1,5	1	3,5
Затраты времени Заказчика	1	—	—	1
Затраты времени Инженера-Тестировщика	—	1,5	1	2,5
Ухудшение репутации	1	—	1	2
Потерянный доход	—	—	2	2
Итого	7	4	5	16

Если будем готовить документацию по факту выполненной разработки, вложив 1 единицу ресурса Технического Писателя, то это сэкономит 3,5 единицы и стоимость качества снизится с 16 до 12,5. (Структура затрат: Документирование + Подтверждение Дефекта + Устранение Дефекта + Устранение Ошибок)

Обеспечив недопущение дефектов, вложив в это дополнительные затраты времени Инженера-Тестировщика в размере 1 единицы, стоимость качества снизится с 12,5 до 7 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Устранение Ошибок)

Недопущение ошибок потребует вложения 2 единиц, по одной от Инженера-Разработчика и Руководителя-Разработки, и снизит стоимость качества с 7 до 4 единиц. (Структура затрат: Документирование + Недопущение Дефектов + Недопущение ошибок)

Если вложимся в то, что Технический Писатель — Аналитик начнёт писать пользовательскую документацию про то как система должна решать бизнес-задачу Пользователя ещё до разработки, то, возможно, не придется:

1. Не только спорить с Заказчиком дефект это или нет, но и вообще общаться с ним по поводу дефектов.
2. Анализировать причины по которым ошибки в выполнении целевых задач ПО проскочили к Пользователям через этап Тестирования.
3. Анализировать причины по которым Разработчик сделал так, что программа работает не так как должна и отдал это в Тестирование.
4. Тратится на дополнительные мероприятия по недопущению ошибок и дефектов, когда проектная документация отсутствует и нужно что-то придумывать чтобы компенсировать её отсутствие.

И на это нужна всего 1 единица затрат. (Качество основанное на развитии процесса проектирования продукта)

Кто отвечает за качество?

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

У нас Software Quality Assurance (Обеспечение качества ПО) утрировано до восприятия как Тестирование, а Quality Assurance Engineer до Инженер-Тестировщик. Но Инженер-Тестировщик максимум что может сделать это найти все ошибки и вернуть их Software Ingineer (Инженеру-Разработчику), но он никак не влияет на их появление.

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

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

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

Есть ещё Product Owner (Владелец Продукта), который как владелец подходит на роль Отвечающего за Качество Продукта. По этой причине их порой делят на две позиции Marketing Product Manager (Менеджер по продукту) и Software Delivery Manager (Менеджер по выпуску ПО). Первый отвечает за развитие продукта с точки зрения рынка (работа с Заказчиками и требованиями), а второй за развитие производственного процесса выпуска продукта.

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

Поделить ответственность по этапам Software Development Life Cycle (Жизненного цикла разработки ПО) не получается. Как только это деление начинается, неэффективная работа по середине сразу делает бессмысленной работу сделанную в начале и нагружает дополнительной работой как тех кто стоит в конце, так и всю производственную цепочку заводя на её вход ошибку для устранения.

Заключение

Это классический подход к работе с качеством из промышленности, который основан на трёх методах:

1. Качество через проверку готового продукта (тестирование: отлавливание ошибок и дефектов)
2. Качество через развитие производственного процесса (предотвращение ошибок в ходе производства)
3. Качество через развитие процесса проектирования продукта (предотвращение ошибок закладываемых в скелет-основу продукта при проектировании)

И основным посылом: необходимо больше внимания уделять работе с причинами, а не работе с последствиями.

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

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

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

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

Что с этим делать? — мне нравятся ответы данные в статье «Будущее гибкой разработки».

Что ещё почитать по теме:

Уделите пару минут ответу на три вопроса, так вы поможете провести диагностику средней температуры отношения и внимания к качеству ПО в ИТ-отрасли нашей страны на 1 августа 2017 года. +1 вам в карму за это доброе дело.

Кто такой QA-инженер, чем он занимается и сколько зарабатывает

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

Какие именно задачи решает QA-специалист, какие навыки ему нужны в работе и как им стать — расскажем в нашем материале.

АЛЬМИРА НИЗАМОВА

Благодарим Никиту Балясного, senior QA-инженера в М.Видео и эксперта Нетологии, за помощь в подготовке материала.

Кто такой QA-инженер и чем он отличается от тестировщика ПО

QA — Quality Assurance — переводится с английского как «обеспечение качества». QA-инженер — специалист, который следит за качеством продукта на всех этапах его разработки.

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

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

Если тестировщик проверяет работу уже готового или почти готового продукта, то QA-инженер обеспечивает качество на протяжении всего жизненного цикла ПО.

С точки зрения функций тестировщик — более узкоспециализированный специалист.

Никита Балясный

Senior QA-инженер в М.Видео

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

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

QA-инженеры бывают ручными и автоматизированными.

Ручные QA не пишут код — все действия они выполняют руками с помощью клавиатуры, мышки и дополнительных инструментов.

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

Где работает и какие задачи решает QA-инженер

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

Вне зависимости от того, в какой компании работает специалист, он выполняет примерно одни и те же задачи:

• Анализирует техническую документацию и требования к продукту на этапе проектирования ПО.
• Разрабатывает сценарии тестирования.
• Тестирует MVP — Minimum Viable Product — самую примитивную версию продукта, которая уже может привлечь первых пользователей.
• Создаёт метрики качества ПО. Их можно разделить на два вида: внутренние и внешние. К первым относят свойства продукта, которые видны только команде проекта: метрики размера, сложности и стиля. Внешние — это свойства, видимые пользователям. Здесь выделяют метрики надёжности, функциональности, применимости и стоимости продукта.
• Фиксирует найденные ошибки.
• Отслеживает процессы исправления багов и ошибок.
• Повторно анализирует качество ПО.
• Проводит мониторинг метрик качества.

За счёт новых гибких методологий разработки ПО QA-инженер работает в тесной связке со всей командой проекта: тестировщиками, разработчиками, аналитиками, менеджерами. Иногда QA взаимодействует и с другими специалистами, например, системными администраторами и DevOps-инженерами.

Никита Балясный

Senior QA-инженер в М.Видео

Раньше разработка ПО проходила следующим образом: мы два месяца писали документацию, столько же времени разрабатывали продукт и ещё два месяца — тестировали его. В результате команда создавала довольно серьёзное обновление, но его выкатка занимала полгода.

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

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

Какие знания и навыки нужны QA-инженеру

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

Знание языка программирования

Как правило, QA-инженеры не задерживаются в роли ручного специалиста и переходят к автоматизированному тестированию. Поэтому базовое владение языками программирования — Java, JavaScript, Python — желательно для профессионала. Не помешает и умение работать с SQL — языком запросов для баз данных. Это касается как ручных QA, так и автоматизаторов.

Понимание основ теории тестирования и тест-дизайна

Как строится тестовая документация, как её писать и оформлять, что такое чеклисты и тест-кейсы, какие виды тестирования существуют — всё это является теоретической базой, на основе которой строится работа QA-специалиста.

Чеклист — краткое обозначение действий, которые необходимо проверить.

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

Знание методологий разработки Scrum и Kanban

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

Scrum в основном используют при разработке ПО силами небольшой команды. Работа делится на короткие временные отрезки — спринты — и чётко распределяется между участниками проекта.

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

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

Разбираемся в Scrum и Kanban

Понимание устройства компьютера и основ операционной систем Linux, Windows, Mac OS

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

Способность работать с баг-трекингами Jira и YouTrack

Баг-трекинговые системы помогают QA-инженеру систематизировать и хранить отчёты об ошибках, которые он пишет десятками.

Jira — платный баг-трекинг, у которого есть бесплатный тариф с возможностью добавления до 10 пользователей. Изначально эта система предназначалась для отслеживания ошибок, но теперь её часто используют для планирования agile-проектов.

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

Чаще всего QA-специалисты используют именно Jira, но иногда в работе применяют и её аналоги: YouTrack, Redmine, Trello.

Умение работать с фреймворком Selenium Web Driver

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

Среди софт-скиллов QA-инженера можно выделить ↓

Умение мыслить аналитически

QA-инженер должен уметь правильно подходить к решению задач и самостоятельно придумывать новые решения.

Грамотный тайм-менеджмент и стрессоустойчивость

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

Умение выстраивать здоровые рабочие отношения и аргументировать свою позицию

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

Усидчивость

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

Самообучаемость

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

Профессия

Инженер по тестированию: с нуля до middle

Узнать больше

• Освоите IT-профессию, для которой не требуется опыт и техническое образование
• Изучите ручное и автоматизированное тестирование, а также языки программирования: Java, JavaScript и Python
• Начнёте работать уже через 2 месяца обучения

Сколько зарабатывает QA-инженер

Работа junior-, middle- и senior-специалистов в области QA оплачивается по-разному. В России специалист с минимальным опытом работы в ручном тестировании может рассчитывать на зарплату в 70 тысяч рублей с полной занятостью:

Профессионалы-автоматизаторы более высоких грейдов — middle и senior — зарабатывают больше:

В свою очередь, QA-инженеры в США получают около 82 тысяч долларов в год, то есть примерно 6,1 тысячи долларов в месяц. Эта цифра актуальна на конец 2021 года.

Никита Балясный

Senior QA-инженер в М.Видео

Судя по вакансиям QA-инженеров в стране, средняя зарплата junior-специалистов в ручном тестировании составляет 50 тысяч рублей, то есть вилка — от 30 до 70 тысяч. У автоматизаторов цифра чуть выше — 60 тысяч.

Что касается middle-инженеров, то они могут рассчитывать на зарплату в районе 100 тысяч рублей, автоматизаторы — 120 тысяч.

Предложения по работе для senior-специалистов начинаются с зарплаты от 180 тысяч, предела может и не быть. Иногда в индустрии выделяют отдельно лидов: это плюс 30–40 тысяч рублей к ежемесячному доходу.

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

Как стать QA-инженером

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

В этом случае стоит обратить внимание на образовательные программы в МГУ, МФТИ, Высшей школе экономики, Санкт-Петербургском государственном университете. Так, в ВШЭ на совместном факультете университета и Яндекса есть бакалавриат «Прикладная математика и информатика», который готовит инженеров-разработчиков и инженеров-исследователей по программному обеспечению. Также хорошую базу можно получить на программе «Фундаментальная информатика и информационные технологии» факультета вычислительной математики и кибернетики МГУ.

Ещё один путь к профессии QA-инженера — самостоятельное обучение. Книги, онлайн-тренажёры, видеоуроки, профессиональные чаты помогут получить знания и навыки на уровне стажёра или junior-специалиста. Такая база может стать подспорьем для получения первого предложения о работе.

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

Никита Балясный

Senior QA-инженер в М.Видео

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

В программе курса «Инженер по тестированию: с нуля до middle» Нетологии акцент сделан именно на практику, и все упражнения основаны на реальных задачах QA-инженера.

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

На ком лежит ответственность за качество программного обеспечения?

Agile методология разработки программного обеспечения и DevOps, и в особенности их упор на юзер экспириенс, обращают наше внимание на людей, стоящих за продуктами. Но действительно ли процесс разработки имеет значение или же цель попросту оправдывает средства? Лондонская P3X или People, Product, and Process Exchange в значительной степени сфокусирована на точке пересечения трех этих P, причем, пожалуй, последняя из них является наиболее интересной, поскольку объединила в себе самое большое количество акронимов — разработка через тестирование (TDD — test-driven development), разработка на основе поведения (BDD — behavior-driven development), непрерывная доставка (CD — continuous delivery), разработка на основе предметной области (DDD — domain-driven development) и многие другие — чтобы помочь командам определить, как систематически создавать лучшие системы.

Соучредитель Agile Testing Fellowship Джанет Грегори завершила свой основной доклад о процессе обеспечения качества программного обеспечения, попросив собравшихся поднять руки, если они чувствуют момент волшебства в своей agile-команде и чувствуют, что несут миру качество. Лишь несколько человек из аудитории, предположительно полностью состоящей из практикующих agile разработчиков, подняли руки.

Как так получилось, что с момента подписания Agile-манифеста прошло 17 лет (на момент доклада), а все еще так мало людей вышли за рамки созерцания теней на стене пещеры? Быть может, у нас все еще нет правильного диалога. Быть может, мы все еще не ведем его с правильными людьми. Или, может быть, диалог вообще не являются частью наших процессов.

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

Но что такое «качество»?

Грегори отмечала, что субъективное определение качества зачастую должно быть определено заранее. Чтобы с чего-то начать определение качества, она предложила «Пять подходов к определению качества» Дэвида А. Гарвина 1984 года:

Трансцендентный (абстрактный) — Атмосфера, врожденное совершенство, универсально узнаваемые достоинства

На основе ценности — Цена и стоимость

С точки зрения пользователя — Ценность для пользователя — это то, что будут представлять большинство людей, думая о качестве

На основе продукта — Что необходимо вашим пользователи? (например, какой именно вид молока из представленных)

На основе производства — Методы, процессы, стандарты, требования, спецификации — Правильно ли мы наладили производство?

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

Подход на основе производства

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

Грегори утверждает, что оно предполагает проектирование через тестирование, потому что «написание чистого кода значительно сокращает количество доработок. Давайте делать правильно с первого раза, чтобы не плодить баги. Тогда мы сможем релизить с уверенностью».

TDD, практика разработки автоматизированных тестов до самого тестируемого программного обеспечения, что, в свою очередь, приводит к уменьшению связанности этого программного обеспечения, является важной частью производственного качества. Грегори процитировала исследование, в котором говорится, что команды, которые внедрили TDD, получают в итоге на 60-90 процентов меньше дефектов, чем те, кто его не практикует, но TDD отнимает в среднем на 15–30 процентов больше времени на разработку.

Многие команды сталкиваются с этим компромиссом между качеством и скоростью.

«Может случиться, что PO (Product Owner — владелец продукта) говорит, что предпочел бы качеству реализацию новой фичи. Кто должен принимать такие решения?»

Помимо TDD, Грегори рассказала, что производственные процессы включают в себя:

Написание кода для обеспечения поддерживаемости

Мониторинг логов ошибок

Исследовательское тестирование по историям (stories)

Тестирование продукта на соответствие спецификациям

Автоматическое создание тестов для быстрой обратной связи

Статический анализ платформы

Четкое определение состояния ”Готово”

Наконец, она сказала: «Практики, такие как DevOps, стараются снизить риск клиента во время релиза их клиентам».

Подход на основе продукта

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

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

Вся суть заключается в двух вопросах:

Создаем ли мы то, что нужно?

Добавляем ли мы функционал, который нужен?

Разработку через приемочные тесты (ATDD) или, как ее иногда называют, разработка на основе сюжетного тестирования — привлечение ключевых клиентов к этапу TDD

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

Исследовательское тестирование фич

Подход с точки зрения пользователя

Именно здесь точки зрения разнятся. Как сказала Грегори: «Разные люди выбирают разные вещи. У них разные желания, разные потребности. Если мы пытаемся предоставить покупателю право выбора, нам все-равно нужно удовлетворить его».

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

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

Подход на основе ценности

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

Качество с точки зрения ценности, оценивается с помощью некоторой комбинации следующих факторов:

Трансцендентное качество

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

Как мы измеряем качество программного обеспечения?

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

Количество ошибок в продакшене

Серьезность ошибок в продакшене

Количество дней с момента последнего запуска в продакшн

Количество новых обращений в службу поддержки за X дней с момента последнего релиза

Индикатор сборки остается зеленым

Нет непройденных автоматизированных тестов (случайных сбоев)

Статический анализ кода кодовой базы не выявляет проблем

Количество исправлений на низком уровне

Одни и те же баги не всплывают повторно

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

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

И конечно, командам необходимо соблюдать баланс между желанием избегать ошибок и скоростью разработки.

Вся команда несет ответственность за качество

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

Вся команда владеет качеством

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

Но она не раскрыла никакого секретного рецепта идеального стремления к качеству.

«Какие подходы к качеству вы используете, меня не волнует, но вам нужно задаться вопросом, когда вы смотрите на ваши процессы — приводит ли это к уверенности в релизах?» — говорит Грегори. «Измеряет ли качество процесса качество продукта?»

Она процитировала соавтора BDD Book 1: Discovery Себа Роуза: «Когда мера становится целью, она перестает быть хорошей мерой».

«Независимо от того, как вы это измеряете, это должно привести к разговору, дискуссии о том, что вам нужно», — говорит Грегори.

Она продолжила: «У команды есть качество, но нужно думать шире. Качество в процессах и качество в практике. Компетентность в вашей команде, компетентность в том, как вы доставляете программное обеспечение».

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

«Давайте встроим управление качеством в наш процесс и научимся говорить о том, что мы делаем», — сказала Грегори.

Профессия тестировщик: разбираемся в QA, QC и testing

Анастасия Шарикова, преподавательница курса «Тестировщик» в Нетологии и QA Lead в Bookmate, рассказала, чем занимаются тестировщики, как формируются отделы по контролю за качеством, а также какая специализация в тестировании пользуется сейчас наибольшим спросом.

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

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

Что такое QA, QC, тестирование и кто такой тестировщик

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

Схематически отношения между QA, QC и тестированием можно представить так:

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

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

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

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

Специализацию тестировщиков можно разделить по направлениям: тестирование безопасности, производительности, юзабилити; а также по методам написания тестов: ручное и автоматизированное тестирование.

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

Карьера тестировщика: варианты развития

У тестировщика практически в любой компании есть три пути развития карьеры: вертикальный, горизонтальный и смежный.

Вертикальное развитие

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

В каждом сегменте тестирования существуют свои грейды, которые определяют уровень специалиста: junior, middle и senior. Руководителем всех специалистов является test-lead или team-lead в зависимости от специфики компании. На некоторых проектах может быть также отдельный инженер по качеству, head of QA.

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

Горизонтальное развитие

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

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

Спрос на автоматизированное тестирование

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

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

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

Переход в смежные сферы

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

Как стать тестировщиком

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

Однако в вузах нет специальности «тестировщик». Если рассматривать государственное образование, то проведение тестов изучается только в рамках программирования. Минус в том, что практики при обучении в вузе всё равно не получить, если не работать параллельно на реальных проектах.

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

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

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

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

Если говорить об обучении уже практикующего специалиста, например, ручного тестировщика, то здесь тоже немало вариантов: от специализированных курсов до самостоятельного изучения языков и инструментов, которые понадобятся в новом направлении. Как пример, если интересно тестирование веб-приложений, можно начать с изучения Selenium или Katalon Studio и Java.

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

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

Обеспечение качества сейчас — бурно развивающаяся перспективная сфера, особенно в России и СНГ, и это очень радует и вдохновляет постоянно развиваться в этом направлении.