среда, 23 мая 2012 г.

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

"essentially, all models are wrong, but some are useful"
- George E. P. Box

В продолжение вот этого поста.

Так уж сложилось, что софт для тестирования в большинстве своем отвратителен со множества сторон. Причем по большей части отвратителен именно как софт. Т.е. как нечто, что призвано решать какие-то проблемы тестирования. TCMS в большинстве своем не исключение.

Почему мне не нравится сама идея TCMS?
Что такое TCMS по своей сути? Это система электронного документооборота. Со своей спецификой документов, со своими workflow и прочая прочая. Хорошо если вы сможете настроить формат документтов и/или workflow, хотя с этим в большинстве TCMS все очень плохо.

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

Больше систем хороших и разных. С довольно поганой интеграцией друг с другом. И чтобы каждый работник в каждой из систем исправно и регулярно работал. Здорово? Не думаю.

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

Почему TCMS это трата времени?
Потому что переключение контекста это отличный способ демотивации сотрудников и подрыва их производительности. А если они проходят за день по здоровенным чеклистам, то вариантов у них мало:
  1. Вносить изменения по ходу работы. Т.е. это или будет постоянная сверка с чеклистом по ходу работы, или человек будет делать дампы небольшими кусками.
  2. Вносить изменения постфактум. Это тоже кушает время, но не требует переключать контекст во время работы.
Есть способы сделать жизнь легче. Вот такой, или вот такой, например. Только почему-то, AFAIK, в TCMS пока ничего подобного нет. А пока нет - ваше тестирование будет сродни пилоту, который вынес нафиг все показания датчиков на спинку своего кресла и должен постоянно оборачиваться чтобы понять что происходит и куда дальше.

При этом TCMS использует гениальнейший способ отображения больших кусков информации - таблицы. Нифига не агреггированные, по больше части, ввиду особенностей данных. Для того чтобы оценить то, насколько это круто, можете почитать книжки про работу с данными. Это не все, но верхних трех из списка хватит чтобы оценить масштабы бедствия.

При этом сами TCMS как правило ограничивают ваши тесты как формой так и форматом. Вам нужен бинарный результат. Вам скорее всего придется потратить время на такую вредную штуку как сведение всех ваших тестов до одного уровня атомарности. Делаете очень много маленьких тестов - получаете почти полную невозможность делать хорошие, сложные тесты. Много больших - получается обратная проблема. Много разных - ваши метрики вроде pass/fail ratio начинают трещать по швам от своей бесполезности.

Ну и конечно же "счастье" в виде поддержки тысяч кейсов для динамически развивающихся продуктов. Хотите? Считаете что оно стоит того? Есть компании, где существовали специально выделенные люди для актуализации тесткейсов. Вам к ним.

Почему сомнительные бонусы?
Из написанного выше следует, что мы или подгоняем всю свою тестовую активность под шаблоны TCMS или эта система как сборник и мониторинг вообще всей вашей тестовой деятельности никуда не годится. Но подгон под такие шаблоны это уже не тестирование, а самое натуральное вредительство.

Ведь если нам нужно понять в каком состоянии находится проект, то можно работать над такими штуками как Low Tech Testing Dashboard. Вот хороший пример. Это быстро, нет никакого мусора. Можно делать хоть на вашей доске прямо в кабинете.

Если вам нужно понять какие тесты у вас уже есть, а каких нет - рисуйте MindMap'ы, оформляйте используемые модели каким-нибудь более удобным способом чем стена текста всунутая в таблицу. Есть много отличных способов работать с многомерными моделями/данными.

История прогона тестов сама по себе ценности не несет. Есть ценность в материале для post mortem анализа, которым может являться история тестов. Но после данного анализа этот материал практически не нужен.

