Недостаточно просто написать какую-то программу или приложение — нужно ещё убедиться, что всё в ней работает как задумано, а нестандартное использование не приводит к ошибкам.
В любительских и учебных проектах с такой задачей может справиться сам разработчик, а ошибки можно исправлять по мере выявления. Но если продуктом будет пользоваться много людей, проверки должны быть более тщательными и разносторонними, и провести их нужно до того, как продукт попадёт на рынок.
Получается отдельная работа и самостоятельная специальность. Сегодня разбираем, кто такой тестировщик: как быстро можно обучиться и начать работать, что нужно знать, как можно развиваться и сколько получать.
Кто такой инженер по тестированию и чем он занимается
Если разработчик создаёт программу только для себя, то в случае ошибок проблемы будут только у самого разработчика. Но если её делают для сотен и тысяч пользователей, от ошибок пострадают и пользователи, и разработчики, и вся компания. Пользователи не смогут решить свои задачи, разработчикам придётся всё исправлять и дорабатывать, а компания понесёт убытки и заработает плохую репутацию.
Чтобы такого не было, ошибки стараются находить до финального релиза. Делать это можно по-разному. Например, можно привлечь сотрудников или ограниченный круг пользователей, чтобы они испытали продукт на себе и оставили замечания. Такой подход годится для небольших компаний и стартапов, но в нём есть недостатки. Если продукт тестируют сотрудники, то они либо занимаются этим вместо основной работы, либо уделяют этому процессу недостаточно внимания в свободное время. А если проверку доверяют первым пользователям, то их сообщения об ошибках нужно как-то систематизировать и обрабатывать. В любом случае на оба варианта нужно время и дополнительные ресурсы.
В серьёзных компаниях проверкой качества программных продуктов занимаются отдельные специалисты — тестировщики. Название может быть немного другим: инженер по тестированию, QA-тестировщик или QA engineer. QA — это аббревиатура слов quality assurance («обеспечение качества»). Такие специалисты проверяют софт в самых разнообразных условиях и пользуются им необычными способами, чтобы убедиться, что он работает должным образом, стабильно и соответствует всем требованиям. А если что-то нужно исправить, то после внесения изменений тестировщики снова проводят проверку.
Задачи и обязанности тестировщика
Профили тестировщиков бывают разными — точно так же, как разными бывают сами программы. Вот лишь несколько видов тестировщиков:
- тестировщик ПО;
- тестировщик сайтов;
- тестировщик игр;
- разработчик автотестов;
- тестировщик безопасности.
Но есть общие задачи, которые не зависят от того, какой именно продукт тестируется:
- изучать документацию и разбираться в работе того, что надо протестировать;
- анализировать требования и составлять список пунктов для проверки;
- составлять план тестирования по каждому пункту;
- проводить проверки и фиксировать результаты каждого тест-кейса.
Что такое тест-кейс
Тест-кейс — это специальная форма записи по каждому тестированию, то есть по каждой отдельной проверке. Работа формы регистрации, добавления в корзину, кнопок навигации — на все случаи нужен отдельный тест-кейс.
Единого стандарта этой записи нет, но есть общие правила. Хороший тест-кейс должен включать всё для удобства работы тестировщиков и разработчиков:
- все данные по проекту — название, проверяемый модуль, стадия работы;
- информацию об участниках — тестировщике, проверяющем, разработчиках;
- сведения про сам тест — дата, цель, ожидаемый и реальный результат;
- описание процесса, то есть алгоритм действий для каждого тестирования;
- выводы — что нужно устранить, что исправить, на что обратить внимание.
Получается одна удобная инструкция, которой можно пользоваться многократно. Например, после обновления дизайна можно протестировать работу основных функций и убедиться, что ничего не сломалось по пути.
Для тестирования есть много инструментов, и в большинстве есть возможность составления тест-кейсов. Вот пример одного из шаблонов для тестов:
Как тестировщики ищут ошибки
Для разных программ нужны разные виды тестирования и разные инструменты. Два основных способа — ручное и автоматическое.
Ручное тестирование проводят без специальных сервисов или программ: вручную вбивают данные в формах ввода, много раз перезагружают страницу, закрывают приложение во время сохранения данных и так далее. Ручное тестирование выполняют, даже если сделаны все автоматические проверки: только так можно убедиться, что продукт получился удобным для пользователей, которые будут совершать те же действия, что и тестировщики.
Автоматическое тестирование предполагает написание программ, которые будут тестировать другие программы. Это позволяет создать один алгоритм для частых повторяющихся проверок, например, для теста работоспособности основных функций после внесения изменений в один из составных модулей кода.
В каких случаях ручное тестирование лучше автоматического:
- проект небольшой или на начальном этапе разработки;
- проверяется понятность и удобство использования;
- тестировщик проводит исследование и ищет возможные проблемы, основываясь на интуиции и насмотренности;
- нужно проверить какие-то физические устройства — часто это быстрее сделать вручную, чем программировать автотесты.
Писать автотесты долго и дорого, но иногда их создание и использование оправданно:
- какой-то набор тест-кейсов часто повторяется;
- проект будет масштабироваться и расти — в этом случае лучше сразу добавлять автотесты ко всему, что пишут разработчики, чтобы видеть все ошибки при росте;
- при работе с большими объёмами информации, например при тестировании баз данных;
- чтобы исключить вероятность человеческой ошибки при ручном тестировании.
Что лучше — ручное или автоматическое тестирование
При ручном тестировании можно найти ошибку, которая не предусмотрена в алгоритме автотестов. Человек сможет оценить удобство и целесообразность интерфейса и общее впечатление от работы с сервисом, а машина — не сможет. Но проводить тесты вручную долго, а тестировщик может ошибиться, что-то забыть или не увидеть.
Автотесты работают быстро, ничего не забывают и сразу показывают ошибки в тех частях, для которых их написали. Но на написание нужно время и навыки, и автотесты тестируют только то, для чего созданы.
Правильнее будет сначала посчитать, сколько будет стоить работа каждого тестировщика и создание автотеста, прикинуть вероятность ошибки и стоимость её устранения. После этого можно решить, какие тесты и в каких объёмах необходимы для проекта.
Виды тестирования по назначению
Функциональное тестирование проверяет работу продукта по назначению и выявляет, работает ли он, как задумано. Это самый популярный вид тестирования.
Для теста нужно пройти по всем возможным сценариям использования и убедиться, что пользователи смогут взаимодействовать с сервисом так, чтобы решить свою задачу. Например, зарегистрироваться в онлайн-магазине, сделать заказ и получить уведомление на телефон и электронную почту.
Нефункциональное тестирование проверяет технические детали: производительность, безопасность, масштабируемость. Например, к нефункциональному тестированию относится нагрузочное: будет ли сайт работать, если на него одновременно зайдёт сто тысяч пользователей во время распродажи?
Статическое тестирование проводится без запуска финальной программы. Тестировщик проверяет написанный код, документацию и требования.
Статическое тестирование может быть ручным и автоматизированным. Можно написать другую программу, которая проверяет качество кода и документацию на соответствие требованиям, указанным тестировщиком.
Динамическое тестирование проходит во время запуска и работы готового кода. Тестировщик оценивает общее поведение программы. Запускается ли код вообще? Как сильно при этом нагружаются ресурсы компьютера? Достаточно ли быстро всё работает?
Динамическое тестирование тоже можно автоматизировать: написать программы, которые будут запускать основной сервис и замерять показатели.
Можно ли найти все ошибки
Зависит от конечного продукта. Если тестируется какой-то технический инструмент с жёсткими заранее известными правилами работы, например база данных, то автотесты с большой долей вероятности смогут покрыть 99% ошибок.
Если софт предполагает какие-то открытые сценарии, где можно импровизировать, например графический редактор или игровой движок, даже большая команда тестировщиков, скорее всего, не сможет предугадать все возможные ситуации. В таких сервисах важны не только тесты, но и быстрое исправление багов. Можно настроить автоматические оповещения о проблемах и для каждого выявленного случая написать автотест или тест-кейс.
Ещё бывают баги, которые появляются редко и не всегда по понятным причинам. Их нельзя предугадать заранее, а значит, нельзя и придумать алгоритмы для их выявления. Для таких ошибок придумали специальные названия, вот несколько из них:
- Гейзенбаг меняет свои свойства во время попыток устранения и починки.
- Баг Ферма появляется только на стороне пользователя.
- Баг Шрёдингера существует, но не влияет на работу программы до своего случайного обнаружения.
Какие бывают тестировщики
Профессия тестировщика довольно молодая, поэтому можно услышать много вариантов названия специалистов и обязанностей для каждого варианта. Но пока что они ещё не устоялись и зависят в основном от компании и её внутренних правил. Чаще всего используют такую градацию:
QA-тестировщик — это специалист, который следит за общим качеством продукта от начала разработки до выпуска в релиз и поддержки готовой версии. Можно сказать, что это директор по качеству тестирования.
Задача QA-инженера — предугадать все возможные сценарии происходящего:
- Как воспроизвести действия пользователей, которые вероятнее всего приведут к ошибкам? Как понять, что могут попытаться сделать клиенты? А что могут делать разработчики других систем, если начнут подключаться к нашему продукту по API? Как всё это систематизировать и ничего не упустить?
- Что, если сервис или приложение будут работать не так, как ожидают клиенты? Что можно сделать, чтобы продукт был понятнее для людей?
- Когда конечная программа выйдет в релиз и мы начнём получать ошибки — кто будет их исправлять? Как правильно расставить приоритеты ошибок, чтобы самые критичные из них разработчики могли исправить за час-два, а наименее срочные — максимум за неделю?
- После того как будет готова новая версия приложения — когда и как именно нужно провести повторное тестирование?
Это довольно общие вопросы, потому что QA охватывает всё происходящее с проектом.
QC (quality control) подключается на стадии тестирования готового продукта. Задача этого специалиста — проверить максимум возможных происшествий. Для этого нужно разобрать конкретные, более узкие вопросы:
- Какие фрагменты и модули сервиса или приложения нужно протестировать? Окно запуска, кнопки, формы обратной связи, скорость отклика?
- Что должны показать результаты тестирования? Какие результаты будут удовлетворительными, а какие — нет?
- В каких сценариях тестировщики должны проверять алгоритм работы вручную, а где обязательно нужно автоматизировать тесты?
- Как распределить работы между несколькими тестировщиками?
Если в компании много тестировщиков, то QC — это руководитель, который будет назначать каждому из них конкретные задачи и контролировать выполнение.
Тестировщик выполняет все задачи из списка QC после согласования этого списка с QA.
Часто на проектах есть только QA и тестировщики или вообще только QA, если продукт небольшой. Тестирование любого продукта предполагает все перечисленные уровни работы, просто их может выполнять один специалист.
Навыки специалиста по тестированию
По мере того как растёт уровень тестировщика, увеличивается объём его задач и требуемых знаний. Вот некоторые из навыков, которые могут понадобиться на старте:
- Знать правила работы с тестовой документацией и уметь писать её самостоятельно.
- Понимать код, на котором написан продукт, на базовом уровне, чтобы суметь разобраться в его логике.
- Уметь работать с SQL-запросами в базы данных и самостоятельно их составлять.
- Разбираться в системах контроля версий, например Git.
- Уметь отправлять API-запросы — для этого достаточно познакомиться с инструментом Postman или одним из его аналогов.
Ещё пригодится умение писать автотесты, но на старте можно обойтись без этого. Становиться разработчиком для тестирования необязательно.
Кроме технических навыков, важны личные качества:
- Внимательность. Если у вас её нет, придётся её развить, потому что для тестировщика это один из главных навыков.
- Дотошность. После идеальной работы QA-инженеров сервисы и приложения работают без сбоев, а это значит, что проверить нужно всё.
- Аналитическое мышление поможет не только находить ошибки, но и прогнозировать возможные действия пользователей.
- Умение отстаивать свою точку зрения — без него будет сложно постоянно доказывать разработчикам, что найденные ошибки нужно исправить, а не выпускать недоработанный продукт на рынок.
Плюсы и минусы профессии тестировщика
В любой работе можно найти разные преимущества и недостатки, но мы приведём самые очевидные. Загибайте пальцы.
Вот плюсы:
- Стать тестировщиком — один из самых быстрых и лёгких способов начать работать в ИТ.
- Для начала работы не нужно знать программирование и алгоритмы на высоком уровне, достаточно уметь базово разбираться в чужом коде. А освоить специальные инструменты для тестирования можно за несколько месяцев.
- У тестировщиков хорошая зарплата, и их работа востребована в разных областях.
- Ни одна серьёзная компания не станет выпускать на рынок непроверенный сервис, поэтому спрос на тестировщиков есть всегда.
Теперь к минусам:
- На старте (да и потом тоже) работа будет довольно однообразной по своей сути. Первые несколько месяцев нужно будет составлять похожие тест-кейсы, учиться работать с программистами и осваивать технические инструменты.
- Учиться тоже нужно, чтобы не отставать от остального мира ИТ.
- Ещё такая работа просто не всем понравится: нужно искать нестандартные подходы, анализировать поведение пользователей, защищать свою точку зрения перед командой и периодически быть тем злодеем, из-за которого выход продукта откладывается на несколько дней.
Карьера тестировщика
Можно начать работать тестировщиком-джуном, развиваться в этом направлении и дорасти до уровней QC и QA.
Если захочется уйти в сторону разработки, то это будет несложно сделать, если понимать общие принципы и уметь пользоваться нужными инструментами. Останется подтянуть навыки программирования и освоить дополнительные инструменты — какие именно, зависит от профиля разработки.
Во время работы тестировщик может учиться у других разработчиков, перенимать лучшие приёмы и практики и совершенствоваться в программировании. Поэтому можно сказать, что рост в QA идёт сразу в двух направлениях.
Сколько зарабатывают тестировщики
На момент написания этой статьи на сайте hh.ru в Москве открыты 2537 вакансий тестировщика, 535 из них — с зарплатой выше 75 000 ₽:
Хабр Карьера оценивает среднюю зарплату тестировщиков в 151 666 ₽. Разница между окладами джуна и мидла — почти в два раза:
Как стать тестировщиком
Чтобы понять, подходит вам это или нет, почитайте статьи о тестировании, посмотрите видео и интервью с практикующими тестировщиками, где они рассказывают о своей работе. На этом же этапе желательно пройти тесты на внимательность и аналитическое мышление, чтобы понять, на каком уровне у вас развиты эти навыки.
Ещё можно пройти курс Яндекс Практикума «Инженер по тестированию». Там есть бесплатная часть и с нуля учат, например, такому:
- анализировать требования к приложениям;
- создавать и вести проектную документацию;
- писать SQL-запросы;
- работать с таблицами;
- тестировать мобильные и веб-приложения, а также API;
- программировать на Python на базовом уровне;
- автоматизировать тесты;
- взаимодействовать с командой и другими ИТ-специалистами;
- работать с обратной связью от заказчиков.
Короче, тестирование — один из самых простых способов попасть в ИТ. Если хотите начать хоть с чего-то, начните с этого.
