Бесплатный фрагмент - QA Engineer

ОБ АВТОРЕ

В период написания этой книги я выполнял работу Software Developer in Test, разрабатывая автоматизации как для QA, так и за пределами этой области. Вдобавок к этому консультировал менеджеров от QA Lead до CEO в вопросах процессов и стратегий, а также давал рекомендации за пределами компании. Я прошел путь от QA Engineer до Head of QA в других компаниях, а собственные идеи позволили значительно повысить качество моих проектов.

Мой путь не типичен и начался с того, что в средней школе я с легкостью решал задачи по программированию для старшеклассников, при этом не имея доступа к интернету или профильным книгам. В техникуме и университете я смог доказать себе и остальным, что понимание и любопытство важнее, а главное, эффективнее запоминания. За 7 лет я получил два диплома по разработке программного обеспечения, один из них с отличием. Я писал полноценные Web и Desktop приложения, а также Backend для игр. Такой опыт позволил мне интуитивно понимать аналитику и тестирование. Для меня всегда было важно, чтобы мои небольшие детища работали хорошо. В то же время любопытство заставляло задавать вопрос «А что если?».

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

О КНИГЕ

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

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

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

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

1. КТО ТАКОЙ QA ИНЖЕНЕР

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

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

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

Плюс заключается в том, что, хорошо освоив эту профессию, всегда можно уйти в аналитику, дизайн, разработку, автоматизацию тестирования или разные виды менеджмента. Да, такой переход потребует немалых усилий и скорее всего будет означать кратковременное понижение заработной платы. Но опыт работы в тестировании и в целом в ИТ никуда не пропадет, а даже даст в чём-то преимущества на новом месте. В любом случае работа QA инженера предполагает развитие навыков в «T–shaped», а этот подход в будущем даст больше возможностей в карьере. Ведь у вас со временем появятся широкие познания о смежных областях и одновременно хороший опыт своей специальности. Также существует довольно много видов QA инженеров, каждый из которых занимается своей углубленной задачей. А значит, возможно, менее болезненно будет поменять направление внутри профессии QA инженера.

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

Вот, какие личностные качества необходимы:

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

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

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

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

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

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

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

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

— Операционные системы — вы должны понимать, как установить приложение на Windows, MacOS, iOS, Android, Linux (реже) и уметь изменять настройки операционной системы на уровне обычного пользователя. В процессе работы вы наверняка будете что–то устанавливать и этот простейший навык, конечно, пригодится.

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

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

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

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

— Работа приложений — общее понимание того, как работают приложения или их части, и чем они отличаются от других (Desktop, Web, Mobile, backend–часть). Временами приложения внутри устроены довольно сложно, что увеличивает вероятность ошибок. Понимание устройства приложения помогает их находить.

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

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

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

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

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

2. ГРАДАЦИИ QA ИНЖЕНЕРОВ

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

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

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

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

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

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

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

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

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

Вы наверно заметили, что я часто упоминаю слово «карьера» и это не просто так. Большинство QA инженеров строят карьеру, даже не называя ее так. Они проводят анализ имеющихся возможностей и раз за разом делают выбор. На первых этапах это не очень сложно. У большинства специалистов на старте карьеры довольно низкая зарплата. Просматривая вакансии они понимают, что достаточно потратить несколько месяцев, чтобы обучиться новому, и это откроет путь к увеличению зарплаты на ощутимый процент. Поэтому если вы не планируете всю жизнь работать за условные 500–800$ и бояться оказаться ненужным как специалист, то рекомендую временами думать о том, куда движется ваша карьера и движется ли она вообще.

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

2.1. Разделение по уровню опыта (по грейдам)

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

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

Грейды:

— Trainee — люди этого уровня способны выполнять лишь 10–15% задач, относящихся к простым, и с большими временными затратами, а их работу требуется обязательно перепроверять и исправлять.

— Junior — сотрудник, способный выполнить 40–50% задач со скоростью ниже среднего, его работа все еще требует тщательных проверок, исправлений, регулярной помощи и наставлений.

— Middle — на этом уровне специалист может самостоятельно без дополнительной помощи выполнять 80–90% всех задач, которые только можно придумать. Его скорость работы средняя или немного выше.

— Senior — тот, кто выполнит не только оставшиеся 10–20% работы с высокой скоростью, но и самостоятельно решит задачи, о которых даже Интернету ничего не известно.

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

2.2. Разделение по уровню ответственности

Здесь речь именно о степени ответственности, а не о должностях, так как на практике чаще всего инженеры полностью или частично берут на себя роль Lead, то есть специалист квалификации Middle может выполнять эту роль. Это обусловлено естественностью процесса повышения навыков.

