Профессия «qa-инженер»

Кому подойдет быть QA-аналитиком

QA-аналитика— это ваше, если:

• вам нравится общаться с людьми. Вы не боитесь разговаривать с клиентами, нормально относитесь к многочисленным митингам, созвонам, дебатам с разработчиками, публичным выступлениям;
• вам нравится писать тексты. Много, много текстов: писем, инструкций, документации и т.п.;
• в вас живет следователь. Вам нравится докапываться до истины, из двух строчек требований, присланных клиентом, создавать целые документы и ТЗ, вытаскивать из клиента правду, чего он хочет на самом деле;
• вы обладаете устойчивой психикой. Аналитик и PM (project manager) — это авангард, на который может приходится основной психологический удар со стороны участников проекта, если в нем что-то пойдет не так. 

Насколько востребована профессия тестировщика

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

• в декабре 2020 на HeadHunter было более 4 000 вакансий тестировщиков ПО;
• больше 12 000 — на Trud.com;
• на Indeed — около 1 000, и это только по России.

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

Вот, например, скрин с hh.ru, где работодатель перечисляет требования к тестировщику:

Большим спросом пользуются универсалы, владеющие современными методами тестирования, знающие языки программирования, умеющие составлять и автоматизировать тесты, например:

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

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

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

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

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

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

Как и куда развиваться в профессии

Рассмотрим карьерный рост QA-тестировщика по этапам.

• Стажёр — это новичок, который изучил основы, но пока не получил опыта работы.
• Новичок — сотрудник с небольшим опытом работы, обычно меньше полугода. Он может проводить простые тесты.
• Специалист QA-тестировщик — специалист, который умеет писать скрипты тестирования, может сам протестировать продукт и составить отчёт о проверке. Он также способен проанализировать результаты улучшения показателей и знает, как оптимизировать процесс разработки.
• Старший QA-тестировщик — опытный специалист, который может брать на себя ответственность за выполнение сложной работы. Старший QA-тестировщик хорошо разбирается и умеет применять разные виды тестирования, может брать шефство над новичками.
• Ведущий инженер — способен руководить командой инженеров, оценивать сроки тестирования и определять наиболее эффективные способы тестирования.
• Разработчик — навыки, приобретённые в тестировании, помогут тестировщику создавать и проверять свой продукт.
• Менеджмент — если тестировщик во время работы прокачается в управленческих навыках, он может начать работать с командой. Менеджер ставит задачи подчинённым и контролирует их выполнение.
• Бизнес-аналитик — это посредник между заказчиком и командой. Он умеет разобраться в бизнес-процессах и перевести задачи на язык разработчиков.

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

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

Виды тестов игры

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

• В большинстве случаев — это тестирование функциональности. Людям поручено находить большинство дефектов в игре, и они часто являются одной из первых групп, которые дают отзывы о ранних сборках игр. Тестировщикам функциональности поручено проверять функции и то, насколько хорошо они интегрируются с остальной частью игры.
• Затем идет тестирование локализации, которое требует проверки текста и звука, чтобы гарантировать, что игра будет хорошо принята во всех регионах. Некоторое тестирование локализации может потребовать непосредственного перевода и внесения изменений в диалоги.
• Далее идет тестирование совместимости, где вы проверяете, хорошо ли игра работает на разных платформах, например, хорошо запускается как на PS4 Pro, так и на PS4.
• Наконец, есть тестирование соответствия / сертификации. Создатели платформ, как Nintendo, Xbox и PlayStation, имеют свод правил для игр, как разработчики должны доносить информацию в соответствии с консолью. Тестировщикам, например, нужно следить за тем, чтобы подсказка кнопки Nintendo или сообщение об ошибке PlayStation не появлялись в игре Xbox. Проверите неправильно и игра не пройдет сертификацию.

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

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

Малахи О’Нил, директор по тестированию в Runescape developer Jagex, говорит об этом следующее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ступеньки карьеры и перспективы

Традиционный карьерный путь QA-инженера выглядит так: 

1. Trainee QA Engineer – начинающий специалист.
2. Junior QA Engineer – специалист, проработавший в должности от 1 до 6 месяцев и умеющий выполнять задачи среднего уровня сложности с помощью опытных коллег.
3. Middle QA Engineer – специалист среднего уровня квалификации со стажем работы от 1 до 3 лет, умеющий работать самостоятельно и консультирующий младший персонал.
4. Senior QA Engineer – специалист высшей квалификации, выполняющий самые сложные технические задачи и занимающийся обучением младших сотрудников.

Кроме технического, можно пойти управленческим путем и стать QA Lead → Head of QA или же сменить специальность и перейти в проджект-менеджеры или бизнес-аналитики.

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

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

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

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

