Скучная работа

Disclaimer.

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

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

Необходимое классическое вступление.

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

А что, не так, что ли?

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

Но это так, присказка.

Как вообще понять, интересная работа или нет? Я вижу три способа:

1.  Попробовать и понять. Хочешь понять, вкусна ли жареная форель, - закажи в ресторане и съешь. Хочешь понять, интересно ли тестирование, - поработай тестировщиком. Тут конечно есть опасность, что в данном ресторане просто не умеют готовить форель, но мы этот случай рассматривать пока не будем.
2.  Спросить и поверить. Можно спросить людей, которые уже работают тестировщиками или знакомы с тестировщиками, нравится ли им их работа. Правда, придется полагаться на мнение других людей. А они, может, вообще рыбу не любят, не только форель.
3.  Узнать и подумать. Попытаться понять, из чего все-таки состоит работа тестировщика, и подумать, интересна ли подобная деятельность. Тут тестирование выгодно отличается от форели, и какие-то объективные данные таки можно получить.

Собственно, я и хочу привести некий обобщенный, но неполный список того, чем занимается отдел тестирования.

Список

• оценка затрат на тестирование и проверку (того или иного функционала или требований)
• планировние тестирования (что и когда будет делаться)
• обсуждение новых фич и их спецификаций с заинтересованными лицами (роль тестировщиков может варьироваться от пассивного чтения документа до полноправного участия в создании спецификации. Какая роль будет в реальности во многом зависит от самих тестировщиков)
• тестирование новой функциональности (с использованием различных подходов)
• создание тестовой документации (в соответствии с принятым в компании стандартом. Да, возможно - и разработка этого стандарта)
• создание артефактов необходимых для тестирования функциональности (тестовые данные, скрипты и т.п.)
• исследование и описание найденных дефектов (что обычно требует глубокого понимания тестируемой области)
• проверка исправленных дефектов (здесь тоже без понимания того, что нужно проверить, никуда. А хорошо бы еще и вокруг посмотреть)
• автоматизация имеющихся тестов (причем вполне возможно, что далеко не каждый из имеющихся тест-кейсов имеет смысл автоматизировать. Кстати, какой язык программирования будем использовать?)
• выбор средств автоматизации и создание фреймворка для автоматизации тестов (либо выбор и покупка существующего готового решения с последующим допиливанием. А без единого фреймворка и смысла в автоматизации нет. Ох, его еще и поддерживать/развивать придется)
• проведение нагрузочного тестирования (что так же включает в себя выбор средств для создания/имитации нагрузки, создание скриптов и программ выполняющих тестирование и анализирующих данные. И - да, нагрузочные тесты для разной функциональности часто не имеют между собой почти ничего общего)
• проведение регрессионного тестирования (включая автоматизированные и неавтоматизированные тест-кейсы)
• проведение usability-тестирования (для различных интерфейсов, например API и GUI)
• проведение тестирования безопасности (права доступа, инъекции, бэк-доры и т.д.)
• проверка пользовательской документации (документация - часть продукта. Мы же тестируем продукт, а не программу, верно?)
• организация и настройка среды тестирования (тестовых стендов для всех видов тестирования - функционального, нагрузочного и т.п. в соответствии с нуждами и здравым смыслом. Системы бэкапов для критичных данных. Служебных серверов для различных нужд. Сети. И так далее)
• обслуживание среды тестирования (заказ, покупка, починка серверов. планирование апгрейдов имеющегося железа и ПО, etc)
• разработка, внедрение и поддержка внутренних сервисов облегчающих разработку (wiki, баг-трекеры, таск-трекеры и многое другое)
• анализ дефектов, пропущенных отделом и найденных клиентами (бывает и такое, нужно же понять, почему оно бывает)
• анализ успехов и неудач (чтобы знать, где мы молодцы, а что можно и нужно улучшать. А также разработка и внедрение улучшений в процесс тестирования, а то и разработки в целом)
• регулярное предоставление информации о состоянии и качестве продукта другим заинтересованным лицам и отделам (а это значит, что это состояние регулярно каким-то образом измеряется и оценивается. Каким образом? Это тоже придется решить)

Вот такой кратенький список, всего-то 19 пунктов. Из них от силы три (тестирование функциональности, описание и проверка дефектов) вспоминают те, кто заводят речь о скуке тестирования. Кстати, вся эта деятельность происходит не в пыльной отдельной коробке, а при активном взаимодействии с кучей разных людей - программистов, техподдержки, сисадминов, менеджеров и т.д. И без постоянного изучения новых технологий и продуктов тоже дело редко обходится.

Резюме.

Такая вот скучная профессия.