Я выступила с докладом о методе xBTM на конференции STARWest 2011. В зале присутствовал Джон Бах, который дал нам ряд полезных рекомендаций.

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

Тест-план

Я начала с создания ментальной карты, которая служила мне тест-планом. Я предпочитаю XMind для этих целей. Вначале я создала новую карту и сделала наше приложение – SBTExecute – центральной темой. Несколько минут я размышляла над очевидными подразделами для этой темы и придумала следующие:

• Конфигурация
• Документация
• Запуск
• Импорт
• Генерация
• Отчетность.

Я добавила шесть этих подразделов на карту, после чего решила добавить стресс-тестирование:

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

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

Тестирование

Я начала с функции импорта, так как она ключевая для приложения. Если информация из отчетов о сессиях не импортируется – можно дальше не проверять. Я оценила цепочки в разделе «импорт» как укладывающиеся в сессию длиной в 45 минут. Чтобы отметить это в плане, я поменяла цвет всех этих цепочек на синий:

Тестирование всех цепочек раздела «Импорт» в течение одной сессии

Отчеты о сессиях я пишу в шаблоне SBTExecute для Excel, и использую функционал ментальной карты, чтобы привязать отчетность к плану тестирования. Иконка желтого листочка у раздела «Импорт» показывает, что для раздела есть заметка, которую можно просмотреть и отредактировать по клику на иконке:

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

Я начала сессию тестирования, делая в процессе пометки в отчете. Как только я понимала, что тестирование какой-либо цепочки можно завершать, я добавляла зеленую иконку «проверено» на ментальную карту. Во время сессии я поняла, что не хочу тестировать цепочку «Неверные данные», так как валидация данных встроена в шаблон Excel. Я поставила эту цепочку на паузу, чтобы вернуться к ней позднее, если останется время. На ментальной карте появилась соответствующая иконка и комментарии, почему работа над цепочкой была приостановлена:

Цепочка «Неверные данные» поставлена на паузу.

Затем я вспомнила, что не расставила приоритеты для областей тестирования. Приоритет я выставила при помощи разноцветных цифр, где 1 – наивысший, а 6 – низший приоритет:

Расстановка приоритетов.

Как оказалось, инструмент работает только с файлами в xslx-формате, и не может читать старые xls-файлы. Я точно не знала, баг это или фича, поэтому пометила цепочку вопросительным знаком и оставила к ней заметку.

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

Я завершила сессию, но так как меня разбирало любопытство по поводу читаемого формата файлов, вместо новой сессии я решила взглянуть на область «Конфигурация». Несколько минут я провела, создавая отчеты о сессиях в версиях Office 97-2003 и Open Office, и пытаясь загрузить их в систему. Эти цепочки тестировались именно как цепочки, а не в рамках сессии. Я потратила на них всего несколько минут, так как это была область низкого приоритета, написала к ним короткую заметку, поставила цепочки на паузу, чтобы вернуться к ним позже. Если бы я вернулась к ним (чего я в результате не сделала), я бы продолжила делать заметки в специальном окошке:

Краткое тестирование двух цепочек и установка их на паузу.

Далее я решила протестировать все цепочки в области «Генерация» в рамках сессии, по аналогии с областью «Импорт»:

Тестирование всех цепочек раздела «Генерация» в рамках сессии.

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

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

Завершив сессию «Генерация», я углубилась в раздел «Отчетность». По моим прикидкам, подразделы «Итерационные отчеты» и «Сводные отчеты» были достаточно крупными, чтобы объединить их в сессионное тестирование.

Тестирование двух цепочек в рамках сессии.

Проведя три сессии и протестировав две цепочки по отдельности, я привела свою ментальную карту к следующему виду:

Статус тестирования после трех сессий и раздельного тестирования двух цепочек.

Документация к приложению состоит из трех учебников, и я тестировала их как цепочки. На этом моменте у меня уже практически не оставалось времени, поэтому я просто бегло пролистала их. Я использовала частично закрашенные квадратные иконки, чтобы продемонстрировать, как далеко я продвинулась в тестировании каждого документа, и я оставляла краткие заметки. Отчет о сессии я не оформляла, так как тестировала их как цепочки. Последние несколько минут я потратила на запуск приложения с различными параметрами, что тоже проверялось как цепочка, так как на сессию уже не хватало времени.

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

Отчет о тестировании

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

Отчет о тестировании

У меня также были на руках три отчета о сессиях (Импорт, Генерация, Отчетность) и список дефектов.

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

Запись Метод XBTM — применение на практике впервые появилась Портал TMGuru.

«Я много говорил о том, как мотивировать других людей, но ничего из того, что я говорил, не помогало. Поэтому сегодня я расскажу о том, как демотивировать:

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

9. Никогда не объясняй логику своих решений. Вспомни своих родителей: «Потому что я так сказал!». Тут это тоже работает.

8. Назначай сотрудникам бессмысленные задачи. Самое важное в работе — выглядеть чем-то занятым, хотя бы и какой-то бессмысленной фигней.

7. Даже если задача сделана великолепно — критикуй! Добудь себе большой красный маркер и подчеркивай им все подряд. Не фокусируйся на содержимом или на главной идее — обращай внимание на строение предложений и раздражающих лично тебя словах.

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

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

4. Пропускай все мимо ушей. Главное — заставить людей думать, что ты слушаешь! Поэтому смотри им в глаза, кивай в знак согласия и думай о своем.

3. Отказывайся рассматривать любые способы работать эффективнее. Инструменты? Нам не нужны инструменты, у нас нет на это денег! Обучение? У нас был оплачен целый курс пять лет назад, вы что, забыли?

2. Воспринимай свою команду как набор механизмов, которые никогда не должны ломаться. Заболел? Он что, забыл о презентации, которую должен был сделать?

1. Никогда, ни при каких обстоятельствах никого не хвали и не признавай чужих заслуг! Иначе люди начнут чувствовать себя счастливыми. Помни — если ты не хвалишь людей, тебе даже не надо их оскорблять: ты просто их игнорируешь, и они увольняются. После этого ты сможешь нанять новых людей и демотивировать их!»

Оригинальное видео: Ten Proven Ways to De-motivate Your Team

Запись 10 способов демотивировать свою команду тестирования впервые появилась Портал TMGuru.

Цель этого документа — дать добрые советы любому начинающему руководителю группы.Руководитель группы это не человек, который заполняет планы. Руководитель группы — это лидер коллектива, который может привести коллектив к вершине, а может увлечь в пропасть.В документе собраны советы, которые покрывают наиболее ключевые области работы руководителя. Это советы не теоретиков, это советы практиков.Прочитайте этот документ, проникнетесь им и попробуйте следовать этим советам. Это не просто, но это стоит делать.

Содержание

• Работа с людьми
• Ответственности
• Оценки трудоемкости
• Переработки
• Планы и отчетность
• Добрые советы, по организации рабочего процесса
• Резюме

Работа с людьми

Вам подчиняются люди. Качество их работы во многом зависит от качества Вашей работы. Иными словами Вы непосредственно влияете на благополучие сотрудников в компании.

Вы отвечаете за работу каждого вашего подчиненного. Если человек дает плохое качество и Вы об этом узнаете от кого-то — это Ваша вина.

Например. Разработчик отчитывается о сделанном функционале, и Руководитель группы разработки (ЛидДев) заявляет функционал в тестирование. Если после этого тестировщик говорит, что все не по дизайну или половина дизайна не сделана — виноват ЛидДев.

Делайте ревью того, что делают Ваши подчиненные.

Вы можете аргументировано затребовать снятия человека с проекта (направления) — примеры тому были — но если Вы продолжаете работать с человеком и не ставите Руководителя проектов (PM) в известность о проблемах, то это Ваши проблемы. Для PM это значит, что Вы готовы помочь человеку и это:

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

Иными словами, если Вы покрываете человека, и PM не в курсе, то аргументы типа «я тут и так зашиваюсь, а меня еще спрашивают по моим задачам» или «давайте я все брошу и буду делать то, что обещал(ла)» не проходят.

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