Ну и, конечно же, метрики вписанные в TCMS.
Хотите из результатов прошлых тестов получить за сколько будет выполнен следующий прогон? Тогда, наверное, вы не очень хорошо понимаете почему тестирование кушает больше или меньше времени. Сюда же можно записать отслеживание прогресса.
Хотите использовать их для pass/fail ratio? Тогда вы наверное забыли что такое "один единственный баг из-за которого ничего в продакшен не пойдет". К тому же если ваш тест начинает падать, то надо проблему чинить. Ну или выкидывать тест, если эта проблема всех устраивает.

Вместо "итого"
TCMS отлично подходят для:

  1. Тестов на примерно одном уровне абстракции
  2. Тестов не сильно отличающихся по вариативности
  3. Тестов с бинарным результатом
  4. Когда мы можем легко отслеживать выполнение тестов и логировать его
  5. ...
  6. Ну вы понели
Это все отлично подходит для большинства автоматических тестов, вписывающихся в Productivity модель. Т.е. сравнительно несложных, атомарных проверок, которые (так уж исторически сложилось) принято называть тестами. Для постобработки такого материала хорошая работа с табличными данными более чем пригодна. Увы она есть не во всех TCMS, но даже с этим можно что-то сделать.

Для ручных тестов получается три варианта:
  1. Вы осознанно отказываетесь от различной тестовой активности, которую нельзя уложить в шаблоны использования TCMS и которые приводят к уплыванию встроенных туда метрик. Можете еще попробовать отрубить себе ногу.
  2. Вы пытаетесь впихнуть в TCMS невпихуемое. Получается уродливо, неудобно, да к тому же большую часть бонусов от работы с TCMS вы потеряете.
  3. Вы честно признаетесь что в TCMS будут не все ваши замечательные тесты и не вся тестовая активность. И скорее всего там будут только автоматические тесты. Если вообще будут.