Уровни:

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

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

— Head — управляет работой нескольких Lead и несет ответственность за тестирование всего проекта или группы проектов. Создает и исполняет длительные стратегические планы, управляет ресурсами и длительными планами развития сотрудников. Его отличает то, что этот специалист совсем или почти не занимается обычным тестированием роли Engineer, вместо этого он сосредоточен на стратегических задачах. Хотя участвовать в процессе он, конечно, может, особенно если это касается автоматизации тестирования.

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

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

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

2.3. Разделение по функции

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

Типы:

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

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

— Fullstack QA Engineer — это инженер, занимающийся ручным и автоматизированным тестированием.

— Software Developer Engineer in Test (SDET) — это разработчик с хорошим опытом в тестировании. Занимается автоматизацией ручного тестирования, DevOps задачами и разработкой полноценных приложений/ботов/скриптов для нужд команды QA.

— (Manual / Automation / Fullstack / SDET) Lead — это инженер, выполняющий функции в одной из областей: Manual, Automation, Fullstack, SDET и управляющий командой, состоящей только из Manual / Automation / Fullstack / SDET специалистов.

К сожалению, при поиске работы вы постоянно будете сталкиваться с тем, что название вакансии сильно расходится с функциями в описании. Не очень сложно найти вакансии QA Engineer, в описании одной из которых от вас не требуют опыта и предлагают заниматься только ручным тестированием, а в другой вы должны быть опытным Senior автоматизатором с более чем пятилетним опытом. Не редки вакансии, где SDET называют Automation QA и наоборот, а QA Lead на самом деле выполняет работу Head of QA.

2.4. Разделение по типу программного обеспечения

В разделении по типу программного обеспечения обратите внимание на то, что backend часть проектов на практике не всегда, но нередко является общей для нескольких систем (Web, Mobile, и т.д.).

Типы:

— Web Engineer — тестирование frontend и всех частей backend веб–сайтов. Один из самых востребованных сегментов, в котором за последние годы сильно выросли требования к знаниям и умениям инженеров.

— Mobile Engineer — тестирование мобильных приложений и нередко backend. Возможно, это уже немного обогнавший Web сегмент, в котором также выросли требования к знаниям и умениям инженеров.

— Desktop Engineer — ставший менее популярным сегмент тестирования приложений для Windows/Mac/Linux, который, тем не менее, очень востребован. Приложения на компьютеры никуда не делись и исчезнут не скоро. Требования к инженерам тут растут не так быстро, как в Web и Mobile.

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

2.5. Разделение по направлениям тестирования

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

Состоит из:

— Manual Engineer — инженер, создающий и выполняющий тесты вручную.

— Automation Engineer — инженер, создающий и выполняющий автоматизированные тесты.

2.6. Градация инженеров на практике

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

К осознанным можно отнести:

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

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

К неосознанным можно отнести:

— Отсутствие компетенции для объективной оценки сотрудников. Ситуации, когда человек уровня Middle годами занимает позицию QA Lead, не редки в мире. Возможно, в компании нет QA Lead в принципе и сотрудников оценивает, к примеру, Project Manager, не имеющий для этого компетенций в QA. На практике это могут быть компании даже с количеством QA инженеров в десятки человек.

— Сильно устаревшее понимание количества навыков, необходимых для определенного грейда. Если уровень тестирования на проекте не повышали 10 лет, то было бы странно переписать название должностей существующих сотрудников, понизив их в грейдах. Отсюда и появляются Senior++, Super Principal и другие непонятные грейды навыки которых заметно превышают требования и представления о грейдах на проекте и которых непонятно как оценить в данных условиях.

3. КЛАССИФИКАЦИЯ ТЕСТИРОВАНИЯ

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

3.1. Классификация по типу приложения

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

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

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

— Mobile — сюда относятся все приложения мобильных платформ для смартфонов и планшетов. Они отличаются тем, что работают на таких мобильных устройствах и требуют установки на них. Тестирование наиболее похоже на Desktop и приложения тоже могут устанавливать на устройство полностью или только с «легким» клиентом.

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

Категории Mobile, Web и Desktop могут включать в себя Backend как неотъемлемую часть для выполнения бизнес-задачи. В то же время информацию для таких приложений могут предоставлять один или несколько сторонних Backend приложений, не имеющих никаких графических оболочек и выполняющих роль сервиса. Также на практике QA инженеры могут участвовать в тестировании целых экосистем, состоящих из множества приложений всех представленных видов.

3.2. Классификация по запуску кода

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

Классификация включает следующие виды:

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

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

