Wiki как информационный гарант безопасности

История одного Ф1.

Начну с небольшого жизненного случая.

В проекте разрабатывается функционал средней тяжести Ф1. Изначально приоритет был ниже плинтуса , ровно потому, что бизнес сказал: "Можно не торопиться". 

Вас, привлекли в середине первого цикла тестирования (тогда вы еще не знали, что он первый) и стали вторым тестировщиком. Первый цикл закончился тем, что фича Ф1 вернулась в доработку фиксить баги.

Между тестированием фичи Ф2 и Ф3 вы (поскольку первый тестировщик переключен на другие проекты) решаете, что у вас достаточно времени протестировать Ф1 еще раз (разработка рапортует об успешном исправлении ошибок). Этот цикл заканчивает нахождением регрессионных багов.

Для следующего цикла вы обучаете третьего тестировщика и менторите его. Опять регрессионные ошибки.

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

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

У вас осталось 30 минут, чтобы написать письмо с ответом.

В идеальном мире вы конечно же держите руку на пульсе и каждую из Н-цать фич знаете, как свои пять пальцев. В идеальном мире вся документация и все письма и все общение заносится в Jira/Mantis/BugZilla/выбери свою систему. В идеальном мире менеджер общается с бизнесом не раз в месяц, а постоянно. В идеальном мире менеджер не делает вид, что ничего не понимает,  и решает организационные проблемы команды сам. В идеальном мире нет багов, а слово "тестировщик" нарицательное.

Но мы с вами здесь и сейчас. И у нас осталось 29 минут.

У меня случился вышеописанный кейс. Было тяжело решать задачу, но поучительно. Во времена ахтунга начальство задает вопросы, которые действительно их раньше не интересовали. Почему? Ответ может варьироваться от "я вам доверял", до "ну вы же профессионалы в своем деле, вы должны понимать, что делаете". С последним не поспоришь никак. Можно начать кидаться фразами "а мы вам говорили", "а мы вас предупреждали", "мы то профессионалы, а вот...". Но ни к чему хорошему это не приведет.

Что делать? Нужно готовиться к встрече со звездами! Как? Поделюсь своим рецептом.

Wiki карточка функционала

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

Description: Здесь будет ваше краткое описание релиза/функции.
Development start date: Дата начала разработки
Development end date: Дата окончания разработки
QA start date: дата начала тестирования
QA end date: дата окончания тестирования
Release Date:  дата, когда релиз/функция стала доступна бизнесу
Release Testing Estimation Plan History: ссылка на отдельную страницу с оценкой трудоемкости

и ссылки на Jira/Sharepoint

RELEASE LINKS

1. SHAREPOINT
Release Main Folder: Точка входа в главный каталог релиза/функции
Kick-off meeting: Результаты kick-off митинга (устраивается перед выдачей в тестирование)

Test Plan Folder: Каталог, где распологается тест план (могут быть разные версии документа)

Daily Status Report Folder: Каталог для ежедневыных отчетов

Functional Results Folder:  Каталог для test evidence по функциональному тестированию

Regression Results Folder: Каталог для test evidence по регрессионному тестированию
Performance Results Folder: Каталог для test evidence по тестированию производительности

Sign-off: Каталог, где лежит официальное подтверждение, что тестировщики работу закончили и "разрешают" релизить функционал.
Lesson Learned: Если проводилась ретроспектива релиза, то результаты искать здесь
Metrics: Если функция большая, то собираем стандартные метрики и выкладываем.
2.JIRA:
Release Filter: Фильтр со всеми изменениями.
Organization Jira: Во время тестирования тестировщики могут решать организационные проблемы (коммуникация, исследование). Все время затрачееное на эту активность вносилось в эту джиру.

Regression  Jira: Джира с описанием регрессионных тестов и времени, которое на эту активность потрачено.
QA Procedure implementation jira: Тестировщики могли тратить время на активности не связанные с релизом, но для поддержания тестирования в проекте (грубо говоря "чтобы еще такого внедрить, чтобы все ахнули, а качество стало лучше?"). Время и активности можно найти в этой джире.

Envrionment Downtime Jira: Какие проблемы были
Envrionment Showstopper Jira: Как проблемы повлияли на работу команды тестирования
3.DEVELOPMENT INFO:
Release Notes: Здесь ссылка на страницу команды разработки. Обычно указывается какой номер билда, какой функционал, какие технические (не функциональные) изменения и пр.

Данная страница решала проблему быстрого перехода на нужную точку входа. Также мы хранили там контакты релиза, конфигурацию тестовой лаборатории, ссылки на базу знаний и пр. пр. пр. Чего там не было, так это истории организационных проблем.

Правило 4W

Я уже упоминал про ежедневный отчет начальству. Отчасти он должен немного прикрыть ваши мягкие места, но когда у вас в тестировании несколько направлений то у вас, соответственно и несколько отчетов. Воссоздать историю организационных изменений о прошедших 3 месяцах за оставшиеся 25 минут уже сложновато. Поэтому у нас появилась таблица 4W:

1.What was changed?

А что вообще случилось необычного, что нужно описать? 

Разработчики во время не предоставили билд? - подходит. 

Менеджер решил передвинуть сроки или приоритеты? - подходит.

У вас отобрали тестировщика? - подходит

Тестирование остановилось, потому что нет информации от менеджера? - ПОДХОДИТ!

2.Why was changed?

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

3.Who changed?

Кто владелец изменения: команда тестирования, команда разработки, бизнес, менеджер.

4.When was changed?

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

Заведите себе правило 4W если вас это действительно касается. Краткая информация может вам помочь. Более развернутая инфа может легко быть перенаправлена. Причем эта таблица для организационных проблем. Я уже упоминал про проблемы с тестовым окружением и как мы ими управляем.

Выводы

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

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

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

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