Процесс с нуля. Первые шажки 2: Планирование и Знания

В первой части своих же первых шажков я упомянул о двух стратегических направлениях новичка-тестировщика: взаимоотношениях и тестовой лаборатории. Сегодня я бы хотел коснутся планирования работ и знаний.

То, сколько я знаю о проекте всегда сильно влияет на мою оценку трудоемкости. Причем наблюдается тенденция, когда зная больше - я больше и закладываюсь на тестирование. Впору придумывать теорию расширяющего знания тестировщика ))).

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

УЧЕТ РАБОТ И ПЛАНИРОВАНИЕ

Я не умею давать оценку на работы которые еще не делал. Слышал и читал про техники, но не могу себя заставить поверить в них. Стыдно. Бью себя по щекам.

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

Самоучет помогает и понять и показать производительность, а возможно и вскрыть узкие места новичка, предугадывая вопросы типа: а-что-ты-такого-делал-вчера-что-ничего-не-успел?

УЧЕТ РАБОТ

Понять как учитывать время

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

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

В последнее время появилась такая полочка, как планирование/принятие решений. Но для новичка тестировщика эта полочка не так важна.

Все полочки я как скупой рыцарь собираю в https://www.toggl.com/

и затем раскладываю по Jira-м. В дальнейшем я могу собирать статистику по релизам и проектам.

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

Собрав данные за период можно начинать подумать и о сущем зле, которое проносят с собой в проекты тестировщики - проектных метриках.

МЕТРИКИ

Lesson 198. There’s nothing more dangerous than a vice-president with statistics

Lesson Learned in Software Testing

Во первых, мое глубокое ИМХО - считать лучше чем не считать вообще.

Во вторых - я малодушно делю метрики на те, что нужны мне и те что мне не нужны... те, которые хочет получать руководство. 

В третьих приходится собирать метрики даже те, что не нужны лично мне.

Се-ля-ви.

Собирать свои метрики
Первая группа метрик, которые мне малодушному нужны на первых порах (а потом и на вторых и на третьих) - это отношение различных полочек=категорий к категории "тестирование". Под тестированием я здесь имею ввиду прогон тестов, только - прогон и ничего большего.

Коммуникация/тестирование

Настройка тестовой лаборатории/тестирование

Документирование/тестирование


Исследование/тестирование


Ретестирование/тестирование

Все эти метрики должны - должны стремиться к нулю. 

Спорный тезис. 

Аргументирую.

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

Время затраченное на вспомогательные активности стремятся к нулю в тех случаях, когда растет опыт команды.

Отдельно о таких активностях как исследование и ретестирование.

Исследование - неотъемлемая часть работы тестировщика. Как правило, чем дольше работаешь над отдельной областью - тем меньше тратиться время на исследование. Есть исключения - появление новой, совсем новой функциональности приводит к всплескам и росту исследований (что не плохо бы тоже сохранить как метрику сложности).

Ретестирование - повторное тестирование, как правило - перепроверка баг фиксов. Чем меньше ретестирование, тем лучше разработка... или хуже тестирование - каждый выбирает свой ошибочный путь интерпретации метрик ;).

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

Узнать кому какие метрики нужны 

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

В любом случае их метрики позволяют им чувствовать себя ... комфортнее что ли.

Если начальник чувствует себя комфортнее работая с человеком, который вроде бы управляем - что мне мешает ему помочь?

Узнать какие метрики и сделать себе галочку на будущее. Просто галочку - за чем к вам придут в будущем ваши большие и мудрые хозяева начальники.

Кстати, еще один добрый совет:

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

Я вообще в общении с разработчиками полагаюсь на печенье и шоколад (а в последнее время и на алкоголь - мальчики растут)  больше чем на административный ресурс. Печенье и шоколад нельзя динамить занятостью.

ПЛАНИРОВАНИЕ

Планировать - используя статистику итераций
Планирование это целая наука, которая раз за разом доказывает, что планы - ничто.

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

Я уже бил себя по щекам из-за недостатков в образовании планирования для новых проектов, поэтому просто напомню (возможно баян) - планируйте исходя из статистики.

