0 просмотренных постов скрыто
На словах-то
На словах сеньор толстой а на деле джун простой!
Как уложить тестирование фичи внутрь спринта?
Когда команда с горем пополам научилась попадать с разработкой запланированного внутрь спринта, то встает следующий вопрос - а почему мы все равно не успеваем впихнуть то, что уже было разработано в релиз после спринта?
У нас именно так и получилось. Вначале разработчики не использовали никакой системы при планировании спринта - это было больше похоже на индивидуальное планирование, каждый брал себе столько сколько сможет унести, и конечно результат спринта был достаточно рандомным. Что конечно расстраивало заказчиков, никто не понимал - когда же будет доставка конкретной фичи?
После внедрения poker planning и story points, ситуация с прогнозированием разработки улучшилась значительно. Но заказчики (Product Managers в нашем случае) инстинктивно воспринимали завершение разработки как готовность фичи. Это конечно было ошибочное ожидание, более того, когда PM смотрели на каждую фичу и видели:
Фича A -> 3 Story Points
Фича B -> 8 Story points
То ошибочно думали, что тестирование будет занимать пропорциональное количество времени, то есть например:
Фича A -> 1 день?
Фича B -> 2 дня?
Но в реальности объем тестирования никак не был связан с Dev Effort по разработке конкретной фичи. Все могло быть с точностью до наоборот:
Фича A -> 3 дня
Фича B -> 1 день
Дело в том, что тестирование очень часто находит ошибки в новой фиче, что вызывает еще один цикл исправлений (дополнительный Dev Effort), и еще один цикл тестирования/перетестирования. И чем больше объем тестирования конкретной фичи, тем дольше цикл перетестирования. А чем более сложная фича (не равно емкости Dev Effort), тем больше циклов исправлений и перетестирования ожидается.
Можно предложить укладывать циклы тестирования и перетестирования в изначальный Dev Effort в Story Points, но Capacity команды Тестирования не входит в команду Dev, поэтому так не получится.
Поэтому мы решили попробовать следующий подход. Команда тестирования на стадии прототипирования фичи (до начала разработки), пишет предварительные тесты для покрытия этой фичи, и должна давать отдельную оценку Test Effort, включающую риски по возможным багам, и их переработкой.
Чтобы эту оценку не путать и не складывать с Dev Effort, мы решили сделать ее не цифровой, а символьной, в размерах маек S, M, L, XL.
Мы долго думали, должна ли шкала оценки быть нелинейной (фибоначи например), как Dev Effort в Story Points. И решили, что в этом не необходимости. Дело в том, что заказчик (PM), хочет знать, когда он получит фичу в Прод, и при планировании спринта у него есть выбор, состоящий из Dev Effort и Test Effort, который либо "влазит" в спринт, либо нет. Тогда при планировании сразу понятно, что с большой вероятностью будет доставлена, а что потребует больше одного спринта.
Получилась вот такая схема:
Прогноз усилий по тестированию в размерах маек
То есть, чтобы впихнуть L фичу, надо отдать ее тестировщикам в конце первой недели спринта. Для M, S во вторник, четверг второй недели соотеcтвенно. Для XL зарелизить в рамках одного спринта шансов нет!
А как у Вас с этой проблемой?
Показать полностью
1
QA. Первые дни на проекте
Всем привет!
Возможно, кому-то будет полезно узнать, как проходят первые дни на проекте у начинающего тестировщика. Первые дни могут быть интересными, но в то же время пугающими. Важно подготовиться заранее и иметь хотя бы какое-то представление о том, чего ожидать.
Постараюсь дать небольшую инструкцию:
1.Начните изучать продукт как можно раньше.
Первым шагом должно стать изучение продукта, который вы будете тестировать. Понимание его функциональности, целевой аудитории и особенностей поможет вам эффективнее выполнять свою работу.
2. Установите коммуникацию с коллегами.
Важно наладить взаимодействие с коллегами с самого первого дня. Общение с разработчиками, проектными менеджерами и другими членами команды ускорит освоение системы и рабочих процессов.
3. Знакомство с инструментами тестирования
Познакомьтесь с инструментами, используемыми на проекте: баг-трекеры, TMS, Swagger и другие. Изучите тестовую документацию, это улучшит понимание системы и процессов тестирования.
4. Постановка задач и ожидания.
Обсудите с руководством или командой конкретные задачи, которые вам нужно выполнить в определенный срок. Четкое определение задач поможет вам лучше ориентироваться в проекте и отслеживать свой прогресс.
В зависимости от проекта, процессы адаптации могут различаться. Где-то вас будут поддерживать, где-то придется самостоятельно разбираться. Я попытался озвучить базовые вещи, которые пригодятся любому начинающему QA-инженеру и надеюсь, что это будет для кого-то полезным.
Показать полностью
Индексация ЗП в IT
Работаю в IT-компании на позиции Middle QA уже более года. Около месяца назад состоялся Performance Review, где мне дали хорошую обратную связь, и все стороны остались довольны. Звучал вопрос о зарплатных ожиданиях на следующий год, на который я дал чёткий ответ о сумме, которую хотел бы видеть на расчётном счету каждый месяц в течение следующего года.
На днях HR направила предложение о продлении контракта, и сумма там отличается от той, которую я озвучивал – в меньшую сторону.
В общем, рост ЗП за год составил 10%.
Поделитесь, кто на сколько вырос в ЗП за год в рамках своего проекта?