Могут ли тестировщики повлиять на решения команды

В команде нередка ситуация, которая развивается примерно так:

1. Системный аналитик (удаленный) создал требования
2. Программисты чего-то там напрограммировали, но еще не до конца. Становится, очевидно, что в программе есть архитектурный косяк, который создает пользователю большие неудобства
3. Тестировщики исследуют эту ситуацию и говорят ведущему программисту, что надо что-то менять
4. Ведущий программист отвечает, что и так нормально, "Пользователь просто должен делать..." или "Не должен делать…"
5. Тестировщики пишут аналитику, что в программе косяк
6. Программисты следом пишут, что исправить его очень сложно и на это требуется много-много часов
7. Аналитик говорит, оставить так (программу он еще не видел). Тестировщики замолкают. Фича, так фича
8. Далее программа проходит все этапы: разработка/тестирование (снова разработка тестирование), написание документации. Ура, релиз!
9. Пользователи пишут «у вас в программе косяк!» Техподдержка видимо устает отвечать «Это не косяк, это фича»
10. Создается дефект и тут ВНЕЗАПНО обнаруживается, что это та самая архитектурная проблема, о которой говорилось пол года назад.
11. Принимается решение ее исправлять. И вот теперь на это действительно нужно много-много часов.
12. Принимается решение написать костыли, если это возможно.
Итог: программа обрастает костылями, а потом костылями для костылей и связанными со всеми этими костылями багами.

Вопрос: могут ли тестировщики изменить этот сценарий?

И еще. Последнее слово в нашем случае за тем человеком, кто писал требования.

Вообще могут, если аргументы тестера убедительные.

Вообще могут, если аргументы тестера убедительные.

зависит от процесса разработки. Тестировщиков тоже можно и,ИМХО, нужно привлекать к процессу написания спецификаций.

Может.
Если удастся уговорить аналитика побыть пользователем.
И проиграть ситуацию с точки зрения пользователя.
Сложно, конечно!

зависит от процесса разработки. Тестировщиков тоже можно и,ИМХО, нужно привлекать к процессу написания спецификаций.

Тут все зависит от руководства, на сколько оно заинтересовано в юзабилити и прочих вещах, если цели руководства "побыстрее выпустить" то наверное убеждения тестера не помогут, тут уж пока шишки не набьет.. А вообще читала я книжку "ключевые процессы тестирования" там написано как тестерам подходить к убеждению руководства.

Вопрос: могут ли тестировщики изменить этот сценарий?

Это в первую очередь зависит от самих тестировщиков: их коммуникативных навыков и авторитета. Если тестировщики могут грамотно аргументировать суть проблемы, и если они не поднимают панику по любому поводу, то почему к ним могут не прислушаться?

Вопрос: могут ли тестировщики изменить этот сценарий?

Ответ: да.

Конечно могут.
Если твои предложения логичны и доказаны то Аналитик просто допустит сознательную ошибку отказав в этом.
У тебя будут доказательства, что он допустил ошибку. Покажи эти доказательства начальству и аналитик больше не захочет не брать тебя в расчет.
Какая разница кто вносит предложения тестировщик или кто-то другой, главное чтобы они были обоснованы. Если же предложения не принимаются только потому что ты тестировщик то значит это очередная ошибка аналитика.

Но возможно в вашей ситуации просто нет времени на исправление этого, в таком случае надо создать баг и пометить его как отложенный на будущее.

Мой вопрос к правдорубу leftCh и его команде: а как в методике (которую пишет ваш отдел) приёмо-сдаточных испытаний вам удалось скрыть данный дефект от Заказчика?
Ответ на ваш вопрос: нет (без пояснений, в стиле Гуру - см. сообщение 'Отправлено 11 Февраль 2011 - 02:53').

В команде нередка ситуация, которая развивается примерно так:

