А как у вас разработчики относятся к такому? Не считают, вдруг, что выполняют работу тестирования? Или с этим проблем нет? :-)
У нас по одному тестировщику в команде, он может уйти в отпуск или заболеть, потому команде нужно уметь справляться без него. У нас даже в матрице зрелости команды есть пункт "QA не является bottleneck", потому QA регулярно шарит знания и учит тестировать. Один разработчик может протестировать за другим и даже отличный чек-лист напишет.
Т.е. вы список неких проверок получаете уже от аналитиков? А можете его расширить / сузить сами?
Что-то мы получаем от продакт-менеджера, но потом обсуждаем задачу, уточняем у него то, что не было учтено в описании и так расширяем критерии приемки.
Насчет порога покрытия, в идеале не опускать его до 70-80%, но так бывает не всегда, конечно) Порог зависит от уровня критичности сервиса, его влияния на весь Авито.
Процент покрытия юнитами фичи без которых, например, задача не передается в тестирование?
Такого нет, но звучит интересно. А как это организовано у вас?
Здравствуйте, Евгения, Вполне нормально, если на первых порах придется посмотреть не один курс, а 2-3, но постепенно с опытом понимание придет. К сожалению, не смогла найти тот самый курс с Udemy, который упоминаю в статье, но вот другой по Java с ютуба, который мне в своё время тоже помог: https://www.youtube.com/watch?v=Zf8kizU6S1M и потом Java+Selenium: https://www.youtube.com/watch?v=L2jMIJy0u90
Привет! Спасибо, рада, что статья понравилась :) Да, мы смещаем проверки максимально близко к разработчику - по возможности на уровень простых и быстрых Unit и API/интеграционных тестов. То есть у нас есть задача с критериями приемки и список проверок. Когда думаем, какие тесты нужно написать, чтобы покрыть фичу тестами, задаем себе вопрос: "Можно ли это проверить Unit тестом? Нужен ли API тест? Нужен ли UI тест?" Ещё до того, как отдать фичу в тестирование разработчик может прогнать написанные тесты у себя на локальной машине и убедиться, что они не падают. Конечно же, я не утверждаю, что в юнитах не может быть ошибок) Но для QA быстрее пройтись по PR разработчика и посмотреть, какие юниты он написал, чем писать на эти проверки е2е. Такой подход уменьшает время обратной связи для разработчика и удешевляет как исправление возникающих багов, так и разработку в целом.
Благодаря Shift-left команда получает: 1. Ускорение тестирования и улучшение ТТМ 2. Снижение количества ошибок, выявляемых в процессе ручного тестирования и написания е2е. 3. Сокращение трудозатрат на тестирование 4. Пирамида тестирования получается в форме пирамиды 5. Приобретение разработчиками навыков тестирования
В моих глазах, применение подхода Shift-left оказывает косвенное влияние на пирамиду тестирования и способствует её формированию именно в виде пирамиды.
Привет!
Начну с конца )
У нас по одному тестировщику в команде, он может уйти в отпуск или заболеть, потому команде нужно уметь справляться без него. У нас даже в матрице зрелости команды есть пункт "QA не является bottleneck", потому QA регулярно шарит знания и учит тестировать. Один разработчик может протестировать за другим и даже отличный чек-лист напишет.
Что-то мы получаем от продакт-менеджера, но потом обсуждаем задачу, уточняем у него то, что не было учтено в описании и так расширяем критерии приемки.
Насчет порога покрытия, в идеале не опускать его до 70-80%, но так бывает не всегда, конечно)
Порог зависит от уровня критичности сервиса, его влияния на весь Авито.
Такого нет, но звучит интересно. А как это организовано у вас?
Здравствуйте, Евгения,
Вполне нормально, если на первых порах придется посмотреть не один курс, а 2-3, но постепенно с опытом понимание придет.
К сожалению, не смогла найти тот самый курс с Udemy, который упоминаю в статье, но вот другой по Java с ютуба, который мне в своё время тоже помог: https://www.youtube.com/watch?v=Zf8kizU6S1M и потом Java+Selenium: https://www.youtube.com/watch?v=L2jMIJy0u90
Привет! Спасибо, рада, что статья понравилась :)
Да, мы смещаем проверки максимально близко к разработчику - по возможности на уровень простых и быстрых Unit и API/интеграционных тестов.
То есть у нас есть задача с критериями приемки и список проверок. Когда думаем, какие тесты нужно написать, чтобы покрыть фичу тестами, задаем себе вопрос: "Можно ли это проверить Unit тестом? Нужен ли API тест? Нужен ли UI тест?"
Ещё до того, как отдать фичу в тестирование разработчик может прогнать написанные тесты у себя на локальной машине и убедиться, что они не падают. Конечно же, я не утверждаю, что в юнитах не может быть ошибок) Но для QA быстрее пройтись по PR разработчика и посмотреть, какие юниты он написал, чем писать на эти проверки е2е.
Такой подход уменьшает время обратной связи для разработчика и удешевляет как исправление возникающих багов, так и разработку в целом.
Благодаря Shift-left команда получает:
1. Ускорение тестирования и улучшение ТТМ
2. Снижение количества ошибок, выявляемых в процессе ручного тестирования и написания е2е.
3. Сокращение трудозатрат на тестирование
4. Пирамида тестирования получается в форме пирамиды
5. Приобретение разработчиками навыков тестирования
В моих глазах, применение подхода Shift-left оказывает косвенное влияние на пирамиду тестирования и способствует её формированию именно в виде пирамиды.
Спасибо за ссылки на ютуб-курсы на английском!