Итерации, наверное самый короткий путь отточить навыки учета времени и планирования. Можно еще назвать - лишение премии и отпуска, но это немного радикально...

Составить календарь отпусков и праздников
Они - бедствие.

Они перечеркивают все планы.

Они нарушают субординацию и мешают превратить весь этот мир в один строгий разлинованный майлстоунами проект-план и имя им легион Праздники, Дни рождения, Отпуски, Тим Билдинги...Пятницы.

Я не самый опытный планировщик работ, но часто вижу одну и туже проблему - мы редко знаем праздники других стран и дни рождения сослуживцев.

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

Тем не менее мы же знаем это - можем подготовиться.

Порой полной неожиданностью являются отпуска коллег (тем более разработчиков) из зарубежья. "Да, кстати - я с понедельника на 3 недели в отпуск....".

Но можно подкинуть идею планирования отпусков менеджеру проекта.

А какие неожиданные пьянки случаются по случаю дней рождений... и в пятницы (ровно потому что это пятницы!)

Календарь нужен.

В праздники и предпраздники люди склонны работать медленнее или не работать вовсе. Это нужно учитывать. Тем более в самом начале.

ДОКУМЕНТАЦИЯ, ПРОБЛЕМНАЯ ОБЛАСТЬ И ЗНАНИЯ

Во-первых вопрос о документации в команде может даже и не стоять. Т.е. - ее может просто не быть вовсе, в том смысле, который вкладывают адепты "идеальных процессов".

Во-вторых люди действительно могут не понимать, зачем им документировать то, что они и так "все" знают (Так и слышиться шепот за спиной: "Ты новичок, тебе нужно, ты и ищи...").

В третьих, доказать им что если они сейчас все опишут, то через год, когда их может в проекте уже не быть... Скользкий, очень скользкий вопрос.

Документация может быть тупо Jirой.

Документация может быть самодокументированным кодом (это отдельная лебединая песня).

Документация может быть вон тем листочком с пунктами на скрам доске.

Она очень многоликая эта документация. Она любит называть себя "гибкой", скрывая что является "бесполезной" и "устаревшей"...

Найти источники знаний (кто-то их еще называет требованиями)

Прежде чем ругать проектную информацию, стоит ее найти.

Источники информации для новичка команды - те же самые, что и для "старичков" . Их на самом деле не так уж и много:

• Пользователи,
• Команда разработки,
• Тест сценарии, Тест планы, Тест Стратегии, Тест-прочие-названия-документации
• Спецификации,
• Баг трекинг/Таск трекинг системы,

Я недавно писал про то тестировщиков, журналистику и интервью. Может быть кому нибудь поможет развить навыки брать интервью. Писал, но понимаю:

Невозможно одной статьей научить работать с людьми.

Также невозможно одной статьей научить читать и понимать тест сценарии и спецификации.

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

Поэтому предлагаю учиться на своих ошибках. Раз в день пробегаться по списку и тратить энное количество времени на поиски и чтение, анализ, обдумывание - любой другой глагол, который пусть небольшим, но твердым шажком приближает нас к черте "зрелых" или "старичков" (прям дедовщину какую то  развел).

Сохранять информацию

Сохранить информацию для себя и поколений - задача как раз для новичка.

Часто приходится наблюдать, как новый специалист, продираясь сквозь забытые способы получения паролей, установки системы с нуля на отдельно взятом компьютере, собирает и затем бездумно теряет с трудом собранную информацию.И новый тестировщик начинает свой собственный путь Сантьяго.

Я обычно начинаю собирать информацию и складывать на вики. Страница так и называется QA Newcomer Checklist. Кто будет против такой странички? Я же делаю это для себя! Никто не будет против. Но потом, очень многие приходят ее почитать.

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

Не зацикливаться на документации (практиковаться и общаться чаще чем читать)

Информации будет много.

Мусора много.

Будет много того, что придется выкинуть и забыть.

Единственный способ соотносить информацию и правду - практиковаться. 


Практика вообще единственный способ перестать ходить первыми шажками.