1. Системный аналитик (удаленный) создал требования
2. Программисты чего-то там напрограммировали, но еще не до конца. Становится, очевидно, что в программе есть архитектурный косяк, который создает пользователю большие неудобства
3. Тестировщики исследуют эту ситуацию и говорят ведущему программисту, что надо что-то менять
4. Ведущий программист отвечает, что и так нормально, "Пользователь просто должен делать..." или "Не должен делать…"
5. Тестировщики пишут аналитику, что в программе косяк
6. Программисты следом пишут, что исправить его очень сложно и на это требуется много-много часов
7. Аналитик говорит, оставить так (программу он еще не видел). Тестировщики замолкают. Фича, так фича
8. Далее программа проходит все этапы: разработка/тестирование (снова разработка тестирование), написание документации. Ура, релиз!
9. Пользователи пишут «у вас в программе косяк!» Техподдержка видимо устает отвечать «Это не косяк, это фича»
10. Создается дефект и тут ВНЕЗАПНО обнаруживается, что это та самая архитектурная проблема, о которой говорилось пол года назад.
11. Принимается решение ее исправлять. И вот теперь на это действительно нужно много-много часов.
12. Принимается решение написать костыли, если это возможно.
Итог: программа обрастает костылями, а потом костылями для костылей и связанными со всеми этими костылями багами.

Вопрос: могут ли тестировщики изменить этот сценарий?

Конечно могут. Точнее даже обязаны, ибо это часть нашей работы. (Счастье пользователей )
У нас с этим проще. Перед реализацией чего-либо сначала читаются всеми требования, затем обсуждаются и правятся. Если по мере написания возникают какие-либо вопросы или предложения, то тоже обсуждается и правится по ходу разработки. Если что-то реализовано, но мне не нравится, я сначала прикидываю сколько времени уйдет на переделывание, затем узнаю у лида разрабов его оценку. Обычно она близка, если большие расхождения, то прошу разъяснить на основе чего такая оценка. После этого созываю менеджера проекта и аналитиков и мы обсуждаем что, да как. Очень хорошо иметь стенд, на котором можно показать как работает сейчас, ибо не всегда просто понять по требованиям как все будет выглядеть и работать в конечном счете. Показываю им что есть сейчас, как бы мне хотелось переделать, естественно, нахожу весомы аргументы зачем это надо и говорю сколько это будет стоить (в человеко-часах). Также делаю предположения на что это может повлиять в дальнейшем. После чего совместно принимается решение. В 85% случаев срабатывает. Еще в 10% предлагаю слишком масштабные изменения, которые могут существенно сдвинуть сроки (обычно записывается в виде фичи), еще 5% решили не переделывать вообще.
Главное в таких случаях быть в хороших отношениях с ПМ и аналитиками и привести весомые аргументы. Плюс не мешало бы ввести тестирование требований. Позволяет избежать ситуаций, подобных Вашей.

Спасибо, Mystery_Andrew (см. 'Отправлено Сегодня(13.09.2011), 15:23') за рассказ про свою работу.
Делаем выводы:
1) Как поразить Заказчика неадекватом реализованных требований во время сдачи проекта?
До и По ходу разработки правим требования. (...было бы понятно, если бы Заказчик что-то попросил в них изменить...)
2) Как поразить неадекватом Коллег?
Что-то не нравится - берём с потолка сроки на переделку, вымучиваем их (с обоснованием, почему не совпадает) из ведущего разработчика, созываем руководство проектом (пожар - еженедельных летучек не бывает).
3) Почему хорошо иметь стенд тестировщикам?
Не смотря на то, что требования постоянно изучаются и правятся, не понять как все будет выглядеть и работать в конечном счете (люди же не ведают, что делают).
4) Какие предложения вызывают гордость?
Масштабные изменения, которые могут существенно затянуть сроки, сорвать планы, испортить нервы...
5) Какие остаются записки на манжетах?
Плюс не мешало бы ввести тестирование требований (...вы же их до и по ходу разработки внимательно прорабатываете!?)

leftCh, могут ли тестировщики изменить тот сценарий?

Спасибо, Mystery_Andrew (см. 'Отправлено Сегодня(13.09.2011), 15:23') за рассказ про свою работу.
Делаем выводы:
1) Как поразить Заказчика неадекватом реализованных требований во время сдачи проекта?
До и По ходу разработки правим требования. (...было бы понятно, если бы Заказчик что-то попросил в них изменить...)
2) Как поразить неадекватом Коллег?
Что-то не нравится - берём с потолка сроки на переделку, вымучиваем их (с обоснованием, почему не совпадает) из ведущего разработчика, созываем руководство проектом (пожар - еженедельных летучек не бывает).
3) Почему хорошо иметь стенд тестировщикам?
Не смотря на то, что требования постоянно изучаются и правятся, не понять как все будет выглядеть и работать в конечном счете (люди же не ведают, что делают).
4) Какие предложения вызывают гордость?
Масштабные изменения, которые могут существенно затянуть сроки, сорвать планы, испортить нервы...
5) Какие остаются записки на манжетах?
Плюс не мешало бы ввести тестирование требований (...вы же их до и по ходу разработки внимательно прорабатываете!?)

