Как стать автором
Обновить

Комментарии 4

Если я правильно понял, то вы просто заставляете разработчиков перед отдачей тикета в тестинг, пройтись самостоятельно по тест плану, который написал он сам, вместе с QA?

У вас на графике, после начала эксперимента, стало больше фикситься багов, это появилось время на старые из бэклога или?
1) Мы никого не заставляем. Обсуждаем и доносим, что таким образом команда снимает внутренние зависимости. Отдельной стадии тестинга теперь нет. Разработчик самостоятельно производит проверку по тестовым сценариям, дальше — продакшен. Я подключаюсь в тех моментах, когда требуется помощь с тестовым окружением, с воспроизведением сложных кейсов, при взаимодействии с другими командами и прочее.

2) Это связано с процессами внутри команды. Мы стали более внимательно относиться к багам, соблюдать внутренний OLA по багам (Operational Level Agreement), ежедневно к дейлику проверяем все возможные каналы поступления багов. И да, разобрались со старыми багами из бэклога.
1. Когда тестировщик это выделенный человек, получается что кто-то еще смотрит на фичу перед релизом, причем свежим взглядом и возможно немного в других условиях. Это позволяет получить некоторый фидбэк (например, «то как это работает выглядит очень понятно», «здесь опечатка», «на моем компьютере не работает»). Не боитесь ли вы что потеряете такого рода обратную связь?

2. Как разработчики относятся к тому что им нужно готовить какие-то тест-кейсы и проводить тесты? Как справляются, это же немного другой способ мышления и навыков.

Спасибо за статью, тема мне кажется очень интересной.
1. Здесь есть несколько вариантов, зависит от фичи, которую мы выпускаем.
1.Часто случается так, что перед релизом всей командой так или иначе смотрим на фичу. Потребности разные: нужно написать UI тесты, сделать скриншоты для публикации статьи в базу знаний, подготовиться к демо и прочее.
2 Каждую неделю у нас проходит демо, на котором команды показывают\рассказывают другим командам что они успели сделать за неделю. Зачастую, с этого демо выносится полезный фидбек.
3. Сотрудники нашей компании — активные пользователи нашего продукта. За неделю-две до официального релиза включаем фичу только на аккаунт нашей компании, анонсируем и собираем фидбек.
4. Мы знаем пользователей, которые пользуются интеграциями в нашем продукте. За неделю-две до официального релиза предлагаем этим пользователям стать бета-тестерами и попробовать новую фичу.

2. Относятся нормально. С тех пор как эксперимент прижился мы идем дальше по пути снятия зависимостей от внешних для команды людей. Например, недавно, наш серверный разработчик стал самостоятельно писать код сайта (на сайте у нас заложена некоторая логика). Клиентские разработчики планируют переписать серверную часть одной из интеграций с java на node.js, чтобы им было проще с ней работать и не прибегать к помощи серверного разработчика.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.