Рабочее: про взлетающий самолет
Мои новички, на которых я тут "не нарадовалась" (был постинг friends only), и на обучение которых я угробила последнюю пару рабочих недель, вчера вышли в боевую обстановку. У меня никогда не было случаев работы с командой неопытных тестировщиков, как-то все нормальные, продвинутые люди попадались. Поэтому я, как заправский паникер, сначала
( Read more... )
То есть это всегда аутсорсинг.
На аутсорсинг целиком отдают обычно только маленькие проекты (у больших проектов либо собственный QA заказчика, либо другой вендор. Обычно индийский и QA-ориентированный.)
То есть речь идет о небольших проектах, когда заказывают команду из N человек девелоперов и M тестеров. N >> M. И это хорошо, если вообще удается убедить неопытного заказчика, что тестирование должно быть 30% от усилий девелопмента для ин-хауз проекта для 4 секретарш и минимум 100% для коробочного.
Дальше со стороны заказчика выделяется человек, более-менее представляющий бизнес-процессы под именем "консультант" и вменяемый технический чувак, который следит, чтобы "эти русские" не понаписали чего левого.
Между техническим человеком и программистом сразу складывается любовь и взаимопонимание. Потом приходит консультант и начинается переписывание спек на лету в рабочем порядке. В общем, пока тестеры пишут тест-кейсы по утвержденной спеке, разработчики с благословения технических людей заказчика сделали уже все по-другому.
Хорошо, если спеку апдейтят. Обычно сообщают голосом или в чате и уже после того, как тестеры откроют десяток багов.
В результате часть времени отведенного на тестирование тратиться на одобную чепуху.
Дальше продукт, понятное дело, не укладывается в сроки или выходит с не тем качеством.
Люди заказчика к этому времени уже браться навек с программистами + все помнят тот десяток багов "не по делу", и когда срочно надо искать виноватого - понятно кто им оказывается.
Reply
во-первых все уже уяснили, что спеки на лету не правятся, а если правятся, то -только исключительно бизнес-аналитиками громко, так, чтобы все были в курсе. Этот момент хорошо отработан уже.
Во-вторых, увы - 20%, а не 30%, стандарт у нас такой. 30% - только если совсем все сложно.
но в любом случае это не объясняет то, почему сами тестеры-то чувствуют вину за баги ДО того, как тестирование закончилось
Reply
20% - возможно потому, что процесс давно отлажен.
У нас почти каждый проект все новое, начиная если не с предметной области, то с бизнес-процессов этого конеретного заказчика. Оборудования, окружения, того, с чем интегрируемся. Ну и распределенность добавляет рисков всегда.
Reply
кстати, вот да, именно это и объясняет это чувство вины!!!!
я понял! =) спасибо за просветление!!!
да, и по поводу 20% ты права, тут все отлажено, стандартизированно и QA-зированно =)
Reply
Reply
Reply
Leave a comment