Информируйте PM-а о проблемах в команде, информируйте даже о решенных проблемах.

Каждую минуту рабочего дня Вы обязаны знать, чем занят каждый Ваш подчиненный и когда он закончит поставленные задачи. Для этого не обязательно его дергать ежеминутно, достаточно понимать, когда он закончит и на протяжении срока выполнения уточнять укладывается ли сотрудник в сроки, и нет ли проблем. Иногда проще созвониться, иногда подойти… как оптимальнее — пробуйте, подбирайте…

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

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

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

• Не умереть от загруженности
• Вовлечь в процесс других сотрудников и обучать их
• Сплотить команду

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

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

Помните про разницу во времени между офисами.

Помните, про то, что все люди разные — Вы как руководитель обязаны научиться работать с человеком. Понять, КАК ему лучше ставить задачи, КАК его оптимальнее мотивировать на работу, КАК ему говорить об ошибках. Поймите, Вы можете сильно травмировать человека неосторожным словом… Вы можете часами объяснять человеку что-то и он никогда Вас не поймет, если Вы будете говорить непонятным для него языком и приводить несущественные для него доводы. Если Вы не найдете общий язык с человеком, Вы не сможете с ним оптимально работать. Причем подстраиваться зачастую должен не только он, но и Вы. Помните, про национальные различия. Хороший руководитель обязан знать основные национальные черты и особенности подчиненного.

Помимо работы с подчиненными Вы обязаны тесно работать со своим коллегой (2-м лидом). Для лидQA неприемлемо не знать дат ближайших билдов… для ЛидDEV неприемлемо не знать дат окончания основных этапов тестирования. ЛидDEV обязан делать ревью тестплана, ЛидQA — ревью дизайнов. За качество конечного продукта отвечают оба лида. Перед тем как говорить, что сроки двигаются из-за того, что тестировщики слишком поздно находить начали баги, подумайте, может девелопмент давал настолько сырые билды, что QA затратили на тестинг и багретест больше времени, чем планировалось? Перед тем как говорить, что сроки двигаются из-за того, разработчики все в последний момент правят, подумайте, может это QA тестирует дольше, чем планировалось?

Всегда помните, если Вы не сдержали обещания, и план поехал — это автоматом нарушает планы Вашего коллеги и ставит его обещания под угрозу. Не подводите друг друга

Ответственности

Под чем Вы подписываетесь, и что это значит:

• Заявка в тестирование — форма, которой ЛидДев подписывается под выполненной разработчиками работой
• Отчет по заявке — форма, которой ЛидQA подписывается под качеством проверенного билда
• Пройденный Тест план — подпись ЛидQA под качеством проверенных частей системы
• Дата окончания тех или иных работ — подпись лида под обязательством сделать что-то в оглашенное время

Любая неправильно поставленная подпись свидетельствует о том, что Вы плохо сделали работу. Бывали случаи, когда людей увольняли за подобные ошибки (к вопросу о серьезности).

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

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

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

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

Лиды обязаны своевременно отвечать на письма заказчика. Ни одно письмо не должно остаться без ответа. Если ответ не готов, то обязательно надо отписать, что ответ не готов, будет готов тогда-то. Если письмо касается Вашего проекта, но Вы не собираетесь на него отвечать, то обязательно скажите об этом PM. Если у Вас нет времени прочитать/ответить на письмо, обязательно пишите об этом PM.

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

Если Вы пишете о проблеме или готовите вопрос, письмо всегда должно содержать:

• Вводную информацию — поймите, это Вы занимаетесь проблемой, и заказчик вообще не в курсе того, о чем Вы пишите и почему Вы это делаете
• Описание проблемы/вопроса
• Варианты решения с указанием плюсов и минусов и влияния на проект
• Рекомендации

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

Оценки трудоемкости

Вы отвечаете за оценки трудоемкости, которые даете. Не зависимо от того, кто оценивал — Вы или Ваш подчиненный. Не всегда возможно дать четкую оценку, но в этом случае, PM должен видеть оговорку, что оценка неточная и причину, по которой более точную оценку дать было нельзя. Если Вы даете  оценку, без каких либо оговорок, РМ считает ее окончательной и дальнейшие отговорки типа «ну я же быстрее оценить хотел (ла) и не успел (ла) все проверить» или «всегда есть риск» не проходят.

Вы не должны подгонять оценки под желания заказчика или PM. Если задача делается за 5 дней, а через 4 дня доставка — это не Ваша проблема. На основании информации от Вас PM принимает решение, как поступить. PM может принять решение делать за 4 дня но только если он:

• Договорился с Вами о переработке или
• Согласовал с Вами, как можно урезать задачу или
• Предлагает Вам помощь

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

Всякий раз, когда Вы оцениваете ту или иную задачу, Вы оцениваете наилучшее ее исполнение. Если Вы идете на компромиссы и это может отразится на качестве, Вы обязаны согласовать это с PM. Отговорки типа «я хотел (ла) сделать как можно быстрее, время было мало, поэтому получилось плохо» не проходят, если PM не был предупрежден.

Оценки всегда должны даваться из расчета 8-ми часового рабочего дня.

Вы обязаны уметь аргументировано защищать каждую данную Вами или Вашим подчиненным оценку. Если защитить не готовы — должна стоять соответствующая пометка, чтобы PM знал об этом. Зачастую, если PM спрашивает почему эта задача занимает 5 дней, а не 3 — это не «наезд» и не недоверие — это желание разобраться и убедиться в том, что Лид все продумал. Если в ответ на это следует ответ — «ну можно и за 3» или «ну мне кажется, что за 4 не успеем, а за 5 скорее всего успеем», то это большой красный флаг, что Лид дал оценку с потолка.

При работе над оценками Вы должны углубиться в вопрос настолько, насколько это требуется для выдачи наиболее точной оценки. Иногда PM может потребовать оценки АСАП, в этом случае лид должен оговориться, что оценки не точные, если не успел досконально вникнуть в вопрос и по возможности дать вероятный разброс.

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

У каждого лида есть таск leadership. По опыту других проектов — это 10% от всего девелопмента. Но эта оценка может и должна меняться, если того требует специфика проекта или команды.

В leadership входит:

• митинги с руководством и подчиненными
• общение с заказчиком
• ревью работы подчиненных
• подготовка оценок на дополнительные работы
• обсуждение спорных вопросов с руководством и подчиненными
• постановка задач подчиненным
• планирование задач подчиненных
• ведение проектной документации
• сбор отчетности и проставление оценок
• подготовка статус репортов

Переработки

Переработки возможны в следующих случаях:

• PM попросил переработать — будет компенсировано либо отгулом, либо доп. оплатой (переработка в выходной обычно х2, в рабочий день х1.5)

Переработка не компенсируется, если сотрудник не выполнил свои обязательства

• Сотрудник вправе отказаться от переработки, если она не вызвана его ошибками.Подвела команда (например, тестировщики затянули хождение TP, поздно нашли баги и в результате, разработчикам приходится фиксить баги в очень высоком темпе, что часто приводит к переработкам. ИЛИ. Разработчики дали билд позже, чем планировалось и его надо тестить АСАП, что тоже часто приводит к переработкам). В подобных случаях вопрос о компенсации рассматривается отдельно. Вы должны помнить, что работаете в команде, и любые ваши ошибки отражаются на других членах команды и наоборот. Если доставка заказчику не будет сделано по плану, то наказаны будут оба лида, независимо от того, кто сделал ошибку. Поэтому не стесняйтесь требовать со своего коллеги выполнения обязательств в тех фазах, где вы пересекаетесь.
• Сотрудник стремится развиваться и старается сделать больше, лучше — в случае удачи компенсируется повышением ЗП, продвижением по служебной лестнице, желанием PM и других пойти на встречу в случае сложностей.
• Сотрудник отрабатывает отгул

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

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

Планы и отчетность

