39

Введение в тестирование

Мотивация

1. Тестирование – это перспективно. Попробуем описать ситуацию со специалистами по тестированию в странах СНГ. Специалистов явно недостаточно. Тестеров не готовит ни один ВУЗ. В то же время бизнес программирования – это один из наиболее динамично развивающихся бизнесов. В России ежегодный оборот составляет почти 1 млрд. долларов, в Украине – около 300 млн. (конечно, эти цифры – неофициальные). Это больше, чем в любой другой европейской стране. Потребность в специалистах – огромная и, в первую очередь, в специалистах по тестированию.

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

3. Тестирование – это интересно. Это не только функциональное тестирование, которым в большинстве случаев приходится сейчас заниматься. Это тестирование требований, тестирование дизайна (для того, чтобы тестировать дизайн нужно хорошо в этом разбираться), разработка документации, написание скриптов для автоматического тестирования, работа с различными программами для оценки качества кода, производительности программ и т.п. Компании обязаны планировать и серьёзно заняться улучшением подхода к тестированию, и они смогут реально научиться профессиональному подходу и даже внести свой вклад в развитие этого подхода.

4. Тестирование – это круто. Ложно считается, что программирование – это творческая работа, а работа тестера – это рутина. Если внимательно проанализировать, сравнивать работу программиста и работу тестера, то всё выглядит не столь однозначно. Программист делает то, что просит, заказывает клиент. У него есть возможность проявить себя на начальных стадиях, например, когда разрабатывается дизайн приложения (это если его привлекают к дизайну). После этого он делает то, что ему говорят и не более. С тестированием дело обстоит иначе. Например, есть два подхода к тестированию программ – убедиться, что программа соответствует требованиям клиента и доказать, что она не соответствует требованиям клиента. Оба подхода дают простор для творчества. В обоих случаях у тестера есть цель, а как её достичь – это зависит от креативности человека (даже если есть вся полагающаяся документация).

5. Тестирование – это престижно. Во всех компаниях тестеры, которые делают свою работу качественно, пользуются большим авторитетом. Именно от того, насколько качественно выполнено тестирование зависит качество конечного продукта. Нормальный программист чувствует благодарность к хорошему тестеру за то, что он помогает делать его (программиста) работу лучше (а иногда помогает избежать позора). А об отношении руководства компании можно не говорить – естественно, что хорошие тестеры – на вес золота. Заработать хорошую репутацию, работая тестером и делая свою работу на совесть, можно достаточно быстро.

6. Тестирование – это карьерный рост. Компания планирует развиваться и, кроме всего прочего, планирует развивать качество. Для хороших специалистов по тестированию со временем возможен карьерный рост – руководители по тестированию проектов, руководители проектов, аналитики и т.п.

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

История развития тестирования программного обеспечения

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

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

В начале 1970-х тестирование ПО обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы ПО». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования ПО. Однако в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приемо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось, как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.

В 1980-х тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов — наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надежно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

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

В 2000-х появилось еще более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» (en:business technology optimization, BTO). BTO направляет развитие информационных технологий в соответствии с целями бизнеса. Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки ПО для достижения необходимого уровня качества, производительности, доступности.

Качественное программное средство как продукт технологии программирования.

Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту – «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение "качества ПО" в контексте международных стандартов.

ISO 9000 – серия международных стандартов разработанных техническим комитетом международной организации по стандартизации (ISO), регламентирующая управление качеством на предприятиях.

Стандарты серии ISO 9000, принятые более чем 90-та странами мира в качестве национальных, применимы к любым предприятиям, независимо от их численности, объема выпуска продукции и сферы деятельности.

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

