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

Июнь 23, 2020

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

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

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

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

А теперь тот самый исторический пост.
Читать дальше »

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

Июнь 22, 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. Там же и обсудить можно.

Стандарт проектирования пользовательского интерфейса (UX)

Май 5, 2020

На днях читал, что я написал 16 лет назад. Тогда я писал не слишком хорошо. Добавил комментарии к тексnу 16-летней давности.

Да интерфейсы с тех пор сильно изменились. Тем не менее документ вполне годен как основа для разработки современного стандарта.

Пользуйтесь на здоровье. standart-ux_2004.zip

И не болейте.

PS. Иногда прикольно читать свои старые документы.

Доклад “Ключевые метрики тестирования”

Март 18, 2020

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

Расширенная аннотация
Перед докладом крайне рекомендую прочитать книги Голдратта «Синдром стога сена» (в частности там объясняется разница между данными и информацией и поднимается проблема информационного шума) и «Цель-1». Регулярно даю эти советы, но редко кто им следует ;-) . А материал сложен без предварительного изучения базы. По трехбалльной шкале сложности этот материал примерно на пятерку.
Для затравки приведу список метрик, которые в принципе можно измерять. Как будет показано на докладе, это путь в никуда. Не удивляйтесь «потоку сознания», список писался в режиме генерации идей без фазы критики.

Читать дальше »

Новые формы подготовки к докладам и тренингам

Март 18, 2020

Бизнесмены часто задают вопрос: «Почему?».

Это хороший вопрос, но не менее важный: «Почему бы и нет?»,

– Джеффри Безос.

Открываю новый раздел у себя на сайте.
За свою карьеру я прочитал множество докладов. Только за последние два года более полусотни на разные темы: управление, бизнес-анализ, системный анализ, архитектура ПО, тестирование. Каждый раз при подаче заявки на конференцию происходит примерно одно и тоже:
- Пришлите заявку.
- Давайте лучше обсудим темы, которые могут быть интересны слушателям.
Мне не интересно читать доклад, который интересен только мне. Пусть он будет интересен многим в зале.

Действительно, вот прямо сейчас мне может быть интересен такой аспект как: «Метрики разработки ПО, которые наиболее подходят для анализа при помощи карт Шухарта.» Но не факт, что именно на этой конференции эта тема будет интересной. А, например, «сравнение разных методов организации деревьев в реляционных БД» мне сейчас неинтересна (была интересна 15 лет назад), а аудитории может оказаться интересной.

Для эксперимента попробую поступить по-другому. Буду публиковать анонсы докладов, а потом отдавать темы на голосование. А потом посмотрю. Из чего-то получатся круглые столы на посиделках, что-то станет докладом. А что-то придется разворачивать в тренинг, т.к. на материал достоин целого дня, а то и недели.
– Для раздела “Об авторе” —————-
Чем я могу быть интересен?

Мне не слишком интересно рассказывать то, что я прочитал в книге пару месяцев назад. Гораздо интересней изобретать что-то новое. Мне удалось расширить технику разработки требований, известную как CRUDL. Теперь это CRUDL-тесеракт. Получилось придумать достаточно годную фасетную классификацию видов тестирования. И еще немного по мелочи, вроде тех статей, которыми пользуются тысячи коллег.

В своих докладах к обычным инженерным техникам я добавляю что-то из глубинных знаний: психологию, теорию вариаций, теорию систем, методы познания мира. Если есть возможность – привожу экспериментальные данные.

Достаточно часто материал проходит рецензию у завсегдатаев клуба имени Френсиса Бэкона https://t.me/FrancisBaconClub . Иногда после этого материал отправляется в корзину. Но чаще на доработку. Таким образом получается сделать доклад интереснее.

Пример чеклистов для тестирования ссылочной целостности

Март 12, 2020

db-int.xls

Очередной древний документ. Сейчас смотрю на него – вполне годен. Буду рекомендовать на тренинге по тестдизайну.

Данный вид тестирования относится к тестированию «белого» ящика. Нужно иметь доступ к базе данных. Вид тестирования сложный. Рекомендую давать такую задачу «сеньору», имеющему смежную специальность. Крайне желательно, владение SQL и базовыми знаниями о проектировании баз данных. Знание первых трех нормальных форм и формы Бойса-Кодда приветствуются.

Этот вид тестирования в частности отвечает на такие вопросы как:

  • Что будет с задачами, если в Jira удалить проект? А как надо? А я думаю, что если есть задачи, то удалять проект нельзя, это так или нет? Ответь мне аналитик.
  • Что будет с задачами, если удалить Эпик? А как надо? А я думаю, что если есть задачи, то при удалении эпика у задач должна сбрасываться ссылка на эпик, это так или нет? Ответь мне аналитик.

