Небольшое необходимое предисловие
Саму заметку я начал готовить, чтобы просто поделиться ссылкой на презентацию. (см. чуть ниже). Вылилось же все в цепь рискованных заявлений о качестве ПО и обязанностях. Тем не менее, то что Брет Петтичард ввел термин "Школы тестирования", что объясняет очень многое, например почему кто-то ругает Waterfall, а кто то не признает Agile.
Тестировщик за качество не отвечает
Когда мой менеджер вернулся с конференции SQA Days 8, он, в том числе, рассказал о своей беседе с Майклом Болтоном. Даже не беседе, а споре. Одним из вопросов был краеугольный вопрос о качестве - кто отвечает за качество программного обеспечения? Самой презентации Болтона я найти не смог, но одновременно выступал Михаил Павлов, который также затронул вопросы ответственности. Выступления очень сильно перекликаются и сводятся к основным мотивам, что
a) тестировщик за качество ПО отвечать не должен
b) специалисты по качеству могут только способствовать а не обеспечивать качество.
Слушать и смотреть выступление здесь.
Причем, я ни разу не слышал, чтобы люди спорили одновременно с этим и о том - что такое отвечать за качество в процессе разработки (редко наверное в споре участвую). Это вопрос всплывает как то последовательно, как само собой подразумевающееся. Я полагаю, что некоторые оппоненты просто беседуют о разном. Но некоторые действительно спорят о тех, кто отвечает и перед кем. Моя позиция в этом вопросе наверное слишком безвольная - кто должен, тот пусть и отвечает.
Кто должен, тот пусть и отвечает
Меня вполне устраивает: Кто отвечает за принятое решение?
Уточню. Если конечный пользователь приходит к менеджеру и спрашивает: "порхуя" у нас опять не работает то, что мы заказывали? Менеджер буквально будет "отвечать" на вопрос пользователя и несет ответственность за принятое решение выкатывать новый/очередной релиз.
Если к тестировщику приходит менеджер и спрашивает - ммм... а почему вы не предупредили меня, что качество немного того - не очень? Тестировщик, который предоставляет информацию о качестве продукта, несет ответственность за принятое решение - не препятствовать отдавать релиз пользователю.
Т.е. если установлены точки ответственности между ролями клиент-менеджер-тестировщик - (модель, конечно очень упрощенная), то на каждой точек должен быть ответственный, который отвечает за принятое им решение относительно дальнейшей судьбы ПО. Перед клиентом - менеджер, перед менеджером - тестировщик. Вот именно тут я считаю правильным сказать - кто должен, тот пусть и отвечает.
И если отдел тестирования (или обеспечения качества - как кто его не называет) по мнению руководства компании должен принимать решение и давать зеленый свет - пусть именно этот отдел отвечает за качество ПО в том объеме, в котором руководство считает нужным.
И если отдел тестирования (или обеспечения качества - как кто его не называет) по мнению руководства компании должен принимать решение и давать зеленый свет - пусть именно этот отдел отвечает за качество ПО в том объеме, в котором руководство считает нужным.
Зоны ответственности и влияния тестировщика
Небольшие комментарии к приезентации Михаила Павлова.
Тестировщик не вносит изменения в код? Но тестировщик может принять решение - насколько это критично для ПО и процесса вцелом, а если тестировщик хорошо разбирается в бизнесе клиента, то и для бизнеса.
Тестировщик не может организационно повлиять на разработчиков? Он всегда может договориться с разработчиком. Если не с разработчиком, то с его лидом. Если не с лидом, то с менеджером. Если не с менеджером, то всегда можно обратиться к тому, кто считает, что тестировщики "должны отвечать за качество" - как еще решаются организационные вопросы? Если "они" все против - пишите письмо и ... улыбаемся и машем.
Тестировщик не управляет бюджетом и ресурсами? Как это вообще влияет на обеспечение качества или отвечает на вопрос - кто отвечает за качество?
Еще немного измышлизмов
Для меня любой процесс сводиться к трем основным действиям.
1. Получение информации.
2. Принятие решения относительно корректирующий воздействий.
3. Выполнение действий ( в том числе корректирующих воздействий).
Переводя на рельсы качества.
1. Получение информации о качестве ПО.
2. Принятия решения относительно изменений в ПО.
3. Исправление дефектов и выпуск ПО.
Получение информации для меня лично (чтобы не говорить абсолютно, что так должно быть для всех и везде), есть часть процесса обеспечения качества.
Если вы не получили информацию (от тестировщика, от менеджера, от клиента, от бизнес аналитиков), как вы сможете изменить продукт?
Моя школа тестирования
Все вышесказанное есть основная часть моей школы тестирования. - Что это значит?
Совсем недавно я наткнулся на презентацию Брета Петтичарда. Она называется школы тестирования. Лично мне помогла понять, почему люди спорят над вопросом "Кто отвечает за качество".
Сам Брет не так известен как те, с кем он близко работает (Кем Канер, Майкл Болтон, Джейм Бах), но статьи и материалы у него очень и очень занятные. Не поленитесь - прочитайте. Человек показывает почему люди из школы Agile спорят о процессах с людьми из школы Стандартов (Standart School) или школы Качества (Quality School).
Сам Брет не так известен как те, с кем он близко работает (Кем Канер, Майкл Болтон, Джейм Бах), но статьи и материалы у него очень и очень занятные. Не поленитесь - прочитайте. Человек показывает почему люди из школы Agile спорят о процессах с людьми из школы Стандартов (Standart School) или школы Качества (Quality School).
Чтобы подвести итог хотелось бы заметить, что то как видит себя тестировщик в процессе обеспечения/способствования качества никак (по моему опыту) не сказывается на качестве его работы.
Есть люди, которые видят себя борцами за качество и находят хорошие дефекты, строят процессы.
Есть люди которые видят себя как сервис и находят не менее хорошие дефекты и строят не менее формальные процессы.
Есть люди которым нет дела какая там кухня и кто тут за что отвечает - они просто хотят хорошо выполнять свою работу.
Наверное именно это - внутреннее чувство работать хорошо и нужно ставить в главу всех вопросов.
Наверное.
Все в жизни может быть иначе.
Один мой хороший приятель говорил: "Сколько людей, столько и мнений. Плюс еще одно - правильное."
Посему - стройте свои отдельно взятые школы тестирования в отдельно взятых проектах. И да прибудет с вами святой Исидор Сивильский.
Александр, это, конечно, удобно -- иметь "свою" школу, но непрактично :)
ОтветитьУдалитьШколы, как системы ценностей и концепций, возникают потому, что людям нужно общаться друг с другом, находить общие точки зрения. Каждая школа внутренне достаточно логически стройна и непротиворечива. А противостояние между школами -- это противостояние систем ценностей. Именно поэтому споры получаются нелогичными и быстро превращаются в "холивары" :)
Строить свою небольшую школу в отдельно взятой организации можно и полезно. Но лучше её строить как "секту", взяв за основу что-то уже существующее. Брать концепции из разных школ можно, но сложно, получается лоскутное одеяло, надо аккуратно прятать швы.
Это всё достижимо. Но когда вы переходите из одной организации в другую, или выступаете на конференции, или ещё как-то общаетесь с кем-нибудь вне своей организации, и надо обозначить свою позицию -- бессмысленно говорить, что "я являюсь приверженцем своей собственной школы тестирования", это всё равно, что ничего не сказать.
Поэтому удобно ассоциировать себя с какой-то крупной школой, и тогда достаточно лишь уточнить отличия своей "секты" от основного направления.
Алексей
ОтветитьУдалитьАлександр, это, конечно, удобно -- иметь "свою" школу, но непрактично :)
>так удобно или не практично ;)
>Это всё достижимо. Но когда вы переходите из одной организации в другую, или выступаете на конференции, или ещё как-то общаетесь с кем-нибудь вне своей организации, и надо обозначить свою позицию -- бессмысленно говорить, что "я являюсь приверженцем своей собственной школы тестирования", это всё равно, что ничего не сказать.
Бессмысленно сказать, что я не принаддежу ни к одной из школ? Не могу согласиться. Те 5 школ, что определил в своей презентации Брет не нужно воспринимать как "только существующие" вообще и впринципе и в далеком будущем. Я бы рассматривал их как точки притяжений мнений. Есть крайние "только школа Agile" и ""только школа Качества", но есть и разнообразные градации. Раасмотрите эти пять точек как 5 мерную систему. Любая точка - ваше мнение и ваша школа - находиться внутри этой системы координат. Ваша школа - это то где вы находитесь относительно других школ.
Если вы переходите из одной организации в другую вы должны показывать не то что вы школяр или куда то где то принадлежите, а что вы зрелый человек и можете решать их проблемы. Про конференции особый разговор - на конференции нужно обсуждать новое, тем более если оно спорное. Так и оттачиваются профессиональные взгляды.
>Поэтому удобно ассоциировать себя с какой-то крупной школой, и тогда достаточно лишь уточнить отличия своей "секты" от основного направления.
Школы и "секты".. хех. скатились мы в метафизику. У вас "секта" наверное и есть эта точка на карте школ. Тогда уж лучше обозвать кафедрой ;)
Петтикорд под "школами" подразумевал "схолии", так что метафизика тут вполне уместна :)
ОтветитьУдалитьПод удобно я имел в виду, что это очень просто -- взять и объявить о том, что "у меня своя школа", так может сделать каждый :)
Но это непрактично, потому что при этом невозможно будет общаться -- нет единой терминологии, единых постулатов, единых ценностей.
Естественно, школы развиваются. Естественно, они заимствуют друг у друга, но не просто берут идеи из других школ как есть, а ассимилируют, приспосабливают. Естественно, некоторые школы ближе друг к другу (например, context-oriented и agile), а некоторые дальше (например, aglie и quality-oriented).
Да, можно говорить о школах как о точках в многомерном пространстве, но это именно точки. Петтикорд в своей презентации привёл набор атрибутов, по которым он показал различия между школами -- вот это больше похоже на оси.
Алексей,
ОтветитьУдалитьСпасибо за "Петтикорд". Теперь по крайней мере юуду знать как его произносить правильно.
Не понимаю почему нужно настаивать на непрактичности. Почему нет единой терминологии, постулатов, ценностей?
Если вы выходец из одной школы и знаете терминологию школы другой - у вас просто наслаиваются термины, постулаты и ценности. Просто они будут другого не синего или желтого, а зеленого цвета (не знаю как более точно выразить - цвета, вроде бы подходят). Устоявшаяся школа или заново формируемая - вопрос в зрелости, а не в невозможности общаться. Этак можно дойти до того, что начать утверждать будто коммерсант с программистом не договоряться никогда (я и моя жена как пример, что это не так).
Любая школа это шкала, можно даже использовать нечеткую логику - ваша личная философия тестировщика на 50% Agile и на 20% Quality based. Можно и так. Я разницы не нахожу.
Моя школа - это терминология, ценности, постулаты школ Quality, Standart и Agile, ровно потому что я работал в проектах где эта школа работала.
Единственная цель мое заметки - доказать что в дискуссии с оппонентом, выходцем из другой школы, нужно понимать его и еще понимать, что вопросы могут в его школе звучать по иному.
Есть в заметке слабые места, но на то и дискуссии чтобы их обнаружить и поправить.
Спасибо за глубокие познания школ жизни тестировщика ;)