В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик.
Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества.
В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика
•Как безболезненно добавить практики XP и Kanban в Scrum процесс
•Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход
Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования
•Быстрое создание и поддержка тестовой документации, миф или реальность?
•Быстрое внедрение автоматизации
•Тестирование нефункциональных требований
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Бизнес требует от ИТ постоянно ускорять обороты. Сроки выхода на рынок постоянно сокращаются.
Применение гибких методологий в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/Scrum затруднено: даже простое на первые взгляд изменение бизнес процесса может затрагивать несколько систем, за которые отвечают разные команды. Выпуск релиза приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень непростой задачей, осложненной к тому же непростой политической ситуацией, типичной для крупной организации.
Мы поговорим о системном подходе к снижению Time-to-Market для сложных задач координации релиза, характерных для крупных организаций
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
Самый большой проект, с котором сталкивалась наша команда занял у нас порядка 70 человеко-месяцев, к концу в проекте было около 9000 тикетов, объединённых в 318 эпиков. Объём технического задания превышал 1000 страниц. Как мы справились с этим довольно небольшой командой? Один менеджер, один аналитик, несколько разработчиков.
Нам помогли бизнес-процессы или попросту жёстко прописанные workflow для любой ситуации, любого вида задач или входных данных. Как задача обрабатывается аналитиком, когда она попадает программистам, когда пишется технический дизайн. Как эта схема накладывается на тикетную систему, как использовать эпики и задачи. Все эти правила мы выписали болью ошибок в планировании (и финансах) и я уверен, что они могут сэкономить вам несколько месяцев собственных опытов.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
Максим Богуславский, Ищем специалиста по обеспечению качества вместеScrumTrek
Проворные методологии прочно вошли в жизнь современной разработки, мы изучили процессы, внедрили их и пожимаем плоды. Теперь вам в команду нужен специалист по обеспечению качества. На примере своего опыта подбора, я хочу показать как собрать команду своей мечты. На докладе я расскажу о:
- подготовке к подбору человека;
- составлении описания вакансии;
- проведении собеседования;
- проведении испытательного срока;
- последующей работе с сотрудником.
Антон Немчинов, Применимость SAFe в крупной финансовой организацииScrumTrek
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Рассказ о новых возможностях конференции разработчиков высоконагруженных систем HighLoad++: экспертной зоне, домашних заданиях, новом подходе к спонсорству и так далее!
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
QA Fest 2014. Катерина Овеченко. Безопасность сессий в веб-приложениях: практ...QAFest
"86% всех сайтов имеют хотя бы одну серьезную уязвимость" WhiteHat Security
Уязвимости приложений относящиеся к управлению сессиями занимают 2ое место в десятке самых распространенных уязвимостей. Уязвимые к атаке сессии позволяют злоумышленнику перехватить сессию пользователя, получить его логин-пароль , тем самым полностью завладеть данными пользователя в веб-приложении. •рассмотрим, как вообще устроена сессия в веб-приложении
•на живых примерах изучим распространенные в уязвимости веб-сессий
•разберем рекоммендации по устранению данных уязвимостей
•рассмотрим несколько инструменты необходимых при тестировании безопасности веб-сессий
Будут рассмотрены следующие уязвимости: Session Fixation, Session Hijacking, Cross-Site Request Forgery.
Данный доклад позволит вам не только ознакомиться с теорией, как тестировать безопасность веб-сессии, но и даст "стартовые" знания для того, чтобы попробовать это тестирование на своем проекте.
QA Fest 2015. Дмитрий Горин. QA dream team или как создать и вырастить свою ...QAFest
Все мы работаем в командах, но не все знают как она создавалась и что было сделано до того как мы пришли.В докладе я расскажу:
когда группа людей становится командой и что происходит в ней на разных этапах
- своем опыте создания QA отдела
- наиболее полезных инструментах для работы с командой
- ценности делегирования для обучения и развития
Подход и инструменты измерения эффективности процесса разработки или как держ...HOWWEDOIT
— Как понять, что процесс разработки эффективен и на что опираться при изменении процессов.
— Как определить узкие места технической команды и посчитать ее эффективность.
— Удобные инструменты сбора, хранения и визуализации данных.
Олег Бунин (Онтико) | Менеджмент и бизнес-процессы в разработке highload-прое...RIF-Technology
Самый большой проект, с котором сталкивалась наша команда занял у нас порядка 70 человеко-месяцев, к концу в проекте было около 9000 тикетов, объединённых в 318 эпиков. Объём технического задания превышал 1000 страниц. Как мы справились с этим довольно небольшой командой? Один менеджер, один аналитик, несколько разработчиков.
Нам помогли бизнес-процессы или попросту жёстко прописанные workflow для любой ситуации, любого вида задач или входных данных. Как задача обрабатывается аналитиком, когда она попадает программистам, когда пишется технический дизайн. Как эта схема накладывается на тикетную систему, как использовать эпики и задачи. Все эти правила мы выписали болью ошибок в планировании (и финансах) и я уверен, что они могут сэкономить вам несколько месяцев собственных опытов.
Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Кирилл Толкачев, Александр Тарасов, Хипстеры в энтерпрайзе. Шагаем в ногу со ...ScrumTrek
В больших компаниях обычно существует пропасть между людьми, которые делают, и людьми, которые сопровождают сделанное. Разные компетенции, разные области знаний, разная ответственность за функционирование продукта не позволяют компании эффективно разрабатывать и внедрять уникальные решения, вовремя менять часть технологического стека или весь стек целиком. Людям становится не интересно и сложно разбираться со старыми наработками, а внедрение новых сопровождается закостенелостью стандартов и инертностью компании. В рамках доклада будут рассмотрены следующие вопросы:
- что сегодня помогает закладывать нужные оси вариативности в архитектуру?
- как отделить и подружить разработку, внедрение и сопровождение?
- как замотивировать людей быть эффективными, использовать удобные инструменты?
- как дать людям свободу в их выборе и разделять ответственность за полученный результат?
а также в программе:
- Docker
- микросервисы
- закон трёх букв
Максим Богуславский, Ищем специалиста по обеспечению качества вместеScrumTrek
Проворные методологии прочно вошли в жизнь современной разработки, мы изучили процессы, внедрили их и пожимаем плоды. Теперь вам в команду нужен специалист по обеспечению качества. На примере своего опыта подбора, я хочу показать как собрать команду своей мечты. На докладе я расскажу о:
- подготовке к подбору человека;
- составлении описания вакансии;
- проведении собеседования;
- проведении испытательного срока;
- последующей работе с сотрудником.
Антон Немчинов, Применимость SAFe в крупной финансовой организацииScrumTrek
Гибкие практики разработки ПО не могут существовать долго в рамках одной команды в крупной организации. Попытки масштабирования подхода на всю организацию сталкиваются с ограничением самой организации. Можно придумать подход самому. А можно воспользоваться готовыми методики, как на пример SAFe. Но без адаптации, изменения процессов, ролей и мировоззрения в организации такая трансформация взлететь не сможет. Мой доклад об опыте применимости SAFe в конкретной крупной финансовой организации и о том, через какие изменения она должна пройти, чтобы достичь успеха.
Рассказ о новых возможностях конференции разработчиков высоконагруженных систем HighLoad++: экспертной зоне, домашних заданиях, новом подходе к спонсорству и так далее!
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
QA Fest 2014. Катерина Овеченко. Безопасность сессий в веб-приложениях: практ...QAFest
"86% всех сайтов имеют хотя бы одну серьезную уязвимость" WhiteHat Security
Уязвимости приложений относящиеся к управлению сессиями занимают 2ое место в десятке самых распространенных уязвимостей. Уязвимые к атаке сессии позволяют злоумышленнику перехватить сессию пользователя, получить его логин-пароль , тем самым полностью завладеть данными пользователя в веб-приложении. •рассмотрим, как вообще устроена сессия в веб-приложении
•на живых примерах изучим распространенные в уязвимости веб-сессий
•разберем рекоммендации по устранению данных уязвимостей
•рассмотрим несколько инструменты необходимых при тестировании безопасности веб-сессий
Будут рассмотрены следующие уязвимости: Session Fixation, Session Hijacking, Cross-Site Request Forgery.
Данный доклад позволит вам не только ознакомиться с теорией, как тестировать безопасность веб-сессии, но и даст "стартовые" знания для того, чтобы попробовать это тестирование на своем проекте.
QA Fest 2015. Дмитрий Горин. QA dream team или как создать и вырастить свою ...QAFest
Все мы работаем в командах, но не все знают как она создавалась и что было сделано до того как мы пришли.В докладе я расскажу:
когда группа людей становится командой и что происходит в ней на разных этапах
- своем опыте создания QA отдела
- наиболее полезных инструментах для работы с командой
- ценности делегирования для обучения и развития
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
QA Fest 2014. Виктор Гожий. Практика юзабилити тестирования на проекте от а до яQAFest
Часто, в процессе работы, мы слышим от разработчиков, что ошибку юзабилити нельзя называть ошибкой, и что фиксить ее не будут. На этот счет мы, тестировщики, готовы предоставить весомый аргумент, который называется юзабилити тестирование.
Вы узнаете, что такое юзабилити тестирование и как с помощью него можно увеличить уровень комфорта Ваших пользователей, а это, соответственно, увеличит Ваши продажи.
Юзабилити тестирование делится на этапы: подготовка, план тестирования, задания на тестирование, команды тестирования. Эти и остальные особенности юзабилити тестирования на примере реального проекта будут освещены в данном докладе. На чем стоит остановится, что нужно добавить, а чего вообще не нужно было делать, и каких ошибок избежать при работе над юзабилити тестированием проекта. Кроме того, рассматриваются вопросы, исследования работ конкурентов, и как выжать максимум с помощью методики юзабилити тестирования.
QA Fest 2015. Игорь Хрол. Тестировщик в Agile - кто это?QAFest
Гибкие процессы разработки привлекательны как для бизнеса, так и для инженеров. Но внедряя Scrum или Kanban на практике, выясняются ограничения в существовавших до этого подходах к тестированию.
На примере проекта Toptal хотелось бы поделиться практиками, как делать продукт быстро и качественно, не делая при этом тестирование узким звеном в поставке.
QA Fest 2014. Ярослав Пернеровский. Appium - два в одном. рецепт приготовлени...QAFest
Попытка раскрытия темы одного из самых перспективных инструментов автоматизации тестирования мобильных приложений. Реализация параллельного прогона одних и тех же тестов на разных мобильных платформах с его помощью. Грабли, по которым придется идти в процессе. И стоит ли игра свеч?
QA Fest 2014. Татьяна Завьялова. Юзабилити и живые людиQAFest
Классический подход к созданию программного продукта с высоким уровнем юзабилити предусматривает итеративную разработку с тестированием на потенциальных пользователях в конце каждой итерации. Зачем проводить тестирование на живых людях? Мы все прекрасно понимаем, что каждая отдельная конфигурация системы, будь то аппаратное или программное обеспечение, влияет на качество работы системы. Но вот с той стороны экрана есть два, вроде как стандартных, глаза, которые видят изображение на экране, и мозг, который полученную информацию интерпретирует. Конфигурации (опыт и навыки) этого мозга настолько разнообразны, что заранее предугадать последующую интерпретацию - задача очень даже нетривиальная.
Я расскажу о том, как проверить догадки бизнеса, дизайнеров и разработчиков методом пользовательского тестирования. Затрону методологию, протоколы, покажу примеры из своей практики. Будет интересно.
Тема скорее обзорная и рассчитана на широкую аудиторию. Формат: лекция с элементами дискуссии.
QA Fest 2014. Юрий Суворов. Использование Pivot tables в связке с TFS для упр...QAFest
Из доклада вы узнаете как использовать одну из мощных возможностей Excel – Pivot Tables в связке с TFS для упрощения сбора метрик в комплексных проектах. Речь пойдет о реализации метода полуавтоматического сбора метрик, который мы разработали на нашем проекте, выигрыше во времени по сравнению с «ручным подсчетом» метрик и примерах с нашего проекта.
Данный доклад ориентирован на средний уровень подготовки слушателей, особенно полезен для слушателей, у которых контроль метрик на проекте ведется «вручную», несовершенен, либо отсутствует.
QA Fest 2014. Антон Капитаненко. Web – магия qa процессов в (сверх-) высоко-н...QAFest
Современный, сложный, нагруженный - это короткое описание того WEB, который создается в Wargaming, и вполне возможно, в вашей компании. Для того, чтобы различные проекты пользовались лучшими практиками предшественников (и не наступали на уже 100 раз опробованные грабли), мы выработали свои процессы и подходы к созданию ПО. В этом докладе я хочу сделать обзор именно QA части в этом процессе – и я очень надеюсь, что вы сможете почерпнуть что-то полезное именно для своих проектов.
Аспекты, которые будут затронуты: •пред-производственные (QA) активности
• QA во время production
• виды (не-функционального) тестирования
• Dev / Test площадки
• тестовые артефакты
• выпуск продукта и post-release активности
QA Fest 2015. Сергей Пирогов. Красивые JBehave отчетыQAFest
В докладе я хочу поделиться личным опытом написания кастомного репортера для JBehave. Покажу причины решения написать свой репортер и пути решения проблемы. В конце я покажу как я имплементировал связку Allure report и знаменитого BDD фреймворка для Java - JBehave.
QA Fest 2014. Анна Гаврилюк. Cool as сucumberQAFest
Что такое Gherkin? Как всё это работает, например с Cucumber-jvm? Какие обычные и специфичные features реализует фреймворк? Каковы best practices его использования? Когда вообще все это стоит применять?
Данный доклад интересен для тех кто желает ознакомится с BDD и вышеназванным фреймворком. Много практических примеров и несколько советов по использованию.
QA Fest. Никита Постолакий. Разработка тест кейсов по методике Pair wiseQAFest
Мастер класс посвящен разработке тест кейсов с использованием методики всех пар (Pair wise).
Когда большое количество входных данных взаимодействует и влияет на поведение системы, pair wise значительно сокращает количество тестов гарантируя при этом высокое тестовое покрытие. Pair wise успешно применяется для конфигурационного тестирования, тестирования веб форм, сложных систем с высоким требованием к покрытию.
На мастер классе мы: •кратко рассмотрим теорию;
•на примерах будем разрабатывать тест кейсы по методике пар вручную;
•обсудим применение pair wise вместе с разбиением на классы эквивалентности и граничными значениями;
•разберем ситуацию с несовместимостью или зависимостью параметров друг от друга;
•будем составлять модели и генерировать тест кейсы с помощью программы PICT от Microsoft;
•обсудим работу с регрессионным тест набором.
В дополнение я покажу пример реальной автоматизации тестирования на основе моделей с применением Pair wise техники.
QA Fest 2014. Алла Пенальба. Eu vs Ukraine workplace the hidden difference, и...QAFest
Многие сейчас задумываются о возможности работы за границей. Но немногие осознают, что условия работы и требования к квалификации ИТ специалистов достаточно разные в Украине и Западной Европе. Во время данной сессии я бы хотела поделиться со слушателями своим опытом поиска работы в ЕС: как постоен процесc рекрутинга и на что стоит обратить внимание при поиске. Также я поделюсь личным опытом работы в бельгийской продуктовой компанией, расскажу как у нас были постороенны процессы и в чем разница между ИТ компаниями в Украине и Западной Европе.
QA Fest 2016. Андрей Мясников. Тест-дизайн для чайниковQAFest
В своём докладе я расскажу вам о том, кто такие тест-аналитики, тест-дизайнеры и должны ли их роль выполнять обычные тестировщики. Также сделаю обзор основных и проверенных методик тест-дизайна. Расскажу про их плюсы и минусы.
Будем учиться тестировать не 12 часов, а головой!
QA Fest 2014. Павел Басюк. Test automation: а что на выходе?QAFest
Атоматизация бывает разной: большой и маленькой, скучной и веселой. Но каждый раз когда запускаються автотесты - есть какие-то результаты. Это могут быть красивые или не очень html отчеты, либо банальный текстовый файл с большым логом. Именно о всём разнообразии отчётов мы и пообщаемся: кто и когда их создает, а кто и зачем их читает. Рассмотрим несколько примеров реальных отчетов, и обсудим как их можно улучшить.
Great functional testing with WebDriver and ThucydidesMikalai Alimenkou
Presentation from online conference ConfeT&QA (October 2012) and Selenium Camp 2013 (February 2013) about techniques and approaches to create great functional automated tests.
Бытовая классификация тестировщиков с точки зрения разработчикаMikalai Alimenkou
Тестировщики часто говорят о противостоянии и конфликтах с разработчиками. Но ведь есть команды, где все живут в мире и согласии. Видимо что-то тут не так? Я хочу поговорить о том, как тестировщиков видят сами разработчики. В докладе будет проведена забавная классификация. Кроме известного всем тестировщика-обезьянки будут представлены тестировщик-муха, тестировщик-нацист, тестировщик-панда и многие другие герои. Высможете лишний раз задуматься над тем, как вас видят со стороны и, возможно, изменить ситуацию к лучшему.
Доклад будет также полезен менеджерам проектов и лидерам команд. Вы сможете быстрее распознавать те или иные шаблоны поведения тестировщикови принимать меры по повышению уровня командной работы. Приходите, будет интересно!
Functional tests are usually the slowest layer of automated tests for almost every product. They use product via UI, store data in real DB, integrate with external services and do other “slow” things. The first easy answer how to make them fast is to run in parallel. But in reality tests depends on the same data and intersect by some common functionality. In this talk we will review useful techniques and approaches how to win this battle.
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Anton Stoliar SQADays2012 Управление качеством в Agile. Как опередить баги.Anton Stoliar
1. Цель презентации:
• Побудить аудиторию пользоваться описанными техниками, которые могут помочь уменьшить количество «фейлов» со стороны QA команды в Agile-based проектах.
• Сфокусировать внимание на «фишках» которые особенно пропагандируются в Agile, которые помогают выпускать более качественный продукт
2. Какова практическая ценность презентации для аудитории:
• Поделиться конкретным опытом использования всяческих Agile-техник : Sprint Planning на основе QA оценок, Создание командного Vision-a на основе Product Canvas, First Release Baseline
• Поделиться некоторыми hint-ами когда ты вроде бы test team lead, но по факту менеджишь еще и команду разработки.
3. Для кого предназначена:
• QA которые уже работали по Agile (Scrum в частности)
• Начинающие ПМs и QA Team Leads
• Ребята которым скоро придется лидать Agile-проекты
4. Короткий план презентации по шагам:
• Чего могут жать от работы QA команды к зависимости от специфики проекта\компании
• Чего ожидают от QA в Agile
• Какие техники могут помочь выпустить более правильный\успешный\ качественный продукт
o Как формировать у команды общий Vision и как это помогает снижать дефекты в продукте
o Как планировать спринт отталкиваясь от QA-команды чтобы снизить овертаймы
o Как First Release Baseline помогает спланировать регрессию, когда совсем не осталось на нее времени
Выступление на семинаре в Яндексе
Как -то получается, что (по большому счету) альтернативы Agile-подходам при построении эффективных процессов нет. А что делать, если Agile применить невозможно? Причин может быть множество: "неправильная" структура организации, "не те" люди, негибкие начальники и так далее.
Невозможно построить скрам? Но придумать вам свой собственный скрам никто запретить не может!
Мы рассмотрим 3 реальных кейса провала внедрения Agile и вместе обсудим, как можно было бы поступить в каждой конкретной ситуации. По каждому случаю я расскажу, что произошло в реальности.
Виталий Шибаев - Креативный менеджмент глазами разработчика: как выжить в agi...HappyDev
Матерый enterprise проект с "зоопарком" из разнообразных технологий. Часто меняющаяся команда и требовательный заказчик. Менеджер, активно пытающийся вытянуть проект... Все составляющие для сюжета, достойного Титаника.
Было перепробовано множество практик для улучшения процесса разработки, и больше всего это влияло на нас, разработчиков. В одночасье рушились привычные устои, а новые, не успев прижиться, менялись снова. Разве возможна нормальная работа в такой нервной обстановке?
Автор критически оценит парное программирование, тестирование, code review и прочие практики из мира улучшения разработки, а также расшарит набитые шишки и обнаруженные грабли.
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
QA Fest 2019. Сергій Короленко. Топ веб вразливостей за 40 хвилинQAFest
Поговоримо про найпопулярніші помилки, яких припускаються розробники веб додатків, та як зловмисник може використати їх на свою користь. Охопимо максимальну кількість матеріалу за короткий проміжок часу.
QA Fest 2019. Анна Чернышова. Self-healing test automation 2.0. The FutureQAFest
Мы уже разговаривали о self-healing автоматизации, как она работает, какие есть подходы, чем они хороши, плохи и о новом инструменте, который мы разрабатываем в EPAM. Наш продукт завершает стадию POC и настало время поделиться результатами и понять, насколько self-healing автоматизация поможет вашим тестам стать стабильнее? Или наоборот, навредит?... Приходи и узнаешь!
QA Fest 2019. Doug Sillars. It's just too Slow: Testing Mobile application pe...QAFest
Mobile apps and websites are now the predominant ways that users interact with brands. Research has shown that slow sites and apps lose customer engagement. Despite this, most mobile sites and apps have performance issues that can be easily resolved once diagnosed. In this talk, we will walk through steps to diagnose network performance bottlenecks in mobile services. We'll discuss real-world examples and how they were resolved. Attendees will leave this talk armed with the tools to test, diagnose and resolve the top network performance issues that affect mobile today.
QA Fest 2019. Катерина Спринсян. Параллельное покрытие автотестами и другие и...QAFest
Раньше мы в Badoo фокусировались в основным на ручном тестировании. Получался этакий дедлок мануальной регрессии: не было времени, чтоб писать тесты, потому что много тестировали руками, а много тестировали руками, потому что не было автотестов.
Но мы смогли наладить свою систему автоматизации и процессы, разорвали этот порочный круг и начали писать годные тесты.
В своем докладе я расскажу, как нам удалось сократить ручную регрессию с 90% до 30% рабочего времени, при этом сохранить достойный уровень качества и профессионально вырасти!
QA Fest 2019. Никита Галкин. Как зарабатывать большеQAFest
Вам знаком термин mindshift? Именно его вы испытаете от этого доклада. Он будет не о QA процессах или инструментах, он будет о деньгах и бизнесе, о рисках и коммуникациях. Все это с примерами из Украинского и мировом IT в формате живого общения с аудиторией.
QA Fest 2019. Сергей Пирогов. Why everything is spoiledQAFest
In this talk, I will cover the pain points of the Test Automation process. We will discuss traps, mistakes and crazy decisions that lead to test automation failure and lost budgets.
QA Fest 2019. Сергей Новик. Между мотивацией и выгораниемQAFest
Поговорим о мотивации простым языком, проясним, что стимулирует нас работать лучше. Поисследуем обратную сторону мотивации – выгорание. Выясним, как диагностировать выгорание и не допустить неприятных последствий.
QA Fest 2019. Владимир Никонов. Код Шредингера или зачем и как мы тестируем н...QAFest
Для разработки современных программных решений необходимо обеспечить эффективную систему тестирования, которая состоит из большого количества компонентов и задает требования ко всем этапам разработки.
Владимир Никонов, руководитель департамента разработки платформы в Terrasoft, эксперт в области проектирования приложений с опытом работы более 10 лет, поделится экспертным мнением с участниками QA Fest и расскажет:
- об инструментах и процессах на каждом этапе создания и поставки функциональности: от unit-тестов до нефункционального тестирования;
- о требования к инструментам тестирования и компетенциям команды QA-инженеров, которые необходимо выдвигать на каждом этапе тестирования;
- как внедрять современные подходы в существующий проект с минимальными затратами;
- как развивать команду и процессы тестирования в целом.
QA Fest 2019. Владимир Трандафилов. GUI automation of WEB application with SV...QAFest
Доклад посвящен автоматизации тестирования WEB-приложений с SVG-графикой. В 1-ой части доклада даны короткое описание процессов разрабатываемого приложения и обоснование необходимости применения SVG-графики. Во 2-ой части сделан короткий обзор SVG-графики, показаны основные преимущества/недостатки такого типа графики, сделан обзор основных SVG-поверхностей и рассмотрен процесс их трансформации с помощью матрицы преобразования с разбором ее основных типов. В 3-ей части обозначены основные проблемы автоматизации действий с SVG-графикой, такие как drag’n’drop графических объектов (SVG на SVG), их масштабирование при помощи колесика мышки и выделение ломаный линий. В 4-ой части показаны решения обозначенных проблем с использованием JavaScript.
QA Fest 2019. Иван Крутов. Bulletproof Selenium ClusterQAFest
Browser tests are known to be the flakiest ones. This is partly because browser infrastructure is complicated to maintain. But the second reason is – mainstream browser automation tools such as Selenium server are far from being efficient.
A year ago I have shown Selenoid - a truly efficient replacement of the standard Selenium server. This year I would like to demonstrate how to organize a fault-tolerant and easily scalable Selenium cluster using virtual machines in the cloud. I will start by setting up several Selenoid nodes and configure them to send logs and recorded videos to S3-compatible storage. Then I will run multiple Ggr load balancer instances allowing to use all running Selenoid nodes and organize a single entry point to the cluster. Finally, we'll discuss how to work with VNC and video recording in such a cluster.
QA Fest 2019. Николай Мижигурский. Миссия /*не*/выполнима: гуманитарий собесе...QAFest
Случалось ли вам запускать автоматизацию на проекте? Испытывать непревзойденное удовольствие от необходимости собеседовать технического специалиста, когда сам не имеешь технического опыта? Если да, то этот доклад для вас.
Мы научимся анализировать сеньорность кандитата, его технический уровень и способность к организации команд. Но самое главное - все это мы сможем достичь без серьезного технического опыта. Будет интересно, заходи на огонек!
QA Fest 2019. Володимир Стиран. Чим раніше – тим вигідніше, але ніколи не піз...QAFest
Це буде огляд підходів до побудови програми безпеки програмного забезпечення в команді розробки або кампанії загалом, доповнений висновками з мого власного досвіду виконання практичних та консультаційних проектів в сфері Application Security.
QA Fest 2019. Дмитрий Прокопук. Mocks and network tricks in UI automationQAFest
Веб-приложения и технологии стремительно развиваются. Мы уже вступили в эру Single Page Application и идем к Progressive Web Application. В большинстве современных проектов идет разделение команд на front-end и back-end, и не только команд, но идет раздельная релизная политика. Это требует более детальных подходов к тестированию front-end. В этом докладе мы рассмотрим кейсы, который есть на практике при тестировании задач front-end и инструменты автоматизации, которые могут решать задачи описанные в этих кейсах: чтение request/response browser network и соответственно мокирование response.
QA Fest 2019. Екатерина Дядечко. Тестирование медицинского софта — вызовы и в...QAFest
Проектирование и производство медицинских устройств — это регулируемый бизнес. Государственные органы во всем мире призваны гарантировать безопасность и эффективность медицинских устройств. Несоответствие нормативным требованиям ставит под угрозу жизнь и здоровье человека. Как медицинское регулирование влияет на рабочий процесс компании производителя? Мы поговорим о том, какие вызовы стоят перед тестировщиком медицинского софта, а также какие возможности при этом открываются.
QA Fest 2019. Катерина Черникова. Tune your P’s: the pop-art of keeping testa...QAFest
Про «тестабилити» в последнее время говорят часто, зачастую говорят в рамках способности тестировать тот или иной функционал. А иногда и ограничиваются только возможностью автоматизировать. Существует техника “10P тестируемости”, которая используется для оптимизации процесса разработки, как инструмент анализа и настройки процессов для достижения успеха на проекте в целом. Вот об этом и поговорим.
QA Fest 2019. Алиса Бойко. Какнезапутаться в коммуникативных сетях ITQAFest
Твою гениальность не замечает никто кроме мамы? Идеи и проекты нравятся только твоему коту? Одногруппники уже руководители подразделений, а ты завис между middle и senior? Пришло время найти баги не только на проекте, но и в своей голове! Прокачаем коммуникативные навыки:)
QA Fest 2019. Святослав Логин. Как найти уязвимости в мобильном приложенииQAFest
С каждым годом мобильных приложений становится все больше, но мало кто обращает внимание на безопасность этого приложения, когда оно находится в процессе разработки. Так как бизнес нацелен только на то, чтобы оторвать большую часть пользователей, которые будут использовать это приложение, они обращают внимание на конфиденциальность своих клиентов в последнюю очередь. В своем докладе я расскажу как мануал QA может проверить мобильное приложение на уязвимости и найти топовые дыры по рейтингу OWASP. В презентации будут использованы такие тулзы Santoku Linux + Genymotion.
QA Fest 2019. Катерина Шепелєва та Інна Оснач. Що українцям потрібно знати пр...QAFest
Маючи досвід роботи з іноземними замовниками і колегами, а також вивчаючи культурні особливості жителів інших країн, ми якось поставили собі за мету з'ясувати, якими українців бачать іноземці, чи потрібно їм підлаштовуватись під нашу манеру спілкування, чи є щось, що вони зовсім не можуть прийняти.
Поділимося з вами результатами цієї затії, а також поговоримо про:
- те, що потрібно знати українцям про свої софт скіли,
- то, як відрізняються софт скіли українців і жителів кількох інших країн,
- важливість софт скілів для успішних комунікацій з іноземними колегами,
- важливість софт скілів для просування по кар'єрі.
QA Fest 2019. Антон Серпутько. Нагрузочное тестирование распределенных асинхр...QAFest
Обычно в процессе нагрузочного тестирование необходимые app-side метрики(response time, throughput, ..) можно получить прямо в генераторе нагрузки. Мы шлем запрос, получаем респонс и зачастую время выполнения запроса это и есть то что нам нужно.
Но что если после того как сервер отдал вам ответ происходит еще ряд асинхронных операций, время выполнения которых нам необходимо проверить? Как замерить время выполнения этих запросов? Какая часть системы является узким местом в производительности?
В докладе рассмотрим какие челенжи появляются в такой ситуации и как их можно решить.
QA Fest 2019. Петр Тарасенко. QA Hackathon - The Cookbook 22QAFest
Хотели бы вы, чтобы в Украине происходило больше QA ивентов? Чувствуете, что их не хватает?
Знаете, кто может это изменить? - Вы!
Я поделюсь подходами, которые мы использовали при организации QA хакатонов в Wix, которыми завтра вы сможете воспользоваться для создания вашего крутого ивента!
2. Состав команды
• 5 Менеджеров
• Распределенная команда:
– 3 центра разработки
– 11 разработчиков
• Разработчики имеют выраженную специализацию
• 1 тестировщик
5. Что-то пошло не так?
• Тестирование «внезапно» стало сваливаться на
последние 4-5 дней итерации
• Резерв спринта не закрывался после
планирования
• Митинги отнимают много времени
• Автоматизация отсутствует
6. Анализ проблем
• Неэффективное планирование.
• Система оценки времени на разработку
неэффективна
• Невозможно закрыть спринт после
планирования итерации
• В угоду скорости страдает качество кода,
накапливается технический долг
• Время тестировщика тратится на активности не
связанные с тестированием
12. Проблемы планирования
• Члены команды разбиты на группы,
поддерживающие разные модули
• Разработчики используют разные языки
программирования
• Внутри групп используются различные по
сложности технологии
• Покер планирования не работает
13. Проблемы покера
• Каждый член команды имеет равный вес,
что влечет за собой возможность
недооценки или переоценки необходимого
времени
• Время тестировщика оценивается всей
командой
14. Что делать?
Переходим от покера планирования к методу взвешенных
экспертных оценок
1. В планировании участвуют только те кто будет разрабатывать
2. Вес голоса зависит от «релевантности» разработчика
3. Коэффициенты зависят от предыдущей эффективности
4. Обязательно вводим в планирование время на юнит тесты, не
даем оценок только по функционалу
5. Время на тестирование оценивается тестировщиком совместно
с ответственным разработчиком
6. Планирование нацелено на сокращение простоев
тестировщика
15. Плючы подхода
• Оценки стали более точными, что
позволяет рационально планировать время
тестировщика в спринте
• Оценки учитывают все аспекты разработки
(BDD, интеграционное тестирование)
16. Спринт не резиновый
• Некоторые страны не успевают дать список
задач до начала планирования
• В любой момент может появиться
«горящая» задача
17. Двух зайцев одним
выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге каждый член команды имеет день в запасе на urgent задачи.
Как мы работаем с такими задачами:
• Если приходит задача емкость которой в человеко-часах больше, чем наш
резерв – задача переносится на следующий спринт
• Задачи меньшего размера берутся в работу лишь до того момента, пока есть
резерв
2. Уменьшаем технический долг
18. Технический долг
Внутренний бэклог проекта содержит такие
задачи как:
• Рефакторинг
• Написание юнит- и компонентных тестов
• Написание автотестов по готовым
сценариям
• Работа с to-do
19. Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой
доходило до 5 в день.
Решение проблемы:
• Назначение ответственного за разработку задачи
• Ограждение обычных разработчиков от лишних обсуждений
• Смена ответственных по окончании итерации
20. Стендапы не нужны?
Перенос этой активности в Jira:
• Start Work – Stop Work
• Активность за день описывается в таске
одним кратким, но понятным
комментарием.
22. Плюсы «некрасивых»
тестов
Плюсы таких тестов в начале проекта:
• Быстро создаются
• Предоставляют быструю обратную связь
• Помогают вовлечь разработчиков в тестирование
• Являются заготовками для будущих «красивых» тестов
23. Сервисы?
• Низкий порог вхождения
• Возможность быстро создать test suite для запуска полного
теста в один клик
• Тесты можно включить в CI
• Возможность разрабатывать тесты используя Mocks
параллельно с имплементацией
• Возможность создания Load и Security тестов
24. Резработчики: привлекаем
внимание
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого
смысла:
- Быстрая обратная связь
- Возможность быстро и самостоятельно проверить качество
перед коммитом
2. Демонстрация Selenium IDE
25. Разработчики: обучение
1. Возвращаем «подсевших» на качество разработчиков в родную
стихию:
- Переход от IDE к RC или WebDriver
- Выделение времени на перевод старых тестов с IDE на Java
2. SoapUI тесты для неподдатливых:
- Обучение созданию
- Расширение возможностей с Groovy
- CI
27. Заключение
• Гибкая методология может быть гибко приспособлена под
нужды команды
• Не стоит бояться экспериментов с техниками
• По настоящему высокого качества можно достигнуть лишь тогда
когда над этим работает вся команда.
• В команде должен быть человек, который недоволен текущим
процессом
Решение этой проблемы начали со внедрения TDD, как самого популярного средства в подобных ситуациях.
Однако внедрение затянулось и даже почти застопорилось. Почему?
Фраза «напиши тест» действует на разработчик магическим образом, он перестает понимать чего от него хотят.
Что является критерием достаточности теста для каждого отдельного случая?
А может быть стоит писать юнит тесты по тестовым сценариям?
Если да, то какие группы тестов использовать?
А как быть, если разработка началась, но тестировщик не успел написать тестовые сценарии?
Вместо TDD внедряем BDD (Behavior Driven Developement).
Что это такое?
Фактически это техника, с помощью которой можно научить разработчика критически оценивать свой код и писать тесты.
Для составления достаточного количества тестов разработчику необходимо определить поведение системы в ситуациях прямо покрытых требованиями и покрыть тестами лишь эти ветви кода. (Пример вынес в Notes)
Фрэнк: Что такое стек?Линда: Это структура данных, хранящая объекты в порядке «первым вошел, последним вышел» или «последним вошел, первым вышел». Обычно у этой структуры есть API с такими методами, как push() и pop(). Иногда присутствует метод peek().Фрэнк: Что делает метод push()?Линда: Метод push() принимает входной объект, например, foo и помещает его во внутренний контейнер, например, массив. Метод push() обычно ничего не возвращает.Фрэнк: Что будет, если передать методу push() два объекта, например, сначала foo, а потом bar?Линда: Второй объект bar должен оказаться наверху концептуального стека, содержащего по крайней мере два объекта, так что при вызове метода pop() объект bar должен быть извлечен первым, до первого объекта foo. Если метод pop() вызвать еще раз, должен быть возвращен объект foo и стек должен стать пустым (предполагается, что в нем ничего не было до того, как мы добавили эти два объекта).Фрэнк: Так метод pop() удаляет самый последний элемент, добавленный в стек?Линда: Да, метод pop() должен удалить верхний элемент, при этом предполагается, что в стеке есть элементы, чтобы их удалять. Метод peek() работает точно также, но при этом объект не удаляется. Метод peek() должен оставить верхний элемент в стеке.Фрэнк: Что будет, если вызвать метод pop(), когда в стек еще ничего не было добавлено?Линда: Метод pop() должен выдать исключение, показывающее, что в стек еще ничего не добавлялось.Фрэнк: Что будет, если выполнить команду push() null?Линда: Стек должен выдать исключение, так как null не является допустимым значением для метода push().
Вторая проблема – плохое планирование. И дело не в сложности оценки в часах, дело в том, что команда разбита на группы, которые занимаются различными модулями проекта, а также используют разные технологии.
Что же в таком случае плохо в Planning Poker?
Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта.
Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.
Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта.
Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.
Пример 1:
На планировании находятся 2 Java девелопера, 1 верстальщик, 1 тестировщик, 1 Flex/Flash разработчик, 1 JavaScript девелопер. На обсуждение выносится задача по разработке front-end приложения на Flex.
Оценка флексера – 12 часов. Оценка тестировщика и верстальщика – 20 часов. Остальные оценивают в 4 часа, хотя тонкостей не знают. В итоге, даже обосновав правильность своей оценки основной разработчик уменьшает время в угоду остальным до 10 часов и в итоге не укладывается в него.
То же самое с переоценкой времени, если никто не понимает как работает твой модуль, очень легко обосновать 40 часов вместо необходимых 12.
Такой же пример будет для каждого пункта, их у меня из личной практики не одна сотня наберется.
Если разрабатывается функциональность затрагивающая один модуль приложения – участвуют только ответственные за эту часть разработчики веса их голосов равны
Если затрагивается комплексная фича – каждый член команды, в зависимости от модуля и используемой технологии разработки получает вес голоса
Введение персональных коэффициентов зависящих от предыдущей эффективности члена команды (пример в ноутах)
Обязательно вводим в тестирование время на юнит тесты, не даем оценок только по функционалу
Время на тестирование оценивается тестировщиком совместно с непосредственно ответственным за разработку девелоперам
Планирование ведется с учетом того, чтобы тестировщик начал работу в первый день спринта и не имел простоев в середине цикла и не был перегружен в конце (пример в ноутах)
Пример:
Разработчик 1 последние три спринта недооценивал время – даем ему повышающий коэффициент 1.2
Разработчик 2 наоборот имеет склонность к переоценке времени – вводим понижающий коэффициент 0.7
Пример 2: Идеальный цикл таков:
Дни 1-2: Составление чеклистов по новым фичам
Дни 3-4: Начало тестирования, либо написание автотестов на фичи из предыдущих релизов
Дни 5-8: Тестирование по функциональностей по мере готовности
День 9: Code freeze и полная регрессия
День 10: Поставка и UAT
Также будет сопровождающая пояснения временная диаграмма