Сообщений в теме: 23

[xp_alp]

До недавного времени при тестировании продуктов мы обходились своими силами (то есть силами самих программистов, путем перекрестного тестирования программ). Но это не выгодно по объективным причинам, поэтому постепенно назрел вопрос о создании отдела тестирования.
Сразу же возникают вопросы по тому, как проводить тестирование, как этим управлять, как распределять задачи и т.д.
(прошу принять во внимание, что я этим раньше не занимался)
Я решил, что для начала необходимо составить документ, который бы объяснял, для чего и каким образом проводится тестирование продуктов. Понятно, что несколькими страницами невозможно осветить все вопросы, но хотелось бы, чтобы было руководство, которое бы помогло хотя бы начать работать в нужном направлении.
Было бы не плохо, если бы в результате нашего общения, что-нибудь подобное и получилось.
Итак, предлагаю для битья начальный вариант:

Положение о тестировании

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

II. Обязанности:

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

III. Порядок тестирования:

В процессе тестирования тестер обязан выполнить следующие действия:
1. Ознакомиться с техническим заданием на тестируемый проект;
2. Оттестировать программный продукт, для этого:
2.1. Составить список функциональных возможностей программы, список поддерживаемых форматов, список системных требований, предъявляемых к программе;
2.2. На основании списков пункта 2.1. составить список тестов, которые планируется провести с данным программным продуктом. Этот список должен быть составлен с учетом следующих требований:
а) должны быть проверены все функции программы и все возможные комбинации этих функций;
б) должна быть проверена работа со всеми заявленными форматами;
в) должна быть проверена реакция программного продукта на попытки некорректного использования:
- неприемлемый формат данных;
- использование неправильных комбинаций функций продукта; 
- работа в критических условиях, к примеру, при одновременной работе нескольких экземпляров программного продукта или при одновременном доступе к файлу (файлам), используемым программным продуктом какой-то другой программы, либо другим экземпляром этого же программного продукта
- другие возможные ситуации, критичные для данного программного продукта.
Составить план тестирования, в котором указывается последовательность всех тестов из составленного списка тестов. 
2.3. Провести тестирование программного продукта. Тестирование производится по составленному в пункте 2.2. плану тестирования. Тестирование должно быть произведено для всех системных требований, описанных в техническом задании (пункты тестирования, абсолютно не зависящие от системных требований можно выполнять только единожды). При тестировании необходимо составлять отчет, в котором должны быть описаны результаты каждого теста. К результатам тестов необходимо добавлять свою оценку по удобству использования программы, либо ее отдельных функций. Для каждого теста необходимо указать время начала и завершения теста и время, затраченное на тест.
2.4. Проверить наличие сопроводительной документации, выявить недостатки документации и несоответствия внутренним стандартам качества. К сопроводительной документации также относятся исходные коды программных продуктов, поэтому они также должны быть проверены на соответствие внутренним стандартам качества. Если в техническом задании указаны дополнительные требования к документации, необходимо проверить соответствие этим требованиям.


IV. Результаты тестирования:
По окончании тестирования тестер должен предоставить письменный отчет руководителю проектов. Этот отчет должен содержать следующие сведения:
1.	Список оттестированных функций и возможностей;
2.	Список проведенных тестов;
3.	Результаты каждого теста, включая длительность теста;
4.	Резюме по удобству использования данного программного продукта, возможно с пожеланиями по улучшению этого продукта;
5.	Резюме по сопроводительной документации.

[Олешка]

Я бы добавила к п.2 перед тем, как вообще начинать тестирование:

"Провести верификацию тестового окружения на соответствие системным требованиям."

Еще - список функциональных возможностей программы должен иметься в спецификации на продукт. Если его составляет тестировщик, это странно.

[Case]

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

[xp_alp]

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

Да, задача не из легких. А будем обязанности делить? Или все-таки на грустном варианте тестера-универсала остановимся?

[Олешка]

ИМХО, надо делить, универсала потом составим.

[Case]

Грустный вариант тестера универсала не исключается, просто и это понятие не охватывает, просто в силу того что возможности человека ограничены в пространстве и времени, предложенный вами список обязаностей.
То есть можно канечно устроить так, что один специалист будет делать всё, но какое тогда будет качество его работы?

[xp_alp]

"Провести верификацию тестового окружения на соответствие системным требованиям."

На сколько я это себе представляю, тестер должен тестовое окружение создать (привести в соответствие).
Предлагаю этот пункт внести с другой формулировкой:
"Привести систему в соответствие с требованиями" или что-то вроде того.

Еще - список функциональных возможностей программы должен иметься в спецификации на продукт. Если его составляет тестировщик, это странно.

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

[Олешка]

To xp_alp - это зависит от системы. Например, тестер может вообще не иметь доступа к настройкам сервера, на котором работает приложение. Еще - тестер может не иметь достаточной квалификации для таких изменений.

[xp_alp]

Да, я об этом не подумал.
Тогда твой вариант более справедливый.
Вносим этот пункт!

[solo]

хм, как это не имеет доступа в серверу и его настройкам. А как же проверка инталяции(деинсталяции)?

