Сообщений в теме: 58

[Green]

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



Я вам так скажу.

Ну чего вы взъелись на девушку?! Ну, трудновато читать. Да. Есть такое. А что, все тут пишут идеально?

Ну не все фразы и термины однозначны. Так что из этого? Смысл то понятен.

Есть компания-разработчик и у нее есть заказчик. Заказчик жмот - денег в достаточном количестве не дает. Исполнитель тоже не ангел. Убедить заказчика в том, что работать правильно в его же интересах не смог. И, как следствие, мучается той командой, которая помещается в бюджет. В результате проектная команда отдувается. Она пытается и так и сяк, а заказчик не доволен. И я его понимаю...

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

Ну, теперь тестировщики стали выполнять еще и функции аналитиков. По идее требования должны улучшиться, работа должна улучшиться, продукт должен улучшиться. Ну и что? Это реально произошло? А заказчик это заметил? Есть от него отклик, что теперь стало лучше? Если нет, то и смысла все затевать не было.

И вообще...
У меня кризис среднего возраста и я все вижу в темном свете.

Алексей в одном своем докладе привел слова какого-то чела:
- Все что я делал - на 80 процентов было дерьмом.
И потом, после небольшой паузы, добавил.
- Но если задуматься, то все в мире на 80 процентов дерьмо.

Как я его понимаю!
За последний год мне пришлось оторваться от светлого мира разработки софта и окунуться в реальный мир потребителей этого софта. Если бы вы знали, сколько дерьма продается на рынке. И кто-то ведь его покупает и даже пытается использовать...

А вы говорите бабочки...

[greesha]

Алексей в одном своем докладе привел слова какого-то чела:
- Все что я делал - на 80 процентов было дерьмом.
И потом, после небольшой паузы, добавил.
- Но если задуматься, то все в мире на 80 процентов дерьмо.

Интересная интерпретация принципа Парето. :)

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

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

Эдвард Йордон. Путь камикадзе

[VLDCORP]

Ну почему у нас все время происходит "шапкозакидательство"? Ведь в итоге это никак не стимулирует писать статьи.
Авторов у нас и так немного, а тех кто пишет хорошие статьи еще меньше. Но всегда много критиков, которые приводят свои или чужие авторитетные мнения сдобряя их отнюдь неконструктивными фразами про Фому и Ерему. Причем постоянно идет фон неких недомолвок (на фоне экспертного кидания пальцами). Мол догадайтесь сами. Я, признаться, порой не понимаю, что хотел сказать автор той или иной фразой.
Вы обвиняете человека, что он изобретает велосипед. Так а что в этом плохого? Многие и слыхом не слыхивали, что бывает так, а не иначе. Ну, а экспертам, которые знают этот вопрос +1 балл в зачетную книжку. Лично я за то, чтобы велосипеды появлялись. Это хотя бы говорит о том, что человек в чем то разобрался. Дошел до этого своим умом. Это очень положительный момент.
Тем кто встал на путь SQA специалиста нужно учиться. Если авторы не будут писать статьи, то где брать современные материалы о положении в отрасли?
Критикуйте конструктивно, зачем эти обидные для автора фразы?
И с другой стороны, если вы эксперты, то пишите статьи.

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

[Case]

Влад прав.

Я раньше просил критиков показать свои публикации. Хоть какие-то. Потом перестал - кто хочет и можем, тот пишет.

[SALar]

Влад прав.

Я раньше просил критиков показать свои публикации. Хоть какие-то. Потом перестал - кто хочет и можем, тот пишет.

Я тоже присоединюсь. Юля молодец. Она растет.
Но. Может попробовать подкорректировать статью?

[Case]

Сергей, я что мог сделать, не задавливая своим мнением идеи и мысли Юли - сделал. Хочешь добавить - сделайте с Юлей второе издание.

[barancev]

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

Однако критики меня не порадовали, что правда то правда. Вместо того, чтобы высказать либо методические, либо существенные замечания, автору было поставлено на вид:
1) неудачное употребление слова "рецензент",
2) избыток ненумерованных списков ("смерть от буллет-поинтов"),
3) серый дизайн сайта (это вообще не к автору, а ко мне :) ),
4) статья чересчур академична (да неужели?),
5) толкование термина качество, отличное от того, которое обычно использует читатель Икс.

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

[barancev]

Ну вот, критиков я пожурил, а по поводу статьи так до сих пор и не высказался. Исправим это упущение.

