вторник, 28 августа 2007 г.

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

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

понедельник, 27 августа 2007 г.

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

Хотелось бы написать собственное мнение о таком направлении как тестирование программного обеспечения. В общем то самое главное к чему я пришел за малое время работы в качестве QA в компании, так это то, что главная цель любого QA не должно быть "Найти максимальное количество багов", более правильным является "Сделать софт максимально качественным для заказчика". Количество найденных багов никогда не может быть показателем работы отдела тестирования. Мое сугубо личное мнение показателем становится реакция непосредственного заказчика на предоставленный софт, в каких то случаях количество фидбэков...
Почему же количество багов в софте не показатель? Потому что проггеры бывают разные и задачи также.
В плане багов большее внимание я бы обратил на адекватность восприятия бага программистом. Исходя из этого и выползают разные виды коммуникации с любым проггером, каждому нужен отдельный подход.
Самым главным в работе отдела QA на мой взгляд является поднятие максимально удобного и понятного багтрака, поскольку процесс выпуска софта у разных компаний имеет индивидуальынй характер. Довольствоваться тем, что есть на руках не лучшее решение. Тем более есть опенсорсные проекты которые всегда можно дописать самим.
Выбор автоматизированного софта для тестирования тоже не маловажный шаг... Самый большой и пугающий факт это то, что хороший софт стоит больших денег. Для того, чтобы сберечь собственную контору лучше всего накачать триальные версии этих программ и попробывать каждую. Исходя из этих опытов выбрать наиболее подходящий.
Для первой части наверно хватит)