Планы должны строиться каждую неделю без напоминаний до 19-00 пятницы. Каждый лид планирует своих подчиненных. Если не ясно или есть сомнения, кто кому в данный момент подчиняется (бывает такое, когда человек у двух лидов или только что перешел от одного к другому) Вы обязаны уточнить это у PM.

Еженедельные статусы по проектам не должны писаться наспех

Еженедельные статусы  должны отражать все, что происходило на проекте за неделю + освещать открытые риски и вопросы.

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

Cотрудники проектной команды обязаны присылать ежедневные отчеты и делать это в конце рабочего дня (а не утром следующего). Лид отвечает за то, чтобы отчеты приходили от всех его подчиненных ежедневно. Если отчеты не приходят в течении 2-3-х дней, для PM это значит, что лид плохо делает свою работу.

План всегда должен отражать реальное положение дел. Не фантазируйте, сами же потом запутаетесь. Не допускается иметь в плане закомпличенными задачи типа bugfixing, bugretest, customer support и т.д.

Все, что можно детализировать в проектном плане, должно быть детализировано

Все, что можно спланировать в проектном плане, должно быть спланировано на максимально возможный срок

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

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

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

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

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

Добрые советы, по организации рабочего процесса

1. Всегда ведите список своих задач на ближайшее время. Удобно выписывать их на лист бумаги вначале дня и вычеркивать по мере выполнения. Это позволит правильно расставить приоритеты и наглядно покажет, что еще предстоит сделать.
2. Научите Ваших подчиненных уважать Ваше время, общение с ними не должно занимать Вас на 100%. Если Вы чувствуете, что общение с кем-то занимает очень много времени, проанализируйте, как строится общение, и попытайтесь его оптимизировать. Иначе управляя 10 подчиненными, Вы только и будете успевать, что на вопросы отвечать. НО! Недостатка в общении быть не должно. Общение должно быть оптимальным.
3. Планируйте все, что можно спланировать. Ставьте себе дедлайны по своим таскам и соблюдайте их.
4. Возьмите за правило регистрировать ключевые моменты, произошедшие за неделю, как в ходе проекта, так и в управлении командой — это поможет Вам при составлении недельного отчета и оценке ребят за неделю.
5. Вот ключевые моменты дня:
   • Начало дня
   • Ревью почты и определение писем, требующих вашего ответа
   • Ревью списка оставшихся задач, составление задач на день
   • Оценка задач и определение приоритетов и последовательности выполнения (оставляйте время на непредвиденные задачи, сколько? смотрите по опыту на проекте).
   • Работа по задачам, апдейт списка задач
   • Прочтение дейли репортов от подчиненных, коррекция их действий, если надо
   • Ревью списка задач
   • Конец дня
6. Не доводите до того, что у Вашего подчиненного осталось задач меньше, чем на день. Если человек во что-то уперся, и у Вас нет возможности ему быстро ответить, у него должен быть список работ, на которые переключиться, иначе Вам придется всем отвечать АСАП.
7. Ставьте себе дедлайн по уходу работы и стремитесь в него вписаться, выполнив все запланированное… частые переработки и работа ночами быстро истощает.
8. Не давайте команде вести Вас, Вы должны вести команду.
9. Старайтесь всегда иметь запас до дедлайна, никогда не планируйте и не работайте впритык. Всегда добавляйте время на непредвиденные ситуации.
10. Старайтесь поддерживать хорошие отношения с подчиненными и коллегами по команде. Бывает, что мы работаем в стрессовой обстановке — в такой ситуации ни в коем случае нельзя ожесточаться и идти напролом. Учитесь слушать и понимать своих коллег. Помните, в VDI в основном работают умные и грамотные люди и если человек поступает определенным образом, значит, у него есть на то причины и их надо понимать и уважать, даже, если человек ошибается.
11. Не стесняйтесь общения с PM — PM и 2 лида — это тройка, которая тащит на себе весь проект, если между ними нет согласованности и единых целей, то это будет лебедь, рак и щука…
12. При планировании бейте задачи как можно мельче — помните хороший план, это больше половины успеха.
13. Не берите на себя то, за что не можете ответить.
14. Избегайте предположений, старайтесь иметь близкую к 100% уверенность в правильности своих решений.
15. Периодически поднимайте голову и смотрите на то, как организован Ваш день, все ли Вас устраивает в процессе работы, не копится ли у Вас негатива, что хорошо, что плохо. Думайте, как улучшить процессы. Не стесняйтесь советоваться с PM. Старайтесь не доводить до того, что PM делает вам замечание. А если делает, то подумайте, почему?

Резюме

• На лиде ответственность за людей, которые ему подчиняются
• На лиде ответственность за то, что делает его команда
• Хороший лид не боится говорить правду
• Хороший лид умеет аргументировано отстаивать свое мнение
• Хороший лид всегда контролирует ситуацию и имеет представление о ходе проекта в целом
• Хороший лид немного психолог, немного воспитатель, немного учитель и всегда надежная опора, как для PM так и для подчиненных и коллег
• Хороший лид умеет организовывать свой день и работу своих подчиненных, так, чтобы успевать делать все запланированное
• Хороший лид всегда развивается, анализируя свои ошибки и успехи
• Без хороших лидов успешный проект невозможен.

Запись Памятка Руководителю группы впервые появилась Портал TMGuru.

Представляю перевод статьи Джеймса Виттакера «Если вы стали QA менеджером«. Оригинальному тексту почти год, я прочла его первый раз как раз, когда сама оказалась на месте героя поста. За это время у меня появились комментарии к мнению Джеймса, поэтому, можно сказать, что мы соавторы получившейся статьи.

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

Начните жить своим продуктом!

Джеймс:
Итак, вы оказались новым QA менеджером. Первое, что вам нужно сделать, это начать жить своим продуктов, загореться им.

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

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

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

К примеру, я сейчас живу без лаптопа и использую в своей повседневной работе только Chrome OS Netbook. Так как люди видят меня с ним в коридорах, мне доводится произносить рекламные спичи по многу раз каждый день. Великолепная практика, скажу я вам! Мне же доводится жить и с огрехами, и записывать штуки, которые ещё надо доделывать. Это хворост для пламени спора между разработчиками и другими стейкхолдерами, и это тоже заставляет меня взвешивать конкурирующие продукты. Когда у меня не получается сделать что-нибудь, что мне нужно, на моем Chrome OS Netbook и я вынужден использовать конкурирующий продукт, это порождает здоровую дискуссию о том, как пользователи воспринимают недостатки наших продуктов, и о том, как мы можем правильно преподнести плюсы и минусы нашего продукта потребителям.

И это прекрасный путь для начинания нового продукта, кстати ;-)

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

Побудьте пользователем других продуктов вашей компании, чтобы понять, как они относятся к вашей продукции. Чего им не хватает: внимания, скорости, скидок? Что они не могут сделать с продуктами вашей компании, и как компания реагирует на это?

Поняв, как это происходит на уровне всей компании, гораздо легче понять, как это работает для для вашего продукта. Вы поймете, кто в команде идет in-line с компанией, а чьи цели лежат в другой плоскости. Вы поймете, кто на вашей стороне (а вы ведь – именно тот человек, который хочет сделать ваш продукт лучше для пользователя и успешнее для компании, правда же?), а кого нужно ещё переманивать. На кого-то можно махнуть рукой, а кто-то просто мешает работе над продуктом. Это шанс улучшить ситуацию. Потому что вы — новый человек со свежим взглядом, и во-вторых – потому что тестирование – это фильтр.

Вы, как тест-менеджер всегда будете аккумулятором информации от менеджера, разработчиков, аналитиков и пользователей. Именно на вас сходится много дорог, и именно вы говорите менеджеру: «Эй, мы сделали классную штуку, этим ребятам понравится! К тому же, она не падает под тестами вот уже вторую итерацию», и именно вы приносите ему вести, рискуя цельностью головы: «Ты знаешь, вот эта новая фича не может выйти на стабильность вот уже 2 недели, постоянно ломает почтовую рассылку. Надо больше времени на отладку, давай не будем включать в релиз».

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