На мой взгляд, в статье имеется две серьёзных методических ошибки:
1) В начале статьи не сформулирована её основная идея, это, в частности, привело к тому, что статья трудно читается, это отметили многие.
2) Для "плохого" подхода перечислены только слабые стороны, а для "хорошего" -- только сильные. Так можно показать превосходство чего угодно над чем угодно :) Честное сравнение предполагает, что для обоих рассматриваемых подходов будут приведены как сильные, так и слабые стороны.

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

[barancev]

Теперь аргумент в поддержку. Что мне нравится (и в докладе на SQA Days Minsk мы это видели, и в статье тоже) -- Юля рассказывает, не про "сферического коня в вакууме", а про обычную жизнь, которая часто, увы, весьма далека от идеала.

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

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

Кто может сказать, что у него в компании идеально поставленный процесс? Даже лучше, чем описано в статье? Расскажите нам, как оно работает. Юля рассказала, а вам слабо?

[greesha]

Кто может сказать, что у него в компании идеально поставленный процесс? Даже лучше, чем описано в статье? Расскажите нам, как оно работает. Юля рассказала, а вам слабо?

У меня не идеальный, и вообще хреновый. Рассказать? Но... куда принести полцарства высылать рассказ?

При внимательном изучении сайта software-testing.ru обнаружил единственный контакт для обратной связи:

При перепечатке материалов ссылка на сайт обязательна. По всем вопросам обращаться по адресу info@software-testing.ru

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

Есть, правда, форма "Добавьте ваш комментарий". Но, вроде бы, это не то место, где нужно размещать статьи?

(На самом деле, у меня есть визитка Главного редактора software-testing.ru. И я при желании могу "воспользоваться служебным положением" и написать лично ему. Но разве у всех есть такие визитки?)

[barancev]

При внимательном изучении сайта software-testing.ru обнаружил единственный контакт для обратной связи:

При перепечатке материалов ссылка на сайт обязательна. По всем вопросам обращаться по адресу info@software-testing.ru

Ну конечно :) Именно туда и надо писать :) По всем вопросам, ага.

(На самом деле, у меня есть визитка Главного редактора software-testing.ru. И я при желании могу "воспользоваться служебным положением" и написать лично ему. Но разве у всех есть такие визитки?)

Так. У кого ещё нет визитки? Срочно встречаемся на конференции SQA Days 2009 в Питере! Сделаю визиток ровно столько, сколько зарегистрируется участников, хватит всем :)

[Alfa]

1) неудачное употребление слова "рецензент",
2) избыток ненумерованных списков ("смерть от буллет-поинтов"),

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

Как оказалось доверие было подорвано не напрасно:

и

Вывод в статье тоже довольно фееричен:

которые несут смысл, в отличие от приведенных вами выше. Возможно не слишком конструктивно, но я разъяснил позицию в последующих комментариях.

Так же пропущены (потом вы сами их приводите) замечания (не мои) по поводу читаемости статьи.

Такова моя критика критика критиков.

По поводу ответственности и полномочий. Если хотите, у разработчика есть полномочия писать код и он несет ответственность за его качество. Это я, возможно слишком неявно, пытался показать в своем примере "виртуальный проект".

[barancev]

Такова моя критика критика критиков.

Критики критиков не нуждаются в критике :)

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

[Clauster]

Я смотрю тут слегка пинают мои посты в этом топике :) Ладно, я отвечу за свои слова

Но всегда много критиков, которые приводят свои или чужие авторитетные мнения сдобряя их отнюдь неконструктивными фразами про Фому и Ерему
...
Вы обвиняете человека, что он изобретает велосипед. Так а что в этом плохого?

Фраза про Фому и Ерему шла вне контекста критики. Про велосипеды был задан вопрос, на который был получен вполне удовлетворивший меня ответ. Ни в чем я автора не обвинял и тем более не подбирал обидных фраз. По поводу критики - если её нет, значит статья неинтересная, не провокационная и т.д. Это мое мнение.

Однако критики меня не порадовали, что правда то правда. Вместо того, чтобы высказать либо методические, либо существенные замечания, автору было поставлено на вид:
3) серый дизайн сайта (это вообще не к автору, а ко мне :) ),
4) статья чересчур академична (да неужели?),
5) толкование термина качество, отличное от того, которое обычно использует читатель Икс.

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

Да, "мысль о начале тестирования на этапе формирования требований далеко не нова". И что? Многие ли реально это делают? Нет? А почему?

