Тестирование ПО, с чего все начинается

Document prepared by Александров А.С.

Version 1.0

Содержание

1. Вступление

2. Мотивы появления тестера

3. Краткая теория, методы и документация

4. Требования и Bug Tracking System

5. Три условия успешного старта

1. Вступление.

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

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

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

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.^{[источник не указан 748 дней]}

С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:

• Надёжность

• Сопровождаемость

• Практичность

• Эффективность

• Мобильность

• Функциональность

2. Мотивы появления тестера.

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

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

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

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

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

Отсюда – первые выводы:

• круг своих обязанностей в организации необходимо конкретизировать (чаще всего, кстати, это означает «сузить») и закрепить;

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

• найденные дефекты обязательно как-то регистрировать, причем так, чтобы потом можно было отследить их жизненный цикл;

• результаты тестирования должны храниться в форме, удобной для поиска и анализа;

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