Фокусируйтесь на тест-плане, сделайте это высшим приоритетом

Джеймс:
Если вы заняли уже существующую роль тест-менеджера в уже существующем продукте, есть вероятность, что тест-план уже тоже существует и что этот тест-план неактуален. Я не наезжаю на вашего предшественника, я просто искренен. Большинство тест-планов являются «временными» документами.

Объясню, что я имею ввиду под этим.

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

Тестировщики очень любят жаловаться на это: «Как мы можем тестировать продукт без полного описания того, что он делает?»

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

Тест-план стал в точности, как спецификация: Документ-Который-Был.

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

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

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

Если вы делаете его для того, чтобы потешить свое чувство сертифицированного тест-менеджера – будьте честными в этом признаться. Хотя бы себе.

Джеймс:
И вот вы – новый тест-менеджер, сделайте исправления этих документов вашей первоочередной задачей. Вы узнаете функциональность вашего продукта, и вы увидите пробелы в текущей структуре тестов, которые нужно закрывать. Плюс к тому, у вас будет почва для разговора с менеджерами разработки, и вы сможете показать им, что вы серьезно относитесь к качеству. Менеджеры разработки в Гугле любят хорошие тест-планы, это дает им понимание того, чем вы занимаетесь.

Разберитесь с процессом и приоритетами релиза

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

Юля:
Будьте всегда готовы ответить себе, команде и инвесторам, почему этот баг встретился 20 процентам пользователей и породил тысячи петиций. Почему вы не наняли ещё троих тестировщиков, чтобы протестировать тщательно все области, а не только самые приоритетные? Почему вы держите именно такой баланс между знанием о качестве и затратами на его контроль? Почему вы в последний момент кинули все силы на эту область, хотя в недельной давности тест-плане она шла вторым приоритетом?

Главное, чтоб вы четко понимали это сами.

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

Я обнаружил, что в Гугле увеличение фокуса команды на мануальном тестировании искренне приветствовалось командой разработчиков. Найдите комфортную зону вашей команды разработки и удерживайте баланс между тем, чтобы всё-таки правильно тестировать, и тем, чтобы сделать финальные часы (дни) как можно безболезненнее.

Тестируйте ваш процесс тестирования

Джеймс:
Начните с чтения каждого теста-кейса и просмотра всей информации. Можно ли привязать эти тесты к тест-плану? Сколько тестов у вас есть на один компонент? А на фичу? Если баг находится за пределами процесса тестирования, создаете ли вы на него тест-кейс? Есть ли у вас процесс исправления или выбрасывания испорченных или неактуальных тест-кейсов?

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

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

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

Ищите пути для инноваций

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

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

Юля:
Очень важно выдерживать баланс между «так у нас принято» и «я знаю, как сделать лучше». Когда вы приходите в новой роли в новую команду, у вас есть огромный плюс и страшное оружие: «свежий взгляд». Если его применять правильно – вы взорвете тестирование на проекте (в хорошем смысле). Будьте готовы столкнуться с «это не заработает, потому что…», «мы это пробовали, это фигня…», «да ну , бред какой-то, лучше делать по-старому…». Жизненно важно отличать реальные причины того, почему здесь делается именно так, от пустых отговорок, за которыми люди скрывают привычку и нежелание двигаться.

Если вы возьмете правильный опыт этой команды и дадите ему новое дыхание – будет бомба!

Джеймс:
Нет совета, который мне показался бы универсально применимым касательно «Как лучше внедрять новшества». Что работает для меня – так это найти звезд в своей команде и убедиться, что они работают над тем же, чем горят. Как менеджер, это одна самая важная штука, которую вы можете сделать, чтобы повысить продуктивность и внедрить новшество.

Юля:
Так что — дерзайте! И удачи вам.

Запись Если вы стали QA-менеджером впервые появилась Портал TMGuru.

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

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

1. Взаимоотношения с командой и пользователями
2. Тестовая лаборатория
3. Учет работ и планирование
4. Документация и База знаний
5. Визибилити и Отчетность

Обозвать шагами — не поворачивается клавиатура. Каждый шажок из одного направления должен включать шажок в другое — и вот таким осминожком нужно двигаться, чтобы успеть везде.Заметка получается громадная (не знаю откуда у меня появляется такое стремление к гигантомании), поэтому разделил на две (а может и на три — будет видно куда приведет психоанализ).Сегодня поговорим про взаимоотношения и тестовую лабораторию. Мой опыт. Мои евристики.

ВЗАИМООТНОШЕНИЯ С КОМАНДОЙ И ПОЛЬЗОВАТЕЛЯМИ

КАК ЖИВЕТЕ?

Первый вопрос команде

Знаете, какой мой первый вопрос к новой команде?Ни о технологиях, ни о практиках, ни о хотелках менеджеров этот вопрос. И кстати, я его никогда не произношу, никому не задаю, но «подразумеваю» постоянно.Главное, что я хочу понять с самого первого шага в проекте:

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

Первые вопросы команды

Вы может быть удивитесь, но

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

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

Спроси чего ждут от тебя начальники и команда — договорись что будешь делать в первую очередь, пусть это не будет нежданчиком для тебя и для них.

У меня в календаре стоят даты, когда я набираюсь смелости и задаю в лоб менеджерам вопросы
- вам хорошо, от того что делают тестировщики?
- вы довольны достигнутыми результатами?
- что еще могут сделать тестировщики?
- когда вы хотите это иметьА потом смотрю на список и произношу:
- … ммм…да… а теперь, когда мы все поняли, что хотим очень многого — давайте расставим приоритеты что ли…Понять чего хочет «начальника» поможет не наступить на мозоль или грабли. В первом случае можно сделать неприятно кому-то, а во втором случае — заработать шишку себе. Шишка — не орден — гордиться нечем ;).

Делиться опасениями, рисками и проблемами
Очень может статься, что о проблемах, с которыми вы сталкиваетесь знают только вы и ваша семья.На совещании промолчал, дома — наорал на жену.

На работе, в отличии от семьи есть две крайности:

- Ну ты же ничего не говорил.

и

- Ну тебя же взяли, чтобы ты проблемы решал, а не рассказывал о них.

Когда то меня подобные ответы заставляли выпучивать глаза и глотать ртом воздух: они что ничего не видели?

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

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

Хотя всегда могут найтись излишне инициативные сослуживцы и начальники…и ведь лесом их не пошлешь…

КОМАНДА — МОЙ КРУГ… МОЙ ПЕРВЫЙ КРУГ… ВТОРОЙ… ТРЕТИЙ…

Знакомиться активно

Быть новичком это и выгодно и невыгодно одновременно. Выгодно, поскольку у нет еще груза ошибок, невыгодно — также нет и авторитета полезных решений. Но ни в одной команде не бывает так, что все против — всегда найдется человек, который может стать первым кругом.Построить первый, второй и прочие круги общения — одна из первых главных задач новичкаПозже вы будете складировать людей в свои круги, но сперва попытайтесь найти среди этих сильных личностей тех… кто любит печеньки )))). Нет честно — ни одна команда разработчиков так и не устояла перед анекдотами, историями из жизни и печеньками. Программисты как дети, ей богу!

Запоминать новых людей

 

Как опытный новичок советую вам с первого дня создать страницу в вашей локальной вики и описывать в ней людей, с которыми вы общаетесь. Конечно, когда ваша команда локальна и не превышает 10 человек, можно обойтись без крайностей.В текущем новом проекте, за три месяца мне уже пришлось общаться кроме своей команды (15 человек в 6 странах) еще с 7-ю специалистами из 5 параллельных проектов. Из 23-х специалистов три месяца назад я знал только двоих.  С 6-ю я общался всего один раз. Без записи — как вспомнить имя Rohit Gnapnadesh и, что именно он отвечает за Emma сервисы на UAT?


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

Быть дураком не стыдно. Стыдно продолбать баг на 300 килоевро из за своей скромности.

