Комментарии 10
Вы при планировании спринта учитываете время на тестирование и багфикс в зависимости от сложности задач? Или смотрите только на производительность по оценкам фич?
1. Насколько полезны ежедневные короткие митинги, особенно если вся команда в одном офисе?
2. Как оцениваются задачи? В story points?
3. Бывает ли у разработчиков простой в конце спринта? Когда ты отдал тестировщику свои задачи, а взять из бэклога уже нечего.
2. Как оцениваются задачи? В story points?
3. Бывает ли у разработчиков простой в конце спринта? Когда ты отдал тестировщику свои задачи, а взять из бэклога уже нечего.
1. В нашем случае команда была не вся в одном офисе, так что полноценно ответить на этот вопрос не смогу. Касательно нас — было полезно, так как в начале, мы, по старой привычке, решали возникающие вопросы личной беседой тех кого они касались (по их же мнению), и в итоге это пару раз привело к тому, что принятые между двумя-тремя людьми решения повлияли на работу остальной команды. SCRUM-митинги в значительной степени позволяют защитить от подобных казусов.
2. Да, в story points.
3. Как такового, простоя не бывало у нас, потому что тестировщику все таки отдавались промежуточные сборки, и он по ним выкатывал некоторое количество багов, которые надо было чинить.
2. Да, в story points.
3. Как такового, простоя не бывало у нас, потому что тестировщику все таки отдавались промежуточные сборки, и он по ним выкатывал некоторое количество багов, которые надо было чинить.
В продолжение 2 — А как сравниваются веса story points у разных членов команды, например, у iOS Developer и у Backend Developer?
В продолжение 3 — То есть не было моментов, когда разработчик закончил story, а тестировщик не успел вернуть ни одного бага, но спринт еще не закончился?
4. А TDD практикуете? Насколько помогает?
В продолжение 3 — То есть не было моментов, когда разработчик закончил story, а тестировщик не успел вернуть ни одного бага, но спринт еще не закончился?
4. А TDD практикуете? Насколько помогает?
2 — у нас в команде веса не сравнивались, так как каждый со своей скоростью работает и story points эту скорость показывали. А уже основываясь на этом показателе, спустя несколько спринтов, разработчик мог понимать сколько soty points набрать себе в спринт.
3 — удивительно, но пока не было, надеюсь так и будет продолжаться.
4 — Нет, TDD не практикуем.
3 — удивительно, но пока не было, надеюсь так и будет продолжаться.
4 — Нет, TDD не практикуем.
Не пробовали программистов привлекать к тестированию хотя-бы не критичных мест?
Естественно программисты сами тоже тестят свой код, но так как темп работы был взят быстрый, а первоочередная задача программистов все таки не тестирование, то делают они это не так эффективно. Это подтвердили первые пара спринтов на одном из проектов, когда тестировщика не было и разработчики тестировали сами. В итоге стало ясно, что без тестера не обойтись.
Мой вариант который работает — тестировщик = пользователь. Он делает блек бокс тестирование билда который получается в результате спринта и который уходит клиенту. Весь фидбек группируется и уходит в беклог. Что то команда сама нашла и поправила, что то нет и надо планировать на спринт. Таким образом тестировщику не нужно знать что куда и как, он просто юзер, а точность бизнес логики функционала проверяется превентивно — описывая спецификацию на фичу, как функциональную так и техническую и последующая разработка через TDD и CI с интеграционными тестами, и пасивно бегающие юнит тесты проверяющие бизнес логику в целом. Если разработчиков ни кто не гонит, то даже джуны делая соизмеримые для себя задачи, делают их качественно и с полным циклом процесса, пускай даже убиваясь над тестами больше чем над разработкой. Качество получаемого продукта не сравнимое с ручным тестированием.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование в рамках SCRUM. Тернии, грабли и успехи