Ломать не строить: кто такой тестировщик в ИТ?

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

Всем привет! Меня зовут Нашкевич Александр, и я ведущий инженер по тестированию в it-компании Tiqum. Я работаю в сфере тестирования ПО уже почти 6 лет, веду образовательные проекты и обучаю студентов. В этой статье я попробую объяснить, зачем тестировщику знание основ менеджмента, желание все ломать и умение протестировать даже ручку.

Тестирование как направление в ИТ появилось более чем полстолетия назад. Правда, сам процесс в 1950-х сильно отличался от современного. Дело в том, что первые тесты проводили для нужд министерства обороны. Они были полностью отделены от процесса разработки и напоминали скорее отладку готовых программ — причем каждый шаг подробно и детально описывался для отчетности военному руководству. Занимались тестированием все те же разработчики — отдельной профессии тестировщика пока не существовало.

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

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

• позитивное тестирование — доказательство работоспособности программы в некоторых заданных условиях;
• негативное тестирование — от обратного, доказательство неработоспособности программы в некоторых заданных условиях.

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

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

И, наконец, к 90-м годам прошлого столетия окончательно оформилось понимание, что тестирование необходимо для обеспечения качества продукта (из него вырос подход quality assurance), а профессия тестировщика стала развиваться как отдельная специальность в ИТ. С тех пор тестирование идет по пути улучшений: появляются новые методики и инструменты — например, микро-революцию произвело появление открытых инструментов тестирования в начале 2000-х — развиваются автотесты. Но кардинальных изменений в фундаментальной теории тестирования пока нет.

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

В связи с этим тестировщик должен быть «и швец, и жнец, и на дуде игрец». Так, он должен уметь проводить все виды тестирования. Самые распространенные среди них:

• кросс-браузерное и кросс-платформенное тестирование;
• конфигурационное тестирование — когда предусмотрено взаимодействие со сторонним софтом, например, если разрабатывается видео-конференц-связь и подключается приложение с камерами;
• интеграционное тестирование — чтобы проверить взаимодействие между функциональными модулями;
• регрессионное тестирование — для обнаружения ошибок в уже проверенном коде при установке новой функциональности;
• инсталляционное тестирование, когда надо установить программный продукт на устройство.

В некоторых случаях тестировщики проводят даже базовые проверки безопасности.

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

Кроме того, важна гибкость, адаптивность мышления и обучаемость. Любые навыки в ИТ — сфера тестирования не исключение — устаревают за 3-5 лет. Да и нередко тестировщикам приходится выполнять не самые обычные для них задачи: например, менеджерить команды или писать инструкции к программам для пользователей.

Я бы также добавил, что тестировщик сегодня должен обладать абстрактным мышлением и творческими навыками. Ведь тестировщик один, а пользователей — тысячи, если не миллионы. Нужно поставить себя на место человека, работающего с программой, и представить все способы, которыми можно продукт сломать. Например, у меня был такой случай. В раскладке клавиатуры буква «ё» — отдельный символ. И однажды я нашел баг в системе известного банка: ввожу в юридическом названии букву «ё», и у меня не срабатывает ввод — система считает, что я использую недопустимый символ. Таких примеров — множество.

И да, кстати — желание ломать вещи тоже будет нелишним.

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

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

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

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

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

Я много раз отвечал на этот вопрос своим студентам словами «Однозначно да» — особенно если вы хотите получить профессию, слабо зависимую от кризисов, изменений на рынке и технологических изменений. Тестировщики будут нужны всегда. К тому же это как минимум интересно — так, меня приглашали протестировать беспилотные автомобили. Можете себе это представить?

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

Сейчас на рынке увеличивается число кадров и растет конкуренция. Поэтому компании стали более внимательно оценивать способности соискателей. Даже если узкие профессиональные компетенции можно получить в процессе обучения и работы, базовые навыки и гибкость мышления — уже давно обязательный минимум для кандидата. Однажды на собеседовании меня попросили протестировать ручку, в другой раз — построить лифт. И с каждым годом требования к соискателям будут лишь расти.