КТО ТАКОЙ КОНЕЧНЫЙ ПОЛЬЗОВАТЕЛЬ?

Познакомиться с пользователями

Еще жив в моей памяти проект, в котором мы не знали своих пользователей. Вернее не знали всех пользователей. А их были десятки… К тому времени как сменилось две команды разработки, 3 ITPM-а, несколько вендоров, и, наконец, пришел я — остался список из 7 проектов, которым мы и предоставляем услуги передачи и обработки данных. Про проблемы остальных мы узнавали, только когда релизили новую версию продукта. Узнавали весьма с печальными последствиями.Это конечно редкий случай, но каждый раз, когда я появляюсь в проекте я хочу знать, кто использует нашу программу и как он ее использует.Только зная как конечный пользователь использует программу — я понимаю как действительно работает программа и как ее нужно тестировать, а также  — как она не используется и как ее тестировать не нужно. Определяются риски и уменьшается объем тестирования. Уменьшается объем тестирования! Нет даже так УМЕНЬШАЕТСЯ ОБЪЕМ ТЕСТИРОВАНИЯ!!!

Найти способ собирать жалобы пользователей

Я сразу пытаюсь присосаться к любому каналу связи, где пользователи жалуются. Нет ничего полезнее, чем крик души от пользователя. Желательно, чтобы этот канал был единственным и широким — там должны быть все.В этом похожи все сервисы — и продажа товаров, и туристические туры и разработка ПО:Жалобы пользователей формируют стратегию улучшения качества продукта, потому что о качестве продукта правду могут сказать только те, кто его используют, кто зарабатывает или теряет деньги используя продукт.


Жалобы пользователей это не тот случай, когда молчание — золото ;)

ТЕСТОВАЯ ЛАБОРАТОРИЯ

ГДЕ ТЕСТИРОВАТЬ?

Разработчик может сказать: «У меня баг не воспроизводится… Будем закрывать?»


Тест менеджер может спросить: «Нашел проблему?…А как работало раньше — в предыдущей версии?»

Проект менеджер может поинтересоваться: «А насколько данные в тестовой лаборатории близки к тем, что на проде?»


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

Отказаться от «не воспроизводится»

Разные данные, разные способы установки/запуска приложений, разные наборы компонент — все это очень сильно влияет на конечный результат.Если в системе может быть разным вообще все — утверждать, что тестировщик в описании бага не упомянул главные детали конфигурации не совсем честно. Кстати, сохранять целиком конфигурацию — тоже не всегда возможно (объем данных, архитектура компонент и т.п  и т.д)
Не каждый разработчик (к сожалению — и не каждый тестировщик тоже) понимает, что нужно одна точка входа для тестировщиков, разработчиков, пользователей и других заинтересованных в проверке лицСлова «у меня не воспроизводятся» — стоят дорого. От их причин нужно избавляться. Моя первая задача в этом случае выбить себе тестовую лабораторию.Вторая задача выбить тестовую лабораторию для программистов.Третья задача  — сделать их похожими.Понимать как работало раньше — в предыдущих версиях

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

Игра «давайте сделаем одну тестовую лабораторию» нередко проходит с крайностями:Раньше и без этого обходились — т.е. и за баранку с бубликом нам этого не нужноДавайте сделаем все как на проде — т.е. не важно сколько времени нам понадобиться, не важно что мы пока не знаем что именно нужно, но не начнем тестировать, пока не будет все прям как на проде. И сердце — нам в руку и данко — во главе тест группы.И вот такие бальные танцы бегемотиков между двумя полярными мнениями порой и называют стратегией развития отдельно взятой тестовой лаборатории … хех.Цена и риски — это два основных существительных в споре.
Тестер:Будет лучше?
Менеджер: Да
Тестер: Сколько мы потратим на это времени или денег?
Менеджер: Нужно тратить деньги и время?Все работы связанные с тестовой лабораторией нужно свести к минимиму

Легко и быстро установить с нуля

Легко и быстро переустановить

Легко и быстро настроить

Легко и быстро скопироватьЛегко и быстро перегрузитьЛегко и быстро получить сообщения об ошибкахЛегко и быстро прочитать логи

Легко и быстро понять — какой релиз кандидат установлен…

Тратить на поддержку тестовой лаборатории мало, ибо есть много других вещей, которые нужно сделать.

ОТ КОГО БЕРЕМ, КУДА ОТДАЕМ

Построить карту приложения

Первый, второй, третий круги бывают не только у людей. Они есть и у приложений тоже.Представьте себе схему метро.Кольцевая это ваш проект.Все что вне — приложения с которыми обмениваемся данными.Первая станция — это первое приложение, вторая это приложение, которое общается с первым приложением, третье…очередное….последнее известное. Примерно так выглядят приложения в банках. И порой черт ногу сломит, чтобы узнать откуда  к нам приходят данные и куда уходят. И — кто на этом заработает ;)Поиск зависимостей, upstream|downstream приложений — еще один важный вопрос. Ибо это практически то же самое, что искать и разговаривать с клиентом.Понять — можно ли использовать псевдозаменители приложений

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

Псевдозаменители, симуляторы, заглушки — одно из дешевых решений.

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

Оригинальная публикация

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

Представьте, что Вы покупаете телевизор. Продавец рассказывает о двух понравившихся Вам моделях. В первой модели он рассказывает о качестве картинки, куче возможных для сохранения каналов и удобном пульте. По второму телевизору он учит Вас, за какую антенну надо подёргать, если вдруг теряется связь, и что делать при помехах. Какой телевизор Вы выберете? Конечно, Вам хочется просто сидеть на диване и переключать каналы, и Вы не горите желанием всё время что-то поправлять! Менеджмент чем-то похож на покупку телевизора. Вы либо строите эффективный процесс, при котором Вам остаётся лишь любоваться качественной картинкой – либо Вы всё время заняты мелкими оперативными задачами, которые по сути сводятся к решению проблем. Как купить качественный телевизор в тест-менеджменте? 10 основных правил успеха Вы найдёте в этой статье.

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

2. Учитесь делегировать. Микроменеджмент, свойственный начинающим руководителям, у многих входит в привычку – в итоге, Вы не даёте развиваться своей команде, а сами всё время заняты мелочами. Поэтому, старайтесь регулярно повышать сложность и комплексность задач: так Вы будете мотивировать и развивать свою команду. И ни в коем случае не попадайтесь в ловушку «никто это не сделает лучше меня». Присмотритесь к своим сотрудникам!

3. Внедрите эффективный тест-дизайн. Если у Вас гибкие процессы с исследовательским или сессионным тестированием, то Вам будет достаточно высококлассной карты функционала, к примеру, распечатанной на большом листе ватмана и повешенной на стене. В более формальных подходах Вам потребуются тест-кейсы, при использовании которых требования к тест-дизайну ещё выше: оптимизация проверок, сокращение трудозатрат, прозрачная отчётность… Инвестируйте в продуманный и грамотный тест-дизайн, и эффективность работы Вашей команды выйдет на новый уровень!

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

5. Внедрите регулярный сбор метрик качества Вашего продукта. Вы всегда можете сказать «кажется, всё работает», но для предсказуемости процесса и возможности принятия правильного решения о выпуске продукта значительно лучшим будет использование более конкретных метрик. Количество и сложность метрик будут зависеть от проекта, но автоматический сбор является, пожалуй, универсальным требованием – иначе это слишком быстро Вам надоест, и хорошая, казалось бы, привычка будет загублена на корню.

6. Определите стратегические цели тестирования. «Если звёзды зажигают – значит, это кому-то нужно». Выявите миссию своей звезды – зачем нужно тестирование на Вашем проекте? Поставьте на основании этого конкретные стратегические цели. Это поможет не сбиваться с намеченного курса и принимать взвешенные решения.

