четверг, 27 июня 2013 г.

ТЕСТ ИТ: прогнозирование появления дефектов

Всем привет!

С вами снова я  - ваш сменный-редактор-по-пятницам - Зинченко Татьяна. Сегодня у нас в рубрике ответ на вопрос Егора. Егор прислал очень развернутое письмо, в котором рассказал и о том, как он работает тестировщиком, и о том, что он пишет дипломную работу по теме "Модернизация процесса создания баг-репорта в процессе тестирования сайта". Собственно, вопрос от Егора звучит так:

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

Даже если я нахожу баг и создаю баг-репорт по нему, то мне:
1) может потребоваться использование внедренного ПО,
2) может и не потребоваться его использование
Это зависит от сложности описания бага.

Из этого всего следует, что невозможно спрогнозировать появление багов при тестировании сайта, а следовательно невозможно спрогнозировать кол-во создаваемых баг-репортов в период окупаемости затрат на внедрение ПО.

Подскажите, как мне быть в таком случае? От чего отталкиваться, в вычислениях срока окупаемости затрат на внедрение ПО? И вообще возможны ли подобные вычисления, если данный процесс основывается на человеческом факторе?



Но Егор еще уточнил:

Я не прошу решать эту задачку за меня! Я прошу направить меня в верном направлении! Я прошу дать моим мозгам волшебного пинка :)
Волшебный пинок так волшебный пинок :)

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

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

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

Я думаю, что после просмотра этих двух выступлений, Вы обязательно найдете дорогу дальше. А если нет - мы все также принимаем письма с вопросами по адресу: sprosi.testera@gmail.com.
Пишите, спрашивайте и, возможно, в следующую пятницу мы ответим уже на ваш вопрос :)

Удачи!



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

  1. О да, кривые нахождения дефектов, прогнозирование времени окончания и прочая прочая. Обычно такие вещи пишут люди очень плохо понимающие как в разных случаях проходит разработка ПО, откуда берутся дефекты и почему они иногда не выявляются своевременно. У Канера есть ряд работ на эту тему и почему это как правило не работает в реальной жизни.

    ОтветитьУдалить
    Ответы
    1. В реальной жизни - да. Для диплома же будет самое оно :)
      Ну и радует уже то, что этим начали заниматься. Вдруг, лет через 15-20.....

      Удалить
    2. А не стыдно диплом про коней в вакууме писать?

      Удалить
    3. А ваш диплом был полон полезной информацией с актуальными данными? :)

      Удалить
  2. Анонимный27 июня 2013 г., 14:58

    А как Вы различаете тех, кто "люди очень плохо понимающие как в разных случаях проходит разработка ПО, откуда берутся дефекты и почему они иногда не выявляются своевременно" и тех, кто знает метрики и умеет ими пользоваться?

    Тот самый "дедушка русского тестирования"

    ОтветитьУдалить
    Ответы
    1. Вероятно, количество людей второго типа настолько мало, что в реальной жизни этой вероятностью можно пренебречь :)

      Удалить
    2. Слушаю. Смотрю. Спрашиваю.
      Подмена качественных характеристик количественными и предложение линейного ретроспективного анализа уже достаточно чтобы начать сильно сомневаться.

      Удалить
  3. Каша какая-то.
    Окупаемость сайта рассчитать - это одна задача.
    Прогнозирование числа багов при тестировании - другая.

    Для умственности в диплом можно к примеру вот это посмотреть:
    http://www.aldservice.com/images/stories/articles_pdf/rams_software_reliability.pdf

    про "assessment and prediction of software reliability"

    Это я навскидку, вроде еще у них были статьи.

    ОтветитьУдалить
    Ответы
    1. Есть коротенькая "Do the software reliability prediction models serve their intended purpose?" от Юан Вея. Есть ряд работ Канера про то почему предсказание дефектов это чисто академическая фикция (в основном на примере распределения Вейбулла, но не суть важно).

      Удалить
  4. )) авторы статьи, которую я привела - жесткие практики. Авиационное ПО.
    Имеют возможность собирать статистику по багам ПО, просочившимся в эксплуатацию.
    И по reliability вообще - специалисты весьма заметные.

    ОтветитьУдалить
    Ответы
    1. Только тут есть пара ньюансов:
      1. Большое количество оговорок в статье, вида "Rate of bugs’ discovery sometimes essentially depends on tester familiarity with the project", которые рассказчики упрощенных моделек почему-то игнорируют.
      2. Модели работающие для этих авторов плохо применимы для вебдванольных стартапчиков работающих в режиме непрерывной поставки, например. Другие ограничения применимости можно посмотреть в указанной мной выше брошюрке от Юан Вея. Покопаться в публикациях Канера тоже будет полезным.

      Удалить
  5. "Модели работающие для этих авторов плохо применимы для вебдванольных стартапчиков"

    естественно.
    Модели заточены под конкретное множество проектов.

    ))) ну я думаю - на "подумать" Егору хватит на первое время.

    ОтветитьУдалить
    Ответы
    1. Модели заточены под заранее известный процесс. Равномерный процесс.

      Модели говорящие сколько багов у вас будет завтра но не говорящие где это, простите, гадание на кофейной гуще. Не выработал норму - получай корректирующее воздействие. Выработал две нормы - корректирующее воздействие соседу.

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

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

      Модели... Да чего очевидные вещи перечислять?

      Удалить