Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 116
Чтобы не «грызлись» тестировщики и программисты, должен быть правильный управленец — опытный, мудрый и правильно просчитывающий минимум на ход вперед. Иначе — «Когда в товарищах согласья нет — на лад их дело не пойдет и выйдет из него не дело, а только мука...»
Знаете, пара моих хороших знакомых (один ведущий QA, другой — программист-разработчик, тимлид) независимо между собой считают, что между тестировщиками и программистами должно быть некое «противостояние».
Всему, безусловно, надо знать меру — т.е. это не должно быть конфликтом; но вот замечено, что когда отношения между разработкой/тестированием немного «в контрах» — это очень эффективно сказывается на рабочем процессе в целом. Возможно потому, что появляется некий азарт или личная заинтересованность сделать работу лучше.
Всему, безусловно, надо знать меру — т.е. это не должно быть конфликтом; но вот замечено, что когда отношения между разработкой/тестированием немного «в контрах» — это очень эффективно сказывается на рабочем процессе в целом. Возможно потому, что появляется некий азарт или личная заинтересованность сделать работу лучше.
Вы же согласитесь, что здоровая «контра» подразумевает «Ну что, ребята, прочешем продукт вдоль и поперек, чтоб ему жарко стало», а не «щас я им багов наколбашу и домой уйду, а они пусть разбираются, если нормально кодить не могут».
Наоборот тоже: «Ого, молодцы, сколько всего понаходили» против «опять багов навалили, достало уже»
Наоборот тоже: «Ого, молодцы, сколько всего понаходили» против «опять багов навалили, достало уже»
Вот знаете — нечто среднее на самом деле оптимально :-)
Добавлю. Всё это должно происходить под контролем тим лида проекта. Который не будет оставлять разность во взглядах тестировщиков/программистов на самотек, а сможет грамотно сказать, чья точка зрения тут правильная (баг это или фича, например, можно ли закрыть баг-таск или сменить его категорию, и т.п.)
Вообще, на 99% конфликты возникают там, где людям находящимся на одном уровне компетенции говорят «ну вы там как-нить сам договоритесь». Иногда они договариваются, но в очень, очень многих случаев возникает конфликт — из-за того что непонятно, чье мнение главнее.
Вообще, на 99% конфликты возникают там, где людям находящимся на одном уровне компетенции говорят «ну вы там как-нить сам договоритесь». Иногда они договариваются, но в очень, очень многих случаев возникает конфликт — из-за того что непонятно, чье мнение главнее.
Согласна.
Рыба с головы подгнивать начинает.
Я бы указанную причину разнонаправленности целей дополнила — либо команде не интересно ничего кроме взаимного гнобления, либо низкий уровень ответственности, либо у членов команды слишком много свободного времени, которое они позволяют себе тратить на поиски виноватых.
В любом случае исправить или привентировать ситуацию в силах только менеджер/тимлидер/нанимающий на работу.
Если в компании не принято подпитывать интерес сотрудников — поощрять их стремление развиваться, исследовать, искать оптимальные решения, никакая локальная инициатива дело не спасет. А интерес сотрудников будет подпитываться доступным способом — мереньем багами и поисками главного вредителя.
Так же и с ответственностью. Если один сотрудник, более менее осознающий ответственность за свою работу, понимает, что на качество его работы влияет и чужая работа. И попытается посодействовать коллегам в улучшении качества ИХ деятельности, тем самым улучшая своё, а коллегам это, мягко скажем, не нужно и иногда болезненно, локальная инициатива так же завянет.
Ну и терки на тему «я нафигачил тыщу багов за день в коде который вы месяц рожали» всегда отжирают кучу времени. Если менеджер не в состоянии эти «утечки» обнаруживать и грамотно локализовывать, то команде это и подавно не нужно.
Рыба с головы подгнивать начинает.
Я бы указанную причину разнонаправленности целей дополнила — либо команде не интересно ничего кроме взаимного гнобления, либо низкий уровень ответственности, либо у членов команды слишком много свободного времени, которое они позволяют себе тратить на поиски виноватых.
В любом случае исправить или привентировать ситуацию в силах только менеджер/тимлидер/нанимающий на работу.
Если в компании не принято подпитывать интерес сотрудников — поощрять их стремление развиваться, исследовать, искать оптимальные решения, никакая локальная инициатива дело не спасет. А интерес сотрудников будет подпитываться доступным способом — мереньем багами и поисками главного вредителя.
Так же и с ответственностью. Если один сотрудник, более менее осознающий ответственность за свою работу, понимает, что на качество его работы влияет и чужая работа. И попытается посодействовать коллегам в улучшении качества ИХ деятельности, тем самым улучшая своё, а коллегам это, мягко скажем, не нужно и иногда болезненно, локальная инициатива так же завянет.
Ну и терки на тему «я нафигачил тыщу багов за день в коде который вы месяц рожали» всегда отжирают кучу времени. Если менеджер не в состоянии эти «утечки» обнаруживать и грамотно локализовывать, то команде это и подавно не нужно.
— от тестировщиков звучат фразы «наколбасил им багов, пусть теперь разгребают»
Немного некрасиво, но ничего страшного в этом нет. Это лишь личное мнение человека, который выполнил свою работу, а остальное его не волнует. Это нормально.
— от программистов слишком часто звучит презрительное «это не баг»
В это случае пинать нужно менеджера, так как скорее всего такой ответ программиста означает, что тесткейс, с которым в данном случае работал тестировщик, неверен. Соответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика. Он лишь проверил тесткейс и зарепортил проблему, за это ему платят.
— программист не проверяет результат своей работы перед передачей в тестирование
Это, конечно, плохой признак. Но в любом случае, это проблема команды программистов, а не тестировщиков. Тестировщикам должно быть наплевать, проверяют ли программисты свой код, или нет. Тестировщики должны лишь проходить по своим тесткейсам и репортить результат. Менеджер сам уже разберется, почему это у такого-то программиста постоянно так много тупых повторяющихся дефектов.
— тестировщики заносят баги, не интересуясь их дальнейшей судьбой
Тут все зависит от процесса тестирования. Если процесс организован так, что цель тестировщика лишь пройти по списку тесткейсов и зарепортить результат, то тестировщик действительно вполне имеет моральное право забить на этот дефект после внесения его в отчет. В следующей итерации тестирования все равно этот же дефект же всплывет, так как тестировщик будет делать те же самые действия.
Если же процесс привязывает тестировщика к каждому дефекту, то тут да, волей-неволей придется интересоваться судьбой дефекта. иначе он не будет закрыт. В таком случае бороться с теми, кто не интересуются судьбой дефектов, очень просто — достаточно завести любую более-менее продвинутую программу трекинга дефектов, и менеджеру все будет видно как на ладони.
— эффективность работы тестировщиков измеряется количество найденных багов, а мера качества работы программистов обратно зависит от этого количества
…
В то время, как только подход «максимум найти и тот же максимум обезвредить» эффективен, на мой взгляд, и работает действительно на цели продукта.
Не нужно специально искать максимум дефектов. Если тестировщики нашли ноль дефектов, это не значит, что они плохие. Тестировщику достаточно проверить все тесткейсы по тестплану, и отрапортовать «все OK» или «такие-то тесткейсы проходят неверно, вот скриншот и логи».
В общем, команда тестирования не должна нести ответственность за дефекты в продукте. За это отвечают разработчики. Команда тестирования несет ответственность только за то, что их репорт соответствует действительности. То есть они прошлись по всем тесткейсам, и напротив каждого написали в отчете «проверено с таким-то результатом».
Если какая-то ситуация не покрывается тесткейсом, но тестировщик видит, что тут возможны дефекты, то ему нужно обратить внимание менеджера на это, и, получив его разрешение, дописать новый тесткейс, или менеджер назначит другого кто допишет. При следующей итерации тестирования эта ситуация уже будет проверяться тестировщиком.
Да, бюрократия конечно… но именно это и будет наиболее полезно для продукта. И конфликты с разработчиками сведутся к минимуму, так как разработчику глупо обижаться например на программу автотестирования (JMeter, и т.д.), а при правильно организованном процессе тестировщик сам по себе играет роль как раз такой программы.
А откуда берутся тест-планы? Их составляют и модифицируют все те же QA-инженеры. Всем вроде ясно, что априори невозможно составить достаточно полный тест-план, что тест-план эволюционирует вместе с продуктом по мере уточнения требований.
Если тестировщик достаточно трепетно относится к продукту, то он будет сообщать о проблемах не зафиксированных в тест-плане. Так же как и программист будет заботиться о всяких мелочах, даже если их нет в спецификации.
Если тестировщик достаточно трепетно относится к продукту, то он будет сообщать о проблемах не зафиксированных в тест-плане. Так же как и программист будет заботиться о всяких мелочах, даже если их нет в спецификации.
Да, работа с тест планом должна быть частью процесса. Но вовсе не обязательно, что их составляют те же QA-инженеры, что и проводят тестирование. Часто их составляют аналитики, разработчики (тимлиды), да и сами менеджеры тоже могут подключаться. Держит под контролем этот процесс QA менеджер, который несет ответственность за соответствие тест-плана проектным спекам.
Например, часто IT компании в Европе пишут тестпланы силами своих штатных сотрудников, а непосредственно тестирование проводят компании-аутсорсеры из Индии.
Например, часто IT компании в Европе пишут тестпланы силами своих штатных сотрудников, а непосредственно тестирование проводят компании-аутсорсеры из Индии.
>> Немного некрасиво, но ничего страшного в этом нет. Это лишь личное мнение человека, который выполнил свою работу, а остальное его не волнует. Это нормально.
Вы знаете, это смотря что при этом подразумевает говорящий. Если это просто формулировка такая, типа как друзья между собой общаются: «Въехал вчера в зад джипу на перекрестке» — «Ну курица ты, что сказать», то конечно ничего страшного нет. Но если это всерьез говорится, то такие высказывания сбивают с толку неопытных тестеров, да и подход такой не способствует эффективной работе.
>> Cоответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика.
Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»
>>Это, конечно, плохой признак. Но в любом случае, это проблема команды программистов, а не тестировщиков.
то же самое, что и в предыдущем пункте
>>Тут все зависит от процесса тестирования.
Согласна. Но в гибком процессе эффективнее, чтобы тестировщики были в курсе дальнейшей судьбы дефектов.
Вообще, я Вам так скажу: это все имеет право на жизнь, если это не клиника. Но намного здоровее и продуктивнее работать с людьми заинтересованными в успехе своего дела. Да, это трудно обеспечить в жестком процессе, где шаг вправо не поощряется.
Если говорить о том, что "«нефиг заниматься не своим делом, за это не похвалят» — то тут у меня такое мнение: все, чему ты учишься, добавляет тебе стоимость (карму, если хотите). В этом проекте тебя считали выскочкой и шикали — в другой компании тебя с руками оторвут и денег дадут больше, и ответственности.
Такой момент: набирая себе людей (я руковожу отделом тестирования), я смотрю на то, в каких проектах им доводилось работать. Если в таких, как Вы описываете, то мне такие не нужны. Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.
Мой выбор такой, именно поэтому и атмосфера у меня в отделе такая, что ничего из описанного в посте нет.
Вы знаете, это смотря что при этом подразумевает говорящий. Если это просто формулировка такая, типа как друзья между собой общаются: «Въехал вчера в зад джипу на перекрестке» — «Ну курица ты, что сказать», то конечно ничего страшного нет. Но если это всерьез говорится, то такие высказывания сбивают с толку неопытных тестеров, да и подход такой не способствует эффективной работе.
>> Cоответственно нужно изменить тесткейс. Если же все же это дефект, то пусть уже менеджер разбирается с тимлидом, это не проблема тестировщика.
Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»
>>Это, конечно, плохой признак. Но в любом случае, это проблема команды программистов, а не тестировщиков.
то же самое, что и в предыдущем пункте
>>Тут все зависит от процесса тестирования.
Согласна. Но в гибком процессе эффективнее, чтобы тестировщики были в курсе дальнейшей судьбы дефектов.
Вообще, я Вам так скажу: это все имеет право на жизнь, если это не клиника. Но намного здоровее и продуктивнее работать с людьми заинтересованными в успехе своего дела. Да, это трудно обеспечить в жестком процессе, где шаг вправо не поощряется.
Если говорить о том, что "«нефиг заниматься не своим делом, за это не похвалят» — то тут у меня такое мнение: все, чему ты учишься, добавляет тебе стоимость (карму, если хотите). В этом проекте тебя считали выскочкой и шикали — в другой компании тебя с руками оторвут и денег дадут больше, и ответственности.
Такой момент: набирая себе людей (я руковожу отделом тестирования), я смотрю на то, в каких проектах им доводилось работать. Если в таких, как Вы описываете, то мне такие не нужны. Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.
Мой выбор такой, именно поэтому и атмосфера у меня в отделе такая, что ничего из описанного в посте нет.
Я здесь говорю о явном отфутболивании, которое является клиническим случаем. А проблема это или не проблема тестировщика — зависит от того, как он относится к проблемам команды и проекта. Можно действительно делать то, за что платят, и спокойно переоткрывать баги по несколько раз, пока менеджер не придет, а можно самому прийти к менеджеру и сказать: «че за фигня? Я время трачу на разборки, хотя мог бы погонять приложение эксплоративно или чего ещё полезное сделать»
Не нужно ходить к менеджеру и говорить «че за фигня». Если отфутболивание имеет место, то тестировщику нужно просто повторно ассигнить дефект не на программиста, а на самого менеджера.
Причем это должно быть прописано в правилах, описывающих процесс тестирования. Это же несложно.
Вы знаете, это смотря что при этом подразумевает говорящий. Если это просто формулировка такая, типа как друзья между собой общаются: «Въехал вчера в зад джипу на перекрестке» — «Ну курица ты, что сказать», то конечно ничего страшного нет. Но если это всерьез говорится, то такие высказывания сбивают с толку неопытных тестеров, да и подход такой не способствует эффективной работе.
Уставший человек в конце рабочего дня поставил жирную точку, и высказал своим коллегам свое мнение о состоянии проекта. Лучше было бы промолчать, но мы же все люди, что тут такого? Если кого-то неопытного он с толку этим и сбил, так это нормально, пусть неопытный учится, и становится опытным. В любом случае, на работе это не должно сказаться вообще никак.
P.S. Вышесказанное верно, если в том человеке не было явной агрессии, но это уже другая тема (резко агрессивных людей нельзя пускать в коллектив людей, работающих головой, есил они уж нужны компании, например гении, то пусть работают изолированно).
Ну это происходит на корпоративном уровне.
А на уровне OpenSource всё обстоит гораздо лучше. Тестеры пишут багрепорты, программеры выпускают багфиксы. В итоге все довольны.
А на уровне OpenSource всё обстоит гораздо лучше. Тестеры пишут багрепорты, программеры выпускают багфиксы. В итоге все довольны.
С коммерческой разработкой нельзя сравнивать. В OpenSource обычно нет жестких сроков, начальство не прессует ни разработчиков, ни тестировщиков, ответственности тоже особой ни у кого ни перед кем нет. Кто-то зарепортил дефект, программисты ему сказали спасибо. Все спокойно, никого зарплаты не лишили, но никто ничего и не получил. Чего волноваться-то и конфликтовать? Что-то или кто-то не нравится — иди в другой открытый проект.
P.S. Я не имею в виду OpenSource проекты, которые выкуплены коммерческими компаниями и фондами. Там люди работают за деньги, часто немалые, и там-таки тот же прессинг и такие же дедлайны, что и в коммерческих разработках, со всеми вытекающими.
P.S. Я не имею в виду OpenSource проекты, которые выкуплены коммерческими компаниями и фондами. Там люди работают за деньги, часто немалые, и там-таки тот же прессинг и такие же дедлайны, что и в коммерческих разработках, со всеми вытекающими.
Тестеры в опенсорсе? Не так много проектов где все так радужно, чаще картина другая: Какой то пользователь нашел баг и отписался о баге на локальном форме или хабре. А то и вовсе забил. Разработчик случайно уивидел багу и подумал что когданить починит. Кто сознательный отметил в багтрекере. И это не факт что разработчик сразу пойдет ее фиксить, у него как правило, куча фич интересных еще не написано.
Когда же техпроцесс выходит на серьезный уровень за исключением оперативности выхода патчей, все становится очень похожим на корпоративную разработку. Разве что иногда чуток бюрократии поменьше.
Когда же техпроцесс выходит на серьезный уровень за исключением оперативности выхода патчей, все становится очень похожим на корпоративную разработку. Разве что иногда чуток бюрократии поменьше.
Эээ
По-моему точно так же обстоит, только программисты еще могут на многие баги забивать, ибо они просто не могут их воспроизвести. Ну например мне лично тяжеловато воспроизводить баги, возникающие в Макоси
По-моему точно так же обстоит, только программисты еще могут на многие баги забивать, ибо они просто не могут их воспроизвести. Ну например мне лично тяжеловато воспроизводить баги, возникающие в Макоси
Главное чтобы в команде было понимание того, что у тестера и программиста одна общая задача — предоставить качественный продукт клиенту, которым можно гордиться всем сотрудникам принимающим участие в разработке и тестировании.
Девушка-программист, да еще и смотрит Гран-При Формулы 1. Вы замужем?
А вообще я видел не раз ситуации с конфликтами меджу тестировщиками и программистами, и даже сам не раз участвовал по молодости, причем с обоих сторон. Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида). Разборки при этом между программистом и тестировщиков не допускаются, каждая сторона работает с менеджером.
А так да, если резвый джуниор-тестер заассигнил тупованый дефект типа «выключил сервер, захожу на любую страницу сайта, вижу белый экран» на резвого же джуниора-программиста, а потом еще в курилке будет кричать что кодеры ламеры, то и до мордобоя дойти может. Все же живые люди, это нужно учитывать руководству и управлять рисками. Если же в команде доверительные и слаженные отношения, тогда могут и напрямую дефекты ассигнить, если текущий процесс разработки это позволяет.
А так да, если резвый джуниор-тестер заассигнил тупованый дефект типа «выключил сервер, захожу на любую страницу сайта, вижу белый экран» на резвого же джуниора-программиста, а потом еще в курилке будет кричать что кодеры ламеры, то и до мордобоя дойти может. Все же живые люди, это нужно учитывать руководству и управлять рисками. Если же в команде доверительные и слаженные отношения, тогда могут и напрямую дефекты ассигнить, если текущий процесс разработки это позволяет.
Такие конфликты нужно предотвращать, подбирая правильных людей в команду и создавая правильную атмосферу. Тогда отношения скорее станут доверительными и слаженными.
Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»
Это sofy skills, которые тоже очень важны при найме специалиста.
В моей прошлой компании приходилось набирать по 20 человек за месяц на новые проекты, сложно было смотреть ещё и на отношение человека к работе, потому что на рынке специалисты вообще дефицит. Но, тем не менее, отказывали потенциальным вирусам.
И исходить правильное отношение к работе и к коллегам должно от менеджера, в первую очередь. Если он, конечно, не координатор работ, а действительно человек, отвечающий за свой проект.
Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»
Это sofy skills, которые тоже очень важны при найме специалиста.
В моей прошлой компании приходилось набирать по 20 человек за месяц на новые проекты, сложно было смотреть ещё и на отношение человека к работе, потому что на рынке специалисты вообще дефицит. Но, тем не менее, отказывали потенциальным вирусам.
И исходить правильное отношение к работе и к коллегам должно от менеджера, в первую очередь. Если он, конечно, не координатор работ, а действительно человек, отвечающий за свой проект.
Буквально сегодня рассказывали историю, как в одну успешную компанию не взяли гениального архитектора потому, что он прямо на собеседовании заявил: «Я не приемлю изменений. Ни одно изменение ни приводит к добру в проекте. Всегда с ними жестко боролся и буду»
Вы мыслите категориями менеджера, а теперь пожалуйста посмотрите на это категориями бизнеса. Если архитектор действительно гениален, значит это известный человек, его можно показывать заказчикам, брать под его имя проекты по очень высоким рейтам, и т.д. И заказчики будут счастливы платить, еще бы, ведь их проект будет проектировать сам Х!
Поверьте, настоящего гения компания не упустила бы никогда, так как он один может выдавать такие решения, которые толпа не-гениев и за годы работы не сделает. Если этого человека в Вашем случае не взяли, значит это говорит только о том, что он (или она) на самом деле или не был гениальным архитектором, или просил неадекватно много денег.
Но речь не об этом. Моя мысль в том, что правильно организованный процесс разработки, включая процесс тестирования, способен свести на нет влияние подавляющего большинства вирусов и тараканов в головах. Не нужно требовать от людей полной лояльности, любви к проекту, и т.д. Но нужно их обеспечить четкими инструкциями что делать в тех или иных случаях. Вот где-где, а в QA это сделать на порядок проще, чем в программизме. То есть, нужно построить машину, работающий механизм, а строить в офисе комфортный санаторий — это уже вторично, хотя тоже не помешает.
Вы в аутсорсинге работаете?
Я мыслю категориями бизнеса, только другого. Если этот продукт моя компания выпустит под своим именем, то ей критичен каждый вздох каждого члена команды. Гениальная архитектура не спасет продукт, если команда будет противостоять изменениям, которые требует рынок от продукта.
Про четкие инструкции — повторюсь: «Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.»
Конечно же, зависит от бизнеса компании, Вы правильно заметили. В аутсорсинге продается предсказуемость. В продуктах — решает лояльность и любовь к продукту.
Я мыслю категориями бизнеса, только другого. Если этот продукт моя компания выпустит под своим именем, то ей критичен каждый вздох каждого члена команды. Гениальная архитектура не спасет продукт, если команда будет противостоять изменениям, которые требует рынок от продукта.
Про четкие инструкции — повторюсь: «Мне дорого держать 10 исполнителей и менеджера-координатора над ними. Лучше взять 5 специалистов, которые будут не только тесты проходить, но и писать их, и приоритеты расставлять, и метрики собирать, и с программистами коммуницировать, и с дизайнерами, и с пользователями.»
Конечно же, зависит от бизнеса компании, Вы правильно заметили. В аутсорсинге продается предсказуемость. В продуктах — решает лояльность и любовь к продукту.
Работаю не в аутсорсе, раньше работал. Последние два года работаю на клиента, у которого как раз свой продукт, и этот продукт уже более 10 лет на рынке.
Если команда противится изменениям, значит нужно выслушать обоснования, почему она противится. Очень вероятно, что эти обоснования весьма весомы, и к ним нужно прислушаться. Далее. Маловероятно, чтобы «рынок требовал» от продукта изменения в архитектуре. Рынок обычно диктует бизнес-требования. И если архитектор действительно опытен, но его архитектура достаточно гибка, чтобы можно было расширять продукт согласно этим требованиям.
Далее, я не предлагаю нанять 10 исполнителей + менеджера над ними. Я предлагаю построить процесс таким образом, чтобы существующие 5 специалистов могли работать так, чтобы конфликтоопасные ситуации не возникали. Вы же предлагаете возложить на людей тяжкий груз борьбы с возможными проблемами… Не лучше ли таких ситуаций не допускать вообще? Давать спецам и писать документы, и тестить, и общаться с кучей разного народа конечно можно, но это должно быть организованно, системно, ходы должны быть просчитаны. Это вполне возможно сделать, и делается.
Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей. Нужно признать, что все работают за деньги, то есть продают компании свое рабочее время, и за перспективы. Только в этом случае процесс будет стабильным. Лояльность и любовь к работе/компании/продукту, как говорят на западе, это способ платить меньше денег, и при этом требовать больший объем работы. Это не хороший путь, на это нельзя делать ставку.
Если команда противится изменениям, значит нужно выслушать обоснования, почему она противится. Очень вероятно, что эти обоснования весьма весомы, и к ним нужно прислушаться. Далее. Маловероятно, чтобы «рынок требовал» от продукта изменения в архитектуре. Рынок обычно диктует бизнес-требования. И если архитектор действительно опытен, но его архитектура достаточно гибка, чтобы можно было расширять продукт согласно этим требованиям.
Далее, я не предлагаю нанять 10 исполнителей + менеджера над ними. Я предлагаю построить процесс таким образом, чтобы существующие 5 специалистов могли работать так, чтобы конфликтоопасные ситуации не возникали. Вы же предлагаете возложить на людей тяжкий груз борьбы с возможными проблемами… Не лучше ли таких ситуаций не допускать вообще? Давать спецам и писать документы, и тестить, и общаться с кучей разного народа конечно можно, но это должно быть организованно, системно, ходы должны быть просчитаны. Это вполне возможно сделать, и делается.
Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей. Нужно признать, что все работают за деньги, то есть продают компании свое рабочее время, и за перспективы. Только в этом случае процесс будет стабильным. Лояльность и любовь к работе/компании/продукту, как говорят на западе, это способ платить меньше денег, и при этом требовать больший объем работы. Это не хороший путь, на это нельзя делать ставку.
Оставим в покое архитектора. Я вполне понимаю, почему в этой конкретной компании такой специалист бы принес больше вреда, чем пользы. А разговор о сферическом архитектора не имеет смысла.
>> Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей.
Требовать постфактум нельзя, конечно. Но можно а) не брать таких, для которых это противно по природе, и б) создать и поддерживать такую атмосферу.
Про меньше денег никто не говорит. И про объем работы тоже. Речь о качестве. В которое входит и скорость. И о человеческом факторе. Который неминуем. Есть 2 пути им управлять:
— построить минимально человекозависимые процессы — это то, о чем Вы говорите
— держать баланс между жесткими процессами и человеческими отношениями — это то, о чем говорю я
Оба имеют право на жизнь. В обоих важно не запустить один раз и полагаться, что само выживет, а постоянно ревизировать, выявлять проблемы, оздаравливать.
Интересно посчитать, сколько тратится на поддержку в обоих случаях и какой реально эффективнее. У меня таких цифр нет, но я верю и работаю по второму. Это не означает отсутствие процессов. Это означает, что в момент принятия решения у человека больше свободы, но он адекватен по дефолту, и, следовательно, с высокой вероятность. выберет не один из предписанных, а третий, более эффективный путь.
В обоих вариантах, кстати, клиники, которую я описываю в посте, как проблемы не возникнет.
А если проблема существует (о чем свидетельствуют рассказы людей), значит не умеют ни процессы настроить, ни с людьми работать. И это плохо.
>> Лояльность и любовь к продукту, конечно, не помешает, но нельзя требовать это от людей.
Требовать постфактум нельзя, конечно. Но можно а) не брать таких, для которых это противно по природе, и б) создать и поддерживать такую атмосферу.
Про меньше денег никто не говорит. И про объем работы тоже. Речь о качестве. В которое входит и скорость. И о человеческом факторе. Который неминуем. Есть 2 пути им управлять:
— построить минимально человекозависимые процессы — это то, о чем Вы говорите
— держать баланс между жесткими процессами и человеческими отношениями — это то, о чем говорю я
Оба имеют право на жизнь. В обоих важно не запустить один раз и полагаться, что само выживет, а постоянно ревизировать, выявлять проблемы, оздаравливать.
Интересно посчитать, сколько тратится на поддержку в обоих случаях и какой реально эффективнее. У меня таких цифр нет, но я верю и работаю по второму. Это не означает отсутствие процессов. Это означает, что в момент принятия решения у человека больше свободы, но он адекватен по дефолту, и, следовательно, с высокой вероятность. выберет не один из предписанных, а третий, более эффективный путь.
В обоих вариантах, кстати, клиники, которую я описываю в посте, как проблемы не возникнет.
А если проблема существует (о чем свидетельствуют рассказы людей), значит не умеют ни процессы настроить, ни с людьми работать. И это плохо.
В продуктах — решает лояльность и любовь к продукту
Если разработчики например делают компьютерные игры, то могу это допустить. Молодым ребятам это обычно интересно — эльфы, гномы и т.д., и могут работать на энтузиазме. Тестировщикам тоже может быть интересно рубить орков целый день, изредка отчитываясь о дефектах…
Но на все проекы это нельзя проецировать. Как думаете, интересно ли программисту из года в год заниматься одним и тем же бухгалтерским пакетом? Стоит ли ожидать любви к такому продукту? А ведь таких продуктов большинство. Так что IMHO все же системный подход решает.
если Вы про Иннову, то на сегодня мы не разрабатываем игры, а лишь паблишим. там совершенно про другое все.
>> Тестировщикам тоже может быть интересно рубить орков целый день, изредка отчитываясь о дефектах…
О, как же ошибочно мнение мира разработки «человеческого софта» о геймдеве. Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.
Теперь про «человеческий софт». Наш отдел разработки делает продукты, которые к играм с точки зрения пользователя имеет отношение очень слабое. Например, биллинг. Сложная финансовая и юридическая часть к оркам и эльфам имеет отношение слабое, всего лишь айдишниками товаров. (бухгалтеров и юристов за сказочных существ не считаем :)). Им интересно решать задачи. Рефакторить для совершенствования. Предлагать решения. (Конечно же, с ограничением, чтоб не разрабатывать ради разработки).
В моей прошлой компании — аутсорс «человеческого софта» — работали и в многолетних проектах. Не бухгалтерский пакет, конечно, но американская система подачи аппликейшнов в FDA тоже не очень весела, поверьте.
И не было там ни отфутболивания, ни презрения, ни высокомерия, ни «кто больше наделает». Были жесткие процессы, потому что объемы и повторяемость. Но были и люди.
>>Так что IMHO все же системный подход решает.
если Вы системным подходом решаете проблему, о которой я говорю, отлично!
>> Тестировщикам тоже может быть интересно рубить орков целый день, изредка отчитываясь о дефектах…
О, как же ошибочно мнение мира разработки «человеческого софта» о геймдеве. Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.
Теперь про «человеческий софт». Наш отдел разработки делает продукты, которые к играм с точки зрения пользователя имеет отношение очень слабое. Например, биллинг. Сложная финансовая и юридическая часть к оркам и эльфам имеет отношение слабое, всего лишь айдишниками товаров. (бухгалтеров и юристов за сказочных существ не считаем :)). Им интересно решать задачи. Рефакторить для совершенствования. Предлагать решения. (Конечно же, с ограничением, чтоб не разрабатывать ради разработки).
В моей прошлой компании — аутсорс «человеческого софта» — работали и в многолетних проектах. Не бухгалтерский пакет, конечно, но американская система подачи аппликейшнов в FDA тоже не очень весела, поверьте.
И не было там ни отфутболивания, ни презрения, ни высокомерия, ни «кто больше наделает». Были жесткие процессы, потому что объемы и повторяемость. Но были и люди.
>>Так что IMHO все же системный подход решает.
если Вы системным подходом решаете проблему, о которой я говорю, отлично!
Им интересно решать задачи. Рефакторить для совершенствования. Предлагать решения. (Конечно же, с ограничением, чтоб не разрабатывать ради разработки).
Вы, вероятно, говорите о программистах, с ними проще немного. Но в данной теме речь идет и о тестировщиках. Неужели они любят такой продукт, причем настолько, что эта любовь все решает и принципиально важна для работы, как Вы написали выше?
Вообще, Вы пишите очень правильные вещи, заметен высокий уровень знаний. Очень даже. Так что я даже боюсь вступать в спор… Просто по моим наблюдениям те команды, которые делают ставку на энтузиазм, лояльность, и интерес к работе, обычно имеют весьма и весьма серьезную текучку кадров. Ибо это все весьма нестабильно. И наоборот, команды с проработанным процессом и формальными отношениями в работе (вплоть до бюрократизма) весьма стабильны, и в большинстве классов задач очень эффективны. Конечно, на, скажем, рисковых проектах класса «стартап» такое работать не будет, это ниша для фанатов… но всему свое место.
>Вы, вероятно, говорите о программистах, с ними проще немного. Но в данной теме речь идет и о тестировщиках. Неужели они любят такой продукт, причем настолько, что эта любовь все решает и принципиально важна для работы, как Вы написали выше?
Я отвечу вам с позиции простого тестировщика. В любом проекте, будь это даже бухгалтерский пакет — всегда есть какая-нибудь внутренняя задача, логику которой приятно раскрутить в голове на уровне абстракций.
Поверьте, внезапное «озарение» о том как работает приложение приносит не меньше удовольствие, чем вид работающего кода, после двух бессонных ночей.
Мораль проста: тестировщики не роботы, сверяющие функционал со спецификацией и мы также ищем моральное удовлетворения от качественного (не количественного) решения поставленных задач.
Я отвечу вам с позиции простого тестировщика. В любом проекте, будь это даже бухгалтерский пакет — всегда есть какая-нибудь внутренняя задача, логику которой приятно раскрутить в голове на уровне абстракций.
Поверьте, внезапное «озарение» о том как работает приложение приносит не меньше удовольствие, чем вид работающего кода, после двух бессонных ночей.
Мораль проста: тестировщики не роботы, сверяющие функционал со спецификацией и мы также ищем моральное удовлетворения от качественного (не количественного) решения поставленных задач.
>Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.
Думаю достойно отдельного поста :)
Думаю достойно отдельного поста :)
>Я рассказывала на майской конференции по тестированию о том, что на самом деле делают мои ребята (те, что играми занимаются) на работе. Если интересно — могу рассказать подробнее.
Думаю достойно отдельного поста :)
Думаю достойно отдельного поста :)
вот ещё, что подумалось:
>>Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида).
Это сильно увеличивает цикл работы над одной ошибкой. Если мы не можем себе позволить ждать, пока менеджер пройдется по багам (раз в день или в конце итерации), то единственный выход — назначать баги напрямую. И тут по-любому возникнет «не на того назначил», «я просто забыл задеплоить, это не баг, перепроверьте». Такие ситуации не перерастают в конфликты только, если люди адекватные и отношения нормальные.
К примеру, у нас баг, найденный на продакшне, как правило, фиксится и выкатывается в тот же день. Это означает быстрый фикс и быстрое регрессионное тестирование. Тут нельзя работать через менеджера.
В то же время, я знаю системы, где запрос на хотфикс от поступления до попадания в следующий билд живет полгода.
В это примере разница в системах в том, что первой пользуются пользователи в интернете, а вторая — для корпоративного использования. я не знаю, всегда ли так, но в этих случаях это работает.
>>Стандартное решение менеджера в таком случае: тестировщики все дефекты ассигнят не на разработчиков напрямую, а на менеджера, а менеджер уже ассингит на того или иного программиста (обычно на тимлида).
Это сильно увеличивает цикл работы над одной ошибкой. Если мы не можем себе позволить ждать, пока менеджер пройдется по багам (раз в день или в конце итерации), то единственный выход — назначать баги напрямую. И тут по-любому возникнет «не на того назначил», «я просто забыл задеплоить, это не баг, перепроверьте». Такие ситуации не перерастают в конфликты только, если люди адекватные и отношения нормальные.
К примеру, у нас баг, найденный на продакшне, как правило, фиксится и выкатывается в тот же день. Это означает быстрый фикс и быстрое регрессионное тестирование. Тут нельзя работать через менеджера.
В то же время, я знаю системы, где запрос на хотфикс от поступления до попадания в следующий билд живет полгода.
В это примере разница в системах в том, что первой пользуются пользователи в интернете, а вторая — для корпоративного использования. я не знаю, всегда ли так, но в этих случаях это работает.
Сходу:
— Критичные дефекты можно постить с более высоким приоритетом. Вы же пользуетесь программами-багтрекерами, знаете, какие возможности они предоставляют?
— Можно установить правила, по которым дефекты разных релизов автоматически назначаются разным адресатам, например критичные дефекты продакшена — напрямую разработчику (с обязательной копией всем задействанным лицам и руководсту.
— Разработчика и тимлида можно включить в CC при постинге дефектов, и им будет идти письмо с описанием дефекта и ссылкой на него. То есть даже если менеджер протормозит, то информацию по дефекту они все ранво получат.
— Менеджер может просматривать дефекты не раз в день, а раз в час-два.
— И т.д., масса технических и административных решений.
Да, это все — лишний некоторый напряг для менеджера (с другой стороны, зачем нужен менеджер, который не находит время периодически узнать состояние проекта?), но если он допустил в своей команде войну между отделами, то пусть расхлебывает, а не кофе пьет, и не заедает на бесполезных многочасовых митингах, или где там он тратит время, что не может в багтрекер глянуть, получив сообщение с высоким приоритетом.
— Критичные дефекты можно постить с более высоким приоритетом. Вы же пользуетесь программами-багтрекерами, знаете, какие возможности они предоставляют?
— Можно установить правила, по которым дефекты разных релизов автоматически назначаются разным адресатам, например критичные дефекты продакшена — напрямую разработчику (с обязательной копией всем задействанным лицам и руководсту.
— Разработчика и тимлида можно включить в CC при постинге дефектов, и им будет идти письмо с описанием дефекта и ссылкой на него. То есть даже если менеджер протормозит, то информацию по дефекту они все ранво получат.
— Менеджер может просматривать дефекты не раз в день, а раз в час-два.
— И т.д., масса технических и административных решений.
Да, это все — лишний некоторый напряг для менеджера (с другой стороны, зачем нужен менеджер, который не находит время периодически узнать состояние проекта?), но если он допустил в своей команде войну между отделами, то пусть расхлебывает, а не кофе пьет, и не заедает на бесполезных многочасовых митингах, или где там он тратит время, что не может в багтрекер глянуть, получив сообщение с высоким приоритетом.
А фотка не этого сезона. Сейчас дозаправок нет :)
поправка. сейчас дозаправки есть.
Можете уточнить? Насколько мне известно, дозаправок с этого сезона нет.
Да, да, теоретически можно дозаправить в крайнем случае, но с использованием машин низкого давления. То есть не в гоночном режиме.
Да, да, теоретически можно дозаправить в крайнем случае, но с использованием машин низкого давления. То есть не в гоночном режиме.
именно так. в регламенте запрещены заправочные автоматы кроме тех, которые дают стандартное давление (около 0.5 л/сек, если я правильно помню). раньше формульная бензоколонка выдавала 12 литров в секунду.
А, ну хорошо. А то я уж думал, что чего-то не понимаю.
Вы уж меня извините, но это бувоедство — говорить «поправка. сейчас дозаправки есть». Ясно, ведь, что человек имел в виду такие «правильные» дозаправки, которые на фотографии изображены.
Тем более (если уж буквоедствовать до конца), что если они разрешены, это не значит, что они есть, т. е. используются.
Вы уж меня извините, но это бувоедство — говорить «поправка. сейчас дозаправки есть». Ясно, ведь, что человек имел в виду такие «правильные» дозаправки, которые на фотографии изображены.
Тем более (если уж буквоедствовать до конца), что если они разрешены, это не значит, что они есть, т. е. используются.
Феррари под номером 1 последний раз ездила в 2004 году:))
А почему перед тестировщиком с программистом не может стоять цели выпустить качественный продукт в минимальные сроки?
Я просто с тестерами ни разу не работал. Сам у себя баги ищу.
Я просто с тестерами ни разу не работал. Сам у себя баги ищу.
Почему же не может? Может и нужет. Если это действительно нужно.
Просто бывает, когда нужно «тупо отработать бабки», тогда эффективность невыгодна. Страдает продукт, страдают люди. Страдают следующие хорошие продукты, в которые эти испорченные люди потом придут работать.
Мне рассказывали про программистов, которые прямо так и говорят на полном серьезе: «Я сегодня делал баги, пусть ищут».
Про заставить программистов тестировать — это вообще отдельная песня. Стереотип потому что, что занятие это второстепенное. Но в выпуске продукта второстепенных задач нет, Вы согласитесь, я уверена. Потому что Вы ответственность за свой продукт чувствуете.
Просто бывает, когда нужно «тупо отработать бабки», тогда эффективность невыгодна. Страдает продукт, страдают люди. Страдают следующие хорошие продукты, в которые эти испорченные люди потом придут работать.
Мне рассказывали про программистов, которые прямо так и говорят на полном серьезе: «Я сегодня делал баги, пусть ищут».
Про заставить программистов тестировать — это вообще отдельная песня. Стереотип потому что, что занятие это второстепенное. Но в выпуске продукта второстепенных задач нет, Вы согласитесь, я уверена. Потому что Вы ответственность за свой продукт чувствуете.
Интересно, это у меня одного возникают вопросы типа:
— Это же через какую задницу надо построить работу в коллективе, чтобы такие проблемы вообще появлялись?
— Это же как так надо набирать людей, чтобы потом огрести таких проблем?
Я работал тестировщиком два месяца. Почему-то мне хотелось, чтобы продукт нормально работал. Я работаю программистом третий год. Что со мной не так, что меня в принципе не возмущает никакой баг, репортнутый клиентом или тестером, вне зависимости от того, ерундовый он по своей сути или нет?
За 3 года работы в фирме ни в своем отделе, ни в других не видел даже похожей ситуации.
Менеджеров по персоналу надо набирать по количеству извилин в голове, а не по длине ног. Чтобы потом не хвататься за голову, что каждый второй работник не умеет работать в команде.
— Это же через какую задницу надо построить работу в коллективе, чтобы такие проблемы вообще появлялись?
— Это же как так надо набирать людей, чтобы потом огрести таких проблем?
Я работал тестировщиком два месяца. Почему-то мне хотелось, чтобы продукт нормально работал. Я работаю программистом третий год. Что со мной не так, что меня в принципе не возмущает никакой баг, репортнутый клиентом или тестером, вне зависимости от того, ерундовый он по своей сути или нет?
За 3 года работы в фирме ни в своем отделе, ни в других не видел даже похожей ситуации.
Менеджеров по персоналу надо набирать по количеству извилин в голове, а не по длине ног. Чтобы потом не хвататься за голову, что каждый второй работник не умеет работать в команде.
нет, не у вас одного :)
но Вы даже не представляете, в скольких компаниях такие проблемы. Я часто по конференциям езжу и со многими людьми разговариваю. такого много. Меня такого рода ситуации ставят в тупик. В голове не укладывается, КАК можно считать работу твоего со-командника второстепенной и пытаться нивелировать её ценность. КАК можно сказать «это не баг», зная, что так и пойдет в продакшн, не исправленным.
Во всех командах, где мне доводилось работать, мы вместе с программистами разбирали баги, советовались о приоритетах тестирования и выборе областей наибольшего внимания. С нынешней командой мы совместно импрувим процесс работы, чтобы было удобнее и эффективнее работать.
А извилины менеджера по персоналу тут вряд ли помогут. Если они не сталкивались с такими проблемами, они не смогут идентифицировать их на собеседовании.
но Вы даже не представляете, в скольких компаниях такие проблемы. Я часто по конференциям езжу и со многими людьми разговариваю. такого много. Меня такого рода ситуации ставят в тупик. В голове не укладывается, КАК можно считать работу твоего со-командника второстепенной и пытаться нивелировать её ценность. КАК можно сказать «это не баг», зная, что так и пойдет в продакшн, не исправленным.
Во всех командах, где мне доводилось работать, мы вместе с программистами разбирали баги, советовались о приоритетах тестирования и выборе областей наибольшего внимания. С нынешней командой мы совместно импрувим процесс работы, чтобы было удобнее и эффективнее работать.
А извилины менеджера по персоналу тут вряд ли помогут. Если они не сталкивались с такими проблемами, они не смогут идентифицировать их на собеседовании.
Когда-то были ситуации вида «это не баг».
Де факто это проблема постановки тест кэйса. в этом виноват кто угодно, но не тестер.
Де факто это проблема постановки тест кэйса. в этом виноват кто угодно, но не тестер.
«не баг» — нормальная ситуация.
много «не баг» — ненормальная ситуация, у которой 2 причины:
1) это действительно не баги, тогда смотрим на тесты, на тестеров, на требования, в ту сторону вобщем
2) со второго раза программист признает, что это таки-баг. И если это тенденция, то это не здорово. Я об этом. Отфуболивание.
много «не баг» — ненормальная ситуация, у которой 2 причины:
1) это действительно не баги, тогда смотрим на тесты, на тестеров, на требования, в ту сторону вобщем
2) со второго раза программист признает, что это таки-баг. И если это тенденция, то это не здорово. Я об этом. Отфуболивание.
Ваша позиция не удивляет: вы были по обе стороны «фронта» (:
А вот те, кто не обладает такой профессиональной политкорректностью — и строят такие команды, и участвуют в таких конфликтах.
А вот те, кто не обладает такой профессиональной политкорректностью — и строят такие команды, и участвуют в таких конфликтах.
Тестировщик лучший друг человека программиста, потому как именно он, может стать тем кто спасет программиста от позора. Даже у лучших бывают ошибки, а человек который помогает сделать код лучше, в принцепе не может быть врагом.
программист должен помогать тестировщику искать баги. некоторое поведение программы не хочется проверять каждый раз, всё же час работы тестера дешевле, но о таких вещах нужно информировать тестеров, чтобы те тщательнее проверили.
тестеры могут указать в личной беседе на часто допускаемые ошибки программиста.
главное, чтобы между членами команды постоянно был конструктивный диалог.
тестеры могут указать в личной беседе на часто допускаемые ошибки программиста.
главное, чтобы между членами команды постоянно был конструктивный диалог.
это только безопытные программеры ругаются с тестировщиками. когда приходит опыт, понимаешь, что тестировщик — это как какое-то мифическое существо, благодаря которому получаешь качественный результат. как можно с ним ругаться?
Там, где я работаю от того, сколько багов найдет клиент — напрямую зависит премия и, возможно, повышение зарплаты в конце финансового года каждого программиста и тестера. Получается, и тестеры, и программисты имеют общие цели. Конфликтов нет практически вообще.
И как Вы думаете, это нормально ли, что весь коллектив лишается премии, если какой-то джуниор допустил или пропустил несколько дефектов?
Во-первых, лишается не всей премии, а части, хотя и весьма заметной. Во-вторых, не весь коллектив, а только программист, который писал функциональность, и тестер, который ее тестировал. В третьих, джуниорам не дают работы, которая им по зубам… Таких джуниоров, которым ничего не по зубам — не нанимают.
*им не по зубам
Во-вторых, не весь коллектив, а только программист, который писал функциональность, и тестер, который ее тестировал.
Ну раз так то да, это более справедливо. Хотя непонятно, если над каким-то кодом работало человек пять, что, специальное расследование проводится, кого из них премии лишать?
Нет. Над новой функциональностью обычно работает 1-2 программиста, они за нее и отвечают. Потом тестеры тестят написанное, после чего программисты исправляют найденные баги. Это может повторяться в особо сложных случаях несколько раз, и затрагивать другие тестпланы… Но это отдельная песня :)
Короче, рано или поздно код попадает к клиенту и проходит процедуру «тестирования при принятии» (acceptance tests). Если клиент находит во время процедуры больше багов, чем положено — то тестер и программист, вероятно, лишатся нескольких сот евро в конце года. Пока что, бог миловал, такого у нас не было. Но сам принцип в качестве фактора, объединяющего программистов и тестеров, работает очень неплохо.
То, что клиент найдет после того, как принял функциональность — на размер премии не влияет.
Короче, рано или поздно код попадает к клиенту и проходит процедуру «тестирования при принятии» (acceptance tests). Если клиент находит во время процедуры больше багов, чем положено — то тестер и программист, вероятно, лишатся нескольких сот евро в конце года. Пока что, бог миловал, такого у нас не было. Но сам принцип в качестве фактора, объединяющего программистов и тестеров, работает очень неплохо.
То, что клиент найдет после того, как принял функциональность — на размер премии не влияет.
Кстати, а как быть, если программист и тестер например устроились на работу в январе, уволились в ноябре, потом этот код будет дорабатывать другой, новый программист, и тестировать новый тестер… а недели через три, в конце года, заказчик найдет кучу багов (в коде первого программиста), то кто-то финансово пострадает?
Извините за такие вопросы, просто интересно, теоретически, как такая система может работать… я не могу себе представить, чтобы это было жизнеспособно. Возможно я ошибаюсь.
Извините за такие вопросы, просто интересно, теоретически, как такая система может работать… я не могу себе представить, чтобы это было жизнеспособно. Возможно я ошибаюсь.
Не знаю :) у нас текучки почти нет.
Чисто теоретически, если такое произойдет, думаю что будет сорвана поставка, пострадают финансово все, даже те, кто не разрабатывал этот код, так как премия еще и от размера прибыли зависит, и от других показателей. Но функциональность прийдет к покупателю тогда, когда количество багов в ней согласно тест-плану будет стремиться к нулю.
Вообще, у нас все по плану, по процессам сделано. Очень четко, размеренно и неожиданностей не бывает.
Чисто теоретически, если такое произойдет, думаю что будет сорвана поставка, пострадают финансово все, даже те, кто не разрабатывал этот код, так как премия еще и от размера прибыли зависит, и от других показателей. Но функциональность прийдет к покупателю тогда, когда количество багов в ней согласно тест-плану будет стремиться к нулю.
Вообще, у нас все по плану, по процессам сделано. Очень четко, размеренно и неожиданностей не бывает.
Такого еще не может быть потому, что другому, новому программисту тушить пожар никто не даст, дадут опытному и проверенному, вероятно что тим лиду, который более-менее знаком со всем, что делают все, кто у него в подчинении. С вероятностью в 90%, я думаю, что все в этом случае будет как всегда: хорошо, качественно и в срок.
Узнать кто отвечает за функциональность против которой клиент нашел баги — дело одной минуты. Никакого расследования не требуется. Более того, в конце года в ходе процедуры определения и получения премий — надо делать самооценку и честно писать сколько и по чему было найдено багов. Радость та еще, но, знаете ли, очень менеджерам жизнь облегчает.
И у нас такая система работает, я вам как программист говорю.
Не понимаю где вы таких программистов видели. (Точнее как вы их не выгнали ещё на испытательном сроке.)
Хороший программист понимает, что сам он протестировать не может, просто в силу своей природы. (Любой программист, будет искать доказательство того что багов нет, а тестировщик наоборот, доказательство того что они есть. А они там есть, это аксиома.)
По этому работая с хорошими программистами (которые и сами стараются и к тестировщикам прислушивается) не будет этих проблем. (Это конечно только ИМХО, но мой опыт это подтвердил не один раз.)
Хороший программист понимает, что сам он протестировать не может, просто в силу своей природы. (Любой программист, будет искать доказательство того что багов нет, а тестировщик наоборот, доказательство того что они есть. А они там есть, это аксиома.)
По этому работая с хорошими программистами (которые и сами стараются и к тестировщикам прислушивается) не будет этих проблем. (Это конечно только ИМХО, но мой опыт это подтвердил не один раз.)
Хмм… не могу сказать что у меня такой уж громадный опыт работы в программистских коллективах, но ни разу с такой проблемой не сталкивался, вроде все нормальные люди понимают, что если тестер нашел где то баг, то это ТВОЯ ошибка и нужно её исправлять…
По делу статья написана. Главное в создании ПО — действительно командная работа. И вся ответственность по организации этого лежит на менеджере проекта. Именно он задает ориентировки, согласует условия проекта с заказчиком и т.п. А если мы наткнулись на клинический случай, и специалист по-прежнему упрямо твердит: «Это не баг» или «Я ошибку нашел, дальше — не моя проблема», с таким специалистом, увы, нужно прощаться.
Это все от незнания, а может быть и от нежелания знать, того что должно быть получено в итоге.
Хорошая эмоциональная статья, спасибо!
Видать наболело у автора и, таким образом, решил излить душу… :-)
Видать наболело у автора и, таким образом, решил излить душу… :-)
Проблема известная, у нас тоже есть.
Мы пытались разобраться в причинах и поняли, что беды две: личные качества и коммуникации.
С первым ничего кардинального не сделаешь (не пороть же!). Можно только лучше думать, когда берешь людей на работу. И общаться с теми, кто есть, не замалчивать проблемы.
А про коммуникации подумать стоит. Мы, например, у себя просто посадили тестировщиков вместе с программистами. Стало лучше.
Мы пытались разобраться в причинах и поняли, что беды две: личные качества и коммуникации.
С первым ничего кардинального не сделаешь (не пороть же!). Можно только лучше думать, когда берешь людей на работу. И общаться с теми, кто есть, не замалчивать проблемы.
А про коммуникации подумать стоит. Мы, например, у себя просто посадили тестировщиков вместе с программистами. Стало лучше.
У нас сейчас в требованиях к кандидату (по вакансии QA-инженера) написано:
* Сильные коммуникационные навыки (как вербальные, так и письменные), умение предотвращать и решать конфликтные ситуации.
Это требуется не из-за того, что у нас постоянно конфликты возникают, а для того, что бы они как раз не возникали :-)
* Сильные коммуникационные навыки (как вербальные, так и письменные), умение предотвращать и решать конфликтные ситуации.
Это требуется не из-за того, что у нас постоянно конфликты возникают, а для того, что бы они как раз не возникали :-)
А как на собеседовании выявить эти качества? Из области фантастики.
Все стараются не афишировать свои плохие стороны.
Не была ни разу на собеседовании, посвятите.
Все стараются не афишировать свои плохие стороны.
Не была ни разу на собеседовании, посвятите.
Ну, к примеру, можно пообщаться о том, какие ситуации возникали у человека на предыдущем месте работы. Узнать, какие ситуации кандидат вообще считает сложными, пообщаться на эту тему. Услышать то, как он их решал. Узнать то, что ему нравится/не нравится в коллективе или в процессе разработки, и то, как он пытался изменить это.
Кроме того собеседование проводят живые люди — и их жизненный опыт является очень важным оценочным инструментом. А стабильность рабочего коллектива и хорошие профессиональные успехи отдела подтверждают их право делать выводы.
Кроме того собеседование проводят живые люди — и их жизненный опыт является очень важным оценочным инструментом. А стабильность рабочего коллектива и хорошие профессиональные успехи отдела подтверждают их право делать выводы.
ещё дело в атмосфере
вы можете брать отличных людей, которые друг с другом хорошо общаются, но если в проекте атмосфера «сделать продукт, чтоб менеджер (заказчик) отвязался», ни к чему хорошему не приведет.
Кстати, такая больная атмосфера, в большинстве случаев, исходит от менеджера, который не дает команде понимания, что их работа значима, полезна и ценима
вы можете брать отличных людей, которые друг с другом хорошо общаются, но если в проекте атмосфера «сделать продукт, чтоб менеджер (заказчик) отвязался», ни к чему хорошему не приведет.
Кстати, такая больная атмосфера, в большинстве случаев, исходит от менеджера, который не дает команде понимания, что их работа значима, полезна и ценима
Очень интересная и правдивая статья, спс :)
Из опыта: пока тестировщики и программеры не увидят свой продукт как целое, да еще со стороны пользователя, дела не пойдут. Или пойдут, но плохо, долго и возможно не туда :) Хорошая статья, такие проблемы известны
В идеале тестировщики и программисты не должны пересекаться. При тестировании модуля тестировщик не должен знать, кто этот модуль разработал. Соответственно, и программист не должен знать, кто именно из тестировщиков нашел ошибку в его коде. Именно так работают многие крупные софтверные компании.
Минимизируя взаимодействие между командами, мы уменьшаем общую эффективность.
Например, при тест дизайне или составлении стратегии, взаимодействие с программистами очень важно, например: Для того что-бы актуально оценить риски, сама оценка должна проходить коллегиально.
Нужно работать именно над проектом и плотно взаимодействовать между командами, на достижение (Как уже тут многократно говорилось) общей цели.
Описанный Вами идиальный случай напротив, исключает общую цель и создает много локальных, которые, как-раз могут нанести вреда чем пользы (в рамках всего проекта)
К сожалению, я не знаю о каких крупных софтверных компаниях Вы говорите, можно пример?
Например, при тест дизайне или составлении стратегии, взаимодействие с программистами очень важно, например: Для того что-бы актуально оценить риски, сама оценка должна проходить коллегиально.
Нужно работать именно над проектом и плотно взаимодействовать между командами, на достижение (Как уже тут многократно говорилось) общей цели.
Описанный Вами идиальный случай напротив, исключает общую цель и создает много локальных, которые, как-раз могут нанести вреда чем пользы (в рамках всего проекта)
К сожалению, я не знаю о каких крупных софтверных компаниях Вы говорите, можно пример?
Flex25, в крупных компаниях действительно данный метод используется. Но его имеет смысл использовать как дополнительный. Тестировщики, которые общаются с программистом нужны в любом случае. Именно при налаженном взаимодействии есть возможность быстро протестировать продукт на основные баги, на наиболее вероятные баги, в срочном порядке что-то быстренько подправить и т.п. А необходимость таких срочных действий в процессе работы возникает постоянно. Да и глубоко лежащие ошибки порой легче отловить, зная, с кем имеешь дело :-)=
1: а я профессию сменил. теперь девелопером
2: а раньше кем был?
1: тестером
2: и в чем разница?
1: раньше а кричал на программу «Падай, сука!», а теперь — «Работай, сука!».
© BOR
2: а раньше кем был?
1: тестером
2: и в чем разница?
1: раньше а кричал на программу «Падай, сука!», а теперь — «Работай, сука!».
© BOR
ага, это не баг — это фича :)
только все вышесказанное можно отнести к любому проекту и обобщить для любой профессии.
только все вышесказанное можно отнести к любому проекту и обобщить для любой профессии.
Плох тот программист, который не любит тестировщика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Живут, как тестировщик с программистом