7. Регулярно оценивайте результативность тестирования. Как бы нам этого ни хотелось, совершенный процесс практически недостижим, но мы можем регулярно исследовать результативность тестирования для улучшения текущих показателей. Внедрите регулярную оценку эффективности, используя метрики, связанные с Вашими целями тестирования. Таким образом, Вы будете находить «слабые зоны», которые необходимо «подтягивать» — к примеру, качество заведения дефектов, время на тестирование одной сборки или процент пропущенных ошибок. Помимо обнаружения проблем, Вы так же сможете видеть и положительный прогресс – что, несомненно, не может не радовать

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

9. Наладьте коммуникации с разработчиками. Обеспечьте одинаковое понимание Ваших общих целей. Узнайте у разработчикам, что им нужно и чего не хватает: к примеру, вполне возможно, что у них есть требования к дефектам, о которых Вы не задумывались, но которые существенно облегчат их жизнь. Не стесняйтесь взамен требовать то, чего не хватает Вам: регулярность сборок, информацию о внесённых изменениях… Общайтесь чаще и конструктивнее: от этого в выигрыше будут как все участники по отдельности, так и проект в целом.

10. Внедрите контроль рисков качества. Учёт рисков качества позволит сделать Ваш тест-дизайн более эффективным, а качество продукта более предсказуемым. Вы можете использовать риски качества в качестве основного инструмента тест-анализа или в качестве дополнительно способа формирования тестов. Но при любом из подходов Вам необходимо довести его до конца – «частичного» контроля рисков быть не может.

Вышеописанные 10 советов – это минимальный базис, необходимый Вам для того, чтобы удобно сесть на диван с пультом и любоваться высоким качеством картинки. Не жалейте своё время на внедрение этих нововведений и не ждите, что теория без практики принесут свои плоды. Ниже я приведу список ссылок на источники информации по большинству из перечисленных тем:

Командная работа (Формирование команды, делегирование, коммуникации):

· Бестселлер института Гэллопа: «Сначала надо нарушить все правила»

· Мой тренинг «Управление командой тестировщиков»

Тест-дизайн и риски качества:

· Lee Copeland: «A Practitioner’s Guide to Software Test Design» – это Библия тест-дизайна. Несмотря на отсутствие перевода, её чтения является строго обязательным!

· Мой тренинг «Тест-дизайн для менеджеров»

· Тренинг Алексея Баранцева «Тест-дизайн от А до Я»

Планирование, стратегические цели тестирования, метрики:

· Рекс Блэк: «Ключевые процессы тестирования»

· Школа Тест-Менеджеров

Пожалуйста, если у Вас есть дополнения к списку (книги и тренинги, которые Вам нравятся и которые Вы можете порекомендовать) – дополняйте!

И главное – внедряйте, радуйтесь результатами и гордитесь собой! И о результатах сообщайте – интересно же!

Запись 10 вещей, которые должен сделать любой уважающий себя тест-менеджер впервые появилась Портал TMGuru.

Наш мир – беговая дорожка. Если Вы стоите – значит, Вы движетесь назад. Преобладающая часть современных программ не запустится на компьютерах десятилетней давности. Знания в ИТ-сфере устаревают в среднем за 5-10 лет. Современные избалованные пользователи уже не будут использовать программы и сайты, не удовлетворяющие основным требованиям юзабилити. Если Вы хотите не отставать и даже готовы увеличить скорость – придётся постараться! В этой статье мы разберём следующие вопросы:

• Как определить, насколько успешен и результативен Ваш процесс тестирования?
• Как диагностировать проблемы и определить требуемые улучшения?
• Как принять решение о внедрении изменений?
• Как развиваться и развивать своих сотрудников?

Готовы? Тогда вперёд!

Зачем Вы тестируете?

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

Забудьте обо всём, что «принято» и «сложилось». Зачем тестирование нужно Вашей команде и Вашему проекту? Что действительно важно Вашей компании – экономия, скорость, качество? Если Вы этого не знаете – Вы работаете вслепую, руководствуясь чувством здравого смысла – которое, к сожалению, у каждого своё. Не пытайтесь додумывать. Спросите! РМ, сейлзы, Ваш непосредственный начальник, топ-менеджмент. Заставьте их задуматься и узнайте ответ сами.

Цель и средства

Хорошо, мы узнали, зачем нам тестирование… Но какие конкретные цели? Вы всё ещё думаете, что тест-дизайн, автоматизация и количество найденных багов как-то отражают эффективность тестирования? Тогда мы идём к Вам!

Представьте, что Вы заходите в магазин и хотите купить макароны. Что Вас интересует при выборе? Вкус? Цена? Натуральность? Калорийность? Что-то ещё? Но Вас абсолютно не интересует, на какой модели оборудования они готовятся и в пакеты какого производителя они упаковываются!

То же самое и в тестировании. Есть цели, а есть – средства. К примеру, если ошибки в сборке находятся сразу после выпуска, их проще исправить. Соответственно, находя ошибки раньше, Вы можете сократить затраты на разработку. Это – Ваша цель: сокращение времени на регрессионное тестирование новой сборки. Какое средство Вы выберите? Автоматизацию? Адаптацию тест-дизайна под ускоренную проверку? Обучение сотрудников? Что бы Вы не выбрали для реализации, это будут средства!

Почему так важно не путать цели и средства? Я часто вижу усиленные попытки внедрения автоматизации там, где она вообще «невнедрябельна». Я неоднократно видела тест-дизайн, состоящий из пяти, семи тысяч тест-кейзов, на который была потрачена масса времени и который не используется, потому что просто не нужен. Причина таких ошибок – в подмене понятий цели и средства. Если Вы не хотите допускать такие же ошибки – почаще спрашивайте себя: «Зачем?». Зачем автоматизация? Зачем измерять покрытие кода? Зачем внедрять новые метрики? Если ответ на этот вопрос ведёт Вас к целям тестирования в Вашей компании – значит, Вы на верном пути. Если нет – не тратьте своё время!

Вы здесь не одни

Тестировщики не смогут самостоятельно выпустить успешный продукт, в то время, как и без тестировщиков его тоже не выпустить. Разработка ПО – это командная слаженная работа, в которой все участники проекта, выполняя свои локальные задачи, решают одну общую задачу. И от слаженности вашей работы зависит общий успех. Достаточно ли хорошо налажены коммуникации в Вашей команде? Знаете ли Вы потребности соседних групп? Знаете ли Вы, что они от Вас ждут и что им не нравится?

Процесс взаимодействия с другими отделами можно отобразить приблизительно так:

Эта схема не претендует на полноту и универсальность (в Вашем проекте может быть что-то по-другому), но отражает основные моменты взаимодействия проектных команд. Поговорите с другими участниками проекта: что им нужно? Всё ли их устраивает? Что бы они хотели улучшить? Не додумывайте за них, поговорите лично. Так Вы не только сможете улучшить свою работу, но и наладите коммуникации с другими сотрудниками.

Как определить, что требует улучшений?

Если Вы готовы не стоять на месте, а двигаться вперёд, то самое время определить план действий. Но как?

1. Поговорить с коллегами из смежных отделов.

Главное – подготовиться к критике и воспринять её максимально конструктивно!

2. Провести Post Mortem.

Собрать отзывы и проанализировать причины всех возникших проблем. Как можно сделать так, чтобы они не повторились в будущем? Профилактика эффективнее лечения! Что было хорошо, что было правильно? Это тоже очень важно не пропустить из виду: именно эти действия нужно культивировать в будущем!

3. Завести Issue/Incident Tracking System.

Вы можете использовать ­­­­Jira, Excel или Notepad. Главное – оперативно заводить в эту систему информацию обо всех коллизиях: пропущенные критичные дефекты, срывы сроков, недовольство начальства. По каждому пункту проводите анализ причин и определяйте превентивные меры на будущее.

4. Сформировав список стратегических целей, спросить себя: «Зачем?»

Помните этот магический вопрос? Отбросьте всё, на что Вы не можете дать убедительного ответа!

5. Привлеките к обсуждению решения задач как можно больше участников.

