Найдите 10 отличий

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

Потребовалось время, чтобы тестирование, подобно любой другой области знаний, превратилось в более или менее зрелую дисциплину. Вначале программисты самостоятельно искали и исправляли ошибки в программном коде. Тогда и понятия-то такого не было - "тестирование". Была просто "отладка" как неотъемлемая часть программирования.

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

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

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

Так зарождались основы современного тестирования.

Сегодня тестировщик ищет не только места возможных сбоев, но и изъяны иного порядка - нарушение логики последовательных действий, отсутствие функциональных элементов, иными словами, проверяет разрабатываемый продукт на соответствие требованиям заказчика. Сверхзадача тестирования сегодня близка к тому, что по-английски называется "validation" (дословно - "подтверждение правильности"). Не только каждый законченный фрагмент кода должен соответствовать спецификациям, но и система в целом проверяется на соответствие требованиям к ней заказчика - к ее функциональности, производительности и т. д. Подобное понимание тестирования было невозможно, прежде чем "программирование-кодирование" не превратилось в сложный инженерный процесс с четко организованной структурой.

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

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

"Аутсорсинг" - как много в этом слове…

Мы почти привыкли к тому, что Россия уже давно не "впереди планеты всей" в области технологического развития и, как правило, с заметным отставанием повторяет процессы, происходящие на Западе. Правда, в ускоренном темпе и через призму загадочной российской ментальности. За океаном, например, уже давно осознали необходимость такого явления, как "независимое тестирование". Исторически так сложилось, что к проблемам качества наши западные коллеги относятся с гораздо большей ответственностью. К тому же за годы развития тестирование трансформировалось в довольно стройный технологический процесс, требующий не только человеческих ресурсов, но и специального программного и аппаратного обеспечения, которое далеко не каждая компания может или хочет себе позволить. Кроме того, тестирование - наука довольно специфическая, требующая специальной квалификации, получить которую сегодня у нас можно исключительно на собственном опыте. Даже на Западе немного учебных заведений, этому обучающих. В России же их просто нет. А далеко не каждый программист способен стать хорошим тестировщиком.

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

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

Аутсорсинг тестирования - оно же независимое, оно же контрактное

"Аутсорсинг тестирования" по своей идее мало отличается от аутсорсинга разработки ПО. Это передача функций оценки качества программного продукта третьей стороне, профессионально занимающейся тестированием.

Зачем отдавать эти функции третьей стороне? Если в компании в принципе не существует такой штатной единицы, как тестировщик, ответ очевиден. Как уже говорилось, не каждый программист в состоянии протестировать продукт - прежде всего, по причинам психологическим. Он просто не сможет искать изъяны в своем замечательном изделии.

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

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

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

Правильный вектор

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

Иллюстрацией может служить распространенная сегодня спиральная, или итеративная, методология создания программного обеспечения, предполагающая циклично-эволюционное повторение типовых действий и элементов на разных этапах проекта (методология RUP - rational unified process). Проект представляется в виде спирали, на каждом из витков которой повторяются известные базовые процессы - сбор требований, проектирование, кодирование, документирование, тестирование - а продукт тем временем становится все более зрелым и законченным. Существенным достоинством такого подхода является высокий иммунитет к самой страшной болезни проектов разработки - постоянному изменению требований к конечному продукту.

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

Доверяй, но проверяй

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

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

Некоторые итоги

В настоящий момент нельзя сказать, что в России сложился рынок контрактного тестирования. По сути, его нет. Хотя потребность в такого рода услугах уже назрела. Проблема, как обычно, в ментальности. Российский заказчик пока не понимает, зачем нужно тратить деньги на тестирование, которых, как показывает опыт, уходит не менее 30% бюджета стандартного проекта по разработке программного обеспечения. А есть примеры, когда этот процент значительно выше (для высококритичных приложений). Ведь программирование - сложная инженерная деятельность. Сложная настолько, что ошибки разного порядка просто неизбежны, их число даже можно предсказывать. Существует мировая статистика - на 1000 строчек программного кода среднестатистический программист делает от 20 до 40 и более ошибок, которые сам не в состоянии заметить и исправить. Не потому что некачественно выполняет свою работу, а потому что работа - крайне непростая. К сожалению, сейчас в России очень немногие это понимают. Соответственно и рынок сформируется только тогда, когда придет осознание необходимости и обязательности тестирования программных продуктов. Если принимать во внимание, что западные процессы в России повторяются в ускоренном темпе, ждать осталось недолго. Новая каста управленцев - CIO - люди, грамотные не только с точки зрения менеджмента, но и технически образованные, и их понимание важности и значимости информационных систем в оптимальном построении бизнес-процессов современного предприятия позволяет надеяться, что тестирование программных продуктов станет такой же неотъемлемой частью построения информационной системы предприятия, как, собственно, и ее разработка и последующее внедрение. Тесты оптом и в розницу

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

Функциональное тестирование

Один из самых распространенных видов тестов, на долю которого приходится порядка 70% от общего объема производимых испытаний. Назначение его очевидно - проверка функций, выполнение которых возможно с помощью программы, на соответствие ожиданиям заказчика. Как правило, функциональное тестирование предполагает написание специальных сценариев, моделирующих все допустимые, пусть даже и маловероятные, действия будущих пользователей.

Нагрузочное тестирование

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

Конфигурационное тестирование

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

Тестирование на удобство эксплуатации

Удобство эксплуатации - очень важный параметр программного продукта. Например, программа может вполне соответствовать всем предъявляемым к ней требованиям с точки зрения функциональности. Но функции реализованы неудобно - например, некоторые шаги приходится повторять по много раз, тогда как по логике достаточно выполнить однажды. В результате пользование программой утомляет оператора. Для выявления такого рода "недочетов" и применяют тесты на удобство использования. Часто эта группа тестов относится к категории некритичных, но когда речь идет, например, о рыночном готовом продукте - пренебрегать удобством эксплуатации весьма опасно.

Инсталляционное тестирование

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

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

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