Важно понимать, что соответствие стандарту ISO 9001 не гарантирует высокое качество продукции. Соответствие требованиям и рекомендациям этих стандартов говорит только о способности предприятия поддерживать стабильность качества и улучшать результативность своей работы. Также соответствие требованиям ISO 9001 свидетельствует о некотором уровне надежности поставщика. С точки зрения многих западных и японских компаний, соответствие требованиям ISO 9001 - это крайне низкий уровень гарантий качества, однако это тот минимальный уровень, который даёт возможность вхождения в рынок. Сам сертификат соответствия ISO 9001 является внешним независимым подтверждением достижения требований стандарта. Цель серии стандартов ISO 9000 — стабильное функционирование документированной системы менеджмента качества предприятия-поставщика. Исходная направленность стандартов серии ISO 9000 была именно на отношения между компаниями в форме потребитель/поставщик. С принятием в 2000 году очередной версии стандартов ISO серии 9000 большее внимание стало уделяться качеству всей деятельности предприятия, а не только качеству продукции. ISO 9004 делает акцент на удовлетворении всех заинтересованных сторон, а не только потребителей. Указанные стандарты помогают предприятиям формализовать их систему менеджмента, вводя, в частности, такие системообразующие понятия, как внутренний аудит, процессный подход, корректирующие и предупреждающие действия.

В данный момент используются:

ISO 9001:2008. «Системы менеджмента качества». «Требования».

ISO 9000 содержит словарь терминов о системе менеджмента качества и свод принципов менеджмента качества.

ISO 9004 описывает способы развития системы менеджмента качества и разъясняет методы достижения требований, описанных ISO 9001.

ISO 19011 стандарт описывающий методы проведения аудита в системах менеджмента, в том числе в системах менеджмента качества.

ISO 10000001 – 10000004 серия стандартов регламентирующих методы прямой и обратной связи с потребителями в системах менеджмента качества.

ISO 10000005 стандарт создания планов или программ качества.

Конечные цифры в обозначении версии стандарта соответствуют году принятия, например: ISO 9001:2008

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

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

На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения, представленная в наборе стандартов ISO. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки (см. рис. 1).

Иными словами, с точки зрения ISO, качество программных средств можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

• надёжность;

• сопровождаемость;

• практичность;

• эффективность;

• мобильность;

• функциональность.

Рассмотрим характеристики качества ПО:

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

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

Удобство использования – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

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

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

Портативность – характеризует ПО с точки зрения легкости его переноса из одного окружения в другое.

Итак, что же такое качество программного обеспечения?

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

Первая, качество это не отдельно взятая идея или понятие, скорее многомерная и разноплановая концепция.

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

Третья, термин качество является неотъемлемой частью нашего повседневного общения, однако общепринятое и профессиональное использование может быть весьма сильно отличаться.

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

Профессиональный подход к управлению качеством утверждает, что качество — это четко определенная величина, которую можно измерить и проконтролировать, она поддается управлению и улучшению. Попробуем дать четкое и удобное для работы определение. В литературе в 1970 году качество было определено как «соответствие требованиям», а в 1979 его определили как «пригодность к использованию». Эти два определения тесно связанны и прекрасно согласуются, как мы увидим позже.

«Соответствие требованиям» предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно. Позже, на этапе разработки, производятся регулярные оценки разработанного продукта, для определения соответствия требованиям. Любые несоответствия должны рассматриваются как дефекты – отсутствие качества. Например, спецификация на определенную модель радиостанции может требовать возможности принимать определенную частоту радиоволн на расстоянии более чем 30 километров от источника вещания. В случае если радиостанция неспособна выполнить данное требование, она не удовлетворяет требования к качеству и должна быть признана негодной и некачественной. Исходя из тех же принципов, если Кадиллак соответствует всем требованиям к машинам Кадиллак, значит это качественная машина. Если Шевроле соответствует всем требованиям к машинам Шевроле, следовательно, это тоже качественная машина. Эти две машины могут быть совершенно разными по стилю, скорости и экономичности, но если обе измерять по стандартным для них наборам, тогда они обе будут являться качественными машинами.

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

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

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

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

А теперь посмотрим на точку зрения разработчика.

Качество – с точки зрения разработчика – это соответствие специфицированным и собранным требованиям.

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

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

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

