Процесс с нуля. Первые шажки 3: Отчетность и Визибилити

Прошло 9 месяцев со дня публикации первых шажков и - 8 месяцев со дня вторых. Причина по которой третьи шажки так долго готовились - сама тема.

Нет более неблагодарной работы, чем подготовка отчетов и постоянное подтверждение, что ты тот самый, в то самое время, на том самом месте.

Трудности перевода

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

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

Целая тетрадь.

Записная книжка отзаборовдообедов.

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


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

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

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

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

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

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

Процесс с нуля. Первые шажки - 1: Взаимоотношения и Тестовая лаборатория

За последние 2 года мне удалось "поосваивать" - в хорошем смысле слова - несколько разных по сложности о составу команды проектов. Каждый проект уникальный. А задачи с созданием группы тестирования - вроде бы одни и те же...

Новый проект. Новые люди. Новые традиции и новые горизонты в тестировании.

Знакомиться с новыми людьми.

Изучить новый продукт.

Построить свою работу с нуля.

Как не утонуть в новом хаосе?

Я бы хотел сегодня покопаться в этой нелегкой куче.

Работа над ошибками: Почему мы не согласны с менеджером.

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

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

Одним из таких вопросов стал "Если вы не согласны с менеджером, как бы вы поступили?".

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

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

Подумаем?

Кто виноват?

Кто виноват в том, что баг пропустили?

Риторический вопрос.


Наверное разработчики, потому что они баг посадили.


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


А может быть менеджер? - он су..а, времени не дал, чтобы нормально запрограммировать , а потом протестировать.


Мы забыли пользователей. Коя ляд им понадобилась эта функция. И требования(!), требования - не дали. Мы потратили кучу времени на согласование!!!

Связанные одной цепью: кто должен отслеживать состояние бага?

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

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