Абрамова Ю.В.

группа компаний «РЕЛЭКС», г.Воронеж

Воронежский государственный университет, Россия

Общая схема процесса тестирования в процессе разработки

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

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

На всех этапах основное внимание уделяется разным объектам:

·       покомпонентное (модульное) – тестирование отдельных компонентов,

·       сборочное – тестирование взаимодействия между отдельными модулями,

·       приемочное (системное) – тестирование системы целиком.

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

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

Основные операции функционального тестирования

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

Выделим основные операции и рассмотрим их более подробно.

1.   Соответствие алгоритму (возможность реализации всех путей в  программе, проверка правильности логики).

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

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

2.   Соответствие прототипу (требованиям заказчика).

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

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

3.   Правильность обработки некорректных ситуаций.

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

Негативные сценарии должны быть проверены на адекватную реакцию системы, а именно:

·       понятное сообщение о некорректном действии,

·       невозможность потери остальных данных,

·       невозможность завершения некорректного действия.

Для предотвращения возможности некорректного ввода данных разработчики используют следующие методы:

·       маска в поле ввода (позволяет вводить только данные фиксированного формата),

·       автоматическое заполнение поля (при вводе нескольких букв)

·       замена поля ввода на выбор из списка значений (из справочника).

4.   Проверка полученных результатов (учитывается весь набор действий системы).

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

·   сообщение об успешном создании,

·   наличие во всех необходимых списках в приложении,

·   наличие в базе данных с соответствующими значениями,

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

5.   Удобство пользовательского интерфейса (с точки зрения организации диалога с пользователем).

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

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

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

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

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

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

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

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

Рассмотрим вышеназванные операции с указанием очередности проведения:

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

Определить приоритет для самих операций сложно, сильна зависимость от конкретного проекта, поэтому будем опираться на эволюционное тестирование при поиске ошибок:

1.     Наиболее вероятные (область программы),

2.     Наиболее заметные (пользовательские сценарии),

3.     Наиболее используемые (частота использования в программе),

4.     Отличительные особенности (специфика),

5.     Сложные аспекты (требуется время на исправление),

6.     Наиболее понятные исполнителю функциональные области.

Указанные выше пять операций являются основополагающими при проведении процесса тестирования, они тесно связаны друг с другом, в результате составляется отчет о состоянии программы и фиксируются ошибки. В переданной на тестирование программе может быть 1-3 ошибки на 100 исполняемых операторов. При разработке приложения количество ошибок приближается к 2-3 на каждый оператор, включая орфографические ошибки. Естественно, чем сложнее операторы, тем выше вероятность ошибки в них. Аналогичная ситуация для всей программы – чем сложнее предметная область, тем больше потенциальных ошибок содержит программа, тем важнее начать тестирование раньше.

Проектирование процесса тестирования

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

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

Процесс тестирования программного обеспечения включает в себя различные направления деятельности:

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

·       руководитель проекта (если отдел тестирования не организован),

·       руководитель группы тестирования (если в отделе присутствуют тестировщики разных проектов, то есть сложность переключения между ними),

·       руководитель тестирования в проекте или тест-лид (оптимальный вариант, но только для больших проектов).

Для управления тестированием важны все эти факторы. Сначала планируются работы по тестированию, и определяется его стратегия, распределяются ресурсы проекта:

·       по согласованию команды целиком с заказчиком (только в последнее время тестировщики стали изначально включаться в команду, часто заказчик предлагает писать программы без ошибок),

·       по согласованию бюджета с заказчиком (далее в соответствие с бюджетом и сроками подбирается проектная команда, иногда добавляются неоплачиваемые стажеры),

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

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

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

·       от проверки неважного функционала при проблемах в критичном,

·       от потери времени на тестирование одного поля на всевозможные значения, когда пользователь использует только некоторые,

·       от фокусирования на функциональности в ущерб тестированию интерфейса.

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

Состояние версии необходимо оценивать постоянно:

·       на старте работы (если это возможно, например, при переходе на новый этап),

·       в процессе работы (чтобы понимать, укладывается ли проект в свои сроки, не нужно ли подключить дополнительных людей или просить дополнительное время),

·       в конце работы (чтобы оценить полученный результат и качество полученного продукта).

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

Умение работать с багами необходимо всей проектной команде:

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

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

·       разработчики и тестировщики могут увидеть свои текущие задачи, выбрать более понятные для себя или приоритетные, распределить время между ними, проследить статус нужного бага;

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

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

 

 

 

 

 

 

Литература:

1.                Р.Савин «teстирование dot COM или Пособие по жесткому обращению с багами в интернет-стартапах» - М.: Дело, 2007. -  312с. ISBN 978-5-7749-0460-0.

2.                Ron Patton “Software Testing”, Sams Publishing – 2005г. 408 с. ISBN 0-672-32798-8.

3.                Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001. — 544 с. — ISBN 9667393879.

4.                Э.Дастин, Дж.Рэшка, Дж.Пол «Автоматизированное тестирование программного обеспечения» - М.: «ЛОРИ», 2003. - 567с. ISBN 5-85582-186-2.

5.                Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. — М.: «Вильямс», 2002. — 374 с. — ISBN 5-8459-0336-X.

6.                Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М.: БИНОМ, 2008. — 368 с. — ISBN 978-5-94774-825-3.