четверг, 10 мая 2012 г.

Системы управления Тест-кейсами. Часть первая. Про любовь.

В этот раз хочется обсудить кошмар под названием Test Case Management Systems.

Для тех кто не в курсе что это такое - поясню:

Жили были тестировщики. И писали они тесты. Иногда тесты получались гениальные или очень сложные, и тогда они их записывали куда-нибудь. Как только тестов становилось много, их начинали упорядочивать в аккуратненькие документики (мы ведь знаем, что тестировщик в душе своей тот еще бюрократ). Отделы росли, поколения тестировщиков сменяли друг-друга, и примерно через годик-другой ведения таких аккуратных документиков в любой мало-мальски большой конторе со средней паршивости текучкой кадров обычно образуется завал этих аккуратных документиков, которые можно смело назвать "интелектуальное наследие прошлого", aka "помойка".
На этой стадии морального разложения у команд тестирования, как правило, есть куча "очень важных" документов. Обычно это куча экселевских (или еще чего похуже) файликов в которых есть аккуратные таблички, где можно ставить классные галочки или крестики или что вам удобно для того чтобы отмечать прогресс. У протестированной версии продукта должны быть все копии этих ддокументиков завизированные кровью самого старшего тестировщика с отметкой "PASSED" или "ПРОЙДЕНО" (в особо клиническом случае - "БАГОВ НЕТ!!!"). Ну и, конечно же, все должно быть пройдено ручками с точностью до запятой. Эдакое "cover your ass" тестирование, не имеющие ничего общего с качеством, но логично вытекающие из роли тестировщика как козла отпущения. Козел умирать не хочет, потому как может, так и прикрывает свои филейные части.
Иногда есть еще и сакральный документ под названием "план тестирования", который в лучшем случае представляет из себя что-то отличное от сборника всех-всех документиков с тест-кейсами. Но это отдельная, не менее печальная история.
Расово верный тестировщик может годами обсуждать правильные формы для заполнения таких документиков, обмениваться такими формами с коллегами, думать о выделениях разными размерами шрифта и запятыми, и предаваться другим околографоманским забавам.

Но!

У этого вороха документиков есть ряд недостатков:

  1. С ним чертовски неудобно работать. Вообще. Надо создавать копии документиков, держать их открытыми у себя на мониторе, сверяться все ли заполнено. И там даже не стройные ряды чекбоксиков, а частные spreadsheet-like поля. Тысячи их.
  2. Все хорошо пока в отдельно взятой команде тестировщиков есть непрерывная линия устно-фолклорной передачи сакрального знания о пользовании данными документиками. Как только цепочка нарушается - разобраться в этом кошмаре становится очень сложно (тестировщик хоть и бюрократ и гарфоман, но не враг себе, и старается устроить все поудобнее). Иногда трудно понять, что же за кошмар творится в соседнем отделе. Иногда благославенным перстом какого-нибудь корпоративного фюрера вводится "удобная для всех форма", и все работают с ней.
  3. Чтобы понять, "что же эти тестировщики делают", в ряде случаев нужно собрать большой такой ворох документиков и долго, при помощи Microsoft Office'XX и такой-то матери понимать. Иногда это еще называется "в каком состоянии находится вверенный тестировщикам софт".
В общем радужный такой, пост-водопадный бюрократический северный пушной лис.

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

TEST CASE MANAGEMENT SYSTEMS

Сначала были коммерческие, потом стали и не очень коммерческие. Горячо любимые нами вендоры тестерского софта вобрали в такие системы все лучшие практики индустрии:
  1. Вся прелесть пользовательских интерфейсов в лучших традициях Enterprise-решений
  2. Возможность задавать права соответствующие пищевой цепочке ваших тестировщиков (например "самый умный пишет - остальные выполняют") вместе с гибкими настройками рабочего процесса, когда вы можете наслаждаться тем, что изменение одной формочки - это будет не просто коммит, но еще и правко-визирование от N просвещенных тестировщиков
  3. Возможность наслаждаться наиполезнейшими метриками вроде pass/fail ratio и предсказывать сроки! Вам не придется самим считать это темными менеджерскими ночами! Теперь все будет сделано за вас любящей и знающей машиной!
  4. Возможность структурировать все в так горячо любимые тестировщиками таблички. Сотни! Тысячи табличек! Все с блестящей иерархией!
  5. Возможность отслеживать время выполнения. Да-да! Вам не хватает мест куда бы ваши сотрудники могли бы писать сколько минут и на что они потратили? Заведите себе еще и TCMS! Ведь учтенное время это время, потряченное не зря!
  6. Одни и те же тесты можно запускать в разной среде, от чего в обычных экселевских табличках многомерные данные просто не укладываются. Теперь вы можете привязывать конфигурации, и вообще все прямо на месте!
  7. Завизированные тесты теперь будут доступны всем важным лицам для ретроспективного анализа, и никто и никогда не сможет туда добавить что-то задним числом!
  8. Ну и конечно же вы сможете дружить эту волшебную систему со всем подряд, начиная от вашего багтрекера и заканчивая ковриком в кабинете генерального директора

Далее в комментариях я предлагаю обсудить все прелести и недостатки такого монументального решения. 

Свои взгляды на то почему это нихрена не работает я напишу позже. Ровно как и далекие от "Корней" и нарушающие все "Традиции" способы решать проблемы, которые, как думается, должны решать TCMS. Меня за это наверняка подстерегут в темной подворотне и прямо там с особым цинизмом предадут остракизму. А пока вы можете насладиться познанием такого явления как "Арифмомания".

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

  1. Идеальное TCMS, какое оно?

    ОтветитьУдалить
    Ответы
    1. Я вообще думаю что идея TCMS сама по себе порочна

      Удалить
    2. ок, тогда tms это что?
      Если брать за определение то, что ты тут понаписал, то она конечно говно :)
      А если брать за определение любую схему хранения активностей, запланированных для тестирования, как я тебе говорил?
      С моей точки зрения то что ты перечислял тогда: чеклисты, документация, майндмапы etc при доведении до ума для использования в тестировании начинает приобретать черты tcms где-то с момента внедрения централизованного хранения и сквозного текстового поиска и чем дальше тем больше. Вопрос как всегда - в каком месте остановиться, не более того.

      Удалить
  2. Давай я отвечу за тебя.

    > 1. Контроль утилизации бурндауна.
    Может осуществляться по tcms только если мы делаем регрессию, а регрессия говно.

    > 2. Консолидированный отчет по ручным и автотестам.
    Не нужен, поскольку множество автотестов и ручных тестов не пересекается.

    > 3. Составление оценок по историческим данным.

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

    Если я угадал, тогда ты повторяешься.

    ОтветитьУдалить
    Ответы
    1. > Может осуществляться по tcms только если мы делаем регрессию, а регрессия говно.
      можно ли вот этот момент осветить более подробно?

      Удалить
    2. Думаю нет, это была неудачная попытка угадать, что же именно Сергею не нравится в tms

      Удалить
  3. Круто, жду второй части, о ненависти ;)

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