Все же длинный рид-лист - это явная проблема. Ты становишься уже не настолько гибким, не настолько быстро ловишь новые идеи и решения. Вот например только сейчас из глубин моего рид-листа выплыла статься про непрерывный деплоймент на AgileRussia, хотя переводу уже не меньше трех месяцев а сама статья стала почти классикой. Интересно, что можно сделать с рид-листом такое...аджайлистое...читать книги по главам - только интересные и нужные фрагменты и прекращать читать если понял, что остальное - не нужно? Навскидку - так выглядит довольно сомнительно...но, впрочем, почему-бы не попробовать?
Но вернемся к непрерывному деплойменту. Он уже стал почти привычным для разработчиков сервисов и сейчас потихоньку "прокрадывается" и в разработку приложений - как клиентских так и серверных. Все больше ответственности и работы, связанной с обеспечением качества ложится на плечи разработчиков и это, пожалуй, неплохо. Я как раз сегодня разговаривал с разработчиком из команды Microsoft Exchange, который совершенно спокойно и с удовольствием берет на себя полную ответственность за свой код в том числе потому, что действительно уверен в его качестве, в том числе потому, что он сам разработал функциональные и интеграционные тесты. Другой вопрос - а чем в этой ситуации займутся тестировщики?
Тестировщики наконец-то займутся тестированием, а не сверкой спецификаций и реализации.
ОтветитьУдалитьОбратно же "берет на себя полную ответственность за свой код" - сколько таких разработчиков? Пока не подавляющее большинство - у меня будет хлеб.
Рома, вот она истина о нашей работе (тестеровщиках).
ОтветитьУдалитьТестеровщики не нужны (по этому поводу дня два в чате тестеровщиков рассуждали :)).
Сейчас модный тренд: Выкат без тестирования, continuos delivery (возможно это по теме статьи - не читал, не осуждаю:)). Все, уйдем мы из массовой разработки. Злые все, одни мы Д'Артаньяны :)
И перейдем мы в отрасли safety critical. Там без тестирования всё-таки рисковать не будут.
Почти согласен с обоими - такой подход в принципе подходит не всем людям. И перед тем как внедрять его нужно быть готовым понимать, зачем ты это делаешь и что это тебе дает. Если ты понимаешь, что возможность предоставлять пользователям не раз в квартал и даже не раз в неделю а каждый день - это действительно важно для твоего бизнеса...то тогда будь готов потерять тех разработчиков, которые считают тестировщиков ответственными за качество их кода. А чем заняться тестировшикам в таком случае - пожалуй действительно хороший вопрос потому что количество работы для них все равно огромно. Оттого, что большая часть фукнционального тестирования переходит в зону ответствнности - не так много меняется.
ОтветитьУдалитьЯ тоже за ответственность разработчиков. И если у тебя уйдут те, кто считают крайними тестировщиков , то жизнь станет лучше :) А хорошим тестировщикам всегда будет что делать. Их задача не рутина, а поиск того, что еще не покрыто тестами :)
ОтветитьУдалитьФантазия нарисовала две картины:
Удалить1. Суровый тестировщик смотрит на измерение покрытия кода... находит метод, запыленный и вопрошает у него, у программиста и у любимой рыбки: "У тебя есть тесты? А если найду?"
2. Брутальненький тестировщик, смотрит на черный ящик... и загробным голосом вещает: "А почему ты чёрен, но бочина у тебя вмятая?" и такой, тыдыщ битой по ящику... тот в дребезги.
Серега, это 5 :)
Удалить