Если вы знаете язык программирования, вы можете стать разработчиком и писать код. Если знаете математику, можете стать дата-сайентистом и извлекать знания из биг-даты. Если разбираетесь в людях, бизнесе и технологиях, можно стать продактом и рулить продуктом в целом.
А кто такой инженер по тестированию? Говорят, что это хороший трамплин в ИТ. Разберёмся.
На микроволновках
Допустим, в компании решили создать бытовую микроволновку.
Продакт-менеджер:
Коллеги, нам нужно устройство, в котором люди смогут разогревать блюда, но без нагревательного элемента. Чтобы работала быстро. Размер такой-то. Нужна дверца. Обязательно таймер.
Разработчик:
Для этого подходят микроволны. Потребуется сделать вращающуюся платформу и фарадееву клетку.
Продакт:
Ничего не понял, делайте.
Инженер по тестированию:
Постойте!
Все:
Что?
Инженер по тестированию:
От какого напряжения будет работать? Какая будет защита от перепадов? А если включить в розетку вдвое менее мощную? Что там можно будет греть, а что нельзя? Что если включить с открытой дверцей? Что будет, если греть воду? Что если греть камень? А сталь? А кота? А динамит? А если поджечь фитиль? А если туда ничего не положить и включить?
Все крепко думают.
Это и есть работа тестировщика: убедиться, что продукт работает нормально в штатных и внештатных ситуациях. По-умному будет так: «Насколько реальное поведение продукта совпадает с ожидаемым и как это отразится на опыте пользователя?»
Какие бывают
В ИТ-среде в связи с тестированием и качеством принято три обозначения:
QA — quality assurance, самый главный по качеству;
QC — quality control, контролёр качества;
Tester — тестировщик.
В разных компаниях эти обозначения могут сливаться или дополнительно разделяться, но в целом картинка такая.
QA — это тот, кто думает о качестве продукта в целом, причём не только о конечном коде, но и всего процесса разработки. Например:
Как понять пользовательские сценарии, в которых вероятнее всего возникнут ошибки? Как их собрать? Как систематизировать? Как ничего не упустить? (Например, как понять, какие именно предметы люди могут догадаться засунуть в микроволновку, и как защититься от идиотов, которые засунут туда динамит?)
Как соединить запросы людей, требования бизнеса и реальные возможности продукта с точки зрения качества? Что если наш продукт совсем не делает то, чего пользователи могут ожидать? Например, если они будут сушить в микроволновке кошку — это чья проблема? Будем ли мы с этим что-то делать?
Кто, как и в каком порядке будет исправлять ошибки? Как мы будем повторно тестировать места с ошибками?
Что и как тестировать от версии к версии программы, чтобы это было достаточно быстро, но не в ущерб качеству?
Можно представить, что QA — это директор по качеству, главный человек на пути у багов. Он не менее важен, чем главный архитектор или ИТ-директор. Многие его функции могут пересекаться с функциями других ИТ-директоров.
QC — это тот, кто сфокусирован на тестировании самого продукта:
Что именно тестируем? Какие функции, кнопки, состояния, сценарии?
Какие результаты тестирования нам нужны? Какие исходы правильные, а какие — ошибки?
Как автоматизируем тесты? Что нужно обязательно пройти ручками?
Как синхронизировать работу нескольких тестировщиков? Как распределить задачи, области, слои?
Можно представить, что это такой главный бригадир тестировщиков. Его работа — чтобы тесты шли ровно и чётко, без проблем. Разумеется, очень полезно, если он умеет непосредственно тестировать.
Тестировщик — это тот, кто тестирует продукт: проходит его ручками или пишет автоматические тесты; описывает баги; общается с разработчиком по поводу этих багов; заново тестирует исправленное.
Зачем столько тестировщиков
Когда продукт маленький, функция тестировщика может лежать на самом разработчике: сам написал код, сам проверил работу. Никакие QA и QC в маленьком продукте не нужны — там всё решается быстро и компактно.
Но продукты имеют свойство расти: сначала там один разработчик, потом трое. Каждый протестировал свою часть продукта, а кто протестирует продукт в целом и проверит «стыки»? Нужен тестировщик. Продукт продолжает расти, и вот уже у нас не один тестировщик, а пятеро: как сделать так, чтобы они не тестировали одно и то же? Или тестировали, но по правильной методике? Значит, им нужен бригадир — QC.
Не успели оглянуться — и вы уже делаете массовый веб-сервис, у вас несколько сотен тысяч клиентов, а сам сервис состоит из десятков модулей. И часть модулей делают в Москве, другую часть — в Санкт-Петербурге, третью — в Екатеринбурге. У каждого офиса своя атмосфера, куча собственных нюансов и проблем. И вот это всё нужно «причесать», чтобы внутри и на стыках этих модулей не было багов. Над этим работают десятки тестировщиков, несколько QC и один большой важный QA, который управляет тестированием.
Что делает тестировщик
Тестировщику дают продукт и требования к нему (документацию). Он всё это изучает и сопоставляет. Придумывает, как это всё тестировать. Его задача — проверить, чтобы продукт исполнял возложенные на него обязанности по документации, а потом — проверить всякие нештатные ситуации и предложить улучшения.
Само тестирование происходит по множеству разных сценариев. Например, так:
Тестировщик открывает продукт как пользователь и проходит все стандартные сценарии — как будет происходить у 80% всех людей. Все баги фиксирует.
Потом он может пройти кромешные варианты — например, если у человека очень длинное имя или трёхзначный возраст. Например, если у вас интернет-магазин, то что будет, если в нём закажет товар Его Пресвятое Величество Константин Константинович «Навуходоносор II» Константинопольский?
Можно попробовать взломать продукт: вместо имени ввести код; добавить в корзину бесконечное количество товаров; добавить в корзину −1 (минус один) товар; добавить в корзину больше 40 тысяч товаров (и перегрузить переменную счётчика товаров); поискать в строке поиска «Войну и мир» (полный текст).
Можно представить, что у пользователя дефектное устройство: например, ввод происходит бесконечно быстро или вместо русских букв в поле ввода вставляются картинки. Как тогда поведёт себя программа? Все находки фиксируются в багтрекере.
Какие-то из этих тестов можно автоматизировать: пишется специальная программа, которая симулирует действия пользователя и сравнивает результаты с эталоном. Другие тесты обязательно проходятся ручками.
Отдельная кухня — это то, как тестировщик фиксирует баги и доносит их до разработчика. Ведь одно дело сказать «Я нашёл ошибку», и совсем другое — сделать так, чтобы разработчик тоже смог её найти и исправить. Поэтому хороших тестировщиков учат грамотно описывать баги.
В некоторых компаниях тестировщик предлагает улучшения продукта с точки зрения логики, интерфейса или текста. Раз человек пользуется продуктом много и часто, есть смысл его послушать.
Почему говорят, что это трамплин в профессию
С одной стороны, стать тестировщиком проще, чем программистом: не нужно знать языки программирования и математику. Программирование и понимание алгоритмов потребуется только для автотестов, и это не так сложно, как обычная продуктовая разработка.
С другой стороны, тестировщики очень важны: ни одна уважающая себя компания не будет запускать продукт без внимательного тестирования. Везде, где есть разработчики, будут и тестировщики.
Так как профессия довольно молодая, спрос на специалистов есть, и найти работу реально.
Где учиться
На тестировщиков постепенно начинают учить везде, где учат на разработчиков. В Практикуме тоже: посмотрите наш бесплатный тренажёр для тестировщиков и приходите осваивать новую профессию — с наставниками и чёткой системой роста это легко и приятно. Мы обучаем ребят до уровня QC: то есть помогаем научиться самому тестированию и организации работы тестировщика. До уровня QA люди уже доходят самостоятельно.
