I’m not pretty sure about the estimation formula due to it depends on the bug, because there must be other variables, such as priority, or impact.
There are other methods to calculate that estimation?
Introduction
Welcome to this Course for Developers in English
Communicate with your customer accurately
Customer-oriented requirements
How iteration cycles work
Planning considering priorities
Review: communicate with your customer accurately
Understand your customer and the requirements
Prioritizing requirements
Backlog and Milestone 1.0
Organize your tasks!
Organizing your time into user stories and tasks
Stand-up meetings, analyze and design
Review: organize your tasks!
Create deliverable design
Creating deliverable design
Refactoring, meetings and release
Protect your very valuable software
Understanding the principles of defensive development
Functional and unit testing
Review: protect your very valuable software
Understanding Continuous Integration (CI) and testing
Types of software testing
Handle accidents when building the code and what CI means
Test your Software!
TDD Test-Driven Development
Review: test your software!
Be ready for the end
Prepare for the next iteration
End an iteration
Fix your bugs!
Handle bugs to fit your process
Continuous integration test delivery method
Review: fix your bugs!
Conclusion
We've come to an end!
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Iniciar sesión
Handle bugs to fit your process
22/25Recursos
Un bug es un error en el diseño o desarrollo de un software o plataforma que hace que se produzca un resultado inesperado en la experiencia de usuario. El código que creaste en front end o back end se comporta de manera no deseada.
¡¡Encontramos BUGS!! Eventualmente, los bugs aparecerán. Son inevitables en el desarrollo de software y hay que arreglarlos. Hablemos sobre ello para que entiendas cómo modificarlos.
El ciclo de vida de un bug
Un bug pasará por varias etapas en su “vida” hasta estar solucionado. Es una forma de llevar un control del mismo.
- The actual life cycle of a bug is as follows:
- A tester finds the bug.
- The tester files a bug report.
- You create a story to fix the bug.
- Fix the bug.
- Check the fix and verify that it works.
- Update the bug report.
Entrega continua, corregir errores funcionales
A excepción de que el equipo de desarrollo sea grande y puedan darse el lujo de arreglar todos los bugs, solo soluciona los funcionales y los que se encuentran en producción.
- It is necessary to create user stories to fix bugs.
- Fixing bugs takes time, and all that time needs to be taken into consideration when estimating the length of your iterations.
- Fix functional bugs first! Only fix code to fix your user stories.
- Everything revolves around customer-oriented functionality.
- Only fix what is broken, and you know what is broken because you have tests that fail.
- Writing beautiful, perfect code is great, but writing good-enough code is better.
Spike Test
La intensidad con la que hagas tus pruebas será importante. Tomarse un período en donde todo el equipo haga pruebas para determinar la calidad actual del producto.
- A Spike Test is a period in which there is an “explosion” of the testing activities.
- Test continuously, and take random bits of code and functionalities to ensure functionality before delivery.
- Weed out bugs, later you can use the result to estimate adjustments.
- Take a week to do your spike test.
- Pick a random sample from the tests that are failing and try to fix just those tests.
- Act based on the results of the Spike testing effort. At the end of the week, calculate your Bug Fix Rate.
Determinar una métrica, el costo en tiempo y esfuerzo de solucionar los bugs te permitirá realizar mejores estimaciones para la próxima iteración. Trabaja con tu equipo en la estimación de los bugs para luego estimar las tareas más importantes.
Contribución creada por: Kevin Fiorentino.
Aportes 22
Preguntas 4
Ordenar por:
Continuous delivery - fix functional bugs
- Create stories to fix bugs
- Take into consideration when estimating time
- First fix functional bugs
- Everything revolver about customer-oriented functionality
Estimate bug-fixing effort
Spike test
- Period in which there is an “explosion” in the testing activities
- Random and continuous
- Weed out bugs
- Take a week to do it
- Pick a random sample of test that are failing and try to fix them
- Estimate bug fix rate
Spike testing = is test type oriented to the app receives a sudden and extreme increase a decrease in load, this for determinate the behavior of the app when it receives extreme variations in traffic.
Continuous delivery - fix functional bugs:
- It’s necessary to create user stories to fix bugs.
- Fixing bugs takes a lot of time.
- First, you need to fix the bugs that affect your functionality, ASAP.
- Only fix what is broken, and you know what is broken because you have tests that fail.
Spike test: - Is a period in which there is an “Explosion” in the testing activities.
- Test continuously, and take random bits of code and functionalities to ensure functionality before delivery.
- Take a week to do your spike test.
- Pick a random sample from the tests that are failing and try to fix just those tests.
-Spike test
Spike testing is a period in which
there is an “explosion” in the
testing activities.
Test continuously, take random
bits of code and functionalities
to ensure functionality before
delivery.
-Spike test
Weed out bugs, later you can use the results to estimate
adjustments.
- Take a week to do your spike test
- Pick a random sample from the tests that are failing and try
to fix just those tests.
Act based on the results of the Spike testing effort. At the end of
the week calculate your bug fix rate.
Fix functionality only
Thanks
Thanks
Awesome theacher
Also
Firts
More
Awesome
Hello
thanks
About BONUS: if I have calculated my BFR (ex: 4 bugs in 5 work days, then my BFR = 4 bugs/5 days = 0.8 bugs/day). Now, on my next Iteration, I found 9 bugs, therefore to calculate the number of days to fix them would be —> Days = 9 bugs / 0.8 bugs/day. = 12 days. But in the BONUS was calculated 7 days. I think that the correct operation is division instead of multiplication. Am I right?
more
grrat
I’m not sure about the formula to calculate the days that will take me to fix 9 bugs. I think the result should be 11.25 days instead of 7.2 days. Because, the real formula should be:
9/0.8 = 11.25 days
It’s just a simple rule of three. Or You can see it like this:
If the last week I fixed 4 bugs in 5 days, then, how many days will it take me to fix 9 bugs?
4 bugs ------> 5 days
9 bugs ------> x
X = (9 bugs* 5 days)/(4 bugs) = 11.25 days
Handle bugs to fit your process Continuous delivery - fix functional bugs
- Create stories to fix bugs
- Take into consideration when estimating time
- First fix functional bugs
- Everything revolver about customer-oriented functionality
Estimate bug-fixing effort
Spike test
- Period in which there is an “explosion” in the testing activities
- Random and continuous
- Weed out bugs
- Take a week to do it
- Pick a random sample of test that are failing and try to fix them
- Estimate bug fix rate Continuous delivery - fix functional bugs:
It’s necessary to create user stories to fix bugs.
Fixing bugs takes a lot of time.
First, you need to fix the bugs that affect your functionality, ASAP.
Only fix what is broken, and you know what is broken because you have tests that fail.
Spike test:
Is a period in which there is an “Explosion” in the testing activities.
Test continuously, and take random bits of code and functionalities to ensure functionality before delivery.
Take a week to do your spike test.
Pick a random sample from the tests that are failing and try to fix just those tests.
good
Bug Fix
Rate (BFR)
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.