#рабочее

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

осторожно много букофффф



Отчеты - это всегда сложно, отчеты - это головная боль любого сотрудника, неважно, кто он - просто тестировщик или начальник над всеми тестировщиками. И даже если вы привыкли писать ежедневные отчеты о проделанной работе, а также регулярно высылать дорогим менеджерам багрепорты и отчеты по тестированию по билдам - то регулярные недельные отчеты - это все равно ваша головная боль, которую никто не отменял.
Прежде всего, развеем миф о том, что сотрудника надо мотивировать писать какие бы то ни было отчеты - ничего подобного, ЧЕПУХА. Никого мотивировать не надо. Отчетность - это один из видов обязанностей сотрудника на работе, как и поиск собственно багов, их описание, проверка и так далее..

Зачем нужны отчеты

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

Кому они нужны

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

Что туда писать

Прежде всего туда надо писать статистику. Жестокие цифры, поделенные по колонкам, посчитанные, вымученные цифры. Не надо туда мне рисовать графики - графики в радужных цветах для кастомера я нарисую сама, еще и розового слоника туда присобачу. Мне нужны очень честные и, самое главное, ПРАВДИВЫЕ цифры. Не надо беречь мою психику, подрисовывая, подкрашивая статистику, поверьте, правда - вылезет и хуже будет только вам. Я сама буду сочинять сказки для кастомеров - почему цифры такие плачевные - ваша обязанность информировать о цифрах безжалостно правдиво.
Какие же цифры туда писать?
Прежде всего сколько билдов команда разработчиков выдала вам на тестирование (в том числе принятых на тестирование, реджекнтутых по причине непрохождения санити, кривых рук разработчиков, которые неправильно чота там скомпилили, а потом подправили) - все надо считать. Даже на кривой билд вы тратите время, за которое получаете деньги. Считать надо все
Далее.. по билдам надо распределить циферки по всем перечисленным выше параметрам - выдано, принято, отменено, закончено тестирование… и так далее в зависимости от процедуры тестирования принятой на проекте.
Далее. Обычно очень интересует количество багов обработанных за неделю. Значит цифры следующие: количество новых багов добавленных а багтрекинг систему, количество проверенных и закрытых багов, можно еще добавить количество переоткрытых багов (чтоб разработчикам за безделье по лбу треснули, а у начальства сложилось мнение что вы - бедняжки только и делаете, что переоткрываете баги и страдаете…). Можно предоставить распределение багов в зависимости от важности (столько-то критических, столько-то мажорных и так далее)
По билдам можно эти цифры не распределять. У каждого грамотного тестменеджера ведется статистика по билдам, которая хранится в общедоступном месте и всегда может быть предоставлена прожект менеджеру (актуальная статистика). И эта статистика не есть часть виклирепорта.
Несколько слов можно добавить собственного мнения о билдах, которые были выданы на этой неделе - например - пойдет такое: «скорость запуска сервера заметно уменьшается по сравнения с прошлой неделей. Считаю нужным поработать над перфоменсом, начиная со следующей недели, чтобы оценить количественные показатели.. » ну или, что-нить подобное.
Можно (читать НУЖНО) отдельно выделить разделы по различным видам тестирования - функциональном, ГУИ и Производительности - по каждому написать свое резюме небольшое - пару предложений. Например о том, что вы на этой неделе написали 4 замечательных скрипта по нагрузке на сервер, поэтому функиональное тестирование позаброшено немного было + обоснование, почему на этой неделе вы уделили время именно производительности.
Далее самое веселое. Вы информируете прожект менеджера о тех событиях в команде, о которых ему необходимо знать (вы считаете нужным рассказать) - Петя уходит, Вася выпендривается, Вова вообще забил - это ваша команда - маленькое государство - и если вы считаете нужным сообщить о чем-то - викли репорт - лучшее место не только для пожаловаться но и для похвалить - вот, наш драгоценный Ваня выдал нам столько багов - отлично работал на этой неделе. А Маше надо дать премию, Жене новый монитор, Павлику пендаля…
Кто уходит в отпуск, кто болел и так далее…
Если необходимы тренинги, дополнительное время на изучение и ознакомление с проектом - тоже следует подобные вещи обозначить именно тут - какие именно тренинги нужны с обоснованием - почему они и почему именно сейчас.

Как писать викли репорты

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

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

Что в отчеты не писать. Никогда и низачто

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

И, САМОЕ ГЛАВНОЕ, запомните. Никакой отчет не должен быть больше ОДНОЙ страницы машинописного теста, ибо с возрастанием количества букв уменьшается вероятность того, что отчет ваш будет дочитан.
Краткость - сестра таланта. Учитесь выражать свои мысли кратко и четко