Пример – Клиент Джонс заказал приложение для разработки и печати трёхцветных визитных карточек. Программист Иванов подумал, что мы живём в век прогресса, цветных лазерных принтеров и трёхцветные визитки – отстой. Поэтому визитки должны быть полноцветными. Он реализует свои идеи и отправляет программу клиенту в срок. А вот здесь происходит странная вещь – клиент в ярости. Всё дело в том, что он планировал выпустить на рынок программу для печати трёхцветных визиток, продавая её за, скажем, 15 долларов за диск, а потом, продав достаточное количество дисков, предложить новую версию программы, которая будет делать полноцветные карточки и продавать её по 30 долларов, а с тех клиентов, которые купили у него предыдущую версию взять по 10 долларов за обновление. В итоге, клиент требует переделать программу за деньги компании и требует у компании неустойку за то, что программа не была готова к сроку.

Следующий пример – клиент договаривается с компанией о демо-версии программы, в которой будет реализовано ядро новой системы и часть интерфейса. О сроках договорились. Клиент заказывает конференц-зал в Лос-Анжелесе, приглашает журналистов, потенциальных потребителей и планирует презентацию демо-версии программы, всё оплачивает вперёд. Программист Петров работает над ядром. В какой-то момент он понимает, что ядро можно и нужно сделать лучше. Если так сделать, то программа будет работать быстрее в 10 раз. На это потребуется всего лишь 3 дополнительных дня. В итоге ядро системы сияет, но к установленному сроку не готово окно с отчётами. В итоге презентация проваливается, потому что окно с отчётами является основным отличием программы от аналогов. Клиент несёт колоссальные убытки, подаёт в суд на компанию и дальнейшее производство продукта останавливается. Сияющее ядро системы никому не нужно.

Смысл в том, что нужно пытаться понять, что для клиента является наиболее важным. Какая-нибудь мелкая ошибка в окошке Эбаут (About) с неправильно написанной фамилией губернатора или мэра, которого авторы проекта благодарят за содействие, может привести к плачевным последствиям. И в такой ситуации качество всей остальной системы может оказаться неоцененным, т.е. вся работа – «насмарку». Очень важно, чтобы и программисты, и тестеры это понимали и думали об этом. Любые отклонения от начальных договорённостей по срокам, по функциональности должны обсуждаться с клиентом.

В связи с этим при разработке требований они должны подвергаться проверке:

1. на полноту;

2. на однозначность;

3. на непротиворечивость.

Организация, претендующая на получение сертификата ISO должна разработать, задокументировать, внедрить и поддерживать в рабочем состоянии систему менеджмента качества, а также постоянно улучшать ее результативность.

Организация должна:

1. Определять процессы, необходимые для системы менеджмента качества и применять их во все организации;

2. Определять последовательность и взаимодействие этих процессов;

3. Определять критерии и методы системы менеджмента качества (СМК);

4. Обеспечивать наличие ресурсов и информации, необходимы для поддержки этих процессов и их мониторинга;

5. Осуществлять мониторинг, анализ, измерение этих процессов;

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

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

Управление заключается в следующем:

1. проверка документов на адекватность до их выпуска;

2. анализ и актуализация о мере необходимости и переутверждение документа;

3. обеспечение идентификации изменений и статуса пересмотра документа;

4. обеспечение наличия соответствующих версий документов в местах их применения;

5. обеспечение сохранения документов чёткими или легко идентифицируемыми;

6. обеспечение идентификации документов внешнего происхождения и управления их рассылкой (приход документов от заказчика);

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

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

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

• надежностью продукта;

• количеством и глубиной его функций;

• деньгами, необходимыми для выполнения дальнейшей работы;

• сроками выпуска продукта.

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

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

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

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

• Дата выпуска. Если проект выбивается из графика, его руководитель может отложить выпуск. Однако это может обойтись компании крайне дорого.

• Непосредственная стоимость продолжения работ. Эти затраты определяются зарплатой всех участников проекта.

• Дополнительные потери. Если работа выполняется по контракту, руководитель может предусмотреть пеню за несоблюдение сроков или значительный бонус за своевременное завершение проекта. Если продукт должен быть выпущен к началу определенного сезона, например, к осени, Рождеству или Новому году, пропустив его, можно потерять часть покупателей. Кроме того, задержка выпуска продукта может привести к тому, что устареет техника, на которую он ориентирован, или на рынке появятся конкурирующие продукты. Очень важно понимать, что рынок завоевывает продукт, появившийся первым, и по количеству продаж он пре­взойдет более качественные продукты, выпущенные какое-то время спустя. Поэтому задержка выпуска ради повышения качества продукта может его похоронить.

