Правила и рекомендации

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

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

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

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

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

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

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

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

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

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