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. Тестирование и его цели
Тестирование имеет два определения:
– Тестирование как процесс – это систематический, структурированный подход к оценке и улучшению качества программного продукта, включающий в себя разные этапы.
– Тестирование как деятельность – это выполнение тестовых процедур и методик с целью обнаружения дефектов в программном обеспечении и оценки его соответствия требованиям и ожиданиям.
Цели тестирования:
– Подтверждение факта того, что программное обеспечение соответствует различным требованиям и спецификациям на всех этапах тестирования.
– Оценка качества программного обеспечения в каждый момент времени.
– Снижение риска появления дефектов на всех этапах жизни программного обеспечения и уменьшение последствий при их возникновении.
Это цели тестирования как науки. В документации проекта прописано, какие цели тестирования преследуются, но они будут описаны более конкретно уже в контексте самого проекта.
Опытные инженеры, возможно, зададутся вопросом, почему здесь перечислены только три цели, а не больше, как иногда приводится в других источниках. Поясню причины.
Обычно список дополнен пунктами, которые звучат примерно так:
– Обнаружение дефектов. Однако их мы обнаруживаем при проверке соответствия программного обеспечения требованиям. Обнаружение или не обнаружение является следствием, а не самоцелью.
– Подтверждение безопасности. Но критерии безопасности в работе приложения – это такие же обычные требования, которые мы проверяем. Кроме области применения они ничем не отличаются от других требований.
– Подтверждение надежности и стабильности. То, насколько стабильно и надежно работает приложение в разных условиях, это тоже формализованные требования к нему или системе в целом.
– Подтверждение производительности. Производительность любого элемента системы это требование к ней, которое формализуют и проверяют.
– Обеспечение соответствия стандартам, законам и т.д. Любой стандарт или закон это требование, которое должно быть выполнено или учтено в программном обеспечении и впоследствии проверено.
А вот в контексте самого проекта можно более подробно описать первую цель тестирования, акцентируя его на безопасности, надежности, стандартах и т.д.