ЗЫ: Откровенный фашизм с визированием и разделением тестировщиков на "читателей" и "писателей" я не вижу смысла обсуждать. Оно имеет смысл в случае когда к вам пришло FDA, но даже там это не единственная возможная/нужная активность.

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

  1. "Хотите из результатов прошлых тестов получить за сколько будет выполнен следующий прогон? Тогда, наверное, вы не очень хорошо понимаете почему тестирование кушает больше или меньше времени"

    ШТО?!?!
    Ну, то есть, точную величину мы не получим, да.
    И что, нам это мешает сделать оценку?
    Ах да, ты же пишешь про динамически развиваюшиеся продукты, я забыл.
    [уходит]

    ОтветитьУдалить
    Ответы
    1. А разница как они развиваются? Скорость выполнения тестов рычками зависит не от накопленного годами среднего по больнице, а от масштабов изменений/количества новых, сочных багов. Смысл в среднем по больнице я не вижу от слова "вообще". "Экспертная оценка" из категории "сферических коней в вакууме" ничем не лучше генератора случайных чисел в заданном диапазоне.

      Удалить
    2. Про развивающиеся продукты это моя дежурная пролетарская ненависть к вашим релизам каждый день и тому подобным нововведениям, пора привыкнуть уже!!!

      По теме - то есть оценка минимально необходимого времени уже не оценка?

      Удалить
    3. Для нее TCMS совсем не обязательно. Если я эти тесты уже сколько-то раз прогонял, то я и так могу это сказать. Если нет - скорее всего эта оценка не имеет смысла.
      К тому же среднее по больнице от TCMS это даже не минимальное, а вообще хрен знает что.

      Удалить
    4. > Если я эти тесты уже сколько-то раз прогонял, то я и так могу это сказать
      Тестов 10000, не забывай!

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

      Удалить
    5. А разница сколько тестов? Время на их выполнение сказать будет сложнее?

      ЗЫ: У вас не ватерфолл, а самый натуральный аджайл (у вас так в вакансиях написано!). И у вас не карьер, а эти... ну ты понел.

      Удалить
    6. ээээ, "Если я эти тесты уже сколько-то раз прогонял, то я и так могу это сказать", это про автотесты или про ручные?
      Как ты сможешь сказать, сколько времени занимает что то что ты прогонял в лучшем случае полгода назад?
      Ты - мальчик с феноменальной памятью?

      Удалить
  2. Почему карьерный самосвал не подходит для гонок Formula 1. Я правильно понял основную мысль?

    ОтветитьУдалить
    Ответы
    1. В целом да. + немного объяснений где карьерный самосвал, а где Formula 1. Увы для многих коллег это не очевидно. Но это скорее извечная подменя вопроса "как мне решить проблему Х?" вопросом "как мне решить проблему Х при помощи Y?".

      Удалить
    2. Объяснений и правда немного, Сирёжа!

      Удалить
  3. а где альтернативу искать? пока TCMS, вики и багтрекеры все умеют, ими и пользуются.
    у IBM или Microsoft (TFS) есть системы, которые объединяют сразу все - код, юнит тесты, требования и т.д.
    но по сути это навороченный TCMS.

    как Вы себе представляете инструмент, решающий текущие задачи лучше?

    ОтветитьУдалить
    Ответы
    1. Решения вроде TFS весьма отвратны. Это enterprise во всей своей красе, который отлично работает если все настроить как надо и работать в заданном процессе никуда не отступая. Шаг в сторону и начинается лютая морока. До кучи это еще и попытка сделать все сразу и хорошо. В итоге получилось как всегда. IBM, HP и далее по списку ничем принципиально не отличаются. Даже в самом MS не все им пользуются для ведения не автоматизированных тестов, да и для ряда автоматизированных аналогично (читать и спрашивать Алана Пэйджа и Гарри Робинсона, XBox и Bing соответственно).

      Альтернативу надо не искать, а делать. Даже если сейчас посмотреть - есть хорошие подвижки в разные стороны (я тут в линках тот же moztrap приводил). Есть тот же hexawise, который дает существенно больше полезного выхлопа чем TCMS, скажем, в TFS. Но в тестовом софте (да и в методиках) наблюдаются, ИМХО, серьезные проблемы в анализе и визуализации данных. Нормальных работников от BI и data visualization. Но как обычно - тестовый софт это побочный продукт для большинства компаний, потому и недополучает. Фичи (pass/fail, недо-coverage) вшитые в TCMS по большей части древние как динозавры и со всех сторон обмусоленные со своими плючами и минусами.

      Если самим делать религия/бюджет не позволяют - пользоваться тем что есть и плакать. Или не пользоваться и плакать. То что, собственно, происходит сейчас с багтрекерами. Все плохие, просто альтернатив не особо.

      Ну и главное - текущие задачи и потребности у всех разные. А TCMS а-ля TFS это рельсы, которым все равно какие у вас задачи и потребности - пользуйтесь тем что дают или не пользуйтесь вообще. И вместо того чтобы решать свои проблемы люди по большей части пытаются выбрать себе проблемы из списка предоставляемого TCMS.

      Удалить
    2. Да, согласен, тестерский софт необходимо во многом улучшать, и в частности - делать его гибким, не только за счет возможности настройки.
      На своих проектах мы используем решения HP (плюс системы из набора обсуждаемых - баг трекинг(целых два), вики, TCMS), но когда они не справляются с задачами, дописываем руками то чего хотим видеть.
      Например, написали софт, который мониторит автоматизацию и если она отвалилась (а у IE + HP QTP это не редкость, к сожалению) то она нажимает на нужные кнопочки чтобы QTP долго не думал. Еще написали скрипты, которые генерируют HTML отчеты на основе XML, возвращаемых автоматизацией. И ещё систему агрегации всех результатов, которая одновременно мониторит тестовую лабу (если вдруг какое-то устройство выключилось - тревога).

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

      Удалить
    3. Я как-то не уверен что маленьким проектам это вообще нужно. Если важна скорость то минимизация бюрократии не дающей ничего в краткосрочной перспективе (а другой нет) это первое что нужно сделать

      Удалить