leftCh, могут ли тестировщики изменить тот сценарий?

Я говорю о том, что, на мой взгляд, было бы хорошо.
1) У нас заказчик=работодатель. Даже если бы было не так, то с заказчиком проговариваются основные аспекты работы будущего софта, но есть множество деталей, которые не проговариваются.
2) Я не требую точную оценку времени, нужна прикидка по времени, чтобы понять стоит ли оно того. Тем более этот вопрос будет все равно задан, если не мной, то ПМ. А для созыва руководства есть такая прекрасная вещь, как чат. Если что-то проблемно описать в чате, то просто подошел и объяснил что и как хочу. Минут 15 обычно достаточно, чтобы донести идею.
3) Всегда проще понять, когда есть что-то перед глазами.
4) Не ради гордости я писал, а ради того, чтобы попытаться помочь. Насчет сроков и т.п. я писал, что надо сначала прикинуть чего нужно достигнуть, насколько это целесообразно.
5) Насчет ввода тестирования требований - это применительно к leftCh, позволяет избежать "костылей".

P.S. В Ваших постах прослеживается критика всего и вся. Да, возможно Вы ГУРУ и мы Вам в подстилки не годимся, но все же может стоит проявлять хоть каплю уважения к людям? Тем более у людей может быть мнение, отличное от Вашего, что не значит, что оно не правильное.
P.P.S. Я сомневаюсь, что leftCh написала данный вопрос только ради получения ответа "Да" или "Нет", тем более, что нет ничего невозможного. Поэтому я и позволил себе не столь короткий пост. И зачем же Вы задаете leftCh тот же вопрос, с которым она обратилась к другим и к Вам в том числе?

Mystery_Andrew, не обижайтесь, пож-та.
Для вас, как тестера, тоже важно максимально (по существу) раскритиковать программный продукт, чтобы улучшилось его качество.
Разработчики же не говорят вам, какой вы злой, когда вы находите жуткие баги в их программе.

Давайте вместе разберём, с чем обратилась к нам leftCh (см. Отправлено 10 Февраль 2011).
1)
Требования по прикладной части (уточнив, как собирается использовать продукт Заказчик) создаёт бизнес-аналитик.
Требования реализации (проведя экспертизу: в какой инфраструктуре/условиях будет эксплуатироваться продукт, какая архитектура и технологии должны при этом использоваться) создаёт системный аналитик.
Как правило это очень умные и опытные люди (очевидно, первое и последнее слово за ними).

Тестировщики там и рядом не стояли (не беседовали с заказчиком, не изучали его мат. часть, их интеллектуальный уровень ниже чем у аналитиков).
Что они там могут изменить? Ничего (ну может быть небольшие опечатки в бизнес-требованиях).

2)
Обратите внимание как leftCh отзывается о созидателях (программисты чего-то там напрограммировали), - слух не режет?
Очевидно, был сделан прототип, экспериментировали, дали тестерам поискать слабые места.
Тестеры предоставили отчёт (leftCh помпезно выразился - написали аналитику).
Девелоперы и аналитик им сказали спасибо и приняли (на основании им известных аргументов, фактов, результатов тестирования,..., ограничений на сроки, стоимость,...) решение как продолжить разработку.

Тестировщики сделали то, что от них требовалось. С какого перепугу они претендуют на то, чтобы перед ними отчитывался аналитик о своём решении?
Что они там могут изменить? Ничего.

3)
Выпущенный в срок продукт успешно прошёл приёмо-сдаточные испытания, которые показали, что в целом он позволяет Заказчику решать задачи, для которых создан.
Исполнители (включая тестеров), получили от него вознаграждение.

Чем тестировщиков не устраивает данный сценарий? (leftCh, измените его, верните зарплату Заказчику).

4)
Появились условия для усовершенствования/доработки программного решения. Тестировщики абсолютно не в курсе, что это за условия (может Заказчик усовершенствовал аппаратную часть, пропускную способность сети,...,приобрёл лицензии на более новые мощные библиотеки,...), какова концепция текущей реализации, какие пути её усовершенствования наметили аналитик и разработчики, но заявляют - костыли принялись писать (да, сразу видно, тестеры много понимают...)