Таким образом Вы не только получите множество полезных (и не только ) советов, но и заручитесь поддержкой в реализации!

Вы уверены?

Итак, у Вас есть список улучшений. Можно приступать к работе, но… Вы уверены, что Вам это нужно? Вернёмся в магазин к макаронам. Вот они, на полке: красивые, аппетитные, ароматизаторы идентичны натуральным… И цена – 1000$. Вы готовы столько платить за макароны? Из своего кошелька, скорее всего, вряд ли.  Изменения на работе тоже требуют вложений, финансовых и временных. Стоят ли они того? Не можете ли Вы за это время сделать что-то более полезное для Вашего проекта? У Вас никогда не хватит времени и возможностей сделать всё, поэтому надо выбирать наиболее результативные действия. Посчитайте, насколько соотносятся проблема и стоимость её решения. 1000$ за макароны – это много, а 1000$ за новую иномарку – это мало. Сравнивайте проблему и решение, чтобы приоритезировать задачи – только тогда Вы сможете потратить свои ресурсы наиболее эффективным образом.

Вы готовы?

Времена, когда тестирование было второсортной, не требующей особых навыков отраслью, прошли. Monkey testing уступил место контролю качества. Вы готовы? Как Вы оцениваете свои технические, методологические и управленческие навыки? И насколько эти оценки соответствуют реальности?

В опубликованной статье (слегка депрессивной, кхе-кхе ) Алексей Лупан перечисляет возможные пути развития в отрасли: курсы, книги, блоги, статьи… Эти пути хороши и необходимы как для начинающего, так и для «продвинутого» специалиста, но их значимость – ничто по сравнению с опытом реального использования! Даже проработанные на тренинге навыки не заменят опыт внедрения «в боевых условиях». К сожалению, многие люди, приходящие ко мне на тренинги, приходят за знаниями. За теорией, которую они смогут рассказывать на собеседованиях. И которую они не планируют внедрять, учиться использовать, модифицировать, улучшать. Вы правда думаете, что Вас это развивает? Не давайте своим знаниям пылиться, используйте их!

Будьте честны с собой

Основная причина, по которой не производится должных улучшений – неготовность к принятию проблем. На многих своих тренингах я рассказываю про взаимосвязь с другими группами и спрашиваю у учеников, насколько у них зрелый процесс тестирования и насколько довольны смежные группы и клиенты. Все (ВСЕ!) отвечают, что всё хорошо! И только немногие соглашаются опросить коллег. Некоторые из этих людей впоследствии говорят, что их мнение подтвердилось, но в большинстве случаев оказывается, что всё совсем не так, как они думали!

Если Вы готовы двигаться вперёд – то самое время принять критику. Зачастую, признать истинные проблемы значительно сложнее, чем решить их.

Выбирайте: решать проблемы или делать вид, что их нет.

Эволюция бесконечна

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

Запись Управление тестированием: непрерывно совершенствуем процесс! впервые появилась Портал TMGuru.

Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.

Если задать среднестатистическому РМ’у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)

Зачем вообще формулировать какие-то ожидания от тестирования?

Камон! Тестирование — это всякие там нажимания на кнопки, хорошо если автоматизированные. И так понятно, какие цели! Нужно находить баги, и чем больше, тем лучше. Какие ещё могут быть цели у тестирования?

Упс… Если исходить из этого подхода, то во всех компаниях с тестированием всё в порядке. Баги находятся, фиксятся, проверяются… И что, тестирование всегда полезно? Всегда раскрывает весь свой потенциал?

Что-то мне подсказывает, что нет. Тогда в чём отличия между теми редкими случаями, когда «с тестированием всё отлично», и преобладающим большинством?

Попробую привести ещё одну иллюстрацию. Вы никогда в жизни не ходили на массаж. Вы заходите в салон (а что, все ходят, почему бы и вам не сходить?) и заказываете получасовой сеанс. У вас есть фиксированный бюджет и есть требования: «помассируйте меня». Невнятного вида дама невнятно возится с вашими вполне внятными плечами, кайфа никакого, вы выходите из салона и думаете «эх, массаж — фигня полная». Но ведь ваше требование «помассируйте меня» было выполнено! Может быть, дело в некорректности требования? У вас болела спина, и вы хотели, чтобы боль прошла? Или не хватало растяжки? Или хотелось релакса? Чем точнее требования, тем больше у исполнителя шансов их удовлетворить. Но если вы не можете сформулировать, что хотите, то и исполнитель не сможет сделать то, что нужно, и вы не сможете объективно оценить результат.

Какими могут быть ожидания от тестирования?

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

Упс… Простой пример из практики. Команда тестирования своевременно находит дефекты, команда разработки не располагает временем их исправить, продукт неизменным выходит на рынок, клиенты говорят «отстой»… Что, тестирование было плохим?
Или давайте наоборот. Тестировщики тщательно исследуют продукт, используя его и в хвост и в гриву, не находят ни одной ошибки, он выпускается на рынок, пользователи довольны, шапки летят в воздух, цветы отправляются на адрес фирмы-разработчика… Тестировщики молодцы или нет?

В общем примеров можно привести много. Но вывод почти всегда один: тестирование на качество никак не влияет. Так же как ваша стрижка не влияет на вашу успешность. «Эй, парикмахер, постригите меня так, чтобы я сдал экзамен!». Никакой логики, правда? В тестировании то же самое. Тестирование предоставляет информацию, в определённый бюджет, в определённом формате, с определённой скоростью… Но тестирование никак не влияет на качество, даже если очень хочет.

Что же тогда может предоставить тестирование?

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

Давайте сначала рассмотрим эти пункты, а потом перейдём к самим формулам.

1. Тестовое покрытие

Это % возможных пользовательских сценариев, условий, настроек, входных параметров и т.д., который был проверен группой тестирования. Чем выше этот процент, тем больше найдено багов, тем меньше пропущено. Тем больше багов можно исправить при желании и возможности.

При этом, тестовое покрытие и количество тестов, а так же затраченные на тестирование ресурсы, связаны очень косвенно. Квалифицированные тестировщики имеют целый арсенал техник и инструментов, позволяющих «впихнуть невпихуемое», aka оптимизировать тестовый набор, aka обеспечить максимальное покрытие при минимальном количестве тестов.

Покрытие можно и нужно измерять: traceability matrix, code coverage, % пропущенных дефектов и масса других метрик вам в помощь.

2. Предоставляемая информация

Годами живёт мем о тестировщике, с паникой в глазах говорящем «ничего не работает!». А если попросить объяснить подробнее, он отвечает: «ну совсем ничего!». Возможно, он обеспечил хорошее тестовое покрытие, но, увы, адекватную информацию не предоставил. Какая же информация может быть нужна проекту от тестирования?

• Качественно описанные баги в баг-трекере
• Статистическая информация о продукте для прогнозирования релизов и принятия решений по процессам
• Метрики качества для принятия решений о релизах
• Оценка самого тестирования: какое покрытие, что проверено, насколько достаточно тестирование и т.д.

Если группа тестирования не предоставляет внятной информации о продукте и проекте (а это её основная функция!), то принимать решения очень сложно.

3. Скорость тестирования

ОК, покрытие хорошее, информация чёткая… Только поздно. Или долго. Или долго, и поэтому поздно.
Все вы явно сталкивались с ситуацией: до релиза 3 дня, находится критичный баг. Разработчик получает по голове, начинает исправлять, и тут оказывается, что багу этому без недели полгода, и вообще-то его можно было найти значительно раньше. И что этот баг 2 месяца назад был бы исправлен за полчаса, а теперь на него полпродукта завязано, и возиться придётся неделю.

Мало кто берётся анализировать проекты по ТОС, и мало кто замечает, что тестирование иногда удлиняет релизы в несколько раз. Вот замените тестирование на своевременное, и получите релиз в два раза быстрее.

Обычно это незаметно, и кажется, что баги — источник всех бед… А ведь иногда найти их раньше = сократить затраты на весь цикл разработки!

