договорённость с руководителем, что до 20% времени я могу тратить на свой проект
Как реализуется эта договоренность? На какой проект вы тратите это время? Для чего нужна эта договоренность, если руководитель может просто доверять, что подчиненные делают нужное?
Верно ли я понял, что карта покрытия тестами приводит к появлению задач, вида «у нас вон там совсем мало тестов, надо написать еще»?
Есть ли в вашем проекте другие сценарии использования этой инфы?
Почему считается идеальной ситуация, ручные тестировщики пишут тест-кейсы, а автоматизаторы пишут по ним автотесты? По-моему, это плохой паттерн :)
1. Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
2. Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
3. Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
Почему? Возьмем, например, пользовательские сценарии. Их модель часто используют для black-box тестирования. И даже эти сценарии очень сложно хотя бы зафиксирировать на бумаге полностью.
Выбирая плохое качество кода в тестах, вы также получаете:
Долгую поставку фич. Например, потому что тесты писать сложнее и сложнее. Или потому что они нестабильные, надо возиться с их падениями.
Озлобленных инженеров. «на фичу ушел день, а только на написание тестов еще три дня» — такое бесит людей. Еще людей раздражает писать плохой код, потому что они начинают себя с ним ассоциировать :)
Длинный цикл обратной связи для разработчиков. Если программисту сложно проверить, как работает его код — он попросит тестировщиков. И о багах в основном сценарии узнает не сразу, а через много времени. Это тоже сильно удлинняет время поставки фич.
Я думаю, что менеджеров проектов должны волновать такие вещи. Как минимум, на долгих проектах.
Хорошее качество обеспечить можно и с ручным тестированием. Между хорошим кодом с плохим покрытием и плохими тестами с хорошим покрытием я бы выбрал первое.
Про код тестов я с вами не согласен. Даже у многих разработчиков навыки поддержки больших кодовых баз не очень хороши. При том, что они full time работают с кодом. Тестировщикам еще сложнее приобрести эти навыки, потому что кроме кода, у них много других дел и нет опытного наставника-разработчика. А проблемы в больших кодовых базах с тестами — такие же злобные, как в продакшн коде.
Проблемы с покрытием решаются, если не сваливать автотесты только на разработчиков или тестировщиков. Я согласен с вами, что разработчик скорее всего покроет только очевидные сценарии. А тестировщик может подумать после него и дописать тестов. В такой модели и код тестов нормальный, и разработчик добавил тестируемость в систему и покрытие ниче так.
Тем более хороший код — это не самое главное в автотестах.
Позвольте с вами не согласиться.
Если вы захотите покрыть тестами весь регресс немаленького продукта, вам потребуется много тестов. Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.
Вам будут нужны много доработок по тестируемости приложения — без них вы не сможете сделать тесты с 99,99% стабильностью и они будут только мешать. Разработчики могут вносить правки в приложение, а тестировщики не могут (плохо кодят + не знают код продукта).
Если ваши разработчики не будут обязаны писать тесты, то вы их не заинтересуете помогать с вещами, которые я описал. И у вас не получится отказаться от ручного тестирования регресса.
Без хорошего кода ваши автотесты далеко не уйдут ;)
На одинаковом наборе кейсов, тестировщик потратит столько же или больше времени, чем разработчик :) Потому что первому нужно фиксировать баги для передачи второму. Скриншот, описание. Еще потом проверить, что баг исправлен! На возню с багами может уходить до 80% времени выполнения ручных тестов. И это мы еще не говорим про блокеры.
Когда тестирует разработчик, никому никуда иныормацию передавать не надо, он все еще в контексте задачи и может фиксить на лету.
Спасибо за увлекательную статью! Интересны подробности :)
Сколько у вас приемочных тестов? Какова стабильность?
Какие классы приемочных сценариев вы покрыли тестами, а какие — нет? Интересуют не сценарии продукта, а категории типа "совместимость нового компонента с данными старой версии" или "сценарии отката релизас
Если команды разработки сами пишут приемочные тесты, то почему они не разбирают их падения и почему гоняют тесты только перед релизом? Могли бы делать это раньше, например до своего ручного тестирования :)
Я правильно понял, что при деплое нового компонента на стенд, версии других на стенде сбрасываются до релизных? Если нет, то на какой версии всего продукта гоняются тесты?
Как у вас релизятся фичи, в которых надо согласованно обновить несколько компонентов от разных команд?
Хочу уточнить, что наша основная работа — это искать баги в задачках всеми доступными средствами и способствовать быстрым релизам.
А автотесты пишем и поддерживаем всей командой разработки (разработчики, аналитики, тестировщики). Потому и обходимся без отдельных автоматизаторов.
Про критерии выбора тоже хочу добавить. Можно выбирать по полезности, эффективности и такому вот. Есть еще один: личный комфорт. Мне очень стремно делать оценки по отдельным задачам:
Это само по себе сложно, неточно и все время ошибаешься. Ошибаться раздражает.
Кроме этого, на твои оценки неявно начинают полагаться другие люди. А когда ты в оценки не попадаешь, они ощущают негатив по отношению к тебе. Это портит отношения.
Даже если за ошибки не ругают, то раздражает, когда при непопадении в оценку какой-то другой человек приходит «разбираться, а что пошло не так». Это тоже психологическое давление, как бы его ни оправдывали :)
И пока я не вижу значимых плюсов оценки сроков по отдельным задачам, мне неясно, зачем впускать вот это все в мою жизнь. Я уже так работал и больше не хочу.
150 тестеров — это всего в Контуре, в разных командах разработки.
Я работаю в команде, про которую в конце статьи пишут. Могу рассказать что-нибудь :)
3000 тестов UI с поднятием приложения, 3000 API тестов с поднятием приложения, 10000 юнит-тестов. В прогоне из-за нестабильностей падает 0-7 тестов.
У нас 6 тестировщиков и регрессия покрыта тестами полностью. Это верно, что мы тратим много сил на это. Но без овертаймов. Если бы не тратили, у нас было бы больше тестеров(16?), потому что ручной регресии было бы очень много. Кажется, в нашей ситуации 6 тестеров и автоматическая регрессия выходят дешевле, чем 16 тестеров и «какие-то» автотесты.
Во-вторых.
Я почти не работал в мире, где все задачи с дедлайнами. Вы мне расскажите, как там?
На берегу, мне кажется что ставить дедлайны по всем задачам — это самообман. Все равно команда разработки не сможет сделать больше Х задачек в месяц. Еще придется устраивать адски сложные планирования в стиле «надо приоритизировать и оценить сроки для 40 входящих задач, а также посмотреть на 30 задачек, что сейчас в разработке». Вы в другой ветке писали, что на планирование уходило по 2 дня из 10 (=двухнедельный спринт). Я пока не увидел плюсов у таких гигантских трудозатрат.
Еще интересно, были ли в вашем мире овертаймы у команды разработки. Если да, то как часто и как плохо?
Как реализуется эта договоренность? На какой проект вы тратите это время? Для чего нужна эта договоренность, если руководитель может просто доверять, что подчиненные делают нужное?
2. Для чего вы смотрите «тестировалось или нет»? Для постмортемов каких-то?
Верно ли я понял, что карта покрытия тестами приводит к появлению задач, вида «у нас вон там совсем мало тестов, надо написать еще»?
Есть ли в вашем проекте другие сценарии использования этой инфы?
Ваши менеджеры такое спрашивают? Если да, то зачем? Что они делают с этой информацией, для каких решений им это нужно?
1. Дизайн ручных тест-кейсов и тест-кейсов для автоматизации различается. Сценарии для автотестов нужно нарезать иначе.
2. Ужасно долгий воркфлоу «тестировщик написал тест-кейс — создал задачу автоматизатору — автоматизатор написал тесты». Если в рабочих процессах можно обойтись без лишних рабочих центров и передачи задач между ними — нужно обходиться.
3. Путь развития автоматизатора мне кажется сомнительным. Ты все еще не настоящий разработчик, но и с ручными тестировщиками тебе не по пути. В итоге, ты остаешься один или с несколькими такими же, как ты. Тебе не у кого учиться и вместо best practices написания кода ты учишься странному.
Почему не стремиться к тому, чтобы тестировщики делали всё: писали сценарии и писали автотесты? Это даже не утопия, я видел такие команды.
Можете раскрыть, почему вы так думаете?
На длительный проект, на мой взгляд, лучше нанять четверых крутых тестировщиков, чем десяток послабее.
Более того, все состояния системы даже представить не получится.
Я думаю, что менеджеров проектов должны волновать такие вещи. Как минимум, на долгих проектах.
Хорошее качество обеспечить можно и с ручным тестированием. Между хорошим кодом с плохим покрытием и плохими тестами с хорошим покрытием я бы выбрал первое.
Проблемы с покрытием решаются, если не сваливать автотесты только на разработчиков или тестировщиков. Я согласен с вами, что разработчик скорее всего покроет только очевидные сценарии. А тестировщик может подумать после него и дописать тестов. В такой модели и код тестов нормальный, и разработчик добавил тестируемость в систему и покрытие ниче так.
Позвольте с вами не согласиться.
Если вы захотите покрыть тестами весь регресс немаленького продукта, вам потребуется много тестов. Работать с большой кодовой базой это сложно. Разраьотчики это умеют, а тестировщики — нет.
Вам будут нужны много доработок по тестируемости приложения — без них вы не сможете сделать тесты с 99,99% стабильностью и они будут только мешать. Разработчики могут вносить правки в приложение, а тестировщики не могут (плохо кодят + не знают код продукта).
Если ваши разработчики не будут обязаны писать тесты, то вы их не заинтересуете помогать с вещами, которые я описал. И у вас не получится отказаться от ручного тестирования регресса.
Без хорошего кода ваши автотесты далеко не уйдут ;)
В статье как раз прикольный чеклист того, что можно посмотреть, не привязываясь к код или постановке задачи.
На одинаковом наборе кейсов, тестировщик потратит столько же или больше времени, чем разработчик :) Потому что первому нужно фиксировать баги для передачи второму. Скриншот, описание. Еще потом проверить, что баг исправлен! На возню с багами может уходить до 80% времени выполнения ручных тестов. И это мы еще не говорим про блокеры.
Когда тестирует разработчик, никому никуда иныормацию передавать не надо, он все еще в контексте задачи и может фиксить на лету.
Спасибо за статью.
Жаль, что не раскрыта мотивация, зачем вообще фронтендерам искать баги самим.
Спасибо за увлекательную статью! Интересны подробности :)
А автотесты пишем и поддерживаем всей командой разработки (разработчики, аналитики, тестировщики). Потому и обходимся без отдельных автоматизаторов.
Про критерии выбора тоже хочу добавить. Можно выбирать по полезности, эффективности и такому вот. Есть еще один: личный комфорт. Мне очень стремно делать оценки по отдельным задачам:
И пока я не вижу значимых плюсов оценки сроков по отдельным задачам, мне неясно, зачем впускать вот это все в мою жизнь. Я уже так работал и больше не хочу.
Я работаю в команде, про которую в конце статьи пишут. Могу рассказать что-нибудь :)
3000 тестов UI с поднятием приложения, 3000 API тестов с поднятием приложения, 10000 юнит-тестов. В прогоне из-за нестабильностей падает 0-7 тестов.
У нас 6 тестировщиков и регрессия покрыта тестами полностью. Это верно, что мы тратим много сил на это. Но без овертаймов. Если бы не тратили, у нас было бы больше тестеров(16?), потому что ручной регресии было бы очень много. Кажется, в нашей ситуации 6 тестеров и автоматическая регрессия выходят дешевле, чем 16 тестеров и «какие-то» автотесты.
Во-вторых.
Я почти не работал в мире, где все задачи с дедлайнами. Вы мне расскажите, как там?
На берегу, мне кажется что ставить дедлайны по всем задачам — это самообман. Все равно команда разработки не сможет сделать больше Х задачек в месяц. Еще придется устраивать адски сложные планирования в стиле «надо приоритизировать и оценить сроки для 40 входящих задач, а также посмотреть на 30 задачек, что сейчас в разработке». Вы в другой ветке писали, что на планирование уходило по 2 дня из 10 (=двухнедельный спринт). Я пока не увидел плюсов у таких гигантских трудозатрат.
Еще интересно, были ли в вашем мире овертаймы у команды разработки. Если да, то как часто и как плохо?