Комментарии 22
А сколько у вас сейчас людей в отделе? И сколько проектов в работе? Насколько это отличается от прежнего формата работы?
Честно говоря, не совсем понял, почему данный подход противопоставляется agile-разработке. На мой взгляд, это даже больше похоже на концентрированный agile. Разве эти две цитаты не про одно и то же?
Тест-менеджеры могут начать день с одного плана, а к обеду — поменять его кардинально.
vs
Готовность к изменениям важнее следования первоначальному плану. Не отрицая важности того, что справа, мы всё таки больше ценим то, что слева.
Потому, что в аджейле разрабатывается Стори или фича, отдаётся в тестирование и внедряется, возможно внедрение фичи по частям в прод. В нашем же случае мы внедряем сразу весь процесс, мы не тестируем отдельные куски доработок, мы тестируем весь процесс целиком. У нас нет спринтов, у нас есть четкие сроки когда бизнес хочет увидеть этот процесс на проде и наша задача распланировать нашу работу так, чтобы успеть точно в срок, гибкости в части срока у нас практически нет.
А в части чего гибкость? Режем функционал? Нанимаем ещё людей? Если нельзя двигать сроки, то как работать? Хочу новую фичу уже завтра, например.
возможно внедрение фичи по частям в прод
Это очень хороший и правильный подход, чем он не угодил? Или вы фичи, в принципе, никак не дорабатываете?
'Нужны доработки'
'Извините, функционал уже принят, никаких доработок'
в аджейле разрабатывается Стори или фича ... В нашем же случае мы внедряем сразу весь процесс
В чем разница между процессом и стори/фичой? Назовите процесс историей - что изменится?
У нас фиксируется объем тестирования и сроки, а не содержимое спринтов. И соблюдаем мы обязательства именно по объемам и срокам тестирования, согласованным с командой.
В части чего гибкость? Как уже отвечено выше – в раннем сборе потребностей, в перераспределении собственных тестировщиков между проектами, в подключении специалистов от систем, в приоритизации выполняемых цепочек. Мы не говорим, что все возможно, т.к. качество тестирования ставится нами в приоритетные цели, но мы делаем все возможное, чтобы сроки тестирования были понятны и прозрачны заказчику.
В нашем же случае мы внедряем сразу весь процесс, мы не тестируем отдельные куски доработок, мы тестируем весь процесс целиком.
То есть вы отдельные «куски» в принципе сами по себе вообще не тестируете? Действительно ждёте пока всё будет готово целиком и только потом начинаете тестировать?
Потому, что в аджейле разрабатывается Стори или фича… У нас нет спринтов...
Мне кажется что вы путаете аджайл и скрам. В аджайле совсем не обязательно должны быть стори/фичи и спринты. Возьмите тот же канбан например.
«Отдельные куски» мы можем тестировать на входе в Е2Е, т.к. не всегда команды готовы отдать код одновременно, или в ходе работ, когда часть бизнес-процесса блокируется багами. Такое тестирование позволяет эффективнее находить слабые места выполненной разработки. Но конечным результатом нашей работы является полностью пройденные бизнес-процессы, от начала до конца.
Ну то есть вы тестите отдельные фичи и в конце ещё делаете какой-то общий «интеграционный» тест для всего процесса в целом? И вы почему-то считаете что так нельзя делать в аджайле?
Я вас наверное очень удивлю, но так даже в скраме делают. Просто если вы хотите в конце каждого спринта протестировaть ещё и весь процесс целиком, то вы планируете под это время и всё. Или делаете отдельную команду под такие тесты и вместо «простого» скрама делаете нексус или там «scrum of scrums» с несколькими командами…
Это если вы обязательно хотите именно скрам делать, а не другие варианты аджайла.
Я вас наверное очень удивлю, но так даже в скраме делают. Просто если вы хотите в конце каждого спринта протестировaть ещё и весь процесс целиком, то вы планируете под это время и всё. Или делаете отдельную команду под такие тесты и вместо «простого» скрама делаете нексус или там «scrum of scrums» с несколькими командами…
Это если вы обязательно хотите именно скрам делать, а не другие варианты аджайла.
Интересный подход, т.е. вы полностью все функции тестирования делаете распределенными, а не только само выполнение тестовых задач.
Как тест-менеджеры / -аналитики справляются с ведением нескольких проектов? Им хватает на все времени? Или они в мыле жонглируют экселями и с утра до вечера торчат в телефонных конференциях?
Как вы рассчитывате долю стоимости тестирования в проекте, если распределение часов меняется динамически? Закладываете вначале «с запасом» бюджет, а потом списываете реальные расходы по часовой отчетности участников?
Как тест-менеджеры / -аналитики справляются с ведением нескольких проектов? Им хватает на все времени? Или они в мыле жонглируют экселями и с утра до вечера торчат в телефонных конференциях?
Как вы рассчитывате долю стоимости тестирования в проекте, если распределение часов меняется динамически? Закладываете вначале «с запасом» бюджет, а потом списываете реальные расходы по часовой отчетности участников?
Мы просим максимально заранее обращаться к нам с заявками на тестирование и в первую очередь нам помогает четкое планирование ресурсов с учетом заявленной потребности. Планирование ведется как на верхнем уровне: месяца, недели, так и ежедневное, с учетом текущей ситуации. За счет того, что мы жестко не фиксируем команды – возможно перераспределение ресурсов, чтобы погасить пиковые нагрузки. Но, как только мы понимаем, что ресурсов не хватит, а сдвиг сроков не возможен – прибегаем к гибридной схеме тестирования, подключая специалистов от систем на прохождение части шагов в их системах.
Несколько проектов тест-менеджер берет только если масштаб проектов это позволяет сделать.
Долю стоимости мы рассчитываем исходя из уже накопленной в отделе экспертизы, она зависит от глубины изменений и количества задействованных в тестировании систем. Реальные расходы на тестирование определяются фактическими трудозатратами.
Несколько проектов тест-менеджер берет только если масштаб проектов это позволяет сделать.
Долю стоимости мы рассчитываем исходя из уже накопленной в отделе экспертизы, она зависит от глубины изменений и количества задействованных в тестировании систем. Реальные расходы на тестирование определяются фактическими трудозатратами.
Почему-то первая мысль после прочтения статьи о том, что разработчики решили отказаться от модульных и интеграционных тестов, потому что не успевают.
И менеджеры сделали заявления: "Будем тестировать всё на серверах!"
После чего пошли дальше оптимизировать и распределили тестировщикам по проектам.
Поэтому вопрос: какая часть кода у вас покрыта модульными и интеграционными тестами?
Эффективность Е2Е на сыром коде стремится к нулю, поэтому начинать с нас – не имеет практического смысла.
У нас каждый продукт/проект до выхода на Е2Е проходит все виды тестов: UNIT-тесты, функциональное и интеграционное тестирование. Мы подключаемся уже после всех ранее пройденных видов тестов. И конечно же есть большое количество фич, которые в принципе к нам не поступают на наш вид тестирования, т.к. влияют только на один продукт и для них достаточно функционального и (при необходимости) интеграционного тестирования.
У нас каждый продукт/проект до выхода на Е2Е проходит все виды тестов: UNIT-тесты, функциональное и интеграционное тестирование. Мы подключаемся уже после всех ранее пройденных видов тестов. И конечно же есть большое количество фич, которые в принципе к нам не поступают на наш вид тестирования, т.к. влияют только на один продукт и для них достаточно функционального и (при необходимости) интеграционного тестирования.
НЛО прилетело и опубликовало эту надпись здесь
Почитайте как тестирует Google, найдете много схожего. Хорошая команда тестирования это дорогой ресурс и получаем либо вообще без внутреннего тестирования, либо 1-2 мануальщика, либо существенные затраты.
Если в каждый проект по одному манульному мидлу то это +100К в зарплатах Москвы, этот мидл будет 2-3 месяца изучать систему, потом усиленно тестировать, а через год решит, что это ему не интересно, и что будет делать следующий? Опять все изучать.
Если в каждый проект по одному манульному мидлу то это +100К в зарплатах Москвы, этот мидл будет 2-3 месяца изучать систему, потом усиленно тестировать, а через год решит, что это ему не интересно, и что будет делать следующий? Опять все изучать.
Кажется, что причина такого «ультимативного подхода», который требует целые департаменты тестирования в слишком мелкой нарезке системы на сервисы. Иначе команды были бы более уверены в качестве своих интеграционных тестах и end2end тестов требовалось бы совсем немного. Кто-то опять заигрался в микросервисы…
Интересен состав команды, есть ли SDET'ы и вообще автоматизация. По самим тест-кейсам 114 шт это интересно, но насколько эти E2E что либо находят?
По мне вы должны отлаживать процесс писать документацию и тест-кейсы, а потом передавать все команде и их тестировщику, если он есть.
Про «кросс-системный» напоминает какой то маркетинг, или это слоган «делай не как все» (крос- систем-). В описании вижу отдел тестирования, не закрепленный за проектами.
По мне вы должны отлаживать процесс писать документацию и тест-кейсы, а потом передавать все команде и их тестировщику, если он есть.
Про «кросс-системный» напоминает какой то маркетинг, или это слоган «делай не как все» (крос- систем-). В описании вижу отдел тестирования, не закрепленный за проектами.
Зуммеры изобрели водопад
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кто такой кросс-системный тестировщик и почему он не должен быть «agile»?