Архив за Июнь, 2020

История моей фасетной классификации видов тестирования

Вторник, Июнь 23rd, 2020

Немного некропост. Или мемуары.
В 2001 я познакомился с шаблонами документации RUP. В частности, в «Плане тестирования» была интересная и нетривиальная классификация видов тестирования.  На мой скромный взгляд, эта классификация из 90-х и сейчас превосходит классификацию ISTQB.

Но что-то мне в ней не нравилось. В 2003 я разработал свою фасетную классификацию. Правда тогда я не знал, что она фасетная. В 2005 впервые опубликовал. Но ее еще нужно было дорабатывать и дорабатывать. Тогда еще я не знал о ГОСТ 9126, а до ГОСТ 25010 оставалось 10 лет…

Потом эта классификация появилась в книге у Савина, на тренингах Баранцева, в докладах на конференциях.
Потом Vader опубликовал ее в википедии.
Потом ее в википедии испортили.

На текущий момент я ее доработал, как и хотел. И даю на тренингах. Собираю фидбек. Очень неплохо прокомментировали эту классификацию в СКБ-Контур. Спасибо им большое.
По-хорошему, надо бы в книгу ее включить. Но это столько ж писать надо…

А теперь тот самый исторический пост.
(more…)

Когда багов создается больше чем решается…

Понедельник, Июнь 22nd, 2020

Иногда мне присылают вопросы, достойные ответа в виде статьи. Или хотя бы виньетки или драбла.

– Самое интересное … когда багов создается больше чем решается … что в этом случае советуешь делать? Палкой бить?

Зачем же сразу палкой? Да еще разработчиков. Данная ситуация полностью в компетенции менеджмента. Либо ручного контроля, либо контроля со стороны его величества Регламента.

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

Разберем последнюю ситуацию. Тестировщик может искать дефекты в фиче-бранче или в мастере. Мне ближе в мастере, т.к. после тестирования в фиче-бранче по-хорошему все равно придется тестировать мастер после всех мержей. Но подход вполне имеет право на жизнь. Зависит от степени запущенности софта.

Дефекты делятся на:
1. Не правим вообще и живем с ним долго и счастливо. Как с JRA-1330 жили дюжину лет.
2. Правим в рамках отладки фичи. Фичи с этими незакрытыми дефектами не выпускаются.
3. Дефект будет правиться, но не прям сейчас. Выпустим, а потом будет время подчищать долги, вот и поправим.

В Jira это легко организуется следующим образом. Фичи – это задача, иногда эпик с задачами. Дефекты создаются как подзадачи. Можно повесить скрипт, который не даст закрыть фичу, если есть незакрытые дефекты-подзадачи. Решили перевести из второй категории в третью – измените тип. С дефекта-подзадачи на дефект-задачу. Все, дефект не привязан к фиче, релиз выпускаем.
А теперь главное правило работы с дефектами: «Если вы решили править дефект, то время от внесения дефекта в код до исправления должно быть минимально.»
Идеальный вариант – программист получает реестр ошибок через 5 минут после коммита в фиче-бранч. Именно для этого нужны автоматизированные тесты. И начинать автоматизацию с регрессионного тестирования – занятие так себе. Не, если паровоз прицепить позади состава, то двигаться вперед можно. Но плохо-плохо.

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

Второе главное правило работы с дефектами: «Исправление дефекта, который решили править, приоритетней, чем запиливание новой фичи.» Повесьте это правило в кабинете программистов. И в кабинетах заказчиков тоже.

Перейдем к анализу. Перед вами малоизвестная, крайне редко применяемая и крайне полезная диаграмма для анализа потока создания ценности VSM.

vsm.PNG

W – работа.
M – muda. Потери. Простои в очередях.
W1 – программирование фичи. Точнее внесение дефекта в код.
W2 – нахождение дефекта.
W3 – определение категории: правим немедленно, правим потом, не правим.
W4 – Исправление дефекта.

Как уменьшить время исправления? Довольно простое решение – убрать W3 из производственного потока. Неприятно, да? «Чтобы улучшить производственный поток, нужно устранить из него менеджера и заменить его регламентом». Такова суровая правда науки управления. «Sad but true.»

Далее. После запиливания фичи, тестировщики должны приступать к работе немедленно. Сокращаем m1 до нуля. Для этого тестировщики должны иметь запас по мощности (должны простаивать) 20-25%. «Sad but true.» Или вы занимаетесь субоптимизацией, или вы беспокоитесь об эффективности производственного потока. Если прибыль фирмы важнее чем таймшиты по 40 часов в неделю, то к черту таймшиты!

И наконец. «Исправление дефекта, который решили править, приоритетней, чем запиливание новой фичи.» Получив реестр дефектов, программист должен немедленно или почти немедленно начать их править. Нетленка подождет.

Может показаться, что я не ответил на начальный вопрос. Нет, ответил. Дефект проживший более [года | полугода | квартала] должен автоматически попадать в первую категорию. И закрываться скриптом.

Вот собственно и все. Don’t worry be happy.

PS. Первая публикация в facebook. Там же и обсудить можно.