Сталкиваем с реальностью популярные мифы о тестировании
Почему-то считается, что тестировщики — новички, которые ищут легкий старт в IT. Этот и другие расхожие представления о профессии не отражают реальный уровень навыков и обязанности людей, занятых в тестировании программного обеспечения. N + 1 вместе с «ЛАНИТ Экспертизой» (входит в ГК ЛАНИТ) отобрал самые популярные мифы о тестировании и рассказывает, как все обстоит на самом деле.
Как отдельная профессия тестирование ненамного моложе программирования. Дело в том, что первые компьютеры и компьютерные программы создавались для очень ограниченного круга специалистов. Ученые писали код для собственных целей — и сами же его проверяли. Да и как привлечь стороннего специалиста, чтобы найти алгоритмическую ошибку в программе, которая управляет полетом космической ракеты или спуском лунохода? Считается, что одна из первых команд тестировщиков была создана в 1958 году и занималась проектом «Меркурий» — первой пилотируемой программой США.
К тому моменту пионеры программирования уже работали над теорией и методологией тестирования. В 1957 году американский физик Чарльз Бейкер предложил различать тестирование программ и устранение багов, предвосхитив будущее разделение разработки и тестирования. В 1968 году на конференции, организованной при поддержке НАТО, впервые обсуждалась тема программной инженерии (software engineering) и упоминалась необходимость обеспечения качества (quality assurance) софта. Год спустя ученый-информатик Эдсгер Вибе Дейкстра, выступая перед научным комитетом НАТО, сказал: «Тестирование может использоваться, чтобы продемонстрировать наличие багов, но никогда — чтобы показать их отсутствие».
Компьютеры и софт становились сложнее, а ученые все более активно обсуждали подходы к тестированию программного обеспечения. Однако забота о качестве еще некоторое время оставалась уделом относительно узкого круга специалистов — в основном тех же, кто эти программы писал.
Впоследствии, благодаря расширению рынка коммерческого софта, потребность в тестировании выросла. Были основаны первые компании, сконцентрированные на создании инструментов, призванных помочь разработчикам контролировать качество программ. Теперь софт должен был работать не только на компьютерах в конкретной компании или лаборатории, но во множестве организаций и домохозяйств — и одинаково хорошо выполнять свою задачу на разных платформах. Все это в конечном итоге привело к выделению тестировщика в отдельную профессию.
Прежде чем перейти к мифам, необходимо разобраться с тем, чем сегодня занимается тестировщик. Если вы думаете, что речь пойдет только про поиск ошибок в работе приложений, значит этот раздел — для вас. Тестирование делят на три направления, каждое из которых требует особых навыков.
Этот процесс имитирует реальное пользование продуктом. Провернуть это не так просто, как может показаться. Тестировщикам необходимо проанализировать возможные сценарии поведения пользователей и убедиться, что не найдется такого сценария, который не был бы предусмотрен и содержал бы критический баг.
Необходимые навыки: функциональным тестировщикам нужно уметь работать с багтрекинговыми системами*, писать SQL запросы, разбираться в форматах передачи данных и технологиях сетевого взаимодействия, чтобы находить дефекты в визуальной составляющей веб-приложений. Также тестировщики должны понимать, как устроена клиент-серверная архитектура и как диагностировать ошибку в логах.
Эта область находится на стыке между тестированием и программированием. Тестировщикам необходимо писать скрипты, которые максимально аутентично имитируют действия настоящих пользователей. Для создания скриптов чаще всего применяют языки Python и Java. При этом Java, отмечают специалисты «ЛАНИТ Экспертизы», чаще используется при создании и проверке проектов от финтех компаний, где есть соответствующие компетенции. Python предпочитают компании, которым нужна максимально быстрая отдача от автотестов (скорость написания кода / быстрая переквалификация и т.п.).
Необходимые навыки: специалистам этого направления необходимо иметь навыки как тестировщика, так и разработчика. Это необходимо, чтобы не только понимать цель и методы тестирования, но также писать скрипты для проверки сценариев.
Это особый вид тестирования, задача которого — проверить ПО на производительность. Как и в автоматизации функционального тестирования, производительность системы проверяется скриптами, которые имитируют действия, одновременно совершаемые множеством пользователей.
Необходимые навыки: в этой области тестировщикам необходимо четко понимать, какие пользовательские действия создают основную нагрузку на систему и как часто они выполняются. Поэтому специалистам в этом направлении необходимы, во-первых, уверенные знания матстатистики и основ Data Science для разработки профиля нагрузочного тестирования, а во-вторых, знания в области программирования — это пригодится для разработки скриптов имитации операций, совершаемых пользователями.
Отдельно стоит исследование продукта на уязвимости. Этим занимаются пентестеры, а их деятельность часто называют этическим хакингом. Как и нагрузочные тестировщики, они проверяют, насколько сервис устойчив, но не перед наплывом пользователей, а перед кибератаками. Часто такие люди работают на фрилансе, а их основным доходом становятся bug-bounty — выплаты за найденные уязвимости, которые не стали достоянием злоумышленников.
Таким образом, даже состоявшийся тестировщик в одном направлении не сумеет без подготовки работать в другом. Может показаться, что в автоматизированное тестирование легко перейти из функционального — и там, и там работать нужно с функционалом приложения. На самом деле, нет. Поэтому начинающему специалисту лучше сразу определить, в каком направлении он хочет развиваться.
К сожалению, мифы о тестировании нельзя развеять эффектным взрывом цементовоза или прикручиванием ракет к креслу с манекеном. Тем не менее, мы постараемся убедительно доказать, что расхожие представления о тестировании не отражают реальность и подкрепим наш рассказ комиксами.
Миф № 1: Работа в тестировании — первая и легко преодолимая ступень для попадания в разработку. Тестировщики — это недопрограммисты
Из-за этого мифа функциональное тестирование считают просто первой ступенью на пути в IT, а автоматизированное тестирование — переходным этапом на пути к позиции разработчика. Далекие от мира ИТ люди часто заблуждаются, представляя тестировщиков специалистами низкой квалификации, которые идут в эту область, чтобы набраться опыта для другой профессии. В жизни все обстоит иначе.
Для качественного тестирования специалисту нужно владеть профессиональным софтом и фреймворками*. Тестировщики недавнего прошлого удивились бы, узнав, что в 2021 году существуют возможности автоматизированного тестирования десктоп-приложений. Запустив программу на компьютере, вы не сможете увидеть ее код — в отличие от веб-страниц, код которых можно просмотреть в браузере нажатием на «инструменты разработчика». Все еще думаете, что попасть на позицию тестировщика просто? При этом некоторые проекты требуют получения тех же сертификатов, что и у программистов, например, Oracle Java.
Еще не так давно «каста» разработчиков действительно ставилась выше тестировщиков. Дело в том, что работа тестировщиков считалась несоразмерно менее значимой в сравнении с программистам, но в современных методологиях разработки программисты и тестировщики находятся на одном уровне постоянного взаимодействия. По словам специалистов «ЛАНИТ Экспертизы», сейчас разница лишь в том, что разработчики пишут продуктовый код, а автоматизаторы, к примеру, скрипты, которые будут его проверять. Соответственно, и у тестировщиков, причем из всех направлений, существует разделение на профессиональные уровни: senior, middle и junior.
Миф № 2: Эффективность тестировщика определяется по количеству найденных дефектов
Здесь на сцену выходит другой миф о тестировщиках: чем больше дефектов тестировщик найдет, тем он эффективнее и полезнее. Звучит логично, но верно далеко не всегда.
Эффективность тестировщиков, которые ищут дыры в защите различных сервисов, действительно оценивается количеством обнаруженных уязвимостей. Однако тестировщики выявляют не только функциональные ошибки (когда программа работает не так, как задумано — например, не дает вам прикрепить файл), но и вполне наглядные визуальные: например, картинка неправильно смещается при открытии сайта на смартфоне или в слове «логин» допущено четыре ошибки. Разумеется, такие визуальные дефекты проще обнаружить и исправить, чем «блокеры» — ошибки, нарушающие задуманную работу с сервисом. Поэтому их обнаружение занимает меньше времени.
Может показаться, что в работе тестировщика значительное место занимает случай: нашел дефект — повезло, нет — увы. Однако изначальное присутствие дефектов в программе, не зависит от тестировщика (это скорее вопрос к программистам). Его обязанность — качественно пройти наибольшее количество сценариев использования. При этом надо пройти их так, чтоб в программе не осталось критических дефектов. Именно это определит его эффективность. Покрытие программы большим числом сценариев требует системного подхода и следования современным методологиям тестирования.
Миф № 3: Тестирование гарантирует отсутствие дефектов в готовом продукте
Возможно, вы думаете, что после работы тестировщиков в программе не остается багов. Это не так.
Один из главных принципов тестирования — исчерпывающее тестирование недостижимо. Возможных комбинаций параметров и вводимых данных просто слишком много. Поэтому существует тест-дизайн и тест-анализ, в процессе которых тестировщики определяют наиболее критичные пути и выставляют приоритеты различным требованиям к ПО. Отсюда появляются и так называемые запланированные дефекты. Их наличие оговаривается с заказчиком, а вызваны они зачастую сжатыми сроками и необходимостью выпустить продукт в объявленную дату релиза.
Значит ли это, что содержание тестировщиков экономически невыгодно, раз после их работы программа все равно содержать ошибки? Разумеется, нет.
По опыту экспертов ЛАНИТ, исправление ошибок на этапе тестирования обходится как минимум в несколько раз дешевле, чем после релиза программы. Кроме того, крупные сервисы постоянно выпускают обновления, каждое из которых должно быть протестировано и отлажено. Чем больше компания, тем больше должна быть команда тестирования.
Миф № 4: В скором времени все будут тестировать ИИ. Но сначала автоматизированное тестирование полностью вытеснит ручное
Так, может быть, стоит заменить тестировщиков автотестами и нейросетями? Это позволит сэкономить и автоматизировать процесс. Ответ: увы, не получится.
Созданием скриптовых тестов и нейросетевых инструментов для тестирования тоже занимаются тестировщики. Цель существования таких средств поддержки — не вытеснение тестировщиков, а упрощение и ускорение их работы.
Автоматизированное тестирование вряд ли в обозримом будущем заменит человека. В конце концов, подобные тесты только подражают пользователям на основе имеющихся примеров, но не понимают человеческую логику и не способны реализовать ее. Поэтому исследование программы человеком так же необходимо, как и раньше — просто теперь это быстрее и надежнее.
Интересно, как на самом деле выглядит работа тестировщика?
Тогда перейдем от слов к делу: попробуйте верно ответить на вопросы, основанные на реальных задачах из области функционального, автоматизированного и нагрузочного тестирования.
Текст — Богдан Сиротич, комиксы — Женя Зеленый