Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Отличный рассказ.
Но если бы там были формулы, и немного философии — это только придало бы плюсов.
Но если бы там были формулы, и немного философии — это только придало бы плюсов.
тестировщик садится с ним за один компьютер, берёт блокнот с ручкой и начинает проверять, комментироватьМне кажется, программист в этот момент еще и учится видеть потенциальные проблемы; учиться думать как тестировщик.
Понятное дело, что всех ошибок не отловить, поэтому и выходят тестовые версии: альфы, беты.
Но еще применяется хорошее решение, когда сама программа репортирует об ошибках разработчику.
Последнее я применил в одном веб-проекте, где в базу система ложит что-то вроде лога ошибок с типом (ошибка, предупреждение, исключение) и всем стеком. В принципе, очень даже помогает.
Но еще применяется хорошее решение, когда сама программа репортирует об ошибках разработчику.
Последнее я применил в одном веб-проекте, где в базу система ложит что-то вроде лога ошибок с типом (ошибка, предупреждение, исключение) и всем стеком. В принципе, очень даже помогает.
На самом деле статистика (если она действительно работающая, а не «длягалочная», как вы выразились :-) — это огромная помощь в оптимизации бизнеса.
Главное, вносить данные полностью и без искажений, а дальше графики сами нарисуются и нужно будет только мозг включать время от времени для интерпретации данных.
Главное, вносить данные полностью и без искажений, а дальше графики сами нарисуются и нужно будет только мозг включать время от времени для интерпретации данных.
Вот!!! Тут с метриками есть такая хитрость: приходит руководство в один ужасный день и говорит «я буду вас мерять вот такими-то метриками, собирайте». И все собирают, но
* не любят это делать, чувствуют давление
* начинают читерить, стараться что-то приукрашивать
Метрики никогда не должны исходить от руководства, их должна придумывать команда! И я стараюсь руководству вообще их поменьше показывать. Для них нужны 1-2 метрики про продажи и сроки разработки, но глубже лезть не следует, ответственной команде это только мешает, а безответственная начинает работать на метрики вместо результата.
* не любят это делать, чувствуют давление
* начинают читерить, стараться что-то приукрашивать
Метрики никогда не должны исходить от руководства, их должна придумывать команда! И я стараюсь руководству вообще их поменьше показывать. Для них нужны 1-2 метрики про продажи и сроки разработки, но глубже лезть не следует, ответственной команде это только мешает, а безответственная начинает работать на метрики вместо результата.
Спасибо за статью! У меня на проекте проблемы по третьему примеру.
Тестировщик считает багами нормально поведение (описанное в спеке), тестирует релизы с нуля, а не инкрементно, не перепроверяет старые баги на новых релизах.
В итоге заказчик выдвинул — разработчики должны сами все тестировать. Релиз перед публикацией не тестируется.
Тестировщик считает багами нормально поведение (описанное в спеке), тестирует релизы с нуля, а не инкрементно, не перепроверяет старые баги на новых релизах.
В итоге заказчик выдвинул — разработчики должны сами все тестировать. Релиз перед публикацией не тестируется.
Мне кажется, в последнем случае неделя — недопустимо малый промежуток времени между итерациями. Мы тоже одно время так работали, и это приносило много стресса и команде, и энд-кастомеру. А как перешли на цикл в 2 недели — всё стало на свои места.
Дело, мне кажется, в том, что планирование на одну недели, или на две недели занимает не сильно разное время. А сконцентрироваться такой темп очень сильно мешает — не успел начать фичу, а её уже нужно отдавать на тестирование. А когда порефакторить, когда продумать архитектуру?
Идея про мгновенный тестинг — гениальна, часто встречал девелоперов которые даже смок-тестить свой код не умеют, на всём полагаясь на 100% чисто на тестеров.
Дело, мне кажется, в том, что планирование на одну недели, или на две недели занимает не сильно разное время. А сконцентрироваться такой темп очень сильно мешает — не успел начать фичу, а её уже нужно отдавать на тестирование. А когда порефакторить, когда продумать архитектуру?
Идея про мгновенный тестинг — гениальна, часто встречал девелоперов которые даже смок-тестить свой код не умеют, на всём полагаясь на 100% чисто на тестеров.
Идея про 2 недели очень упрощает жизнь, но увеличивает общие сроки разработки. У меня на моих проектах тоже 2 недели, но это потому что я разгильдяй и каждую неделю релизы просто не переживу :)
Но мы тоже когда-нибудь прийдём к одной неделе: это и заказчикам хорошо, и позволяет держать более высокий темп разработки. НО к этому надо быть готовыми, процессы должны быть налажены и выверены. С текущими остатками бардака я пока что не решаюсь, но со временем это неизбежно произойдёт.
Кстати история про 1-недельные итерации единственная 100%-успешная из списка приведённых, всё оказалось не так сложно.
Мне очень нравится книга Имаи «Гемба Кайдзен», там он рассказывает о том что менеджер должен быть часто в Гемба (это завод или другое место, где производится продукция, в нашем случае пишется код) и внимательно наблюдать. Просто наблюдать. Я стараюсь часто это делать и в итоге вижу, где «узкие горлышки», с какими проблемами кто сталкивается. Со стороны заметить это проще, чем для непосредственных участников процесса, а вместе с ними потом можно обсудить, как эти проблемы решать.
Сократите срок итерации — и проблем сразу будет заметно значительно больше, они будут более яркими. Можно это даже иногда специально для контролируемого стресса делать, и для диагностики проблемных мест.
Но мы тоже когда-нибудь прийдём к одной неделе: это и заказчикам хорошо, и позволяет держать более высокий темп разработки. НО к этому надо быть готовыми, процессы должны быть налажены и выверены. С текущими остатками бардака я пока что не решаюсь, но со временем это неизбежно произойдёт.
Кстати история про 1-недельные итерации единственная 100%-успешная из списка приведённых, всё оказалось не так сложно.
Мне очень нравится книга Имаи «Гемба Кайдзен», там он рассказывает о том что менеджер должен быть часто в Гемба (это завод или другое место, где производится продукция, в нашем случае пишется код) и внимательно наблюдать. Просто наблюдать. Я стараюсь часто это делать и в итоге вижу, где «узкие горлышки», с какими проблемами кто сталкивается. Со стороны заметить это проще, чем для непосредственных участников процесса, а вместе с ними потом можно обсудить, как эти проблемы решать.
Сократите срок итерации — и проблем сразу будет заметно значительно больше, они будут более яркими. Можно это даже иногда специально для контролируемого стресса делать, и для диагностики проблемных мест.
Отлично написано. Спасибо!
Спасибо за статью. Мне тоже очень понравилась идея о мгновенном тестинге. Аж обидно, что сам не додумался. Как всегда, все гениальное — просто. Попробую это в нашей компании в самое ближайшее время. Тем более, что мы как раз переходим на ажайл и за каждой небольшой командой закрепили своего личного тестировщика QA инженера.
Читал и не понял — ты говоришь о метриках как инструменте МОНИТОРИНГА хода проектов, или как инструменте ДИАГНОСТИКИ и радикального улучшения показателей на конкретном одном?
Во втором случае, если проблему и причину обнаружили и устранили, зачем продолжать собирать метрики, тратить на это ресурсы?
Во втором случае, если проблему и причину обнаружили и устранили, зачем продолжать собирать метрики, тратить на это ресурсы?
Тут есть и те и те метрики. «Мы пропускаем много багов», «Мы долго выпускаем релизы» и т.д. — это метрики мониторинга, и их надо собирать на регулярной основе.
«Причина пропуска бага», «причина появления бага» — это метрики диагностики, и они нужны только в тех случаях, когда метрики мониторинга показывают что что-то плохо.
А когда мы решили проблему, мониторить статус всё равно нужно, чтобы убеждаться, что проблема не воскрешается потихоньку, и чтобы заметить её на ранних этапах. Это касается метрик мониторинга, а диагностические — временные, до решения.
«Причина пропуска бага», «причина появления бага» — это метрики диагностики, и они нужны только в тех случаях, когда метрики мониторинга показывают что что-то плохо.
А когда мы решили проблему, мониторить статус всё равно нужно, чтобы убеждаться, что проблема не воскрешается потихоньку, и чтобы заметить её на ранних этапах. Это касается метрик мониторинга, а диагностические — временные, до решения.
Если честно, как-то ваши истории и метрики не убедили. Возможно всё упирается в тип компании и квалификацию сотрудников, но ощущение, что они какие-то однобокие и решаю одну проблему, потенциально создают другие.
Скажите, у вас есть более репрезентативные выборки с историями успеха метрик?
Скажите, у вас есть более репрезентативные выборки с историями успеха метрик?
Действительно, мы диагностируем проблемы и какую-то одну проблему и решаем. А почему они потенциально создают другие? Можно примеры?
Про «более репрезентативные выборки» не поняла, как они должны выглядеть?
Про «более репрезентативные выборки» не поняла, как они должны выглядеть?
пример, ниже привели.
более репрезентативные — это значит, чтчо мы это сделали на 10 разных командах и везде результат одинаковый.
как найду время (возможно, в выходные, рапишу свои мысли по вашим решениям), у меня просто ощущение, что решив одну проблему вы добавили другую. Можно будет вместе подумать и обсудить это.
более репрезентативные — это значит, чтчо мы это сделали на 10 разных командах и везде результат одинаковый.
как найду время (возможно, в выходные, рапишу свои мысли по вашим решениям), у меня просто ощущение, что решив одну проблему вы добавили другую. Можно будет вместе подумать и обсудить это.
Схему про пропуски багов (История #2) я внедряла ну может не в 10, но больше чем в 5 проектов точно. Естественно результаты диагностики в разных командах были разные, решения тоже, но % пропущенных ошибок везде удавалось успешно сокращать.
По остальным метрикам опыт «одноразовый».
Но я про любые не гарантирую работоспособность в каких-либо условиях, метрики везде уникальные даны, я просто даю общий алгоритм «найди метрику — датчик проблемы», а потом «сделай метрику- диагност — источник проблемы». А что и когда это будут за метрики — зависит от конкретных условий!
По остальным метрикам опыт «одноразовый».
Но я про любые не гарантирую работоспособность в каких-либо условиях, метрики везде уникальные даны, я просто даю общий алгоритм «найди метрику — датчик проблемы», а потом «сделай метрику- диагност — источник проблемы». А что и когда это будут за метрики — зависит от конкретных условий!
Я прочитал этот топик на одном дыхании! Хочется отметить что автор очень интересно и профессионально пишет! И вообще очень много для себя взял на заметку! Спасибо Вам огромное! Побольше бы таких статей. Пишите обязательно на эту тему еще! Мне очень понравилась статья! Проблема эффективного управления командой всегда остается актуальной.
Супер!
Пару лет используем решение из истории 3 — персональное тестирование «на лету», когда программист правит баги в режиме живого общения с тестировщиком.
Пока это один из самых эффективных способов тестирования.
Но есть проблемы, интересно, как их решили вы.
1. Необходимо соотношение тестировщиков\программистов один к одному. Дорого. Иначе — очереди и затея теряет смысл. И да, программисты имеют свойство доделывать задачи одновременно.
2. Сажать за один комп — работает на простенькой функциональности, неопытных программистах и очевидных багах. А если фича сложная, а программист опытный, то первые замечания появятся часа через три.
Пока это один из самых эффективных способов тестирования.
Но есть проблемы, интересно, как их решили вы.
1. Необходимо соотношение тестировщиков\программистов один к одному. Дорого. Иначе — очереди и затея теряет смысл. И да, программисты имеют свойство доделывать задачи одновременно.
2. Сажать за один комп — работает на простенькой функциональности, неопытных программистах и очевидных багах. А если фича сложная, а программист опытный, то первые замечания появятся часа через три.
а можете рассказать как вам удалось решить эти проблемы?
p.s. Кстати, мне кажется у остальных историй, есть подобные проблемы тоже.
p.s. Кстати, мне кажется у остальных историй, есть подобные проблемы тоже.
1. Ну я бы не сказала, что нужно такое соотношение. Конкретно в случае, описанном выше — 7 тестировщиков на 17 разработчиков, то есть отличия в 2 с лишним раза. А вот с одновременными доделками часто сталкиваемся, есть такая проблема. Пытались договориться о разбросе сроков, планировать каждую отдельную фичу с точностью до полдня — не сработало. Просто в случае одновременной готовности идём по порядку, кому-то приходится ждать. Я бы не сказала, что это прямо ПРОБЛЕМА, просто 1-2 фичи в неделю могут подвинуться на пару часов в тестировании.
Решение — больше тестировщиков, но эти затраты *конкретно в нашем случае* не оправданы.
2. Если нет очевидных дефектов, то тестирование на лету вообще не нужно! Минут 20-30 вместе покликали, убедились что в целом фича рабочая — и продолжаем тестировать на тестерском компьютере. Если баги и найдутся, то это уже не будут блокеры, из-за которых встанет вся итерация.
Если у вас что-то не так — значит, у вас слишком большие фичи, которые не подходят ни для коротких итераций, ни для тестирования на лету.
Решение — больше тестировщиков, но эти затраты *конкретно в нашем случае* не оправданы.
2. Если нет очевидных дефектов, то тестирование на лету вообще не нужно! Минут 20-30 вместе покликали, убедились что в целом фича рабочая — и продолжаем тестировать на тестерском компьютере. Если баги и найдутся, то это уже не будут блокеры, из-за которых встанет вся итерация.
Если у вас что-то не так — значит, у вас слишком большие фичи, которые не подходят ни для коротких итераций, ни для тестирования на лету.
Вообще, приведённые мной истории — это упаси боже не предложение «делайте вот так». У меня сейчас есть проект с релизами раз в год и фичами, которые делаются целыми командами разработки по несколько недель. Тестирование на лету в этом проекте совсем не применимо, да и не нужно.
Нет «хороших» решений, есть подходящие или не очень ПОД КОНКРЕТНЫЕ УСЛОВИЯ.
Нет «хороших» решений, есть подходящие или не очень ПОД КОНКРЕТНЫЕ УСЛОВИЯ.
А как в описанных ситуациях Ваши решения повлияли на сроки выполнения? Увеличился ли срок выполнения фичи, всего проекта?
Об этом же в статье написано… Мы сократили сроки в 2-м и 3-м случае, и по разработке фичи, и по выпускам итераций. В 1-й же истории временные затраты врядли изменились.
Мы стали находить больше багов, но сроки выпуска итераций фиксированные, просто мы стали исправлять в итоге более приоритетные дефекты, а сроки выпусков и ресурсы на тестирование остались неизменными.
Т.е. истории №1 и №2 — про сокращение сроков без ущерба качеству, №3 — про повышение качества без замедления разработки.
Мы стали находить больше багов, но сроки выпуска итераций фиксированные, просто мы стали исправлять в итоге более приоритетные дефекты, а сроки выпусков и ресурсы на тестирование остались неизменными.
Т.е. истории №1 и №2 — про сокращение сроков без ущерба качеству, №3 — про повышение качества без замедления разработки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полезные метрики для оценки проектов