Около трети вакансий, которые будет закрывать рекрутер в стандартной аутсорсинговой компании, — это тестировщики. А что нам известно о профессии тестировщика? Что это человек, который ищет баги? Но если копнуть глубже, окажется, что видов тестирования десятки, соответствующих специализаций — тоже. Кроме того, некоторые аутсорсинговые компании продают тестирование как самостоятельный вид услуги. Так что если разобраться в теме, то и продажи, и собеседования могут значительно улучшиться. Поехали.
Упрощенная классификация видов тестирования
Классификация видов тестирования
Итак, тестирование ПО — это процесс проверки программного продукта и сопутствующей документации с целью выявления дефектов до того, как ПО попадет к заказчику.
Существует огромное количество видов и подвидов тестирования. Многие тестировщики со временем выбирают какую-то конкретную специализацию и фокусируются на ней.
Must have в тестировании
Как и в любой профессии, в тестировании есть необходимый минимум, который должен знать каждый тестировщик, независимо от уровня.
-
Смоук-тестирование
Смоук (от англ. smoke — дым) тестирование направлено на проверку самой главной, самой важной, самой ключевой функциональности, неработоспособность которой делает бессмысленной саму идею использования приложения.
Смоук-тестирование проводят в двух случаях:
- после выхода нового билда (версии) ПО — в данном случае смоук-тестирование помогает принять решение о целесообразности проведения других видов тестов, таких как тестирование критического пути и т.д., поскольку при наличии критических багов дальнейшее тестирование, как правило, останавливается, чтобы не тратить время впустую;
- при срочном выпуске новой версии ПО на продакшн (hot-fix) — в случае, когда выпуск новой версии ПО критически важен, например, в случае серьезных проблем, блокирующих работу на стороне заказчика, вместо регрессионного тестирования ограничиваются смоуком в целях экономии времени.
Количество смоук-тестов всегда небольшое, они сосредоточены исключительно на критической функциональности продукта и являются хорошими кандидатами для автоматизации, т.к. смоук-тестирование выполняется часто.
Алгоритм действий при проведении смоук-тестирования
Регрессионное тестирование
Задача регрессионного тестирования — проверить, что в ранее работоспособной функциональности не появились ошибки, вызванные изменениями в другой части приложения или среде его функционирования. Дело в том, что при исправлении какого-либо дефекта или добавления новой функциональности есть ненулевая вероятность (по разным данным от 20 до 40%), что появятся новые дефекты там, где их раньше не было. Именно поэтому регрессионное тестирование является неотъемлемым инструментом обеспечения качества и используется практически в любом проекте.
Стоит отметить, что регрессионное тестирование — довольно дорогое с точки зрения временных и финансовых затрат, поэтому часто регрессию проводят не по всему программному продукту, а только для тех частей, которые могли быть «затронуты» изменениями в билде.
Ручное тестирование
На сегодняшний день ручное тестирование остается основополагающим типом проверки качества разрабатываемого продукта.
Основные плюсы ручного тестирования
- Возможность обратной связи о UI и UX. Тестировщик примеряет на себя роль конечного пользователя и может внести предложения об улучшении опыта использования. Аналогично в случае UI недочетов, например, отличающихся цветов или дефектной анимации (например, с долгой задержкой).
- Гибкость. В случае мелких изменений и правок тестирование занимает небольшое время, не нужно тратить время на написание кода для автоматизированных тестов.
- Простота внедрения. Для небольших и средних проектов чаще всего используют ручное тестирование именно по причине простоты внедрения: не нужно настраивать специальное окружение и инструментарий для тестов, не нужно использовать CI/CD для их автоматического запуска и т.д. (об этом мы подробно писали в нашей статье).
Основными минусами ручного тестирования являются невозможность смоделировать большую нагрузку пользователей на систему (применимо не для всех программных продуктов) и большое количество времени, необходимое для проведения всего объема тестирования по сравнению с автоматизированным тестированием.
Автоматизированное тестирование
Автоматизированное тестирование — частично или полностью автоматизированный процесс, при котором тест-кейсы выполняет специальная программа.
Основные плюсы автоматизированного тестирования приложений
- Повторяемость: автоматизированные тесты частично или полностью могут быть переиспользованы, например, при внедрении новой функциональности.
- Небольшое время прохождения тестов: по сравнению с ручным тестированием время, затрачиваемое на выполнение полного объема тестов, в случае автоматизации в десятки раз ниже.
- Возможность моделирования сложных сценариев, например, высокой нагрузки на приложение или security-атаки.
Основные минусы автоматизированного тестирования
- Высокая стоимость внедрения. Мы уже говорили, что автоматизация требует времени как на настройку процессов, так и на написание и поддержку самих автотестов.
- Ненадежность. Зачастую при автоматическом тестировании возникают дополнительные технические проблемы, например, тесты не запускаются или их прохождение занимает очень много времени.
Чем выше уровень тестировщика, тем более всеобъемлющим будет тестирование. Кратко рассмотрим возможные виды тестирования, часто применяющиеся на проектах.
Наиболее частые виды тестирования
Справочная информация для ознакомления
По запуску кода на исполнение
- Статическое тестирование — тип тестирования, который предполагает, что программный код во время тестирования не будет выполняться. Это тестирование начинается на ранних этапах жизненного цикла ПО. Для этого типа тестирования в некоторых случаях даже не нужен компьютер, например, при тестировании спецификации проверяются сами требования на предмет их полноты, однозначности и т.д., то есть происходит просто вычитка требований.
- Динамическое тестирование — это методика, направленная на проверку работы программы во время выполнения кода. То есть данный тип тестирования подразумевает фактическую эксплуатацию программы и проверку, работает она в соответствии с ожиданиями либо нет.
По доступу к коду и архитектуре приложения
- Метод белого ящика (англ. white box testing) — это метод тестирования, когда мы имеем доступ к коду и тестируем его. Тестировщики могут видеть код на этой стадии, поэтому метод имеет и другие названия, например: открытое тестирование или проверка кода.
- Метод черного ящика ( англ. black box testing) — это когда мы ничего не знаем о внутреннем устройстве системы. У нас нет доступа к коду или мы не умеем его читать. Поэтому ориентируемся только на внешнее поведение системы или техническое задание. Например, в требованиях указано, что по нажатию на кнопку «Войти» в интернет-магазине пользователь должен попасть на экран личного кабинета. При тестировании методом черного ящика тестировщик проверяет, что внешнее поведение системы соответствует требованиям, то есть пользователь действительно попадает в личный кабинет, а не на главную страницу сайта, к примеру.
- Метод серого ящика ( англ. gray box testing) — совмещение методов белого и черного ящика. Это метод тестирования программного обеспечения с неполным знанием его внутреннего устройства. Чтобы выполнить подобный вид тестов, не нужно иметь доступ к исходному коду ПО. Тесты создаются на базе простого знания алгоритмов, архитектуры и других характеристик поведения продукта. Например, нужно проверить сортировку товаров в списке на сайте интернет-магазина. Зная алгоритм сортировки (белый ящик), тестировщик может составить тест-кейсы на все возможные комбинации и протестировать их с точки зрения выдачи пользователю (черный ящик). Как правило, тестирование методом серого ящика применяют для проверки алгоритмов, когда доступ к коду ограничен и невозможно провести тестирование методом белого ящика.
По уровню детализации приложения (по уровню тестирования)
- Модульное (компонентное) тестирование — тестирование каждой отдельной части приложения обособленно в искусственной среде. Цель состоит в том, чтобы проверить, что каждая единица программного приложения работает должным образом. Модульное тестирование выполняется разработчиками во время разработки (фаза кодирования) приложения.
- Интеграционное тестирование — это тип тестирования, при котором части приложения логически объединяются и тестируются как группа. В основном программный продукт состоит из нескольких таких приложений, которые пишут разные программисты. Целью интеграционного тестирования является выявление багов при взаимодействии между этими приложениями.
- Системное тестирование — это тип тестирования, при котором проверяется взаимодействие всех частей приложения в составе единой системы. Это завершающий этап тестирования, когда разработчики и тестировщики вместе с пользователями (если это возможно) проводят тестирование всей системы: смотрят, где реальное поведение пользователя отличается от ожидаемого, куда кликают пользователи, какое время отклика интернет-странички и пр.
Системное тестирование проводится при следующих условиях:
- модульное и интеграционное тестирование успешно завершено;
- разработка ПО в соответствии с требованиями спецификации завершена;
- создана соответствующая тестовая среда для проведения системного тестирования.
По принципам работы с приложением
- Позитивное тестирование — это тестирование с применением сценариев, которые соответствуют нормальному (штатному, ожидаемому) поведению системы. С его помощью мы можем определить, что система делает то, для чего и была создана. Тестирование проводится строго по инструкции, не допускается ввод некорректных данных.
- Негативное тестирование — это тестирование, в рамках которого применяются сценарии, которые соответствуют внештатному поведению тестируемой системы. Это могут быть исключительные ситуации или неверные данные. Например, если по техзаданию поле ввода может содержать только цифры, то одна из стандартных негативных проверок в тестировании включает в себя ввод букв (латиница и кириллица), специальных символов и пробелов.
Позитивные тесты являются приоритетными. В первую очередь следует проверить основной функционал продукта, способность корректно обрабатывать корректные запросы пользователя, условно проверяется «правильная» работа пользователя с системой. А уже потом приступаем к проверке системы на пользователя, который допускает различные ошибки. И наша система должна быть готова ответить на неверный запрос.
Тестировщик — кто это?
Тестировщики задействованы практически на каждом проекте по разработке ПО.
Не стоит путать профессию тестировщика и профессию QA-инженера (читать про различия этих двух профессий здесь). Обычно тестировщики занимаются проверкой работоспособности продукта и его внешнего вида. Однако бывает, что возникает необходимость проверки и баз данных, и бизнес-процессов. В своей работе тестировщики постоянно взаимодействуют с представителями заказчика, разработчиками, дизайнерами.
В зависимости от специализации профессия тестировщика также разделяется на несколько видов. Рассмотрим основные из них.
Ручные тестировщики
Ручной (функциональный, мануальный, manual QA engineer) тестировщик — это человек, который вручную проверяет программу на баги и уязвимости. Все сценарии прогоняются тестировщиком вручную каждый раз. Отсюда следует и вывод о том, что наиболее целесообразно ручное тестирование применять на небольших и средних проектах, где инвестиции в написание автоматизированных тестов не окупаются.
Вилка зарплат для ручного тестировщика колеблется в зависимости от опыта (junior vs. senior) и специализации (к примеру, тестировщики-автоматизаторы получают больше ручных).
Статистика зарплат ручных тестировщиков за 2020 год по версии dev.by
Наиболее частые требования к тестировщику уровня middle (более 90% вакансий на рынке труда) — это хороший английский, знание и опыт в тестировании и баг-репортинге, базовые знания SQL.
Примеры требований к кандидату на позицию Test Engineer от различных IT-компаний
Практически все виды ручного тестирования так или иначе можно продать как услугу. Сегодня существуют целые компании, основным видом деятельности которых является аутсорс тестирования (наиболее известная — A1QA).
Аутсорс тестирования как отдельная услуга от IT-компаний
Тестировщики-автоматизаторы
Если ручному тестировщику необязательно знать программирование, то автоматизатор (test automation engineer) — тестировщик, целью работы которого является написание кода, который автоматизирует процесс тестирования. То есть фактически это программист.
Основные требования, выдвигаемые работодателями к middle test automation engineer: хороший английский, знание CI/CD (зачастую автоматизаторам самим необходимо построить процесс и окружение для выполнения автотестов), знание языка программирования (чаще всего Python) и различных фреймворков для написания автотестов.
Требования и вилки зарплат
Другие специализации в тестировании
- Иногда на проектах выделяют отдельную роль для security-тестировщика. Security Engineer, Penetration Tester, Security Expert — все это названия одной специальности. В функциональные обязанности такого специалиста входит выявление уязвимостей ПО и оценка защищенности продукта. Кроме работы с самим продуктом, проводится анализ тестового окружения, способов передачи и хранения данных. Иногда security-тестировщиков называют «белыми хакерами». И это имеет смысл. Ведь и тестировщики, и хакеры пытаются взломать систему. Только тестировщики взламывают ее, чтобы сделать еще более надежной.
- Рerformance-тестировщики тоже занимают свою нишу среди тестировщиков. На некоторых проектах выделяют целые отделы, которые занимаются тестированием производительности программного обеспечения и нагрузок на приложение, измеряют время выполнения различных операций приложением и определяют допустимое количество пользователей приложения.
- Usability-тестировщики (от англ. Usability — удобство) проверяют привлекательность продукта для пользователя и удобство его использования. Функциональными обязанностями тестировщиков являются анализ цветового оформления продукта и грамотное использование его графических элементов, анализ текстового наполнения сайта, анализ шрифтового оформления текста, оценка удобства пользования сервисами.
Где искать тестировщиков?
Кроме известной и самой популярной площадки — LinkedIn, тестировщиков можно искать на тематических площадках и форумах (software-testing.ru, protesting.ru и т.д.).
В последнее время все большие обороты набирают специализированные чаты в Telegram (например, @qaclub_minsk), группы в социальных сетях.
Можно обратить внимание на докладчиков на специализированных конференциях, например, SQA Days, TestCon, COMAQA, QAASP и др., а также людей, ведущих профессиональный блог, и активных участников сообществ.
Подфорумы software-testing.ru / Группа по поиску работы для тестировщиков в VK
Краткие итоги
- Не стоит путать профессию тестировщика и профессию QA-инженера.
- Спрос на тестировщиков остается неизменным — примерно 30% от всех вакансий. Самые популярные специализации по-прежнему ручное и автоматизированное тестирование.
- 90% вакансий для тестировщика — от уровня middle и выше.
- Наиболее популярные площадки для поиска кандидатов — LinkedIn, тематические группы в соцсетях и Telegram.
HRPR — это 10+ лет подготовки IT-рекрутеров
Наши рекрутеры работают уже на трех континентах. Blizzard, Actvision, Google, AT&T, Bell, Amazon — это начало алфавита компаний, где работают наши выпускники.