Я делаю это всегда, когда есть такая возможность. Во-первых, любознательность толкает, во-вторых мне же потом это всё тестировать, в-третьих все остальное, о чем можно прочесть в книжках статьях и блогах.

По поводу упреков "не понравилось попробуй сделать похожее", представьте что вам разработчики то же самое будут говорить. В общем, я не считаю это серъезным аргументом. :)

PS ткните, если что-то упустил, отвечу
PPS готовьте визитку

[Clauster]

Простите, конечно, за такую грубую аналогию, но буквально вчера у Хармса прочел http://petrenko.ru/l...y.php?t=226&x=1

[dlg99]

Кто может сказать, что у него в компании идеально поставленный процесс? Даже лучше, чем описано в статье? Расскажите нам, как оно работает. Юля рассказала, а вам слабо?

не идеальный. Со своими заморочками. По-моему лучше, чем у Юли описано, но у нее аутсорсинг и там свои заморочки.
Читать лучше здесь, а то получится "Рабинович напел".

[Sapiens]

И я суда полезу :)
Сразу говорю, что это мое собственное ИМХО и я его никому не навязываю. Тестирование прежде всего заключается в том, чтобы заказчик получил ровно, то что он хочет. Каким образом это будет достигнуто заказчику абсолютно все равно. В этом смысле делегирование обязанностей аналитика на команду QA + разработчиков и отсутствие аналитика как отдельной сущности ничего противоестественного не несет. Я попробую описать свое мнение исходя из видов самого процесса работы:
1) Если команда работает по XP допустим, то это единственный способ работы на мой взгляд (Planning game). Да конечно в XP все может решать команда разработчиков, но опять же над проектом работает вся команда и обсуждение должно весьтись совместно с QA.
2) Теперь я поставлю обратную связь к статье по другой модели процесса, а именно Scrum. Сущностью аналитика во всеобщем понимании в принципе получает роль Product Owner, при этом если в компании не имеется отдел тестирования, то как вы думаете кому делегируют ответственность по тестированию продукта??? Логичней всего это будет именно Product Owner...
3) Если рассматривать классическую модель водопада, то естественно в ней трудно представить команду без аналитика. И здесь предыдущий сыр-бор я поддерживаю.
Все это написано по причине того, что мне кажется применение QA в качестве аналитиков может быть и оправдано и осуждено только в зависимости от поставленного процесса работы команды. Если это устраивает всех( QA, разработчиков и заказчика), то о чем мы вообще спорим?
P.S. Хочется особенно подчеркнуть то, что такая модель будет очень сильно зависить от персонала данного отдела. Если в отделе QA работают люди не коммуникабельные или не желающие так работать, то смысла переноса ответственности не будет и подавно.

[greesha]

2) Теперь я поставлю обратную связь к статье по другой модели процесса, а именно Scrum. Сущностью аналитика во всеобщем понимании в принципе получает роль Product Owner, при этом если в компании не имеется отдел тестирования, то как вы думаете кому делегируют ответственность по тестированию продукта??? Логичней всего это будет именно Product Owner...

"Всеобщее понимание" уже не такое всеобщее. :)

О роли аналитика в Agile, рекомендую: статья, презентация и видеозапись семинара Андрея Бибичева.
На днях (то есть позавчера) он проводил ещё один семинар на эту тему по этой презентации (с обновлениями) - возможно, команда CustIS обновлённые материалы и видео тоже выложит.

[Sapiens]

greesha
Судя по этой статье я никому не противоречю) http://www.custis.ru...ile-article.pdf . Из статьи

Генрих Книберг в своей презентации «10 способов напортачить со Scrum и XP» говорит о
критерии «сделано» (DoD, Definition Of Done). Согласно этому критерию, задача не
считается до конца выполненной до тех пор, пока соответствующая функциональность не
пройдет функциональные тесты и пока Product Owner не согласится с тем, что сделано то,
что нужно. Т.е. получается, что Product Owner участвует в контроле качества — когда
команда считает, что задача успешно решена, в этом должен еще убедиться и Product
Owner.
Достаточно очевидно, что вместо (или совместно с) Product Owner-а (ом) эта почетная
обязанность может быть возложена на аналитика.

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

При этом лучше не втягивать аналитиков в ручное регрессионное тестирование или
другие рутинные процедуры — только в проверку правильности реализации новой
функциональности.