No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Handle bugs to fit your process

22/25
Recursos

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 鈥渧ida鈥 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 鈥渆xplosion鈥 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:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

I鈥檓 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?

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 鈥渆xplosion鈥 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鈥檚 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 鈥淓xplosion鈥 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 鈥渆xplosion鈥 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.

  1. Take a week to do your spike test
  2. 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鈥檓 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鈥檚 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 鈥渆xplosion鈥 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鈥檚 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 鈥淓xplosion鈥 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)