testomat.io управление авто тестамиПробуем делать, пихаем туда разные тесты, но постановка задачи происходит еженедельно. Как организовать работу тестеров (ручных и автотестеров) чтоб не пришлось давать им таски, либо чтоб они создавали их сами себе?
А в чем проблема собсна?
Наймите qa-менеджера, пусть рулит, ставит таски, раз уж самим мозгов не хватает поставить процесс (уж извините)
Рабочий флоу: 2х-недельный спринт, дев-тим делает функциональность и выкатывает “дев-билды” для qa-тимы; у фичи должен быть внятный дескрипшн + описаны зависимости и прямые аффекты на другие компоненты системы, это позволит накидать чеклист на фичу еще до 1го дев-билда; после получения оного - qa гоняет фичу и параллельно пишет тест-план(ы), если явных багов не обнаружено и дев-билд стабилен - можно начинать автоматизировать.
Параметры можно изменять в зависимости от распределения обязаностей внутри qa-тимы.
З.Ы. не осилите - велком в личку с предложениями о работе))
Хм… Это стандартная задача для QA лида.
- Спринты, я так понял, приняты недельные. OK.
Значит, можно предложить 2 расклада:
а). 3 дня разрабы пишут код, в конце 3-го дня основные фичи должны быть закончены. В это время тестировщики пишут тесты. Тогда у тестировщиков будет 2 дня на тестирование + повторное тестирование, а у разработчиков останется 2 дня на багфикс и докатку тех фичей, которые не успели за 3 дня.
Плюсы подхода: быстрая реакция на изменения. Фича заказана - через неделю уже выкачена.
Минусы подхода: крайне скудный запас времени на тестирование. Если фича приходит с задержкой - тестирование не успеет закончиться.
б). Спринт тестировщиков идёт со смещением в неделю. Тогда у разработчиков есть неделя, чтобы выкатить фичи. Все выкаченные за спринт фичи попадают в тестирование на QA спринт. Иными словами, тестирование всех выкаченных за спринт фич должно быть закончено в следующем спринте. Для мануальщиков это должно выглядеть так: тестировщик берёт фичу, пишет на неё тест, затем проходит его. Если принят расклад, когда тест пишет 1 человек, а проходит другой - тогда 1-й тестировщик пишет тест, затем берёт уже готовый тест от 2-го тестировщика, а его тест берёт коллега и т.д. Если все фичи протестированы и остался запас времени - пишутся тесты на фичу следующего спринта. Для тех мануальщиков, которые планируют перейти в автоматизацию, допустимо на этом этапе попробовать написать свои автотесты.
Плюсы подхода: б_о_льшая стабильность и предсказуемость.
Минусы подхода: более медленная реакция на изменения. От закача фичи до её выкатки пройдёт не меньше 2-х недель.
Насчёт автотестов, я бы предложил автоматизировать регрессию. То есть, расклад будет такой: мануальщики пишут тесты, когда фича принимается заказчиком, данные тесты переходят в разряд регрессии и попадают в скоуп для автоматизаторов. Какие тесты автоматизировать - зависит от приоритета теста + сложности его автоматизации (это если коротко). После того, как тест автоматизирован - он получает пометку Automated и выпадает из скоупа регрессии для мануальщиков (опять-таки, если коротко, есть ньюансы).
Есть ещё куча ньюансов насчёт Entry и Exit Criteria для тестирования, организации скрам-митингов, постановке и приёмке задач, но будет слишком много букв 
У меня вопрос-дополнение к вопросу ТС. Кто-нибудь может поделиться опытом работы в “Agile” команде когда на 15 разработчиков 1 тестировщик (мануальный, автоматизатор, тим лид плюс Jenkins поддерживать - все в одном лице). Спринт 2 недели. Хотят автоматизировать все, не видят профита в мануальных тестах. Буду благодарна за любой совет по выживанию и оптимизации процесса (каким задачам все-таки отдавали больше приоритета?) Моя позиция все-же написать хорошие мануальные тесты и затем уже автоматизировать стабильную часть. (вариант нанять больше тестировщиков пока невозможен, вариант сменить работу в процессе рассмотрения XD шутка).
У нас команда меньше (7 + qa/ta в моём лице, тимлид/pdo отдельно), но в рамках двхунедельных спринтов всё более-мене укладывается. Основной прицел автоматизации - регрессия.
Зависит от направленности проекта. Есть расклады, когда действительно выгоднее автоматизировать всё, но их не так много. Например, если у проекта нет UI или проект представляет из себя middleware между 2-мя или более системами.
Многовато, конечно. Если ставить задачу “по выживанию” - то определяйте приоритеты и автоматизируйте согласно полученному бэклогу. Если ставить задачу обеспечения качества на данном проекте - значит, Ваша задача - вовлекать разработчиков по максимуму в процесс тестирования. Это означает, что юнит тесты - это must. Без нормальных юнит тестов фича не идёт в релиз в принципе. Дальше, как вариант, можно предложить вовлекать разработчиков в написание системных тестов. Если это возможно, я бы строил процесс так:
1). Заказчик добавляет фичу в бэклог и приоретизирует её.
2). Фича смотрится командой, если в описании фичи находятся дефекты - фича отправляется заказчику на доработку.
3). Если описание OK - фича берётся в работу согласно приоритету. Разработка фичи начинается. На этом этапе Вам необходимо написать мануальные тест кейсы для данной фичи.
4). Когда разработка фичи заканчивается и юнит тесты написаны, если у разработчика есть свободное время и Вы ещё не написали автотесты к этой фиче - он может Вам в этом помочь.
5). На этапе тестирования Вы проверяете фичу насколько возможно - автотестами, всё, что не успели написать - мануально.
Где-то так
1 лайк
Это web проект, включающий в себя site-builder, систему резервации, интеграция с внешними системами как booking.com и airbnb и пр, разные каледари и много логики для расчетов тарифов. Поэтому, считаю, что без мануальных тестов никак.
И большое спасибо за советы! 
Ну, на веб-морду 100% автоматизации сделать можно, но тяжко. Но нужна немаленькая команда матёрых автоматизаторов, чтобы успевать за 15-ю разработчиками. Кроме того, очень неприятны задачи по отслеживанию корректности разметки. Их очень просто просмотреть глазами, но очень неприятно автоматизировать.
Так что с Вашим мнением соглашусь.
1 лайк
спасибо
CI сделайте - QA сабтаски к каждой стори: Create TC, Test branch, Test integration
всё - профит