понедельник, 16 мая 2011 г.

Организация процесса тестирования.

Когда-то страшно гордилась тем, что именно меня программисты забрали на новый проект. С течением времени от "страшно гордилась" осталось только "страшно". В лучших традициях гибких разработок нас на проекте шестеро (включая Project Owner и меня). И в лучших традициях тимлидами мы не обзавелись. А, значит, я сама себе аналитик, QA-лид и тестировщик. И если на первом проекте отсутствие первых двух было не так заметно, то тут времени на анализ стало больше. А, значит, и времени "побояться" тоже.

Итак, вопрос: чего у нас на проекте нет? Ответ: ничего у нас нет (подразумевается организация процесса тестирования). Встает вполне привычный вопрос всех времен: "Что делать?"



И начались "хождения по мукам", тыканья в разные форумы, изучения статей, посещения вебинаров... Можно уже проводить мастер-класс: "Как за полгода сделать тест-документацию из того, что есть в наличии" ))))

 Кто-то очень умный сказал: "Все, что бы ты не придумал, уже было придумано кем-то раньше". Вот и я наткнулась на статью I've Just Been Assigned To Manage Testing, What Next?, которая не потеряла своей актуальности и до сих пор, хоть и была написана еще в 2007 году.

Если бы я встретила ее раньше, то могла бы сразу сказать с чего начать. Сейчас же просто подведу итоги. А кому-то, может, пригодится )))

Итак, для эффективного начала управления тестирования необходимо несколько активностей:
- Определение стратегии тестирования;
- Составление Тест-плана;
- Подготовка Тест-скриптов;
- Выполнение Тест-плана;
- Изучить Метрики.

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

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


Тест-скрипты в каждой фирме выглядят по-разному. Я взяла за основу то написание скриптов, которому научилась когда-то, работая на американцев. Используется простейший Excel, в который заносятся стандартные 3 столбца, а во время выполнения приписывается четвертый столбец с датой и идентификацией проверяющего.
Тест-скрипты - это то, что я умела делать изначально. Поэтому у нас они появились еще до того, как появились тест-планы. )))

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

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


8 комментариев:

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

    ОтветитьУдалить
  2. Полностью согласен с will-ом! Нужно жестко привязать требования к тестам, так, чтобы: 1) требования не менялись без ведома (а в идеале и участия) тест-команды; 2) чтобы после изменения требований сразу же апдейтились/писались соответствующие тесты.
    Начинать с нуля очень интересно, как и очень опасно. Но если не терять бдительность, то это крайне увлекательная деятельность :)
    Удачи! Пока что процесс радует.

    ОтветитьУдалить
  3. Да, управления требованиями и изменениями - это любимый больной мозоль...
    Недавно поняла, что почти половину тест-кейсов в ближайшее время нужно будет переписать, потому как интерфейс изменился почти кардинально )))

    ОтветитьУдалить
  4. Вот и у нас так бывало... Интерфейс и функционал давно уже поменялся, а тест-кейсы стары и по ним тестировать невозможно, да и времени на их изменение не хватает.

    ОтветитьУдалить
  5. При написании любой документации, в первую очередь, надо задаваться вопросом для кого она предназначена? Потом как ли можем ли вообще мы её поддерживать? И совершенно чётко понимать сколько понадобиться ресурсов для реализации наших желаний. Мой опыт показывает что наличие плохих или сильно устаревших тест кейсов ни на грамм не облегчает работу. Объясню почему.
    Такие тест кейсы практичнее заменить в чек листе. Его гораздо проще поддерживать в условиях ограниченности кадровых или временных ресурсов или динамично меняющихся требований. Потому как количество бесполезных документов на проекте возрастёт а в результате исполнитель всё равно будет вынужден уткнуться носом в требования. Лучше тогда сразу в требования отправлять человека без запутанной прослойки не адекватных тест кейсов. Кроме того, если проект ориентирован на короткий забег, то польза от написания нормальных документов весьма сомнительна. Надо отдавать себе отчёт в затратах на создание хорошей документации. Потому что иначе я не понимаю зачем вообще создавать документы, заведомо плохие.
    Кроме того не надо бояться уйти от шаблонов. Делай так как будет удобно проектной команде. Если никому из команды не нужен полноценный тест план - не делайте его. Потратьте это время на тестирование требований или исследователькое тестирование, это принесёт больше пользы проекту. При организации процесса всётаки отталкивайся от понимания что мир не совершенен и переполнен сюрпризами. Так как вам всё равно придётся столкнуться с такими вещами. Пользуйтесь хорошими практиками. Начните с маленьких локальных проблем. Экстраполируйте опыт на другие задачи. Экспериментируйте. Помните, главная цель любого проекта, это его успех, а не создание образцовой документации или процесса. Большинство людей не альтруисты и всем будет приятно конвертировать успех проекта в материальные ценности ;)
    PS: Лично я предпочитаю ситуацию когда документация работает, а не лежит на сервере для галочки.

    ОтветитьУдалить
  6. Константин, поддерживаю все до последней буквы )))
    Я тоже обеими руками ЗА то хороший продукт, а не хороший процесс. )))
    Но необходимость в тест-кейсах есть. Как и время (пока во всяком случае) на их написание.

    ОтветитьУдалить
  7. Добрый день!
    Встала примерно такая же проблема. В компании ведется в основном ad-hoc тестирование на основе требований по конкретной функциональности. Хочется понять, что с этим делать и как менять? Спасибо за статью - буду думать)

    ОтветитьУдалить