ТЗ? Какое такое ТЗ!?

Всем привет! 

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

Чтобы ответить на этот вопрос, немного поговорим о документировании.

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

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

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

Для тестировщика ТЗ - это первый документ, с которым он должен ознакомиться для выстраивания стратегии тестирования программного продукта и проектирования тестов.

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

Вот тут вам и пригодится умение работы в команде и коммуникативные навыки!

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

Всем добра и до скорой встречи!