3.3. Классификация по доступу к коду

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

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

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

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

Самым распространенным видом тестирования в этой классификации является Grey box, так как он даёт достаточно высокую эффективность в сравнении с Black box и не требует очень высокого уровня квалификации как White box. При этом Black box сам по себе не говорит о низком качестве тестирования, напротив, он направлен на имитацию работы обычного пользователя, который также мало что знает о работе приложения изнутри.

3.4. Классификация по способу выполнения тестирования

Эта классификация разделяет тестирование по тому, каким способом выполняют тесты.

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

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

3.5. Классификация по уровню архитектуры

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

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

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

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

QA инженер обычно участвует в тестировании приложения на системном уровне, однако он может участвовать и в остальных уровнях (реже).

3.6. Классификация по принципу проверок

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

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

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

Примеры:

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

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

3.7. Классификация тестирования по целям и задачам

Данная классификация разделяет тестирование на основе конкретных главных целей, которые преследуют в процессе проверки программного продукта.

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

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

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

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

— Тестирование безопасности — проводится для выявления уязвимостей, дыр в безопасности и потенциальных угроз для программного продукта. Задачи включают проверки на уязвимость к взлому, SQL–инъекциям, переполнению буфера и другим атакам, а также оценку политик безопасности, механизмов аутентификации и авторизации.

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

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

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

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

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

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

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

4. БАЗОВАЯ ТЕОРИЯ О ТЕСТИРОВАНИИ

4.1. Тестирование и его цели

Тестирование имеет два определения:

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

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

Цели тестирования:

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

— Оценка качества программного обеспечения в каждый момент времени.

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

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

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

Обычно список дополнен пунктами, которые звучат примерно так:

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

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

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

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

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

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

4.2. QA, QC и Testing

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

4.2.1. Testing

Целью Testing (Тестирования) является вся деятельность для выполнения проверок и обнаружения несоответствий между ожидаемыми и фактическими результатами работы тестируемого продукта.

Тестирование включает в себя создание баг репортов, чек–листов, тестовых сценариев, их выполнение. Оно является частью Quality Control и полностью входит в него.

4.2.2. QC (Quality Control)

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

Контроль качества включает в себя результаты проведенного тестирования (Testing), их анализ и оценку для получения картины о том, каким качеством обладает программное обеспечение. Контроль качества является частью Quality Assurance и полностью входит в него.

4.2.3. QA (Quality Assurance)

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

Визуально QA–QC–Testing можно представить так:

Таким образом, QA–QC–Testing являются более подробным описанием трех целей тестирования и того, какие действия проводят для их достижения, без привязки к конкретному программному обеспечению/проекту/компании.

Если более коротко, то:

— Testing — это исследование качества.

— QC — это оценка и контроль уровня качества.

— QA — это создание, улучшение, выполнение регламентов по предотвращению появления дефектов.

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

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

Всего есть шесть основных принципов тестирования:

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

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

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

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

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

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

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

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

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

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

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

4.4. Качество программного обеспечения

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

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

Основные критерии качества:

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

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

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

— Надежность — программное обеспечение должно стабильно работать при различных сбоях и отказах.

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

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

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

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

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

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

4.5. Требования

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

Например:

— Площадь квадрата вычислять по формуле S=a2, где S — площадь, а — длина стороны.

— При открытии Door_127 запускается NPC типа Guard_5, находящийся в Room_34 и запускается скрипт NPC Atack_360.

— Данные хранить в SQL таблице Users с полями: ID (int, unique, not null), login (varchar, unique, not null), password (varchar, not null).

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

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

Типы требований:

— Business Requirements — описывают высокоуровневые цели и задачи бизнеса, которые должен решить проект или отдельная задача. В таких требованиях обычно нет совсем никаких подробностей о реализации, а только цели и потребности бизнеса с их абстрактными решениями. Тестирование таких требований со стороны QA инженеров маловероятно.

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

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

— Non–functional Requirements — описывают нефункциональные атрибуты системы, такие как: производительность, надежность, безопасность, удобство использования, совместимость и т. д. В тестировании таких требований участвуют QA инженеры. Они могут иметь ограниченные технические знания, однако это не мешает им проверить само качество требований.

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

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

Требования могут быть качественными или нет.

Критерии качества требований:

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

— Измеримость — должен существовать способ проверить, выполнено требование или нет.

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

— Атомарность — требование должно быть настолько неделимым, насколько это возможно.

— Релевантность — требование должно быть важным для бизнес–целей проекта.

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

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

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

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

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

— Проранжированность — требования должны быть отсортированы в соответствии с важностью целей.

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

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