Я согласен с тем, что тестовое окружение нужно создать иначе получится что тестирование
неполное. При чем это тоже одно из требований к продукту. Обычно это указывается в Technical Marginal Conditions.

[Олешка]

Нужно создать, если это требуется при инсталляции, если нет - ИМХО, достаточно сверить соответствие окружения системным требованиям.

[Case]

Нужно создать, если это требуется при инсталляции, если нет - ИМХО, достаточно сверить соответствие окружения системным требованиям.

Не понял :)

А можно если продукт не инсталлируется и не создавать тестовое окружение? :)

[Олешка]

Нужно создавать.

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

Я хочу сказать, что тестировщик как минимум обязан проверить, что это окружение соответствует выдвигаемым к продукту требованиям, то есть тестировщик гарантирует клиенту, что продукт, поставленный на такое же окружение, на котором он тестировался, будет работоспособен. Как максимум - может, вероятно, и создавать такое окружение. Если квалификация позволяет. Скажем, тестировщик black box может и не обладать такими знаниями. И что тогда? Возможно, это частный случай.

[Guriy]

А можно если продукт не инсталлируется и не создавать тестовое окружение? :)

Более того - если он не проинсталировался, можете его вообще не тестировать :D

[Guriy]

А если серьезно, то документ вызывает ощущение, что девелоперов хотят заставить тестировать без затрат на создание отдела/ов тестирования:

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

[Case]

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

Господа, снова призываю идти по тернистому пути познания :) согласно предложенному алгоритму - давайте определимся с набрром функций который выполяются отделом или службой тестирования в компании. (см соотв. топик в разделе терминология) - иначе получается каша.

[Олешка]

To Case: Чтобы компания могла что-то гарантировать, ей надо выстраивать процесс тестирования, начиная от работы с требованиями и кончая отчетом о проведенном тестировании, а также управлять этим процессом.

Еще про документ:

Пункт 2.2.:

а) должны быть проверены все функции программы и все возможные комбинации этих функций;

б) должна быть проверена работа со всеми заявленными форматами;

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

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

Пункт 2.4:

Проверить наличие сопроводительной документации, выявить недостатки документации и несоответствия внутренним стандартам качества. К сопроводительной документации также относятся исходные коды программных продуктов, поэтому они также должны быть проверены на соответствие внутренним стандартам качества. Если в техническом задании указаны дополнительные требования к документации, необходимо проверить соответствие этим требованиям.

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

[Case]

To Case: Чтобы компания могла что-то гарантировать, ей надо выстраивать процесс тестирования, начиная от работы с требованиями и кончая отчетом о проведенном тестировании, а также управлять этим процессом.

Каким образом может что-то обеспечивать тестировщик при тех же вводных? :)

[Green]

To Case: Чтобы компания могла что-то гарантировать, ей надо выстраивать процесс тестирования, начиная от работы с требованиями и кончая отчетом о проведенном тестировании, а также управлять этим процессом.

Каким образом может что-то обеспечивать тестировщик при тех же вводных? :)

Небольшая ремарка.

Компания может гарантировать что хочет. Это ее право. <_<

Другой вопрос - может ли она это обеспечить?

Пример.
Фирма гарантирует бесплатную поддержку своих пользователей по всему миру в течении 24 часов. И никто не может помешать ей кричать об этом на всех углах.
Но это еще не значит, что она может это делать.

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

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

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

В качестве отправной точки могу порекомендовать RUP.
(Кстати, для использования RUP совсем не обязательно покупать пакет Rational.) RUP это готовый набор правил, как делать ПО с минимальными потерями качества. Этот набор можно использовать в качестве шаблона и создать свой набор процессов, которые могут лечь в основу своей технологии производства ПО.

В качестве альтернативы RUP можно использовать наработки Microsoft. Статьи об этом можно найти на русском языке на их сайте: http://www.microsoft...ructure/mof.asp
Для разработчиков и тестировщиков более актуальна msf.

[Green]

... поэтому постепенно назрел вопрос о создании отдела тестирования.
Сразу же возникают вопросы по тому, как проводить тестирование, как этим управлять, как распределять задачи и т.д.

Что касается основного вопроса дискуссии, то у меня есть два замечания.

1. Если речь идет о создании отдела тестирования, то как минимум необходимо разделить проблему на подзадачи. Для себя я бы выделил следующие:

а. Административный (стратегический) - какое место занимает, кто возглавляет, какими правами наделен отдел и, соответственно, за что отвечает (вопрос разделения ответственности - это главный вопрос современности B) ), по какой схеме происходит распределение ресурсов между проектами (существует горизонтальная, вертикальная и смешенная), тат вести отчетность по отделу.

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

2. Необходимо найти квалифицированного специалиста для возглавления отдела тестирования. Если об этом речь пока не идет, то надо хотя бы изучить теорию, связанную с вопросами тестирования ПО, т.к. приведенная инструкция больше похожа на песню коренного представителя крайнего севера - что вижу, то пою. :P

Сейчас выложу ссылки на методологию, предлагаемою Microsoft.