О тестировании ПО (2-ч.)

Ну начнем по полочкам:
С чего надо начинать?
В общественном понятии QA team это такие сволочи внутри организации,которые не дают спокойно работать проггерам. Избавится от такого мнения является первой целью. Как этого добиться? Наилучшее решение на мой взгляд это дать понять команде разработчиков то, что QA имеют те же цели, что и они, т.е. "Предоставить заказчику действительно добротный и стабильный софт". Конечно же нельзя забывать о базовых понятиях для QA как багтрак, автоматизированная система тестирования, ну и главное иметь "талант" или расположенность к тестированию. Последнее понятие может показаться спорным, но если чувак не получает удовольствия от тестирования, то рано или поздно все это выйдет боком как для QA, так и для компании. Последствия чаще всего это - лень и утеря коммуникации со своими коллегами, что очень страшно...
Самым сложным в начальной стадии организации QA-team является "самоудтверждение самой команды внутри организации". Т.е. доказывание начальству, да и вообще самой компании, дееспособности и реально приносимой пользы от работы команды.
На мое личное мнение не нужно нагружать все возможныим обязанностями только начавшую свою работу команду. Обязанности будут накладываться по мере потребностей. Для начала команде хватит и GUI тестирования и попытки автоматизации скриптов.
Занимаемое место QA-team в жизненном цикле софта всегда должно быть перед заказчиком, в нормальных условиях только после одобрения QA софт должен отправляться заказчику. Такая жесткая политика просто необходима, поскольку почти во всех фидбэках от заказчика наверняка будут обвинены именно QA, со знакомыми словами "Это ты виноват))".
Обязанности QA, которые могут быть возложены на команду это не только GUI тестирование, но и проверка на правильность решения бизнес логики заказчика, проверка usability. Из этого и вытекает необходимость для команды быть в курсе хода всей системы в целом, знать "ТЗ" и понимать ожидаемые результаты работы выпускаемого софта заказчиком.
Жизнь Багтрака у нас в компании имеет интересную последовательность. Первой его задачей была запись найденных багов и последущее исправление проггерами. По сути она имела 3 статутса: "найден баг", "исправлено"(прогером) и "работает")). Естественно это нас не радовало, поскольку мы не были польностью осведомлены о проделанных изменениях в софте, что приводило к случаям того, что мы не могли протестить все проделанные изменения. При этом выбранный нами багтрак без проблем подключался к нашему SVN репозиторию, но прослеживать все проделанные коммиты было очень трудоемким. Решили эту проблему мы исходя из собственных потребностей. Все карточки(задания для проггеров) перевели на багтрак, при этом добавили(дописали=)) собственные необходимые нам статусы для карточек. Грубо говоря перевели жизненные циклы софта в статусы. Надо отметить, что жизненный цикл софта у разных компаний имеет разный вид, поэтому не стал называть статусы железными именами. Примерная последовательность это - в очереди, делается, на тестировании, найденбаг, закончено. Эта последовательность у каждой комании имеет собственный вид и дополняется собственными потребностями. Неплохо, если к карточкам привязывать жесткую политику последовательности.
Возможность делать собственные отчеты(запросы) по багтраку очень важно. Нашим выбором среди багтраков стал http://trac.edgewall.org/ по большей части из за того, что он был опен-сорс проектом и его можно было дописать, возможность подключения нашего svn к нему и куча созданных для него плагинов. Но опять же для разных видов организации процесса разработки необходимы разные решения.
Думаю хватит на сегодня)