пятница, 8 августа 2014 г.

Я везде беру с собой ...Test plan! Даже на kick-off meeting



"Добрый день мы собрались на kick-off meeting  для того, чтоб обсудить старт нового проекта и дальнейшие шаги..."

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

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

Мой Тест-план для kick-off meeting
По горизонтали
A-План действий; 
B- Приоритеты (1 min-3max); 
C-Стратегия выполнения (частичная декомпозиция);
D-Оценки трудозатрат; 
E-Ответственный за выполнение;
F-Риски при невыполнении
G-Статус-Pass/Fail

 По вертикали 1,2,3...

"Скелет" готов, осталось поразмышлять и заполнить.  Цель- в колонке Статус (G-Статус-Pass/Fail-не поместилась) поставить Pass. 

№1 Порядок тестирования на проекте
ABCDEF
1Определить порядок тестирования3Сделать все нижеперечисленные пункты на PASSТест-менеджерСрыв сроков и процесса


№2 Документация
ABCDEF
2
Определение документации которую предоставляет тестировщик на разных этапах проекта
1Перечислить всю документацию,которую может предоставить отдел тестирования и выбрать конкретно для этого проекта.
Все высказываются. Утверждает тест-менеджер
-неправильные ожидания от процесса тестирования;
-низкое качество документации;
-низкие процент покрытия функционала тест-кейсами;
Checklist 10 часов
Test-cases40 часов
Bug-report20 min\bug
Test plan10 часов 


№3 Жизненный цикл бага
ABCDEF
3Жизненный цикл бага на проекте2Определить и настроить в Jira worckflow (может настраиваться отдельно для каждого проекта)3 часа для настройки и тестированияТестировщик предлагает worckflow бага- для Jira-не будет понимания как движется баг, кому его отправлять.
Worckflow-это часть коммуникаций


№4 Роли
ABCDEF
4Распределяем роли.
Выбор тестировщика для проектной команды
3- определяем руководителя проекта, тестировщика и.т.д.
-определяем возможности коммуникаций
-оцениваем по навыкам наиболее компетентного и подходящего для этого проекта
Все высказываются.
Утверждаем 
один раз
-не собрана проектная команда;
-срыв процесса;


№5 Устройства
ABCDEF
5Утверждаем устройства для тестирования3Сверить список устройств, заявленных на проекте с устройствами, которые есть в наличии (сформировать дозапрос)1 час для подготовки дозапросаТест-менеджер-предлагает, CTO- утверждает-затраты времени на адаптацию проекта под неучтенные устройства ранее (время developer и tester)


№6 Риски
ABCDEF
6Риски3- просчитать все возможные риски относительно тестирования;
-включить "человеческие" риски;
-приоритезировать риски;
На исправление рисковТест-менеджер-учтены не все риски;
-необходимо,обновлять список рисков в процессе проекта;

№7 Формат занесения бага
ABCDEF
7
Утвердить формат занесения бага
3- озвучить шаблонный формат для компании;
Тест-менеджер
-не будет понимания и прозрачности процесса;
- нарушены коммуникации;
3-по необходимости настроить Jira , добавить нужные поля (lables, fix version)1 час для настройки

№8 Ожидания от тестирования

И для подведения итогов вашего общения с командой обсудите ожидания от тестирования.
-какая документация необходима от тестировщиков, например, на этапе code freeze?
-какого качества ожидается продукт?
-при каком процентном соотношении critical и major мы будем релизиться?

... и.т.д

Риски:
-продукт недостаточного качества;
-затраты на тестирования не впишутся в бюджет;
-некорректное взаимодействие отдела тестирования с маркетингом, разработкой, управленческим составом



Такие штуки действуют как превентивная мера к рискам, их надо вести google табличкой с общим доступом, чтоб каждый член команды мог зайти и посмотреть,чего не хватает!


вторник, 28 января 2014 г.

...извечные проблемы в обеспечении качества

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


1. Нет понимания целей и задач тестирования, ни у тестировщика  ни со стороны заказчика (product owner). "Выдайте продукт без багов"; "Все должно работать", и.т.д
А в природе, наверное, не существует продуктов без багов, так почему бы просто не уточнить, при каком количестве мажоров-миноров мы готовы давать ОК на выпуск?
Хватит абстракции, ставьте четкие цели и задачи.
Отсюда вытекают проблемы 2 и 4.


2. Недостаток прозрачности процессов в отделе тестирования. Никто не знает, что делает тестировщик: Что делает? Вон "сидит в углу и тапает".
А тестировщик по-умолчанию знает продукт лучше всех, владеет десятками видами тестирования, тест-дизайном, аналитикой; основами менеджмента, программирования, unity, 3d; освоил всевозможные стандарты, вроде "Human Interface Guidelines"... разве мало?


3. Катастрофическая нехватка коммуникаций и зацикленность на тестировании
Надо развивать не только навыки тестирования, но и навыки построения процессов. Чтобы понимать, что твориться  с точки зрения программистов, меркетологов, дизайнеров и.т.д
Давайте уже настроим коммуникации между отделами! Давайте выделять сумарно 2 часа в неделю и собираться на daily stand-up, ретроспективы и давайте на них все буду приходить (да, и дизайнеры тоже!)

                          

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

4. Нет привлечения на ранних стадиях:
 -Ребята, завтра релиз, мы уже решили и договорились с заказчиками.
-Так мы же не успеем протестировать?
-Да что там тестировать!
...Остается тестировать в те сроки, которые утвердили без Вас, и объяснять, что качество при этом будет плохое.

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


Давайте стремиться к идеалу!

1. Повысьте прозрачность работы всех отделов и всех должностей! Чтобы полностью было понимание жизненного цикла проекта. Кто за что отвечает и какими вопросами "заведует". Донесите эту идею до коллег, затем покажите пример на отделе QA.

2. Покажите эффективность работы отдела тестирования! Для этого неплохо освоить метрики.
Вот например, статья Натальи Руколь "Полезные метрики для оценки проектов" http://habrahabr.ru/post/141671/

3. Затачиваем ум, если не хотите всю жизнь быть "обезьянкой"- надо эволюционировать.
По поводу эволюции тестировщиков, есть статья в блоге Алексея Лупана http://testitquickly.com "Почему тестировщиков всегда будет мало".
-семинары, встречи с профессионалами;
-конференции http://www.sqadays.com/
-тренинги http://www.software-testing.ru/trainings/schedule
-школы http://www.software-testing.ru/trainings/schedule?&task=3&cid=32
Вложите в голову 300-400$ в год-это совсем немного.

Действуйте, развивайтесь, результаты не заставят себя ждать!