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

[Case]

Была проблема.
Уткнулся в проблему переработки архитектуры командой разработки.
Разработчики приняли решения сменить архитектуру приложения (переп\работка начиная с сервера БД и выделение нового уровня в архитектуре).
Как результат серьёзные пересмотр процесса тестирования, сжатие сроков и ресурсов отпущеных на тестирование, выбор другого инструментария.
Кто нибудь сталкивался в подобными проблемами?
Как вели себя в такой ситуации когда переработка необходима, но влечёт за собой резкое падение качества работ по тестированию?

[Олешка]

Ок, пусть меняют все что хотят, я бы в такой ситуации зафиксировала функциональные требования к приложению и сосредоточилась на их тестировании. Идея в том, что независимо от технических деталей реализации проекта, требования высокого уровня по функциональности должны быть выполнены.

[Olga]

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

[Case]

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

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

[Ilka]

Поднимая давно забытую форумчанами тему...
Я в таких случаях
1. требую максимально возможного времени на тестирование;
2. составляю представление о новой архитектуре, выявляю наиболее вероятные проблемные места;
3. тестирую:
3.1 проблемные места архитектуры с максимальной интенсивностью минимальное время, стараясь покрыть наибольшее число рисков;
3.2 основной функционал тщательно.

Обоснование:
При срочном переходе на новую архитектуру очень вероятны ее недоработки.
Пока программисты дорабатывают архитектуру можно заняться тестированием основного функционала.

Выгоды:
Обычно такая тактика добавляет определенное время на тестирование сверх выторгованного в п. 1.
Протестированы и отлажены будут не только основные функциональные требования, но и покрыты некоторые риски связанные со сменой архитектуры.

[Case]

Пункт первый - время.
Время выхода никто не изменяет, как вы понимаете, требовать-то его можно, но вот откуда ему взяться.

Есть проект, планы разработки и тестирования. Потом план разработки мняется и давит на тестирование в сторону уменьшения времени. Как тут быть? Урезать необходимое тестирование? Отказываться от тестирования в запланированном объёме?

[Олешка]

Вопрос вечный... Читая книгу "Быстрое тестирование", наткнулась на умный мысль - выставить приоритеты по требованиям. И четко сказать начальству - нет времени - ок, но тогда - будет оттестировано не все. Идут на такой риск - вперед и с песней.

Кстати, а кто давит - менеджер проекта или руководство компанией? В первом случае есть шанс повлиять через руководство.

[Ilka]

Мне кажется, расставлять надо не только приоритеты требованиям, но и оценивать риски (что может произойти, потери в случае наступления риска).
Таким образом, получаем 2 линейки:
1. Требования, упорядоченные по приоритету;
2. Риски, упорядоченные по стоимости.

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

Однако, если в процессе тестирования выявлены серьезные ошибки в рамках второй линейки, выпуск будет задержан во избежание потери лица фирмы. Либо у тестера будет бумажка о том, что он предупреждал...

Таким образом, тестирование в рамках второй линейки не приветствуется менеджментом, разработчиками, но необходимо тестерам. (Отсюда и спешка при проверках).
Кроме того, это добавляет веса в команде.

[Ilka]

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

[Alex4all]

IMHO Время x Ресурсы x Качество должны приниматься во внимание в комплексе,
т.е.
ограничены по времени, но хотим не потерять в качестве - просим у руководства дополнительных ресурсов;
ограничены по времени, и нет ресурсов - даже менеджеру понятно, что качества гарантировать не сможем, в силу неполного тестового покрытия... Единственное, что можно посоветовать,- это хорошенько объяснить соотв. менеджеру в чем будет заключаться потеря качества и полусить от него на эту потерю согласие, желательно в письменном виде.