Автоматизированное тестирование — проверка в автоматическом режиме, которое ускоряет процесс

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

Юзабилити тестирование — проверка удобства интерфейса для пользователя. Чтобы это проверять, тестировщик должен разбираться в особенностях интерфейсов и особенностях бизнеса

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

Конфигурационное тестирование — проверка работы программы на разных устройствах и платформах.

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

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

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

В отдельной статье разбираем, что нужно знать новичку, чтобы стать QA-тестировщиком

Куда двигаться дальше

Карьера в тестировании может развиваться очень динамично, даже если вы закончили только специализированные курсы. Это подтверждает пример знаменитого QA-гуру Джеймса Баха. В конце 1980-х он стал самым молодым менеджером по тестированию в корпорации Apple, тогда ему было всего 20 лет, а в резюме в графе «образование» – лишь средняя школа. Тем не менее, он построил успешную карьеру и стал признанным экспертом в своем деле.

Вертикальный рост

Если junior-тестировщик заинтересован в профессиональном развитии, он будет расти к уровню middle, а затем и senior-специалиста по мере приобретения необходимого опыта. Как правило, перейти на следующую позицию можно уже через 1-2 года работы. На этом вертикальный рост не заканчивается. Для тех, кто способен организовывать работу внутри команды и мотивировать коллег, есть должности руководителя команды тестировщиков (team lead) или менеджера (test manager).

В компаниях по-разному выстраивают процессы карьерного роста сотрудников, но объективный критерий для повышения – это уровень квалификации. Junior-тестировщик, как правило, работает по руководством ментора и выполняет задачи от старших коллег. Когда сотруднику начинают доверять более сложные задания, позволяют самостоятельно принимать некоторые решения, то он может претендовать на уровень Middle. Senior – это уже опытный специалист, за плечами которого несколько проектов, к нему прислушиваются коллеги, его мнением интересуется менеджмент. Если вы чувствуете, что готовы перейти на новый уровень, уточните у руководства, как это можно сделать.

Горизонтальный рост

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

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

QA должны иметь автономию и авторитет

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

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

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

Статистика зарплат для ‘QA инженер’ по городам

Лидеры по количеству вакансий для ‘QA инженер’: Москва, Санкт-Петербург, Новосибирск, Нижний Новгород, Казань.

Лидеры по уровню средней зарплаты для ‘QA инженер’: Москва, Новосибирск, Санкт-Петербург, Нижний Новгород, Томск.

Обзор зарплат для ‘QA инженер’ по городам

Населённый пункт	Средняя зарплата, руб.	Медианная зарплата, руб.	Вакансий с зарплатой	Всего вакансий
Москва	169725.0	151000.0	207	830
Санкт-Петербург	131423.0	111000.0	123	487
Новосибирск	139585.0	119000.0	41	92
Нижний Новгород	111160.0	79000.0	25	77
Казань	98765.0	91000.0	17	64
Екатеринбург	89316.0	79000.0	19	59
Самара	109857.0	97000.0	14	55
Краснодар	77462.0	79000.0	13	45
Ростов-на-Дону	78200.0	75000.0	15	37
Воронеж	83800.0	73000.0	10	35
Томск	111000.0	91000.0	11	30
Омск	81667.0	35000.0	9	25
Саратов	61400.0	47000.0	5	24
Пермь	102385.0	79000.0	13	23
Челябинск	71667.0	49000.0	6	20
Ульяновск	84000.0	73000.0	8	18
Уфа	80000.0	61000.0	8	15
Рязань	56778.0	39000.0	9	15
Набережные Челны	44000.0	41000.0	8	15
Калининград	43000.0	41000.0	6	14
Красноярск	76778.0	59000.0	9	13
Тверь	68333.0	69000.0	6	13
Калуга	96600.0	107000.0	5	13
Тула	57857.0	63000.0	7	12
Владимир	56818.0	51000.0	11	12
Ярославль	81000.0	71000.0	6	11
Ижевск	59000.0	49000.0	6	10
Белгород	53000.0	53000.0	6	9
Барнаул	69286.0	51000.0	7	8
Чебоксары	56600.0	39000.0	5	8
Иваново (Ивановская область)	39800.0	39000.0	5	8
Иркутск	98200.0	99000.0	5	6

Пошаговая эволюция

1. Меняем тип мышления

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

Например:

2. Ищем единомышленников

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

3. Работаем над “проектом всей моей жизни”

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

4. Идем против системы

