Доклад Александры Ковалевой, Test Lead в QA Service, Softengi, Украина.
В презентации представлен симбиоз теории планирования и практического опыта компании QA Service в оценке трудозатрат на тестирование.
Руководители отдела тестирования, ведущие тестировщики узнают:
Чем отличаются стратегические, тактические и оперативные планы? - Что такое планирование с точки зрения тестировщика?
Кто в отвечает за планирование трудозатрат на тестирование?
Какие существуют методы оценки?
Всегда ли имеет смысл детальное планирование и оценка?
Подводные камни планирование сроков тестирования и связь с другими активностями проекта.
Как начать внедрение системы планирования и оценки «снизу»?
Тестировщикам доклад поможет посмотреть на оценку сроков с точки зрения менеджмента и ответить на вопросы:
Как я оцениваю свои задачи? Как это делают другие? Можно ли что-то улучшить?
Как заставить лида перестать спрашивать о сроках?
Чем отличаются трудозатраты на выполнение задачи и сроки завершения задачи. Как сдавать задачи в срок?
Test Labs 2009. Налютин Никита. Тестирование, как средство противодействия вн...Nikita Nalyutin
В реальной жизни тестировщики часто сталкиваются с ситуацией, когда требования к системе меняются постоянно, сроки разработки сжаты, а 100% покрытие недостижимо – не потому, что заказчик не знает, чего хочет, а потому что постоянно меняется среда, в которой работает система, и потому что опоздать – хуже, чем ошибиться. Здесь приходится говорить о достаточном уровне надежности, приоритетах и принятии определенной доли риска.
Классическая литература такие ситуации часто обходит: считается, что четко определенный процесс тестирования в подобных условиях не существует. На самом деле процесс есть, он просто другой. Целью становится не полное покрытие и документальное подтверждение следования технологии, а постоянная оценка и пересмотр критических мест системы, поддержание целостной информации о ее состоянии, ее функциональности и дефектах. В докладе пойдет речь о возможной организации такого процесса при помощи GTD, управления конфигурациями и быстрой визуальной оценки состояния системы.
Доклад Александры Ковалевой, Test Lead в QA Service, Softengi, Украина.
В презентации представлен симбиоз теории планирования и практического опыта компании QA Service в оценке трудозатрат на тестирование.
Руководители отдела тестирования, ведущие тестировщики узнают:
Чем отличаются стратегические, тактические и оперативные планы? - Что такое планирование с точки зрения тестировщика?
Кто в отвечает за планирование трудозатрат на тестирование?
Какие существуют методы оценки?
Всегда ли имеет смысл детальное планирование и оценка?
Подводные камни планирование сроков тестирования и связь с другими активностями проекта.
Как начать внедрение системы планирования и оценки «снизу»?
Тестировщикам доклад поможет посмотреть на оценку сроков с точки зрения менеджмента и ответить на вопросы:
Как я оцениваю свои задачи? Как это делают другие? Можно ли что-то улучшить?
Как заставить лида перестать спрашивать о сроках?
Чем отличаются трудозатраты на выполнение задачи и сроки завершения задачи. Как сдавать задачи в срок?
Test Labs 2009. Налютин Никита. Тестирование, как средство противодействия вн...Nikita Nalyutin
В реальной жизни тестировщики часто сталкиваются с ситуацией, когда требования к системе меняются постоянно, сроки разработки сжаты, а 100% покрытие недостижимо – не потому, что заказчик не знает, чего хочет, а потому что постоянно меняется среда, в которой работает система, и потому что опоздать – хуже, чем ошибиться. Здесь приходится говорить о достаточном уровне надежности, приоритетах и принятии определенной доли риска.
Классическая литература такие ситуации часто обходит: считается, что четко определенный процесс тестирования в подобных условиях не существует. На самом деле процесс есть, он просто другой. Целью становится не полное покрытие и документальное подтверждение следования технологии, а постоянная оценка и пересмотр критических мест системы, поддержание целостной информации о ее состоянии, ее функциональности и дефектах. В докладе пойдет речь о возможной организации такого процесса при помощи GTD, управления конфигурациями и быстрой визуальной оценки состояния системы.
Как построить программу повышения операционной эффективности. Кейсы проектовECOPSY Consulting
- Что значит «Мы уже все оптимизировали» и как с этим бороться.
- 8 KPI, на которые может работать проект по повышению операционной эффективности.
- Ключевые дилеммы проектов по повышению операционной эффективности. Примеры комплексных проектов.
Подготовлено "ЭКОПСИ Консалтинг
www.ecopsy.ru
Как оценить процесс тестирования на проектеCOMAQA.BY
Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!
Светлана Мухина, Метрики в Agile проектахScrumTrek
Я думаю, что чем сложнее метрика, тем проще ее подвести под необходимые результаты. Зачастую достаточно немного исказить одно не самое важное значение в формуле расчета и в итоге на больших числах можно получить приличное искажение. С помощью визуализации метрик тоже можно оказывать влияние и изменять мнение в необходимую вам сторону. И тут возникает вопрос #2 - "Что делать?" Использовать или не использовать метрики. Возможно, вы найдете для себя ответ на этот вопрос в моем докладе про очень простые метрики: -capacity - кол-во идеальных часов доступное в итерацию; -velocity - количество сделанной работы в стори поинтах или других "попугаях"; -burn-down - прогресс команды на данный момент, сколько сделали и сколько осталось; -индекс стабильности требований - как часто меняются требования; И еще поделюсь своим мнением о том, какая может быть польза команде от заполнения системы учета времени; Я расскажу, как мы собираем эти метрики на проектах и что нам это дает. Например, иногда они помогают найти ответ на вопрос #1 "Кто виноват?" (это шутка).
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Доклад Прониной Ольги на конференции TESTLabs 2016.
Мы привыкли работать с информацией от заказчиков, от разработчиков, с документацией. Но что делать, когда вы оказались в ситуации информационного вакуума? Как продолжать работать и развиваться, как мотивировать команду и себя, а также какие бонусы можно найти в такой обстановке – всё это мы обсудим в рамках данного доклада.
Test labs 2016. QA в тотальном аутсорсеSasha Soleev
Мы привыкли работать с информацией от заказчиков, от разработчиков, с документацией. Но что делать, когда вы оказались в ситуации информационного вакуума? Как продолжать работать и развиваться, как мотивировать команду и себя, а также какие бонусы можно найти в такой обстановке – всё это мы обсудим в рамках данного доклада.
Автор: Ольга Пронина
Как построить программу повышения операционной эффективности. Кейсы проектовECOPSY Consulting
- Что значит «Мы уже все оптимизировали» и как с этим бороться.
- 8 KPI, на которые может работать проект по повышению операционной эффективности.
- Ключевые дилеммы проектов по повышению операционной эффективности. Примеры комплексных проектов.
Подготовлено "ЭКОПСИ Консалтинг
www.ecopsy.ru
Как оценить процесс тестирования на проектеCOMAQA.BY
Тестирование - это процесс, он не стоит на месте, а нуждается в непрерывном улучшении. Мы приходим к ним на ретроспективах, из собственного и чужого опыта и ошибок, интуитивно или на основании некоторых данных. В своем докладе я расскажу, как провести оценку процесса тестирования на проекте: с чего начать, на что обратить внимание, поделюсь практическим опытом и отвечу на ваши вопросы. До встречи на докладе!
Светлана Мухина, Метрики в Agile проектахScrumTrek
Я думаю, что чем сложнее метрика, тем проще ее подвести под необходимые результаты. Зачастую достаточно немного исказить одно не самое важное значение в формуле расчета и в итоге на больших числах можно получить приличное искажение. С помощью визуализации метрик тоже можно оказывать влияние и изменять мнение в необходимую вам сторону. И тут возникает вопрос #2 - "Что делать?" Использовать или не использовать метрики. Возможно, вы найдете для себя ответ на этот вопрос в моем докладе про очень простые метрики: -capacity - кол-во идеальных часов доступное в итерацию; -velocity - количество сделанной работы в стори поинтах или других "попугаях"; -burn-down - прогресс команды на данный момент, сколько сделали и сколько осталось; -индекс стабильности требований - как часто меняются требования; И еще поделюсь своим мнением о том, какая может быть польза команде от заполнения системы учета времени; Я расскажу, как мы собираем эти метрики на проектах и что нам это дает. Например, иногда они помогают найти ответ на вопрос #1 "Кто виноват?" (это шутка).
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Доклад Прониной Ольги на конференции TESTLabs 2016.
Мы привыкли работать с информацией от заказчиков, от разработчиков, с документацией. Но что делать, когда вы оказались в ситуации информационного вакуума? Как продолжать работать и развиваться, как мотивировать команду и себя, а также какие бонусы можно найти в такой обстановке – всё это мы обсудим в рамках данного доклада.
Test labs 2016. QA в тотальном аутсорсеSasha Soleev
Мы привыкли работать с информацией от заказчиков, от разработчиков, с документацией. Но что делать, когда вы оказались в ситуации информационного вакуума? Как продолжать работать и развиваться, как мотивировать команду и себя, а также какие бонусы можно найти в такой обстановке – всё это мы обсудим в рамках данного доклада.
Автор: Ольга Пронина
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
The document discusses Uber's APIs and how they can be used to build experiences that enhance transportation. It notes that Uber has facilitated over 2 billion trips across more than 470 cities. Developers can integrate their apps with Uber's APIs to authenticate users, request rides, access ride details and context through the trip to improve users' experiences. The document provides examples of how ride context could be used to suggest local guides, play media based on trip duration, and control smart home devices like heating when approaching home.
This document discusses building and shipping software using GitHub. It provides key facts about GitHub such as being founded in 2008, having over 15 million registered users and 36 million repositories. It also shares principles from "The Zen of GitHub" including that responsive is better than fast, practicality beats purity, and favor focus over features. The document advocates for empowering businesses to build great software through culture, tools, process and a DevOps approach.
This document introduces .NET Core and its advantages over the .NET Framework. It discusses how .NET Core is cross-platform, uses the .NET Standard library, and can create self-contained applications. It also highlights how .NET Core applications are smaller, faster, and container-friendly. The document demonstrates how to use the dotnet CLI and publish .NET Core applications to reduce their deployment size. Overall, it promotes adopting .NET Core for its performance, portability, and familiar .NET APIs.
René Gröschke gave a talk on the latest features and future direction of Gradle. Some of the key points included:
- Gradle is moving to a Kotlin-based DSL for improved performance, tooling support, and bringing application patterns to builds.
- Performance improvements include a dedicated performance team that has improved Android Gradle Plugin build times significantly.
- Composite builds allow including external projects to debug dependencies or test plugins against real projects.
- Build cache and distributed build cache are incubating features to cache and share build results for faster rebuilds.
- Gradle build scans provide insights into builds to debug issues, optimize performance, and compare builds
The document discusses containerizing ASP.NET Core applications with Kubernetes. It begins with an overview of .NET Core and containers, and how they have converged. It then discusses Kubernetes and how it can help manage containers at scale. It covers Kubernetes building blocks like deployments, pods, labels, services, and replica sets. It provides examples of deploying containers with Kubernetes, including demonstrations of creating deployments, services, scaling applications, and rolling updates.
29. Как фиксировать реальные
трудозатраты?
- по факту выполненной работы списывать
потраченшнное время
- если работа не закончена, то указывать
оценку оставшегося времени
30. Что это дает?
Возможность понять объем выполненной
работы и ее остаток.
Возможность понять процент выполненной
работы по отношению к общей оценке.
43. Закрепим рассказанное примером!
Дано:
Задача 1, T(план.)= 2ч, Т(вып.)= 4ч
Задача 2, Т(план.)= 3ч, Т(вып.)= 4ч
Задача 3, Т(план.)= 1ч, Т(вып.)= 4ч
Задача 4, Т(план.)= 5ч
Найти Т(план.) по задаче 4 с учетом F.
44. Закрепим рассказанное примером!
Дано:
Петя 80% тестирует web, 20% - desktop
Даша 50% тестирует web, 50% - desktop
Desktop Build требует 28 часов на проверку.
Найти:
Сколько дней будет тестировать билд Даша?
Сколько дней будут тестировать билд вдвоем?