План тестирования программного обеспечения (STP) — это типичный документ, определяющий жизненный цикл тестирования программного обеспечения. Он должен включать описание программного приложения, которое должно быть разработано, состав команд, которые будут выполнять тестирование, а также место и график проведения тестов. Он также должен содержать заявление о том, что это «живой» документ, который может изменяться по мере развития проекта. Большая часть этого должна быть описанием хронологии событий, которые будут иметь место. Другими словами, жизненный цикл тестирования.
Этап 1: Анализ
В первые дни тестирование программного обеспечения обычно начиналось на последних этапах жизненного цикла разработки. Не потребовалось много времени, чтобы определить, что уже слишком поздно начинать что-то столь же важное, как тестирование. В идеале разработка плана тестирования должна совпадать с этапом планирования самого программного приложения. Разработчики тестов должны быть включены в анализ требований вместе с разработчиками кода.
Однако конечная цель анализа тестировщиков отличается от цели разработчиков кода. Тестеры будут интерпретировать требования с точки зрения конечного пользователя. Цель здесь состоит в том, чтобы установить методы, которые гарантируют, что приложение достигает цели, желаемой клиентом. Тестировщики должны учитывать уровни квалификации пользователей и среду, в которой они будут использовать приложение.
Этап 2: Планирование
Как только требования достаточно понятны, может начаться предварительное планирование испытаний. На этом этапе тесты будут довольно общими и, возможно, даже немного расплывчатыми. Следует помнить, что требования могут меняться со временем; это называется «ползучесть требований» и, будем надеяться, будет минимальным. Идея состоит в том, чтобы разработать общую стратегию, которая может быть изменена и улучшена в ходе реализации проекта.
Следует учитывать такие концепции тестирования, как требования к данным испытаний (как количественные, так и качественные), параметрические пределы (минимумы и максимумы) и «отрицательные» условия испытаний. «Отрицательное» тестирование включает определение того, что приложение может обнаруживать и обрабатывать информацию, которая является ошибочной, двуличной или выходит за установленные границы. Обнаружение необходимых данных, которые были опущены, также вписывается в эту категорию.
Другим важным шагом, который должен быть реализован на этом уровне, является соглашение о создании независимой среды тестирования, созданной в надлежащее время. Точно так же, как разработчикам нужна система разработки, у тестировщиков должна быть своя собственная схема тестирования. Выполнение тестов с использованием той же системы, в которой происходит разработка, может вызвать много проблем, включая задержки проекта. Этого следует избегать любой ценой.
Этап 3: Дизайн теста
Проектирование и разработка тестовых случаев теперь могут начаться. Формат контрольных примеров должен быть согласованным. Каждый контрольный пример должен представлять собой отдельный документ, содержащий введение, объясняющее, какая характеристика изучается, и общие ожидаемые результаты. Он также должен включать в себя список всех необходимых предпосылок и предположений (например, пользователь уже вошел в систему и перешел на соответствующую страницу). В справочном разделе должны быть перечислены все требования проекта, которые удовлетворяются успешным выполнением этого контрольного примера.
Большая часть контрольного примера будет содержать фактические шаги теста, которые должны быть выполнены. Каждый шаг теста должен быть пронумерован и содержать четкие инструкции относительно того, какие действия необходимо выполнить. Ожидаемые результаты должны быть четко определены. На этапе выполнения следует также предусмотреть место для записи достигнутых фактических результатов.
Каждый шаг теста должен выполнять только одно действие, которое может достичь определенного результата. Сохранение этого простым способом исключает необходимость в длительных, извилистых этапах испытаний, которые могут привести к частичным сбоям, чего следует избегать, если это вообще возможно. Например, тестовый шаг 1: включите компьютер. Ожидаемые результаты: компьютер загружается. Фактические результаты: как и ожидалось. На этом шаге теста больше ничего не произойдет.
Формализация процедуры таким образом обеспечивает документацию для процесса тестирования и позволяет другим выполнять тесты без необходимости воссоздавать необходимую методологию. Клиентам также нравится знать используемые методы и уровень глубокого тестирования, которое было выполнено.
Этап 4: выполнение теста, исправление и повторное тестирование
После того, как разработка кода дошла до достаточного состояния, может начаться выполнение теста. Должна существовать система оценки риска. Высокий риск (как правило, уровень 1) может помешать правильной работе приложения, а риски уровня 2 могут потребовать некоторого обходного пути для получения желаемых результатов. Уровни 3 и 4 представляют собой постепенно снижающиеся риски, которые должны быть исправлены до родов, а уровень 5 обычно является косметическим улучшением.
На начальном этапе этого этапа общение между тестировщиками и разработчиками часто позволяет быстро и неформально решать проблемы. Частое повторное тестирование может происходить после внесения исправлений. Однако по мере выполнения теста должна быть внедрена более формальная и хорошо документированная система регистрации дефектов.
Этап 5: Отчет об испытаниях и закрытие
Когда все формальное тестирование подошло к концу, должен быть создан отчет о тестировании, повторяющий весь процесс тестирования. Он должен включать в себя все основные трудности, с которыми столкнулись, дефекты, которые были обнаружены и исправлены, а также те, которые продолжают существовать. Оценка уровня риска, связанного с выпуском продукта, должна быть тщательно объяснена.
Помимо предоставления окончательного отчета о тестировании, команда тестирования может не принимать широкого участия в принятии клиентов, но руководители проектов обычно хотят держать их рядом, чтобы ответить на любые вопросы тестирования, которые могут возникнуть.
Этап 6: после установки
Тестирование не заканчивается доставкой товара. Могут произойти непредвиденные осадки, которые не были ожидаемы. Разработчики могут делать периодические обновления, которые открывают совершенно новую группу червей. Теперь тестер заботится не только об успешной установке улучшения, но и должен убедиться, что в процессе обновления ничего из существующего кода не было повреждено.
Конечно, каждый проект уникален и имеет свои собственные потребности. То, что я попытался представить здесь, это краткое изложение, если можно, отправная точка, чтобы дать читателю представление о многих возможностях и возможностях, которые ожидают прилежного тестировщика программного обеспечения.
Изображение лабиринта через Shutterstock