Отслеживание качества продукта - важнейшая функциональность тестировщика. В число характеристик качества входит и процесс производства, а его налаживание и есть та миссия, которая поручается тестировщику. Когда производственный процесс налажен чётко и ясно, прозрачно для всей группы разработки, то руководящему звену легко и просто отследить и выявить провисы и перегибы, а следовательно и принять вовремя меры по стабилизации процессов.
Для обеспечения прозрачности работы группа разработки использует какую-нибудь систему BTS (Bug-Tracking System), которая в свою очередь состоит из отдельных задач. У задач есть характеристика - жизненный цикл, который можно представить несколькими способами. Своим поделюсь в этой статье.
Этапы задачи разбиваю на следующие: создание, синхронизация, актуализация, исполнение. Шаг планирования пропущен, так как им занимается менеджер, а не рядовой тестировщик. При чём после каждого из первых трёх этапов вполне реально перепланирование, то есть смена сроков и ответственных. По этой же причине не выделяю отдельно декомпозирование задач. Остановлюсь на каждом из них подробнее в разрезе того, когда по моему мнению ими удобнее заниматься.
Созданием, как и ранее было сказано в статье МОПС, предлагаю заниматься в конце дня, когда в процессе основной работы над модулем или всем продуктом собрано достаточно информации для локализации проблемы. Полный набор сведений лучше собирать исходя из структуры ваших задач, как это было описано в статье "ГКЧП - Где, Как, Что Править?". Не забывайте, что из этих первичных документов, то есть тасков вашей BTS, формируется ваш отчёт о тестировании. Насколько точно и аккуратно будет оформлена каждая из задач, настолько же верно вы получите срез о качестве всего продукта. И дело тут не только в количестве и важности ошибок и предложений, но и в распределении их по модулям-компонентам, ответственным, а также подсчёт потраченного времени. Каждая мелочь, складываясь в общий график, даёт аналитические данные для последующего планирования.
А уже с утра следующего дня до ежеутренней планёрки (если вам привычнее - стендап) рекомендую читать, редактировать и синхронизаровать задачи, оформленные вами и всеми другими членами команды. Большинство советчиков по эффективности тайм-менеджмента предлагают начинать любую работу с лёгкого или мелкого. Придерживаясь этого мнения и я предлагаю начинать рабочий день с мелочёвки - почитать результаты чужих дел. О том, зачем нужно и как проводить оценку, подробно описано в моей статье "Issue review (ГКЧП-2)". Напомню только, что в процессе ознакомления с задачами всех вы упрощаете ежедневную встречу для отчёта о проделанной работе каждым членом команды. Их короткие речи станут вам понятнее, а также успеете сформулировать вопросы для уточнения пути развития продукта. Лишь после сбора всех мнений команды об отдельно взятой задаче для её декомпозиции и планирования будет набрано достаточное количество аргументов.
Актуализацию задач выделяю отдельным этапом, потому что это фактически работа с техническим долгом. Шеф ConquestSS предлагал отводить на это дело по полчаса с утра, но практика показала, что актуализировать забытые или отложенные задачи вы будете весь рабочий день. Зачастую с виду простенькие замечания или идеи требуют обильной проработки и многочисленных исследований в параллельных областях. Так что, тридцати минут даже на одну задачу не хватало. Раз в год или чаще в список для актуализации попадали задачи, давно заведённые в BTS, но до сих пор не попавшие ни в один билд, то есть вовремя не запланированные. В процессе актуализации некоторые задачи закрывались, как часть ранее реализованного, какие-то дополнялись для планирования на ближайший выпуск, остальная часть считалась несвоевременной фантастикой и откладывалась до будущих времён.
Исполнение полноценно оформленной задачи проводится в основное рабочее время. На каждое задание у вас уйдёт ровно столько времени, сколько запланировано, только если с задачей была ознакомлена вся команда, которая аргументированно дополнила, декомпозировала и запланировала её на исполнение. В процессе проверки исправленных багов, исследования новшеств, сбора данных по производительности продукта у вас непременно будут образовываться идеи для развития приложения, замечания по несоответствиям с нормативами, которые откладывайте по системе МОПС для замыкания спирали усовершенствования вашего продукта или, иными словами, жизненного цикла задач, то есть создавайте новые.
Некоторым из вас может показаться, что второй и третий этапы - синхронизация и актуализация - взаимозаменяемы, но уверяю вас, они не есть одно и тоже по нескольким причинам. Да, в обоих случаях проводится исследование и задачи дополняются, корректируются. Но! В синхронизации одной задачи участвуют много работников, в то время как для актуализации нескольких, объединённых по модулю, задач достаточно одного тестировщика. Синхронизация - процесс поверхностный, то есть не требующий больших временных затрат, а актуализировать надо проникая глубоко внутрь идеи. То есть, синхронизация идёт горизонтально вправо и влево в разрезе задач, а актуализация - вертикально вниз по продукту.
Надеюсь, мои вышеизложенные умозаключения помогут менеджерам и рядовым тестировщикам теперь более эффективно распределять рабочее время.
Для обеспечения прозрачности работы группа разработки использует какую-нибудь систему BTS (Bug-Tracking System), которая в свою очередь состоит из отдельных задач. У задач есть характеристика - жизненный цикл, который можно представить несколькими способами. Своим поделюсь в этой статье.
Этапы задачи разбиваю на следующие: создание, синхронизация, актуализация, исполнение. Шаг планирования пропущен, так как им занимается менеджер, а не рядовой тестировщик. При чём после каждого из первых трёх этапов вполне реально перепланирование, то есть смена сроков и ответственных. По этой же причине не выделяю отдельно декомпозирование задач. Остановлюсь на каждом из них подробнее в разрезе того, когда по моему мнению ими удобнее заниматься.
Созданием, как и ранее было сказано в статье МОПС, предлагаю заниматься в конце дня, когда в процессе основной работы над модулем или всем продуктом собрано достаточно информации для локализации проблемы. Полный набор сведений лучше собирать исходя из структуры ваших задач, как это было описано в статье "ГКЧП - Где, Как, Что Править?". Не забывайте, что из этих первичных документов, то есть тасков вашей BTS, формируется ваш отчёт о тестировании. Насколько точно и аккуратно будет оформлена каждая из задач, настолько же верно вы получите срез о качестве всего продукта. И дело тут не только в количестве и важности ошибок и предложений, но и в распределении их по модулям-компонентам, ответственным, а также подсчёт потраченного времени. Каждая мелочь, складываясь в общий график, даёт аналитические данные для последующего планирования.
А уже с утра следующего дня до ежеутренней планёрки (если вам привычнее - стендап) рекомендую читать, редактировать и синхронизаровать задачи, оформленные вами и всеми другими членами команды. Большинство советчиков по эффективности тайм-менеджмента предлагают начинать любую работу с лёгкого или мелкого. Придерживаясь этого мнения и я предлагаю начинать рабочий день с мелочёвки - почитать результаты чужих дел. О том, зачем нужно и как проводить оценку, подробно описано в моей статье "Issue review (ГКЧП-2)". Напомню только, что в процессе ознакомления с задачами всех вы упрощаете ежедневную встречу для отчёта о проделанной работе каждым членом команды. Их короткие речи станут вам понятнее, а также успеете сформулировать вопросы для уточнения пути развития продукта. Лишь после сбора всех мнений команды об отдельно взятой задаче для её декомпозиции и планирования будет набрано достаточное количество аргументов.
Актуализацию задач выделяю отдельным этапом, потому что это фактически работа с техническим долгом. Шеф ConquestSS предлагал отводить на это дело по полчаса с утра, но практика показала, что актуализировать забытые или отложенные задачи вы будете весь рабочий день. Зачастую с виду простенькие замечания или идеи требуют обильной проработки и многочисленных исследований в параллельных областях. Так что, тридцати минут даже на одну задачу не хватало. Раз в год или чаще в список для актуализации попадали задачи, давно заведённые в BTS, но до сих пор не попавшие ни в один билд, то есть вовремя не запланированные. В процессе актуализации некоторые задачи закрывались, как часть ранее реализованного, какие-то дополнялись для планирования на ближайший выпуск, остальная часть считалась несвоевременной фантастикой и откладывалась до будущих времён.
Исполнение полноценно оформленной задачи проводится в основное рабочее время. На каждое задание у вас уйдёт ровно столько времени, сколько запланировано, только если с задачей была ознакомлена вся команда, которая аргументированно дополнила, декомпозировала и запланировала её на исполнение. В процессе проверки исправленных багов, исследования новшеств, сбора данных по производительности продукта у вас непременно будут образовываться идеи для развития приложения, замечания по несоответствиям с нормативами, которые откладывайте по системе МОПС для замыкания спирали усовершенствования вашего продукта или, иными словами, жизненного цикла задач, то есть создавайте новые.
Некоторым из вас может показаться, что второй и третий этапы - синхронизация и актуализация - взаимозаменяемы, но уверяю вас, они не есть одно и тоже по нескольким причинам. Да, в обоих случаях проводится исследование и задачи дополняются, корректируются. Но! В синхронизации одной задачи участвуют много работников, в то время как для актуализации нескольких, объединённых по модулю, задач достаточно одного тестировщика. Синхронизация - процесс поверхностный, то есть не требующий больших временных затрат, а актуализировать надо проникая глубоко внутрь идеи. То есть, синхронизация идёт горизонтально вправо и влево в разрезе задач, а актуализация - вертикально вниз по продукту.
Надеюсь, мои вышеизложенные умозаключения помогут менеджерам и рядовым тестировщикам теперь более эффективно распределять рабочее время.
Комментариев нет:
Отправить комментарий