Баги-Шмаги - снос из темы об ошибках на интервью

Опаньки!!! Как такое вообще возможно, что стажер-тестер мало того, что пристает к девелоперам с “багами”, так даже вынуждает их фиксить баги?

Это скорее говорит не о плохом стажере, а об отсутствии поставленного процесса разработки - что камешек, скорее, в огород менеджеров.

3 лайка

Так то ж вчерашний стажер пишет в назидание стажеру завтрашнему. Как видит, так и пишет…

А если баг критический?

Тестер находит баг, узнает у кого нибудь “постарше”, действительно ли это баг, если это баг, заводит его, ставит ему Priority & Severity какие считает нужными и назначает на девелопера. Все. Его работа закончена. Добиваться от девелопера починки бага не задача тестера. Даже если баг критический.

2 лайка

На последнем месте в мои обязаннасти входило и нудно узнавать у програмистов на счет Fixing the bug раз в день. И помимо самого тестирования приходилось каждый вечер сдавать отчет о разных багах начальнику отдела разработок.
Рас на рас не приходится. В каждой фирме свои требования к тэстерам

1 лайк

А еще это все зависит на каком этапе проект. Вдруг это 2 или 3 цикл, а туда случайно попал файл с не той сборки.
В результате у нас вся команда тестирование пинает - т.к. баг блочит весь функционал.
А тут еще разные часовые пояса - и менеджмент на обеде.

Конечно надо срочно трусить дева - дать хоть какой то фикс - иначе простой будет очень дорого стоять.

It depends :slight_smile: Хотя на интервью, конечно же стоит делать то что нужно, а не фантазировать.

Скажите это стартапам из 10 человек, например, где вообще менеджеров как таковых нет :))))
Это будет называться “плохо поставленным процессом разработки” или “естественным этапом развития компании”?)

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

1 лайк

Да, это будет называться “плохо поставленным процессом разработки”. И это не зависит от количества штатных единиц. И не рассказывайте это человеку с очень долгим ИТ-стажем, работавшим в компаниях размером от 3-х человек (типа, семейный бизнес), до более 1000 (типа, международная корпорация). Увы, ни от размера, ни от статуса не зависит наличие нормальных условий и процессов разработки.

Где я говорил о “полноценном штате” или “неполноценном штате”? Вы, наверняка, знаете разницу между “штатной единицей” и “ролью”.
Я за последние полгода запустил несколько сайтов. Так вот когда я выполнял роль тестера, я тестировал сайт, регистрировал баги и назначал им “степень важности”. Когда я выполнял роль менеджера, я проверял и переназначал “степень важности” для каждого бага, когда я выполнял роль девелопера я исправлял эти баги. Если бы я найдя баг, начинал сам себя доставать по поводу исправления этого бага, я бы еще с первым бы сайтом возился.
То же самое было, когда мы работали втроем и тоже без штатных менеджеров.

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

1 лайк

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

То же самое относится к фразе “тестер должен находить баги” - очень многие руководители, особенно в стартапах, придерживаются принципа, что важно не количество зафайленных багов, а количество исправленных багов. И хотят видеть людей со “strong ownership attitude”. А этому в книжках почти не учат.
То есть по правильным книжкам, зачастую, от тестера якобы требуется просто искать баги и просто их репортить, а дальше там вроде как менеджеры разберутся, и если пофиксят - то перепроверить. Но на деле, когда я встречала таких тестеров, доводилось слышать от руководства, что “he is good, but not good enough”.

Может просто рынок меняется, вам виднее.

хм, дело тестера баг найти, пральна описать, поместить в баг трекинг систему. ну и поговорить с девелопером буде тот к тестеру обратится за разьяснениями. назначать приоритет - вообще не его дело. “добиваться” чего-то от девелопмент команды - вообще не его дело.

понятно, мы не берем короткие / маленькие проекты где девелоперы тестируют код и происходят тому подобный бардак.

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

1 лайк

Julles, Вы - не плохой тестер; Вы - очень и очень overqualified для этой позиции, и Вас, простите, с удовольствием используют.

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

А почему вы думаете, что я не знаю деталей проекта?))))
ПМ чаще со мной консультируется по тем или иным аспектам, как и ux designer, поскольку нюансов много, они сами со временем про какие-нибудь edge cases забывают, а у меня тестирование - каждый день.

Не согласна насчет “используют” кстати. Ведь чтобы добиться повышения, необходимо сперва доказать, что ты справишься с задачами более высокого уровня. А как это доказать, если тебе не будут давать таких задач? Да даже без повышения, просто иметь возможность вписать в резюме соответствующий опыт - тоже полезно. В вакансиях порой такие интересные сочетания встречаются в стиле “и швец, и жнец, и на дуде игрец”. (Я сейчас не говорю про automation, где все и проще, и сложнее одновременно).

1 лайк

В нашей компании такие люди быстро становились QA Analyst.
Ну естественно с большим уровнем зарплаты.

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

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

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

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

Я смотрела вакансии, QA Analysts требуется не так много, на порядок меньше, чем blackbox или (что логично) whitebox тестеров :-/
Чую, перл таки нужно учить)

Ну тут все от компании еще зависит.
Как было у нас - тестер - тестирует баги по готовым ТС.
Инженер - пишет ТС, пишет скрипты.
Синьйор инженер - пишет ТС, скрипты, знает архитектуру, может раздать задачи инженерам. Ведет собеседования и прочее.
Аналитик - принимает участие в UAT. Может проассесить баги. Т.е. он немного уже на грани ВА.
Т.е. не сказал бы, что требуется меньше - требуется другое. Мы были связаны с телекоммуникациями - потому аналитик имел очень сильные представления о мобильной связи, бизнесс процессах кастомера и прочее.

Менеджер - дает всем нагоняи или пряники :slight_smile:

Это все в теории. А если на проекте пару бизнес аналитиков, пачка девелоперов, бригада тестеров. (и у каждой группы свой лид).
Как ПМ за всем уследит? Да и как он уследит за всеми багами? Ему важен отчет - процент качества и т.д.

у каждой компании свои тараканы - только вчера с парнем разбирали тестовое задание которое ему прислали на обычную тестерскую позицию :

написать на джаве мульти поточный краулер который берет данние (линки) с ДБ и покрыть казгдую страницу тест кеисами (протестировать GUI)
понятно , что еше и репорт туда прикрутить