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

Ручное тестирование (manual testing) — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно проводится тестировщиками или обычными пользователи путем моделирования возможных сценариев действия пользователя.

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

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

Пример фрагмента процедуры

1. Подать на вход три разных целых числа;
2. Запустить тестовое исполнение;
3. Проверить, соответствует ли полученный результат таблице [ссылка на документ1] с учетом поправок [ссылка на документ2];
4. Убедиться в понятности и корректности выдаваемой сопроводительной информации.

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

Автоматизированное тестирование

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

Методы ручного тестирования

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

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

Сравнение ручного и автоматизированного подхода к тестированию

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

Инспекции и сквозные просмотры

Инспекции исходного текста и сквозные просмотры являются основными методами ручного тестирования. Так как эти два метода имеют много общего, они рассматриваются здесь совместно. Инспекции и сквозные просмотры включают в себя чтение или визуальную проверку программы группой лиц. Оба метода предполагают проведение подготовительной работы. Завершающим этапом является «обмен мнениями» – собрание, проводимое участниками проверки. Цель такого собрания – нахождение ошибок, но не их устранение (т. е. тестирование, а не отладка). Программа,  тестируется не автором, а другими людьми и фактически «инспекция» и «сквозной просмотр» – просто новые названия старого метода «проверки за столом», однако они более эффективны потому что в процессе участвует не только автор программы, но и другие лица. Результатом использования этих методов является, обычно, точное определение природы ошибок. К тому же этим методом можно обнаруживать группы ошибок, что позволяет в дальнейшем корректировать сразу несколько ошибок.

Инспекции исходного кода

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

Инспекционное заседание разбивается на две части:

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

Сквозные просмотры

Сквозной просмотр, представляет собой набор процедур и способов обнаружения ошибок, осуществляемых группой лиц, просматривающих текст программы. Метод  имеет много общего с процессом инспектирования, но их процедуры несколько отличаются  и в нем используются другие методы обнаружения ошибок. Сквозной просмотр проводится как непрерывное заседание, группа состоит из 3–5 человек. Процедура отличается от процедуры инспекционного заседания тем, что участники «выполняют роль компьютера». Комиссии предлагают небольшое число написанных на бумаге тестов, представляющих собой наборы входных данных и ожидаемых выходных данных для программы или модуля. Тестовые данные подвергаются обработке в соответствии с логикой программы, состояние программы и значения переменных отслеживается на бумаге или доске.Тесты сами по себе не играют критической роли, а служат средством для первоначального понимания программы и основой для вопросов программисту о логике проектирования и принятых допущениях.

Проверка за столом

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