Не надо вестись на комментарии участников проекта: “У нас так принято/по-другому не пробовали/вроде норм”. Аккуратно ворошите улей дополнительными вопросами и весомыми аргументами. Если же возникает напряжение и застой внутри, то пригодится совет с внешней стороны — авторитет более опытных коллег поможет изменить привычный порядок вещей.

5. Не впадаем в крайности

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

В заключение

QA — это отдельный и важный вид деятельности, который улучшит производительность команды в целом. Невероятно, но факт: в компетенцию специалиста по качеству не входит лишь нахождение багов, а сам процесс Quality Assurance стоит воспринимать как комплекс мер для улучшения качества на всех этапах жизненного цикла продукта. Не давайте дефектам возможности зародиться уже в самом начале. Древняя мудрость гласит: “Лучший бой тот, который не состоялся”.

Автор статьи Павел Булич, редактор Yulia Nosakova

Есть ли у тебя какой-нибудь персональный лайфхак, который бы упростил жизнь всем QA-автоматизаторам?

АЛЕКСЕЙ ПОБОЛЬ: Если я нахожу какое-то интересное решение, то сразу документирую это на внутреннем портале, чтобы другие члены команды тратили меньше времени в будущем

ЕКАТЕРИНА ЖУКОВСКАЯ: Сложно назвать это лайфхаком, но могу сказать, что нужно уметь писать не только красивый и правильный по структуре код, но также и уметь создавать, так называемые, “костыли”. Это действительно упростит жизнь и сократит время на решение какой-то нетривиальной проблемы, где красота кода ничем не помогает, ведь это уже будет критическое мышление, основанное на опыте.

А самое главное – не нужно бояться, что ты чего-то не знаешь, главное желание и усердие. Мы учимся всю жизнь –  “Чем больше мы знаем, тем ещё больше нам придётся узнать”.

Что нужно для нагрузочного тестирования?

1. Общие требования. Нам нужно понимать, чего мы ожидаем от нашей системы в контексте нагрузки и производительности, хотя бы в общих чертах. Это может звучать просто, но не всегда у людей есть ясное представление о таких требованиях. «Система должна отвечать быстро под высокой нагрузкой» — это не требование, это пожелание. Я покажу примеры удачнее дальше в статье.
2. Специалисты. Для проведения НТ нужны инженеры. Поскольку серьёзное тестирование всегда требует автоматизации, нужны инженеры с навыками тестирования и разработки, а также аналитики и девопсы.
3. Платформа для тестового окружения. Если вы делаете НТ в первый раз — вам определённо понадобится подготовить инфраструктуру. Хорошо если у вас внедрён подход IaC (англ. infrastructure as a code, инфраструктура как код), он очень пригодится для создания окружения, подобного проду. Если нет — надо внедрять или придётся страдать даже на небольших конфигурациях. И в подавляющем большинстве случаев тестирование на проде — плохая идея. Но есть и исключения, можете погуглить «Netflix testing in production».
4. Время. НТ — это очень затратный по времени процесс, особенно когда вы делаете его впервые. Автоматизация экономит много времени, но всё равно нужно быть готовым потратить на подготовку и проведение НТ несколько дней или существенно больше, зависит от масштабов прода, используемого стэка, сценариев использования и поставленных задач.

Самообучение QA Manual – насколько, на твой взгляд, это эффективно, если серьезно настроен(а) на карьеру в этой области?

На мой взгляд, как раз без способности и любви к самообучению в IT-сфере (как и в любой другой) невозможно достичь каких-либо существенных результатов. Другой вопрос, что начинающим специалистам довольно трудно сориентироваться в огромном объеме доступной информации, здесь важен систематизированный и комплексный подход, а также супервизия и направление со стороны опытного специалиста. Поэтому я считаю, что лучший вариант – это посещение профессиональных курсов в сочетании с самостоятельным углубленным изучением преподаваемых на курсах тем. Как правило, 2-х или даже 6-и месячные курсы не покрывают полностью объем знаний, необходимый для старта в профессии, они дают хорошую базу, от которой нужно отталкиваться самостоятельно. Более того, стремление к получению знаний самостоятельно явственно свидетельствует о замотивированности человека развиваться в выбранном направлении, а также о настоящем интересе к профессии. Ведь мы всегда готовы тратить время на то, что нам нравится.

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

Разница между QA, QC и тестировщиком

В есть два определения:

