У специалиста по качеству со временем вырабатывается профессиональная черта правды. Если QA на каком-то этапе умолчит или недоговорит о возможных провальных последствиях, то руководству позже придётся весьма немало раскошелиться, чтобы "замять" проблему или исправить. Ещё несколько лет назад Максим Дорофеев обмолвился в одном из своих докладов, что предпочитает избегать полёты на определённой марке самолётов, потому что когда-то сам тестировал ПО для небесных машин. А недавно его опасения аукнулись отказом аэропортов от лайнеров мирового гиганта. Получается, что тестировщик своевременно не настоял на исправлении багов, а жизни рядовых пассажиров уже не вернуть, компания терпит огромные убытки и теряет доверие. Или же QA занизили уровень ответственности на этапе проектирования, то есть капельку, но обманули вышестоящие инстанции, чтобы общая оценка KPI соответствовала ожидаемой.
Как тестировщику сработаться с программистами и начальниками, если каждый из них с детства привык к маминой лести (читай "лжи"), нетерпим к правде и критике. Agile манифест предпочитает "быстрое" общение и пренебрегает бюрократией. Хотя именно в документировании, без общения с глазу на глаз, тестировщик полноценно может реализовать своё предназначение - детально и вовремя обратить всеобщее внимание на проблему без вуалирований. На днях мне рассказали случай о начальнице- мазохистке и подчинённом, которого она надеялась уличить в некомпетентности. Начальница получила по электронной почте документ, обнаружила неточность в данных. Как вы думаете, что она предприняла, чтобы опечатка была исправлена? Вернула электронное письмо с припиской о причине доработки? Нет! В век перехода на электронный бизнес начальница распечатала весь документ и на одном из листов обвела маркером место помарки. Потом не поленилась и пришла в кабинет с другими подчинёнными, на глазах у которых ткнула пальцем в опечатку под носом у виновного. Чего она этим хотела добиться? Увидеть униженного и насладиться властью? Возможно. Но получилось обратное, в очередной раз подчеркнула собственную отсталость в освоении современных технологий, потому что у мелкого сотрудника и без того было достаточно срочной и более важной работы, нежели вставлять одну единственную запятую. А ведь если бы об этой опечатке было сообщено через электронный документооборот, то не только у всего коллектива осталось бы рабочее настроение на остаток дня, но и репутация обоих осталась бы безупречной, да и расход канцелярии уменьшился. И это не единичный случай в службе ей подобных.
Примерно в такое же положение члены команды разработки ставят друг друга, когда тестировщик выявляет баг. Если QA - новичок, то его желание побежать к программисту и ткнуть того носом в код можно оправдать только желанием выбиться в "знайки". Но когда сам программист заявляется к тестировщику с претензией на перевод бага в фичу, он должен быть готов к тому, что будет посрамлён своей ограниченной осведомлённостью в предметной области. Тестировщик чаще всего знает о продукте намного больше и шире, чем кодер. И пользователю первой очереди буквально ничего не стоит доказать свою правоту. Разработчик может обидеться на честность специалиста по качеству, но обман будет стоить очень дорого всей команде. Поэтому отстаиваю приоритет ошибок, даже если приходится преувеличивать последствия, но чаще достаточно перечислить лишь самые страшные. А программисту, нанимающемуся в команду с давно работающими в ней тестировщиками, необходимо быть готовым к постоянной оценке его дел. Иначе, зачем же группе разработки нужны QA.
Что же такое "гибкость" для тестировщика? Макаревич пел: "Не стоит прогибаться под изменчивый мир, пусть лучше он прогнётся под нас." Не подменяют ли руководители проектов понятия "рабство", "безукоснительное подчинение" столь модным словом agile? Руководитель ConquestSS ежедневную смену продуктов и направлений тестирования, без возможности долгосрочного планирования хотя бы на один спринт называл "стилем agile". Ему очень хотелось, чтобы досконально подкованный тестировщик глаза в глаза высказывал провалы проектирования недоучке-программисту, вместо письменных долговечных комментариев к задаче. А ведь то, что единожды сказано одному, не доступно остальным. Значит каждому последующему проггеру пришлось бы выслушивать очередное унизительное нравоучение. После нескольких таких разбирательств ратую за обсуждение задач сразу в разделе комментариев Jira вместо созвонов по Skype (команда на 90% распределённая и все совещания проходят через звонки). Тем самым "убиваю двух зайцев": информация подробностей сразу доступна всем заинтересованным лицам, внутрикомандные отношения не портятся из-за чьей-то некомпетентности в предметной области.
Письменная речь имеет много преимуществ:
- перед отправкой можно перечитать и исправить опечатки, нелогичность мыслей, официальный документ исключает использование обидных эпитетов, которые могут проскочить в живом диалоге;
- напечатанный (на листе, в электронном виде) или рукописный текст сам по себе уже является документом, который легко и просто переиспользовать, прикрепить к тех.заданию или представить в виде доказательства при поиске причины проблемы;
- грамотность укрепляется и развивается за счёт письма;
- мелкая моторика развивает нервные окончания, ответственные за мыслительный процесс.
При устном разговоре "слово - не воробей, вылетит - не поймаешь". Поэтому если не хотите быть униженным, то просите давать оценку вашей деятельности письменно. Критик или тестировщик сто раз подумает и подберёт точные слова, которые и мысль обозначат конкретно, и ваше достоинство не унизят случайной фразой.
Но когда QA даёт отчёт по продукту, то большинство проблем приходится обобщать. При этом может утеряться важность и критичность. Если же ваш тест-менеджер умеет рассчитывать KPI найденных задач с полным учётом Severity и Priority, то его отчёт можно считать почти правдивым. Никакая статистика не сможет вместить объём того, что ещё не обнаружено. Коэффициент гибкости тестировщика напрямую зависит от критериев качественности продукта по мнению его владельцев. В этом плане специалисты по качеству аналогичны артистам, которые говорят словами автора пьесы, недоговаривая мысль, чтобы придать многозначность творению, Арлекины лгут зрителю, чтобы оправдать ожидания.
Имеет ли право тестировщик на обман или недосказанность? Как быть нам с постулатами профессии: строго соблюдать инструкции при позитивном тесте, сравнивать результат программистского труда с нормативами, объективно давать отчёт о состоянии продукта. Где ж тут место гибкости? Или agile и специалист по качеству не совместимы? Выбирать вам самим - полная и чистая правда с последующим спокойным сном и совестью, либо красивые и ожидаемые отчёты с последующим нервным расстройством от обилия молитв "лишь бы не попался шаловливый юзер".
Как тестировщику сработаться с программистами и начальниками, если каждый из них с детства привык к маминой лести (читай "лжи"), нетерпим к правде и критике. Agile манифест предпочитает "быстрое" общение и пренебрегает бюрократией. Хотя именно в документировании, без общения с глазу на глаз, тестировщик полноценно может реализовать своё предназначение - детально и вовремя обратить всеобщее внимание на проблему без вуалирований. На днях мне рассказали случай о начальнице- мазохистке и подчинённом, которого она надеялась уличить в некомпетентности. Начальница получила по электронной почте документ, обнаружила неточность в данных. Как вы думаете, что она предприняла, чтобы опечатка была исправлена? Вернула электронное письмо с припиской о причине доработки? Нет! В век перехода на электронный бизнес начальница распечатала весь документ и на одном из листов обвела маркером место помарки. Потом не поленилась и пришла в кабинет с другими подчинёнными, на глазах у которых ткнула пальцем в опечатку под носом у виновного. Чего она этим хотела добиться? Увидеть униженного и насладиться властью? Возможно. Но получилось обратное, в очередной раз подчеркнула собственную отсталость в освоении современных технологий, потому что у мелкого сотрудника и без того было достаточно срочной и более важной работы, нежели вставлять одну единственную запятую. А ведь если бы об этой опечатке было сообщено через электронный документооборот, то не только у всего коллектива осталось бы рабочее настроение на остаток дня, но и репутация обоих осталась бы безупречной, да и расход канцелярии уменьшился. И это не единичный случай в службе ей подобных.
Примерно в такое же положение члены команды разработки ставят друг друга, когда тестировщик выявляет баг. Если QA - новичок, то его желание побежать к программисту и ткнуть того носом в код можно оправдать только желанием выбиться в "знайки". Но когда сам программист заявляется к тестировщику с претензией на перевод бага в фичу, он должен быть готов к тому, что будет посрамлён своей ограниченной осведомлённостью в предметной области. Тестировщик чаще всего знает о продукте намного больше и шире, чем кодер. И пользователю первой очереди буквально ничего не стоит доказать свою правоту. Разработчик может обидеться на честность специалиста по качеству, но обман будет стоить очень дорого всей команде. Поэтому отстаиваю приоритет ошибок, даже если приходится преувеличивать последствия, но чаще достаточно перечислить лишь самые страшные. А программисту, нанимающемуся в команду с давно работающими в ней тестировщиками, необходимо быть готовым к постоянной оценке его дел. Иначе, зачем же группе разработки нужны QA.
Что же такое "гибкость" для тестировщика? Макаревич пел: "Не стоит прогибаться под изменчивый мир, пусть лучше он прогнётся под нас." Не подменяют ли руководители проектов понятия "рабство", "безукоснительное подчинение" столь модным словом agile? Руководитель ConquestSS ежедневную смену продуктов и направлений тестирования, без возможности долгосрочного планирования хотя бы на один спринт называл "стилем agile". Ему очень хотелось, чтобы досконально подкованный тестировщик глаза в глаза высказывал провалы проектирования недоучке-программисту, вместо письменных долговечных комментариев к задаче. А ведь то, что единожды сказано одному, не доступно остальным. Значит каждому последующему проггеру пришлось бы выслушивать очередное унизительное нравоучение. После нескольких таких разбирательств ратую за обсуждение задач сразу в разделе комментариев Jira вместо созвонов по Skype (команда на 90% распределённая и все совещания проходят через звонки). Тем самым "убиваю двух зайцев": информация подробностей сразу доступна всем заинтересованным лицам, внутрикомандные отношения не портятся из-за чьей-то некомпетентности в предметной области.
Письменная речь имеет много преимуществ:
- перед отправкой можно перечитать и исправить опечатки, нелогичность мыслей, официальный документ исключает использование обидных эпитетов, которые могут проскочить в живом диалоге;
- напечатанный (на листе, в электронном виде) или рукописный текст сам по себе уже является документом, который легко и просто переиспользовать, прикрепить к тех.заданию или представить в виде доказательства при поиске причины проблемы;
- грамотность укрепляется и развивается за счёт письма;
- мелкая моторика развивает нервные окончания, ответственные за мыслительный процесс.
При устном разговоре "слово - не воробей, вылетит - не поймаешь". Поэтому если не хотите быть униженным, то просите давать оценку вашей деятельности письменно. Критик или тестировщик сто раз подумает и подберёт точные слова, которые и мысль обозначат конкретно, и ваше достоинство не унизят случайной фразой.
Но когда QA даёт отчёт по продукту, то большинство проблем приходится обобщать. При этом может утеряться важность и критичность. Если же ваш тест-менеджер умеет рассчитывать KPI найденных задач с полным учётом Severity и Priority, то его отчёт можно считать почти правдивым. Никакая статистика не сможет вместить объём того, что ещё не обнаружено. Коэффициент гибкости тестировщика напрямую зависит от критериев качественности продукта по мнению его владельцев. В этом плане специалисты по качеству аналогичны артистам, которые говорят словами автора пьесы, недоговаривая мысль, чтобы придать многозначность творению, Арлекины лгут зрителю, чтобы оправдать ожидания.
Имеет ли право тестировщик на обман или недосказанность? Как быть нам с постулатами профессии: строго соблюдать инструкции при позитивном тесте, сравнивать результат программистского труда с нормативами, объективно давать отчёт о состоянии продукта. Где ж тут место гибкости? Или agile и специалист по качеству не совместимы? Выбирать вам самим - полная и чистая правда с последующим спокойным сном и совестью, либо красивые и ожидаемые отчёты с последующим нервным расстройством от обилия молитв "лишь бы не попался шаловливый юзер".
Комментариев нет:
Отправить комментарий