• Потерянные затраты на маркетинг. Если продукт разрекламирован слишком рано, к моменту его выпуска придется все повторять сначала.

• Параллельные проекты. Люди, работающие над проектом сверх срока, могли бы уже выполнять другую работу. Таким образом, задержки одного проекта отражаются и на других.

• Отсутствие ожидаемой прибыли. Если доходы от выпуска продукта должны быть немедленно вложены во что-то другое, если эти деньги срочно нужны компании — тогда у вас большие проблемы.

Роль тестирования в процессе разработки ПП

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

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

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

С технической точки зрения тестирование заключается в выполнении приложения на некотором множестве исходных данных и сверке получаемых результатов с заранее известными (эталонными) данными с целью установить соответствие свойств и характеристик приложения заказанным свойствам и характеристикам. Как одна из основных фаз процесса разработки программного продукта (Дизайн приложения - Разработка кода - Тестирование), тестирование характеризуется достаточно большим вкладом в суммарную трудоемкость разработки продукта. Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40% - 20% - 40%.

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

f = f₁* f₂* f₃*...* f_n,

где f₁, ... f_n - операторы языка программирования, а их суперпозиция - программа.

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

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

Классификация видов тестирования

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

I. По объекту тестирования:

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

 — это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, необходимые пользователям (функциональные требования определяют, что именно делает ПО, какие задачи оно решает).

Функциональные требования включают:

• функциональная пригодность;

• точность;

• способность к взаимодействию;

• соответствие стандартам и правилам;

• защищённость.

• Тестирование производительности 

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

В общем случае тестирование производительности может проводиться с различными целями:

• с целью демонстрации того, что система удовлетворяет критериям производительности.

• с целью выяснения, у какой из двух или нескольких систем производительность лучше.

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

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

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

• Время ответа сервера - эта концепция строится вокруг времени ответа одного узла приложения на запрос, посланный другим узлом.

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

Типичные вопросы тестирования производительности:

1. Что охватывается тестом производительности? Какие подсистемы, компоненты, интерфейсы и т.д. должны быть протестированы?

2. Если в тест включаются пользовательские интерфейсы, то сколько одновременно работающих в системе пользователей ожидается для каждого интерфейса (необходимо определить пиковые и нормальные значения)

3. Как выглядит аппаратная составляющая тестируемой системы? (Необходимо описать все сервера и сетевое оборудование)

4. Каков сценарий использования каждой компоненты системы? (например, 20% запросов составляет вход в систему, 40% - поиск, 30% - выбор элемента, 10% - выход из системы)

5. Каков сценарий использования системы? (в одном тесте на производительность могут быть задействованы разные сценарии использования каждого компонента)

6. Каковы требования ко времени выполнения серии операций серверной части приложения?

В тестировании производительности различают следующие направления:

• нагрузочное;

• стресс;

• тестирование стабильности;

• конфигурационное.

Рассмотрим эти направления подробнее.

Нагрузочное тестирование — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос (воздействие) с целью установления соответствия требованиям, предъявляемым к данной системе (устройству), причем создаваемая нагрузка на систему не превышает нормальные сценарии ее использования. Термин нагрузочное тестирование может быть использован в различных значениях в профессиональной среде тестирования ПО. В общем случае он означает практику моделирования ожидаемого использования приложения с помощью эмуляции работы нескольких пользователей одновременно. Таким образом, подобное тестирование больше всего подходит для мультипользовательских систем, чаще - использующих клиент-серверную архитектуру (например, веб-серверов). Однако и другие типы систем ПО могут быть протестированы подобным способом. Например, текстовый или графический редактор можно заставить прочесть очень большой документ; а финансовый пакет - сгенерировать отчет на основе данных за несколько лет. Наиболее адекватно спроектированный нагрузочный тест дает более точные результаты. Основная цель нагрузочного тестирования заключается в том, чтобы, создав определенную ожидаемую в системе нагрузку (например, посредством виртуальных пользователей) и использовав идентичное программное и аппаратное обеспечение, наблюдать за показателями производительности системы. В идеальном случае в качестве критериев успешности нагрузочного тестирования выступают требования к производительности системы, которые формулируются и документируются на стадии разработки функциональных требований к системе до начала программирования основных архитектурных решений. Однако часто бывает так, что такие требования не были четко сформулированы или не были сформулированы вовсе. В этом случае первое нагрузочное тестирование будет являться пробным и основываться на разумных предположениях об ожидаемой нагрузке и потреблении аппаратной части ресурсов. Одним из оптимальных подходов в использовании нагрузочного тестирования для измерений производительности системы является тестирование на стадии ранней разработки. Нагрузочное тестирование на первых стадиях готовности архитектурного решения с целью определить его состоятельность называется «Proof-of-Concept» тестированием.

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

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