Тестировщики не разбираются в программировании (или знают его намного хуже разработчиков).
Что они могут изменить в программном коде? Ничего.

Mystery_Andrew, вот мы и обсудили сценарий leftCh и пришли к выводу, что этот сценарий (с чертами имитации бурной трудовой деятельности, принципами типа во все дыры затычки, дефектами самомнения) тестировщики никогда не изменят.

Тестировщики (leftCh и команда), внимательно читайте свои служебные инструкции, права и трудовые обязанности, действуйте в рамках внутрикорпоративных регламентов. Не вы, а уборщица в вашей компании самый главный человек.

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

Выпущенный в срок продукт успешно прошёл приёмо-сдаточные испытания, которые показали, что в целом он позволяет Заказчику решать задачи, для которых создан.
Исполнители (включая тестеров), получили от него вознаграждение.

Чем тестировщиков не устраивает данный сценарий? (leftCh, измените его, верните зарплату Заказчику).

Тем, что тестировщик должен радеть за качество продукта, что должен биться всеми силами, чтобы продукт был как можно лучше, а не просто фиксировать баги.
Тем, что заказчик с радостью перейдет к конкурентам, которые смогут его заверить в превосходящем качестве продукта, а каждый сотрудник должен радеть за свою компанию и делать все (ну или почти все), чтобы она процветала. Если кому-то плевать на то, что будет с компанией, то надо гнать таких в шею.

Появились условия для усовершенствования/доработки программного решения. Тестировщики абсолютно не в курсе, что это за условия (может Заказчик усовершенствовал аппаратную часть, пропускную способность сети,...,приобрёл лицензии на более новые мощные библиотеки,...), какова концепция текущей реализации, какие пути её усовершенствования наметили аналитик и разработчики, но заявляют - костыли принялись писать (да, сразу видно, тестеры много понимают...)

Тестировщики не разбираются в программировании (или знают его намного хуже разработчиков).
Что они могут изменить в программном коде? Ничего.

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

На месте leftCh я бы попытался исправить ситуацию всеми возможными силами. Если в течение некоторого времени Вам не удастся хоть что-то изменить к лучшему, то бежать надо оттуда. Тем более тестеры сейчас много где нужны.

P.S. Не подумайте, что я хочу завысить свою значимость в компании, поднять свою самооценку и т.п., но тестировщик должен быть последней инстанцией в плане качества (выше только начальство). А программистов (не в обиду им будет сказано) надо воспитывать. Да, я тоже сначала столкнулся с непониманием, критикой и игнорированием со стороны программистов, когда устроился на новую работу. Раньше на моем проекте не было тестировщиков. Используя различные методы, мне удалось усмирить программистов, но для этого нужно быть пробивным и хоть слегка разбираться в психологии.

Mystery_Andrew, а вы используете в своей деятельности методику "проказницы мартышки" (нелогичных манипуляций в приложении), чтобы выявить проблемы нештатного поведения ПО? Попробуйте, у вас хорошо получится.

Mystery_Andrew, а вы используете в своей деятельности методику "проказницы мартышки" (нелогичных манипуляций в приложении), чтобы выявить проблемы нештатного поведения ПО?

Нелогичных -- это как раз таких, на которые разработчики отвечают "какой нормальный человек так будет делать", да?

Буквально вчера я нажатием одной "неправильной" кнопки в медиа-плеере VLC отправил винду в синий экран смерти.
Это нормально? Нет, это не нормально, даже если разработчик скажет "да кто вообще будет нажимать эту кнопку".
Потому что я нажал её нечаянно, а последствия оказались явно несопоставимые с масштабом моих ошибочных действий.

barancev, почему нечаянно (да и хорошо, что хоть так)... где ваше стратегическое мышление (я про полноту покрытия)?

Mystery_Andrew, а вы используете в своей деятельности методику "проказницы мартышки" (нелогичных манипуляций в приложении), чтобы выявить проблемы нештатного поведения ПО? Попробуйте, у вас хорошо получится.

Я стараюсь использовать все методики, которые мне известны

Mystery_Andrew, то как вы стараетесь, боретесь, бьётесь и радеете (стиль вашей рассеяной деятельности) напоминает зомбированного внутрикорпаративными психотренингами "винтика" с хорошо промытыми мозгами. А без фанатизма можно?