Или другой аспект скорости тестирования: время, требуемое для проверки сборки. К примеру, готовимся к релизу. Получаем RC (релиз кандидат). Тестированию нужна неделя, чтобы убедиться в его работоспособности, РМ соглашается, выделяет неделю, на пятый день находится критичный баг… 10 минут на фикс, и снова 5 дней, и снова на пятый находится критичный баг… Сталкивались? Звучит знакомо?

4. Бюджет

Пожалуй, это самый простой пункт из всех. Естественно, он относителен. 1000 рублей — это много или мало? Для батона хлеба, пожалуй, много, для поездки на Бали, пожалуй, мало. Поэтому бюджет — это те деньги, которые вы готовы платить, но не за «тестирование», а за конкретные и понятные результаты этого самого тестирования.

Ну и что дальше?

А дальше вот что. Чтобы принести проекту максимум пользы, вы должны точно знать, что ему сейчас нужно. Чтобы знать что нужно, вам необходимо анализировать его показатели, что именно за пределами нормы: сроки, качество или бюджет. И уже после этого создавать вашу уникальную формулу с требованиями к тестированию. При этом, будем честны: «сократить сроки» или «увеличить покрытие» — это всё те же «помассируйте меня».

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

Заметьте, я нигде не говорила «юнит-тесты», «автоматизация», «тест-дизайн» и т.д. Все действия вносятся в процесс только по результатам определённых целей! Нужно повысить скорость тестирования сборки? Внедряем автоматизацию. Нужно повысить скорость нахождения дефектов? Модульные тесты. Качество отчётности? Модерацию дефектов. В тестировании сотни подходов, инструментов, решений, которые можно комбинировать исходя из ваших целей. Но сами по себе инструменты вторичны.

Поэтому, КАК тестировщик/тест-менеджер/тест-аутсорсер будет достигать ваши цели — это его головная боль. Но никто лучше внимательного к своему проекту РМ’а не скажет, что этому проекту нужно!

Запись Что менеджер проектов должен знать о тестировании впервые появилась Портал TMGuru.

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

Почему все рано или поздно приходят к необходимости измерений? К каким результатам приводит численная оценка тестировщиков? О вопросах внедрения метрик по оценке тестировщиков рассказывает в своей статье Наталья Руколь, опытный тест-менеджер и ведущая Школы Тест-Менеджеров.

Почему встаёт вопрос о метриках

В один прекрасный день тест-менеджер, или менеджер тест-менеджера, просыпается и говорит: «результаты работы тестировщиков нужно оценивать и измерять». Почему такое происходит, откуда вообще такие мысли?

1. Не хватает чувства контроля за ситуацией.

Кто что делает? Кто достоин повышения? Кому надо сказать «ата-та»? Менеджеры хотят найти способ оценки эффективности работы, чтобы лучше быть в курсе происходящего.

2. Сотрудникам не хватает внимания.

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

3. Сотрудникам требуются измеримые цели для повышения мотивации.

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

4. Невозможно доказать отсутствие проблем.

Разработчики жалуются на дефекты, РМ’ы жалуются на сроки, клиенты жалуются на баги. Тест-менеджер пытается оправдать работу своего отдела, показав, кто чем занят, и какие высокие у них результаты. А для этого результаты сначала нужно измерить!

А теперь давайте внимательно присмотримся к причинам ведения метрик сотрудников. У вас нет лёгкого чувства обмана? «Что-то здесь явно не то»! Почему это у нас недостаточно контроля? Почему у сотрудников цели неизмеримы, а внимания недостаточно? Почему мы занимаемся оправданием себя вместо решения проблем?

Истина проста: метрики для оценки сотрудников внедряются в ситуациях, когда у руководства есть проблемы с управлением. Что же происходит дальше?

К чему приводит внедрение метрик

Отлично, у нас появились метрики. Это может быть 1-2 значения, а могут быть полноценные KPI. Каков стандартный результат от таких нововведений?

1. Трата времени

Для сбора метрик необходимо расширять используемые инструменты, вводить новые поля, собирать новые данные, обрабатывать их, структурировать. Это неизбежная трата времени и тест-менеджером, и сотрудниками. Эта трата чаще всего несущественная, допустим 1-2 часа в неделю. Но когда вы тратите несколько процентов рабочего времени на задачи, не повышающие качество продукта и результаты тестирования, неизбежно появляется лёгкая демотивация и чувство неважности основных задач.

2. Демотивация сотрудников

В теории мотивации есть очень чёткое деление мотиваторов и стимулов. У сотрудника может быть мотивация делать всё хорошо просто потому что он хочет этого самого отличного результата, это и есть истинная мотивация. Но как только за результатом появляется «морковка», то результат сам по себе теряет ценность. Я уже не хочу выпускать качественные продукты и приносить пользу команде – я хочу завести не менее 144 дефектов в месяц, чтобы получить квартальную премию. Чувствуете разницу? В результатах работы она будет колоссальной. Сложный баг, непонятно как воспроизвести? У меня нет времени разбираться, я лучше 4 минора заведу, это будет выгоднее! Учитываем % отклонённых дефектов? Побоюсь заводить спорный баг. В итоге вы получите дубликаты, ниже качество дефектов, а потом и споры «нет, это не минор, это мажор, ты не объективен ко мне!» и «так я не 100% был занят на тестировании». То есть и объективность не получена, и демотивация, и конфликты.

3. Снижение качества работы

За счёт демотивации сотрудников и ориентации на циферки вместо истинных результатов вы 100% получите прирост по всем выбранным для измерения показателям, и 100% почувствуете в целом ухудшение работы команды. Но что нам чувства, если есть цифры, они-то объективны!

Сторонники числового измерения результатов работы в этом месте обычно объясняют проблему плохо подобранными метриками, не отображающими действительный результат. И впрямь, если метрики на 100% отображают качество работы, то такой проблемы не будет. Но, к огромному сожалению, в тестировании такие метрики невозможны.На заводе всё просто: сколько деталек в день, какой % брака. В тестировании, при всём желании, определить такие метрики невозможно.

Что делать, как жить?

Я не буду пускаться в долгую полемику на тему метрик, хотя с удовольствием отвечу на любые аргументированные комментарии в их пользу. В моей картине мира метрикам в тестировании места нет (опять же, на заводе – пожалуйста). Но описанные в начале статьи проблемы решать как-то всё же надо, если не метриками – то как?

1. Регулярная обратная связь

Сотрудники и без циферок должны знать, что их ждёт, какие их перспективы и куда они могут развиваться. По результатам исследований института Гэллапа люди, понимающие свои рабочие перспективы, работают в разы эффективнее и значительно более счастливы на работе (хотя далеко не все из них понимают важность обратной связи). Более того, многие большие боссы внедряют аттестации с метриками только для того, чтобы менеджеры наконец-то начали общаться со своей командой! А зря: я видела результаты таких «насильно» внедрённых регулярных аттестаций, толку от них всё равно нет. Просто старайтесь не реже раза в месяц общаться с каждым сотрудником тет-а-тет – это всем действительно необходимо!

2. Оперативная оценка задач

Чтобы сотрудники развивались, вы должны регулярно оценивать результаты их работы. Не раз в квартал и не сухими метриками. Делитесь с ними: что вам понравилось, что было не очень. При этом делайте эти оценки обязательно конструктивными! Слова из серии «ты молодец!» не просто не приносят пользы – они зачастую раздражают и вызывают недоверие и отдалённость от менеджера. А вот конкретная похвала заведению дефекта, найденному багу или интересному тесту – очень даже помогают вашим сотрудникам и дальше работать по высшим стандартам, понимая что именно от них требуется. Для критики правило своевременности ещё важнее – говорить «последний квартал ты работал на 22% хуже предыдущего» бесполезно, а вот своевременно комментировать плохо выполненные задачи – залог повышения качества работы.

3. Искренность в общении с сотрудниками и коллегами

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

Запись Числовая оценка работы тестировщиков впервые появилась Портал TMGuru.