Крайне нетривиальная штука. И что самое обидное, такие вещи мало кто продумывает при написании спецификации требований к системе. Если что техника  юзкейсов вам в помощь.
По опыту тестирования новых систем (не настройки уже существующих движков). На сотню проведенных тестов может находиться 50+ ошибок. И 20+ ошибок крайне неприятные. Уровень «Critical». Так что это еще одна техника тестдизайна, позволяющая отловить кучу дефектов.

PS. В книге Lee Copeland этой техники тестдизайна нет.
PSS. Excel более, чем подходит для ведения чеклистов. Есть некая проблема с организацией совместного доступа, но часто Excel сильно удобней того же зефира.

Дети диаграммы Ганта

Февраль 20, 2020

Начал писать короткие эссе. Пока в фейсбуке https://www.facebook.com/sergey.a.martynenko

Если что-то из этого выйдет (хоть четыре дюжины) - соберу в сборник. Посмотрим.

Да, это коллективное творчество.Идея - Вера Данилова.
Присылайте свои мысли - вставлю в сборник.

Пример тестовых наборов (testsuite)

Февраль 17, 2020

sample-test-suite.zip

Рылся недавно в архивах. Обнаружил интересный документ.
Давно это было. Из литературы в магазине только Канер, https://software-testing.ru/ - еще полгода не исполнилось. Конференций по тестированию нет, тренингов нет, литературы нет, спросить некого.
Пришлось изобретать свой подход к ведению тестовых сценариев. Он опирался на технику юзкейсов и на ГОСТ 34.603. Техника оказалась очень неплохой, и я до сих пор часто использую такую технику записи. Вдруг кому поможет.

Документ я почти не редактировал. Убрал некоторую информацию о фирме и сотрудниках (обфускация данных) и кое где ошибки поправил.

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

Проект не отношу к классу больших. Это проект среднего размера. Данный документ описывает тесты всего одного модуля.

PS. Для разнообразия посчитайте, сколько было описано тестов. И сколько нужно времени чтобы все тоже самое написать в зефире, тестрейле или ситечке.

PSS. Нет, я все-таки поклонник Word и Excel для крохотных, маленьких и средних проектов для ведения чеклистов, сценариев и тестовых наборов. А специализированные средства управления тестовыми наборами оставим для энтерпрайза, где число тестов измеряется сотнями тысяч.

Какая главная ошибка менеджера?

Январь 21, 2020

Тоже с тренинга.

Можете выбрать для себя “правильный” вариант. Мне кажется, список - это хорошая отправная точка.

Это все отличные гипотезы.
На основании них крайне интересно построить дерево текущей реальности.

Да, три гипотезы это об одном и том же. И есть еще пара об одном и том же. Найдете?
—————————————–

  • Думает о том, как сделать правильно, но не думает о деньгах
  • Неоднозначное толкование одной и той же сущности разными субъектами (как частный случай неумения общаться
  • Недостаточная пессимистичность
  • использование одного мнения сотрудника
  • неумение отличать общую и особую причины вариации
  • Неумение отличать общую ошибку вариации от частной
  • Непонимание цели бизнеса. (Голдратт)
  • Думает, что может все контролировать и всем управлять.
  • Ошибка - стремление выполнять действия, которые подтверждают теорию, а не опровергают ее.
  • Не учитывают индивидуальные способности людей
  • неспособность работать с ожиданиями
  • Не планировать
  • вмешательство в рабочий процесс когда это не требуется
  • не работать с рисками
  • Отсутствие использования глубинных знаний и опыта экспериментов

Знакомтесь, вариация

Январь 21, 2020

На тренинге по контрольным картам Шухарта попросил участников сделать простое упражнение. Написать заголовок для ошибки. У яндекса довольно много навязчивой рекламы. В частности сделать яндекс стартовой. Проблема у этого предложения - от него невозможность отказаться навсегда. Есть два выбора “сделать” и “не сейчас”. А где “никогда”? Можно спорить, ошибка / не ошибка. Для упражнения это неважно. Упражнение выполняли просто. Все пишут в чате телеграма и по команде одновременно отправляют.
ya.PNG

И вот результат….

Возможно, все написали правильный заголовок.
Настоящая проблема в том, что все написали по разному.
Эта проблема мало кем осознается, но это ОЧЕНЬ серьезная проблема, которую очень легко решить. Легко, но долго.

Читать дальше »