Необходимость стресс-тестирования диктуется следующими факторами:

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

• В случае контракта-соглашения об уровне услуг стоимость отказа системы в экстремальных условиях может быть очень велика.

• Обнаружение некоторых ошибок или дефектов в функционировании системы часто возможно с использованием других типов тестирования.

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

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

Основные направления применения стресс-тестирования:

1. Общее исследование поведения системы при пиковых нагрузках.

2. Исследование обработки ошибок и исключительных ситуаций системой при пиковых нагрузках.

3. Исследование узких мест системы или отдельных компонент при диспропорциональных нагрузках.

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

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

При стресс-тестировании возможно использование пропорциональной и диспропорциональной нагрузки.

Пропорциональная нагрузка. Стресс-тестирование может применяться как для обособленных приложений, так и для распределенных систем с клиент-серверной архитектурой. Простейшим примером стресс-тестирования обособленного приложения может являться открытие файла размером в 50 Мб программой Notepad, входящей в комплект ОС Windows. Условия стресс-тестирования приложения обычно формируются исходя из критических бизнес-процессов его функциональности, определяемыми на стадии разработки требований и анализа рисков. В общем случае в качестве условий для стресс-тестирования может использоваться линейно увеличенная ожидаемая нагрузка.

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

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

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

• Тестирование удобства использования (юзабилити-тестирование) — эксперимент, выполняемый с целью определения, насколько хорошо люди могут использовать некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения, то есть юзабилити-тестирование измеряет эргономичность объекта. Юзабилити-тестирование — метод оценки удобства продукта в использовании, основанный на привлечении пользователей в качестве тестировщиков, испытателей и суммировании полученных от них выводов. Существует еще один подход к юзабилити-тестированию: для решения задачи предложенной пользователю разрабатывается «идеальный» сценарий решения этой задачи. Как правило, это сценарий, на который ориентировался разработчик. При выполнении задачи пользователями регистрируются их отклонения от задуманного сценария для последующего анализа. После нескольких итераций доработки программы и последующего тестирования можно получить удовлетворительный с точки зрения пользователя интерфейс.

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

Интерфейс пользователя компьютерного приложения включает:

• средства отображения информации, отображаемую информацию, форматы и коды;

• командные режимы, язык «пользователь — интерфейс»;

• устройства и технологии ввода данных;

• диалоги, взаимодействие и транзакции между пользователем и компьютером, обратную связь с пользователем;

• поддержку принятия решений в конкретной предметной области;

• порядок использования программы и документацию на неё.

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

Ему разрешено все:

• попытки узнать пароль с помощью внешних средств;

• атака системы с помощью специальных утилит, анализирующих защиты;

• подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

• целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

• просмотр несекретных данных в надежде найти ключ для входа в систему.

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

• Тестирование локализации – это проверка корректности перевода, текст должен быть грамматически, синтаксически и логически правильным. Локализации требует решения несколько задач и вопросов:

• делать локализацию собственными силами или привлекать аутсорсинг или комбинировать собственные силы с аутсорсингом.

• определить список поддерживаемых языков.

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

• осуществить перевод пользовательского интерфейса.

• осуществить перевод системных сообщений и ошибок.

• осуществить перевод help и сопутствующей документации.

• проверка правильности перевода в контексте данного приложения.

• проверка локализованных приложений на разных языковых платформах.

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

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

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