March 30th, 2012

ВсПЛЕСк-2007

Quality Assurance Day 2012

Занесло меня сегодня на "Конференцию для тех, кому не безразлично качество" #qaday. Неожиданно понравилось, даже захотелось перестроить наш процесс разработки ПО.

Перепишу заметки из своего блокнота (там только то, что показалось интересным, остальное я пропускал)

* Перевод "production" как "боевая" окончательно утвердился
* В качестве показателей имеет смысл использовать не количество ошибок, обнаруженных в ходе эксплуатации, а число обнаруженных во время тестирования ошибок к общему числу выявленных ошибок (DDE). Или число исправленных к общему числу.
* Если "code review" вполне привычный для меня термин, то "specification review" прозвучало свежо. Ведь действительно ошибки нужно отлавливать как можно раньше. Точнее даже можно разделить на проверку требований и проверку дизайна.
* Другой новый термин для меня  - UAT (user acceptance testing), хотя по-русски это звучит привычнее - приёмочне испытания.
* Вообще типовой жизненный цикл получается: Specification - Specification review - Code - Code Review - Unit Test - Integration Test - System Test - User Acceptance Test - Production
* А вот статистика обнаружения багам по этапам от Рекса Блека:
Requirement review  - 65% (от тех ошибок, что существуют на этом этапе)
Design review - 65%
Code review - 60%
Testing by developers (poor) - 10%
Testing by developers (avg) - 25%
Testing by developers (best) - 50%
Testing by professional testers (avg) - 85%
Testing by professional testers (good) - 90%
Testing by professional testers (best) - 99%
Плохих тестеров, видимо, не бывает.
* А вот статистика по появлению ошибок на этапах: req - 25%, design - 25%, code - 33%
* Банальную мысль, что чем раньше обнаружена ошибка, тем дешевле её исправить, Рекс подтвердил следующим примером. После оптимизации процесса в компании, у которой бюджет ИТ был 1 млрд, а затраты на исправление багов 250 мил., последние сократились до 150 тыс. Сэкономили примерно 10% бюджета. "Кажется, что это мало? Представьте, что вы идёте в банк, снимаете свои сбережения, а затем, прямо на выходе из банка, сжигаете 10% купюр. Правда, ведь, абсурд?!"
* По его оценке выявление бага в списке требований стоит $37, а на этапе окончательного тестирования $3700. Но в большинстве компаний ошибки появляются в начале разработки, а исправляются только в самом конце.
* Мотивировать разработчиков "Мы делаем отличное ПО", иначе не будет от них толку
* "Начинающих программистов мы заставляли пару месяцев работать тестировщиками, чтобы они почувствовали нашу боль"
* Статистика от Микрософта: средний перерасход средств при разработке ПО - 45%, отставание по срокам - 63%, снижение функционала - 67%.
* А это уже Дмитрий Петунин из Интела: "Рутина мешает привлекать квалифицированных специалистов, поэтому он неё нужно избавляться".
* Ещё советы от него:
используйте то ПО, которые делаете
встроенная самодиагностика
роботы-тестировщика (например для входных данных)
стат и динамический анализ кода
* "Нет для фирмы ничего страшнее, чем креативный бухгалтер. Также плох и принципиальный QA-менеджер." Это к тому, что в процессе разработке новых фич и оптимизации производительности можно закрывать глаза на провал автоматических тестов, но не фич-фризе.
* В Интеле проводят периодическую ротация менеджеров (тестирования и разработки, например), чтобы не костенели в своей области.
* Выделенное QA-подразделение, а не по одному тестировщеку в каждом проекте. Это позволит поднят влияние QA в компании, использовать единые стандарты, карьерный рост для тестировщиков, балансирование работ по проектам.
* В Parallels на 4 программистов 1 тестировщик. Из 10 000 бета-тестеров 200 проявляют активность. (Тимофей Сургученко)
* При обработке отзывов во время открытого бета-тестирования полезно иметь своего "большого парня", который сможет подписываться "вице-президент" и обещать наказать всех виновных программистов.
* KPI для тестирования можно придумать разнообразные, например, "своевременность наполнения тестовой модели" (Рашид Галиев)
* варианты оценки стоимости проекта: экспертная, по аналогии, PERT, use case point, function point analysis, COCOMO (Алёна Горшкова)
* Ещё способы: типовой опросник, шаблон задачи (как операции входят в типовую задачу, чотбы не забыть их посчитать)
* 10-20% времени уходит на менеджмент QA
* Посмотреть jazz.net и Ratonal Requirements Composer