Тестер находит баг, узнает у кого нибудь “постарше”, действительно ли это баг, если это баг, заводит его, ставит ему Priority & Severity какие считает нужными и назначает на девелопера. Все. Его работа закончена. Добиваться от девелопера починки бага не задача тестера. Даже если баг критический.
На последнем месте в мои обязаннасти входило и нудно узнавать у програмистов на счет Fixing the bug раз в день. И помимо самого тестирования приходилось каждый вечер сдавать отчет о разных багах начальнику отдела разработок.
Рас на рас не приходится. В каждой фирме свои требования к тэстерам
А еще это все зависит на каком этапе проект. Вдруг это 2 или 3 цикл, а туда случайно попал файл с не той сборки.
В результате у нас вся команда тестирование пинает - т.к. баг блочит весь функционал.
А тут еще разные часовые пояса - и менеджмент на обеде.
Конечно надо срочно трусить дева - дать хоть какой то фикс - иначе простой будет очень дорого стоять.
Скажите это стартапам из 10 человек, например, где вообще менеджеров как таковых нет :))))
Это будет называться “плохо поставленным процессом разработки” или “естественным этапом развития компании”?)
У нас знакомые на днях сайт запустили, там девелоперы - они же продакт менеджеры, они же проджект менеджеры, они же тестеры, они же контент редакторы и т.п. А если бы собирали полноценный штат (со среднерыночными зарплатами), то до сих пор по своим предыдущим компаниям сидели и никакого стартапа.
Да, это будет называться “плохо поставленным процессом разработки”. И это не зависит от количества штатных единиц. И не рассказывайте это человеку с очень долгим ИТ-стажем, работавшим в компаниях размером от 3-х человек (типа, семейный бизнес), до более 1000 (типа, международная корпорация). Увы, ни от размера, ни от статуса не зависит наличие нормальных условий и процессов разработки.
Где я говорил о “полноценном штате” или “неполноценном штате”? Вы, наверняка, знаете разницу между “штатной единицей” и “ролью”.
Я за последние полгода запустил несколько сайтов. Так вот когда я выполнял роль тестера, я тестировал сайт, регистрировал баги и назначал им “степень важности”. Когда я выполнял роль менеджера, я проверял и переназначал “степень важности” для каждого бага, когда я выполнял роль девелопера я исправлял эти баги. Если бы я найдя баг, начинал сам себя доставать по поводу исправления этого бага, я бы еще с первым бы сайтом возился.
То же самое было, когда мы работали втроем и тоже без штатных менеджеров.
А еще в одной средних размеров международной компании, бизнес встал на пол-месяца, в том числе по причине того, что там тестеры доставали разработчиков по поводу исправления срочных критичных багов. После потери приличных денег, в компании изменился подход к тестированию, назначению приоритетов багам и их исправлению, да и вообще к процессу разработки.
Если играть словами по вашей терминологии, то тогда можно сказать, что люди, которым была назначена роль менеджера, не справились с этой ролью. И тогда, да, процесс не отлажен, поскольку не совсем верно подобраны люди. Можно также сказать, что на интерна рано взваливать обязанности проджект-менеджера, но это зависит от продукта, от людей, от компании. Никто не говорит, что это норма (особенно для крупной компании со сложными/многочисленными продуктами), но если это норма для данной компании, что подразумевает, что другие интерны/начинающие сотрудники с этим справляются, а конкретный интерн с этой ролью справиться не может, значит проблема не в компании, а в интерне. Потому что компания просто подберет других людей. А вот найдет ли человек, который не может или не хочет учиться, другую компанию - это вопрос.
То же самое относится к фразе “тестер должен находить баги” - очень многие руководители, особенно в стартапах, придерживаются принципа, что важно не количество зафайленных багов, а количество исправленных багов. И хотят видеть людей со “strong ownership attitude”. А этому в книжках почти не учат.
То есть по правильным книжкам, зачастую, от тестера якобы требуется просто искать баги и просто их репортить, а дальше там вроде как менеджеры разберутся, и если пофиксят - то перепроверить. Но на деле, когда я встречала таких тестеров, доводилось слышать от руководства, что “he is good, but not good enough”.
хм, дело тестера баг найти, пральна описать, поместить в баг трекинг систему. ну и поговорить с девелопером буде тот к тестеру обратится за разьяснениями. назначать приоритет - вообще не его дело. “добиваться” чего-то от девелопмент команды - вообще не его дело.
понятно, мы не берем короткие / маленькие проекты где девелоперы тестируют код и происходят тому подобный бардак.
А я вчера три user story написала. Донесла до руководства, что есть проблема, очертила варианты как ее можно решить, варианты решения были одобрены, ресурсы выделены, оставалось только подробно задачу сформулировать - ну я и тут помощь предложила, благо мне интересно попрактиковаться. Наверное я плохой тестер, которому скушно раз за разом файлить одни и те же баги из-за одной непродуманной вещи. Но какое же счастье, что никто не говорит, что это не мое дело и мне сюда нельзя))
для вас это безусловно хорошо. для проекта скорее плохо, что этим занимаетесь вы, не зная детали проекта. этим должен заниматься ПМ, который, например, в курсе нужд клиента и может правильно определить приоритеты.
А почему вы думаете, что я не знаю деталей проекта?))))
ПМ чаще со мной консультируется по тем или иным аспектам, как и ux designer, поскольку нюансов много, они сами со временем про какие-нибудь edge cases забывают, а у меня тестирование - каждый день.
Не согласна насчет “используют” кстати. Ведь чтобы добиться повышения, необходимо сперва доказать, что ты справишься с задачами более высокого уровня. А как это доказать, если тебе не будут давать таких задач? Да даже без повышения, просто иметь возможность вписать в резюме соответствующий опыт - тоже полезно. В вакансиях порой такие интересные сочетания встречаются в стиле “и швец, и жнец, и на дуде игрец”. (Я сейчас не говорю про automation, где все и проще, и сложнее одновременно).
я кагбе предполагаю основываясь на некоем опыте. ессно я взял типичную ситуацию - есть клиент, есть проект, который он заказал. есть ПМ, девелоперы, тестеры. еще имеется менеджмент компании. ПМ общается с клиентом и своим начальством. поэтому он может решить сколько ресурсов отдать сегодня на какую-то задачу. с учетом изменившихся нужд клиента (о чем стало известно после очередного митинга) и изменившейся ситуации в родной конторе (например грядет проект с боингом на 100 000 000). поэтому мотивы принятия решения - различны. девелопер хочет сделать хороший продукт или написать чистый код или освоить новую технологию, вы хотите сделать клиента счастливым пофиксив багу, а ПМ должен оптимально использовать ограниченый ресурс.
это просто пример того как оно бывает в общем. ваш случай может отличаться, но в целом если тестер делает работу ПМ или девелопера или саппорта и т.п. - это говорит о том, что процесс разработки не отлажен. и даже в этом случае - я пока не встречал девелопера или тестера, который регулярно общается с клиентом.
:)) вообще повышение происходит когда появляется свободная позиция - кто-то ушел или контора расширяется. и тогда смотрят кого выдвигать. я бы сказал, что выдвигают людей ответственных, грамотных и инициативных.
update - вот только подумал - ваша идея наверное справедлива если вы имеете в виду чисто технический рост, т.е. рост квалификаци как инженера. тогда да - хватайте задачи посложнее…
Я смотрела вакансии, QA Analysts требуется не так много, на порядок меньше, чем blackbox или (что логично) whitebox тестеров :-/
Чую, перл таки нужно учить)
Ну тут все от компании еще зависит.
Как было у нас - тестер - тестирует баги по готовым ТС.
Инженер - пишет ТС, пишет скрипты.
Синьйор инженер - пишет ТС, скрипты, знает архитектуру, может раздать задачи инженерам. Ведет собеседования и прочее.
Аналитик - принимает участие в UAT. Может проассесить баги. Т.е. он немного уже на грани ВА.
Т.е. не сказал бы, что требуется меньше - требуется другое. Мы были связаны с телекоммуникациями - потому аналитик имел очень сильные представления о мобильной связи, бизнесс процессах кастомера и прочее.
Менеджер - дает всем нагоняи или пряники
Это все в теории. А если на проекте пару бизнес аналитиков, пачка девелоперов, бригада тестеров. (и у каждой группы свой лид).
Как ПМ за всем уследит? Да и как он уследит за всеми багами? Ему важен отчет - процент качества и т.д.
у каждой компании свои тараканы - только вчера с парнем разбирали тестовое задание которое ему прислали на обычную тестерскую позицию :
написать на джаве мульти поточный краулер который берет данние (линки) с ДБ и покрыть казгдую страницу тест кеисами (протестировать GUI)
понятно , что еше и репорт туда прикрутить