Обеспечение качества или QA (3.2.10)[от англ. quality assurance — обеспечение качества — прим. ред.— часть управления качеством, направленная на обеспечение уверенности в том, что требования к качеству будут выполнены.

Контроль качества или QC (3.2.11) от англ. quality control — контроль качества — прим. ред.— часть управления качеством, ориентированная на выполнение требований к качеству.

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

Allure TestOps

Allure TestOps – платформа управления качеством ПО, построенная с фокусом на автоматизацию, DevOps-процессы и гибкий цикл разработки. За счёт гибкости системы и большого количества клиентских библиотек и фреймворков её легко интегрировать с уже используемыми инструментами автоматизации тестирования.

Allure TestOps

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

Allure Test Ops

Возможности:

• Клиентские библиотеки

• Легкая интеграция с automation tools

• Хранение мануальных тестов в коде

• Кастомизируемые отчёты по автотестам

• Совмещение работы с мануальными и автоматизированными кейсами

• Многопоточность автотестов, отложенные запуски автотестов

• Кастомизация интерфейса\пользовательские атрибуты

• Тайм-менеджмент (TimeLine)

Allure TestOps

Цены: Allure TestOps стоит от $30 за пользователя в месяц

Бесплатная пробная версия: 30 дней по запросу

С какими препятствиями столкнулись при развитии нагрузочного тестирования в Miro

1. JMeter перестал нас устраивать. В нём было очень неудобно программировать и отлаживать. Сложные сценарии — это почти всегда разработка, а не заполнение форм или написание отдельных небольших скриптов. Сценарий в JMeter — это не программа в обычном понимании, а сочетание инструкций, заполненных в формах, с встроенным кодом скриптов. Также в JMeter плохо с контролем версий, т.к. сценарий хранится в огромном XML. А у нас большое количество WebSocket взаимодействия со своим бинарным протоколом и достаточно сложные сценарии, над которыми работает несколько человек. Не хотелось изобретать обходные пути вокруг «особенностей» JMeter.
2. Много ручных действий для каждого запуска НТ на тестовом окружении. TODO лист состоял из 16 пунктов для каждого запуска, которые надо было проделывать вручную… И это была боль… А боль — это сильный стимул что-то поменять.
3. Не хватало инструментов для генерации разных распределений тестовых данных. А сценарии тестирования для разных компонентов возможны разные и нужно было уметь быстро создать нужное распределение. Идеально использовать базу максимально близкую проду и откатывать после каждого теста, но не всегда это возможно: это могут быть огромные объёмы и надо чистить сенситивные данные пользователей, а воспроизводить синтетические данные в нужном объёме — тоже сложная задача.

1. Много задач.
2. Недостаточно опыта.
3. Недостаточно доступных людей.

Преимущества и недостатки профессии

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

Кроме того, к плюсам относят возможность близко знакомиться с новейшими технологиями в тестировании и разработке. Если вы захотите сменить профессию, но при этом оставаться в IT-сфере, должность QA – оптимальное место, с которого удобно присматриваться к новому направлению.

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

Этапы нагрузочного тестирования

1. Детализация требований — что требуется от системы в терминах нагрузки и производительности, какой тип теста проводим и какие метрики необходимо собрать для проверки требований. Как я писал ранее, общие требования нужны ещё до тестирования, а когда процесс начат, нужно их декомпозировать в предельно конкретные и технические требования. Также нужно выбрать тип теста, реализуемого в тестовом сценарии, и составить список метрик, на сбор которых нужно настроить приложение, сценарий и инфраструктуру. Это аналитическая задача.
2. Подготовка тестового окружения — где будем моделировать прод и пользователей. Необходимо выбрать одно из доступных или создать новое тестовое окружение под разработанные требования и настроить сбор метрик, нужных для оценки степени соответствия требованиям. Это задача DevOps специалистов.
3. Выбор инструмента тестирования и подготовка сценария — как будем моделировать поведение пользователей. В сценарии тоже нужно запрограммировать сбор метрик. Это задача разработки.
4. Проведение теста и замеры — каковы значения метрик. Это может звучать просто, но весьма редко всё работает с первого раза. Бывает нужно откатиться на один из предыдущих шагов и что-то поправить. На данном этапе проводится анализ некоторых ключевых показателей, чтобы убедиться, что нет критических ошибок теста. Этот шаг — задача тестирования. Основная работа по анализу будет вестись на следующем этапе.
5. Анализ — соответствует ли система требованиям, есть ли проблемы. Если собираются правильные метрики, всё должно быть относительно просто, хотя и трудоёмко, а если нет — опять может понадобиться откатиться вплоть до первого шага. Здесь, в отличие от предыдущего шага, мы глубоко погружаемся в большое количество метрик чтобы выявить все возможные значимые факты. Это аналитическая задача.
6. Подготовка отчёта — какие знания мы получили?.. Это самый важный этап. НТ — процесс очень затратный по ресурсам и вы явно захотите получить максимум знаний от него. Снова аналитическая задача.