Что должен уметь тестировщик и QA

— QA и тестировщик — это одно и то же?

— Некоторые говорят «тестирование», а некоторые — «обеспечение качества», то есть QA. Второе понятие более широкое, ведь тестирование — это просто проверка (валидация и верификация). А обеспечение качества — целый процесс внутри команды.

— Какие перспективы у тестировщика?

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

— Насколько нужно знать технические вещи? Достаточно просто сказать «это не работает» или еще нужно понимать причину?

— С минимальным опытом тестировщику сложно понимать, как устроена серверная архитектура или веб-приложение, что на бэкэнде, какие сервисы. То есть описание багов идет поверхностное, как со стороны обычного пользователя: кнопка не работает на сайте — так и пишет. Более опытный тестировщик должен понять, почему кнопка не нажимается. Смотрит консоль: может, JavaScript, а может, запрос пошел, но в ответе ошибка — значит, бэкэнд упал. Чем опытнее тестировщик, тем глубже он копает причину бага. Следовательно, он умеет лучше ее описать, и разработчики смогут быстрее найти и исправить ошибку.

— То есть идеальный тестировщик — это еще и разработчик в душе?

— Хороший тестировщик, опытный, высокого уровня — он немного и разработчик, и бизнес-аналитик, и UX/UI-дизайнер, и проектный менеджер.

— И вы ищете изъяны в их работе, получается.

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

— Если бы те же разработчики идеально выполняли работу, то тестировщики остались бы без дела?

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

Почему выходят забагованные продукты

— Иногда видишь такое: выходит крупное мобильное приложение версии 1.0, и уже через неделю — версия 1.0.1, в описании которой говорится об «исправлении ошибок». Значит, продукт плохо тестировали?

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

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

— За два месяца iOS 13 получила около пяти обновлений, и большинство из них касались не добавления новых функций, а правок существующих. Почему такое происходит? Вряд ли Apple не хватило средств на тестирование.

— У Apple есть четкие циклы выпуска продуктов: нужно в год уложить разработку нового железа и софта, а затем поддерживать совместимость ПО с прошлыми устройствами. Не всегда получается за один год заложить и новые фичи, и новое железо, отсюда и возникают проблемы. Понятно, что это сложнейшие проекты, и регулярно идет «процентовка» — проверка вида «успеваем / не успеваем». Где-то возникли проблемы с производителем железа, где-то споткнулись на какой-нибудь фишке. Тогда принимается осознанное решение: да, будут недоработки, но нужно выходить в любом случае.

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

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

О разных типах тестирования

— Есть «тестирование низкого уровня». Что это и какие уровни, методы еще бывают?

— Существует большое количество классификаций тестирования по уровням, типам, методам и подходам. Если мы говорим о тестировании на низком уровне, то сюда больше подходит понятие «тестирование методом серого ящика». Например, есть проекты, где разработка ведется на низком уровне. Это написание кода, который взаимодействует непосредственно с железом. В последние годы понятие используется в связи с развитием интернета вещей — всевозможные кофеварки и чайники, которые подключаются к интернету. И чтобы это маленькое устройство могло соединиться с Wi-Fi-точкой, смартфоном по Bluetooth и так далее, нужен софт. Но не в обычном понимании, а без UI. Вот это и есть «низкий уровень». К примеру, измерение температуры воды в чайнике, передача этих данных на смартфон — программирование низкого уровня. Сейчас у этой сферы прямо новое дыхание.

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

— Как выглядит мануальное тестирование? Допустим, нужно проверить сайт. Берете и прокликиваете каждую кнопку, смотрите, куда ведут ссылки? 

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

А если мы говорим про обеспечение качества (QA), то сперва нужно посмотреть на сам сайт, узнать у клиента необходимые функциональные и нефункциональные требования, процесс работы, приоритеты. Например, важны ли UI-требования, соответствия палитры и другие вещи. Дальше мы создаем тест-план, в котором, скажем, в рамках UI-тестирования смотрим четкие аспекты — цвет, разрешение (для поддержки различных форм-факторов устройств: ноутбуки, планшеты, телефоны), наличие прототипа интерфейса и так далее.

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

