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

Мне поставлена задача организовать процесс тестирования, сделать его эффективным и еще разработать эти самые тесты.

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

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

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

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

литература
http://www.litportal.kiev.ua/2007/02/02/sjem_kaner_dzhek_folk_eng_kek_nguen_testirovanie_programmnogo_obespechenija_fundamentalnye_koncepcii_menedzhmenta_biznesprilozhenijj.html
Это наше все! Это библия тестировщика. Начни с этого, в голове многое прояснится.
инструментарий
Для начала ничего кроме баг-треккера не нужно. Имхо, для постановки процесса главный инструмент это мозг.
способы дизайна тестов
Хм. Не новичковоуровневый вопрос. У Канера есть ответ. Я бы вместо этого выделила бы тесты на ужас-ужас (т.е. проверка работы самого важного функционала - без которого жить невозможно, у нас это называлось приемочное тестирование - термин может быть не в общепринятом значении), и проверка основного функционала (функциональное тестирование). Если ужас-ужас на приемочных тестах случился, сразу отдаем разработчикам, даже смотреть дальше нечего.
форма представления тестов
Зависит от квалификации тестеров. Для начала нужен хотя бы чек-лист: проверить это, это и это. У Канера про это много написано.
приемы уменьшения трудоемкости
Эд, для начала тебе бы просто трудоемкость определить, а потом уже оптимизировать процесс
оценка качества тестов
Читаем Канера
сокращения числа тестов без потери контролирующей функции
раньше, чем процесс, оптимизацию проводить не надо. О выборе из 2 тестов лучшего написано у Канера
риски
Основной риск - что у тестеров на стенде софт будет работать, а у заказчика - нет. Предохраняемся по заветам Феликса Эдмундыча: чистые руки, горячее сердце и холодная голова - тестовый стенд должен быть максимально приближен к стенду заказчика, тестер должен ЗНАТЬ, что ошибки есть, надо их только найти, тестирование нужно спланировать так, чтоб самое страшное проверить как можно раньше.
Так же один из рисков это то, что разработка затянется, и на тестирование времени останется слишком мало (уж не говоря об исправлении ошибок). Это чревато переработками и пропуском ошибок.
чего следует избегать и т.п.
Ну, Эд, ты у нас умный, почитаешь Канера - сам поймешь. Имхо, сначала нужно спланировать тесты и методику тестирования, а потом уже делать.
Может, кинешь в меня общим описанием проекта? Попробую тряхнуть стариной и прикинуть, с чего начать.
Кроме этого, вспомни AfterParty TrainingLabs и молодого человека с надписью на футболке "Хочешь найти баг, спроси меня как". Александр Лобач показом своей футболки в общем-то нарвался, ты же хочешь найти баг? ;-)

В догонку:
 http://pankratov.org.ua/docs/test_management_print.ppt - презентация тренинга Тест-менеджмент от гуру тестирования Славы Панкратова.
http://software-testing.ru/lib/ - Архив библиотеки проекта Software-Testing.Ru - лучшего и почти единственного русскоязычного сайта по тестированию на постсоветском пространстве.
http://tester.com.ua/ - сайт-родитель для Software-Testing.Ru

Для старта:
http://tester.com.ua/
http://www.intuit.ru/department/se/testing/

Софт тестировщика:
http://www.dmoz.org/Business/Business_Services/Quality_Control_and_Tracking/Software/

Это "Наше все" в Рунете:
http://software-testing.ru/
http://www.interface.ru/misc/testpril.htm

Форум тестировщиков:
http://it4business.ru/forum/lofiversion/index.php/f109.html

Спасибо, друзья. Буду погружаться

Погружение идет стремительно. При разработке тестовых сценариев уже обнаружены ошибки.

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

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

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

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

Эд, чаще всего это очень дорого - автоматизация тестирования.

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

Я понимаю в Microsofte на каждого программиста 2 тестировщика. Здесь это не получится

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

Тут понимаешь от желаний или не желаний зависит мало. Есть задача и ее следует решать. Будет ли она автоматизирована или нет.

Иначе при провале всех собак повесят на тебя, а провал тут очень вероятен.

Ну не надо так пессимично. В худшем случае уволят и будут показывать пальцем

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

Программа уже определена примерно - TestComplete 6- ты ведь говорила знаешь такую.

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

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

В твоей ситуации я бы не стала этим заниматься вообще, пока не станет привычным, штатным и понятным ручное тестирование.

Ну перспективу на 5-тку вперед ты мне нарисовала радужную

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

Бум смотреть...

А до кучи вопросец:
Насколько точным и подробным должен быть тест-сценарий?
Может ли тест-сценарий содержать "цель" шага тестирования, а не точное скурпулезное описание каждого действия.
Т.е. тест-сценарий - это аналог в какой-то степени руководства пользователя, только с точно заданной нагрузкой?

Насколько точным и подробным должен быть тест-сценарий?
Может ли тест-сценарий содержать "цель" шага тестирования, а не точное скурпулезное описание каждого действия.
Т.е. тест-сценарий - это аналог в какой-то степени руководства пользователя, только с точно заданной нагрузкой?

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

Насколько точным и подробным должен быть тест-сценарий?
Может ли тест-сценарий содержать "цель" шага тестирования, а не точное скурпулезное описание каждого действия.
Т.е. тест-сценарий - это аналог в какой-то степени руководства пользователя, только с точно заданной нагрузкой?

Ира опередила.

Но я всё-таки повторю, для лучшей доходчивости: степень необходимой детализации тестового сценария полностью зависит от того, кто по этому сценарию будет программу тестировать.

И цитатку подкину подходящую.

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

Greesha, согласен с тобой и Irr.

Действительно наверное описывать подробности не имеет смысла, где они достаточно очевидны.
Я вижу в тестовых сценариях массу пересечений с вариантами использования.

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

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