Общее правило организации деятельности по обеспечению качества программного изделия заключается в установлении подотчетности соответствующих процедур как можно более высокому уровню руководства фирмы и отделении их от функции разработки. Группа испытаний в этом смысле должна быть органом контроля деятельности других функциональных групп, особенно групп разработки и выпуска документации, и потому следует принять меры, предотвращающие причины разногласий между ними. Наиболее рациональная схема взаимодействия представлена на рис. 8.9, где группа испытаний входит в состав сектора компоновки и выпуска.
Организуя испытания программного изделия, необходимо иметь четкий ответ на вопрос: «где кончается процесс оценки и начинается процесс отладки программного изделия»? Прежде всего, следует ограничить деятельность испытателей, возложив на них только обязанность фиксировать факт наличия ошибки. Им нельзя разрешать диагностировать причины ошибок, и, более того, указывать точное место их возникновения. Если не проводить в жизнь такое распределение труда, то никогда не удастся отделить задачи от обязанностей испытателей и разработчики будут уповать на то, что группа испытаний сама завершит отладку программ.
Рис. 8.9 — Организация взаимосвязи при проведении испытаний
Необходимо продумать вопрос, на кого следует возложить ответственность за компоновку программ в систему, особенно в условиях, когда в проекте участвует несколько фирм-подрядчиков. Объединение функций компоновки и испытаний уменьшает число подразделений-участников проекта и не приводит к утрате объективности оценок. При этом должно четко выполняться требование — на группе разработки лежит полная ответственность за устранение обнаруживаемых ошибок.
Типичный путь эволюции испытаний можно представить следующим образом:
· Испытания не проводятся, разработчики сами отлаживают программные средства и выпускают их для распространения.
· Пользователи присылают много замечаний, указывающих на обилие ошибок, в организации выделяется автономная группа испытаний, которая не оказывает влияние на проектирование.
· Деятельность группы испытаний становится столь активной, что руководитель группы разработки протестует, заявляя: «Как я могу уложиться в плановые сроки, если группа испытаний придирается к любой мелочи и не соглашается рекомендовать изделие к выпуску»? Тогда группа испытаний становится частью группы разработки, и их совместная деятельность продолжается успешнее, т.к. испытатели утвердили «независимый» стиль работы и не склонны допускать нарушения этой традиции.
· Руководители проекта и руководство фирмы осознают, что проблема испытаний требует профессионального подхода и что сотрудники группы испытаний могут играть важную роль в процессах планирования и проектирования изделий. Эта группа начинает постоянно участвовать в составлении планов и спецификаций. В результате вновь возникают трения, т.к. руководитель группы разработки часто нейтрализует предложения испытателей. «Если мы все будем делать так, как требуют испытатели, мы не выполним календарный план, и нам не хватит отпущенных ресурсов». Поэтому группа испытаний выделяется из группы разработки и становится самостоятельной организационной единицей.
Независимо от места, которое занимает группа испытаний в проектной организации, следует не упускать из виду необходимость стимулирования работы ее сотрудников. Ошибочно желание укомплектовать группу испытаний стажерами или людьми, не проявившими себя как разработчики. Испытания, проведенные этими людьми, несут больше вреда, чем просто отсутствие испытаний. Будет затрачена масса времени и сил на отладку самих тестов, общение между испытателями и разработчиками будет происходить на крайне низком уровне взаимодействия, и программный продукт получит крайне плохую репутацию среди потребителей. Только из хороших проектировщиков и программистов получаются хорошие испытатели. Особенно удачно использование системных программистов и специалистов по системному прикладному анализу. Должны быть предусмотрены пути самостоятельного служебного роста для таких людей.