— Что, если тестировщик заметит проблему в UX? Что-то показалось неудобным, нелогичным. Это его сфера ответственности?

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

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

---

Как обстоят дела с подготовкой людей, из каких отраслей переходят в QA и что вообще высшее образование может дать тестировщику, мы узнали в Институте информационных технологий БГУИРа. Декан факультета повышения квалификации и переподготовки кандидат технических наук, доцент Андрей Говин, кандидат физико-математических наук, доцент Инна Кашникова и кандидат технических наук, доцент Валерий Мухаметов рассказали, почему тестировщики в 35 лет становятся «пенсионерами» и куда они идут дальше.

Век такого тестировщика после курсов — 30—35 лет

— Есть мнение, что попасть в IT через тестирование проще всего. Согласны ли с этим и почему?

Андрей Говин: Да, такое мнение действительно есть. Скорее всего, оно складывается из-за малого времени обучения, особенно если говорим о внутренних курсах IT-компаний. Но есть опасность. Вы получите знания в узконаправленной компетенции, то есть то, что нужно заказчикам здесь и сейчас. Дальнейшее развитие специалиста — его личная забота, заказчика это не интересует.

Примерно в 35 лет тестировщик подходит к пенсионному возрасту в IT-сфере. Так же с другими профессиями. Например, программист к этому времени достигает пика по зарплате, а потом она плавно снижается. Затем он становится менее креативным и к 35 годам понимает, что должен что-то делать: или открывать свою компанию, переходить на управленческие позиции, или идти в преподаватели. Молодежь в Беларуси очень способная и дышит в спину очень активно. По крайней мере, у меня такое мнение сложилось о рынке.

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

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

— Как часто обновляете программы подготовки?

Валерий Мухаметов: Специальность тестировщика для нас относительно молодая. Мы обновляем программы каждый год. По своим дисциплинам могу за год сделать пять-шесть версий материалов. Все действительно быстро меняется.

Инна Кашникова: Фактически к каждому набору преподаватели пересматривают лабораторные работы, практикумы, и все постоянно обновляется.

Кандидат медицинских наук пошел учиться на айтишника

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

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

Андрей Говин: Недавно у нас закончил обучение кандидат медицинских наук, а сейчас учится кандидат юридических наук. Представляете, насколько люди решили поменять свою жизнь? Ведь у них хорошая база уже была в своей сфере. Но специалисты захотели идти дальше.

Валерий Мухаметов: Однажды по совету мужа пришла женщина. У нее образование было связано с биологией, и мы сказали, что перечень специальностей не позволяет ей учиться у нас — он хоть и широкий, но ограничен все же. Тогда она пошла в Министерство образования, добилась от них разрешения на учебу у нас, закончила курс с отличием и сейчас работает в крупной IT-компании.

— Дайте напоследок по одному совету для тестировщика.

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

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

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

---

Компания ISsoft — один из крупнейших белорусских разработчиков IT-решений для рынков США и Западной Европы. Основана в Минске в 2004 году как дочерняя компания корпорации Coherent Solutions, Inc. (США). Резидент Парка высоких технологий с 2007 года. Центры разработки ISsoft в Минске и Бресте насчитывают более 1000 квалифицированных сотрудников. Компания ежегодно входит в рейтинги Inc.5000 и Software 500.

Спецпроект подготовлен при поддержке иностранного производственного унитарного предприятия «ИССОФТ СОЛЮШЕНЗ», УНП 190819327.

Читайте также:

• IT-ликбез: UX/UI-дизайнер о золотом сечении, свободе и требованиях заказчика
• IT-ликбез: зачем нужен бизнес-аналитик и почему он — не лишний костыль в компании

Библиотека Onliner: лучшие материалы и циклы статей

Наш канал в Telegram. Присоединяйтесь!

Быстрая связь с редакцией: читайте паблик-чат Onliner и пишите нам в Viber!

Перепечатка текста и фотографий Onliner без разрешения редакции запрещена. nak@onliner.by