Calidad del SW y Procesos de desarrollo

Posts 1-10 of 11

Back
Next

Hector Hidalgo Ferroni
The company name is only visible to registered members.

Estimación tiempo de pruebas
Estimados, necesito información acerca del como "estimar" tiempos de prueba, hasta el momento solo nos basamos en la experiencia, pero nuestro proceso de revisión se encuentra en constante mejoramiento añadiendo nuevos tipos de pruebas, lo que nos complica es que debemos entregar estimaciones a nuestros clientes a veces solo con ver la especificación del requerimiento, trabajamos en mantencion correctiva evolutiva de software hecho por terceros y necesitamos justificar los tiempos de pruebas que han ido incrementandose conforme añadimos nuevos procedimientos a nuestro proceso, favor su ayuda, según nuestra experiencia la estimación entregada es valida, pero necesitamos algún metodo cientifico para hacerla...

De antemano muchas gracias por su cooperación.

Hector Hidalgo.
This post was changed on 21 Nov 2008 at 05:39 pm by Juan Carlos Sanchez Mirabal .
- 03 Jan 2008, 11:10 pm
Hector Hidalgo Ferroni wrote: > Estimados, necesito información acerca del como "estimar" tiempos de > prueba, hasta el momento solo nos basamos en la experiencia, pero > nuestro proceso de revisión se encuentra en constante mejoramiento > añadiendo nuevos tipos de pruebas, lo que nos complica es que debemos > entregar estimaciones a nuestros clientes a veces solo con ver la > especificación del requerimiento, trabajamos en mantencion correctiva > evolutiva de software hecho por terceros y necesitamos justificar los > tiempos de pruebas que han ido incrementandose conforme añadimos > nuevos procedimientos a nuestro proceso, favor su ayuda, según > nuestra experiencia la estimación entregada es valida, pero > necesitamos algún metodo cientifico para hacerla... > > > De antemano muchas gracias por su cooperación. > > > Hector Hidalgo.
Cristian Mardones
The company name is only visible to registered members.

Re: Estimación tiempo de pruebas
Hector,

Notros aplicamos el siguiente criterio: el esfuerzo en la fase de pruebas funcionales(no implica ni elabaoración del plande pruebas ni otro tipo de pruebas), es de un 30% respecto al esfuerzo de la fase de desarrollo (programacioón). Es necesario que tengas datos historicos (en distintos proyectos)para determinar tu % de esfuerzo

Saludos, Cristian M
- 04 Jan 2008, 6:27 pm
Cristian Mardones wrote: > Hector, > > > Notros aplicamos el siguiente criterio: el esfuerzo en la fase de > pruebas funcionales(no implica ni elabaoración del plande pruebas ni > otro tipo de pruebas), es de un 30% respecto al esfuerzo de la fase > de desarrollo (programacioón). Es necesario que tengas datos > historicos (en distintos proyectos)para determinar tu % de esfuerzo > > > Saludos, Cristian M
Post visible to registered members
Javier Alejandro Santillán
The company name is only visible to registered members.

Re: Re: Estimación tiempo de pruebas
Te la tenías guardada Juan Carlos, tanta información quizás me hubiera sido útil antes.
Ahora me hice mi propia estimación y coincido bastante con el ingeniero Cristian Cardone, aunque hay que tener bastante cuidado con ese tipo de estimación dura.
Utilizo sin dudas la extracción de los puntos de función para realizar mejores estimaciones y como antes dije en otros post, para desmenuzar mejor los requerimientos. Por lo tanto todo lo que explicas sirve y mucho, solo que hay que intentar hacerlo simple.
Mi estimación sigue siendo dura del 27% para los TC Funcionales, pero tengo un margen de % de variación, en base a los tiempos reales del desarrollo, ya que son los que inicialmente patean la pelota del tiempo para adelante. Esto me sirve para dar una primera estimación al 40% en base al esfuerzo estimado de desarrollo y al 27% según una fórmula simple que me diseñé, del esfuerzo real, lo cual agregaría desvío significativo a la estimación del testing funcional si se deja la fórmula al 40%.
Aún digo que los criterios de Juan Carlos son correctos y considero que el testing es una de las cosas más dificiles de estimar.

Saludos,

Javier
- 07 Jan 2008, 11:39 pm
Javier Alejandro Santillán wrote: > Te la tenías guardada Juan Carlos, tanta información quizás me > hubiera sido útil antes. > Ahora me hice mi propia estimación y coincido bastante con el > ingeniero Cristian Cardone, aunque hay que tener bastante cuidado con > ese tipo de estimación dura. > Utilizo sin dudas la extracción de los puntos de función para > realizar mejores estimaciones y como antes dije en otros post, para > desmenuzar mejor los requerimientos. Por lo tanto todo lo que > explicas sirve y mucho, solo que hay que intentar hacerlo simple. > Mi estimación sigue siendo dura del 27% para los TC Funcionales, pero > tengo un margen de % de variación, en base a los tiempos reales del > desarrollo, ya que son los que inicialmente patean la pelota del > tiempo para adelante. Esto me sirve para dar una primera estimación > al 40% en base al esfuerzo estimado de desarrollo y al 27% según una > fórmula simple que me diseñé, del esfuerzo real, lo cual agregaría > desvío significativo a la estimación del testing funcional si se deja > la fórmula al 40%. > Aún digo que los criterios de Juan Carlos son correctos y considero > que el testing es una de las cosas más dificiles de estimar. > > > Saludos, > > > Javier
Cristian Mardones
The company name is only visible to registered members.

Re: Re: Estimación tiempo de pruebas
Estimados,

Adiconalmente al 30% respecto al esfuezo de la fase de desaarrollo aplicampos un factor de confiabilidad que va de 0 a 0.15, que se aplicamos de acuerdo a a algunos de los factores indicados por Juan Carlos (este factor queda a criterio de la persona que esta realizando la estimación) pero debe ser justificado al momento de aprobar la estimación.

Creo importante que en el tema de estimación de actividades de pruebas, se estime tambien un tiempo asociado al restesting (por lo general se ecnuentran errores y estos deben ser probados nuevamente). Para esta actividad tambien realizamos estimación pero con distintos pesos y factores.

Saludos Cristian M.
- 08 Jan 2008, 4:36 pm
Cristian Mardones wrote: > Estimados, > > > Adiconalmente al 30% respecto al esfuezo de la fase de desaarrollo > aplicampos un factor de confiabilidad que va de 0 a 0.15, que se > aplicamos de acuerdo a a algunos de los factores indicados por Juan > Carlos (este factor queda a criterio de la persona que esta > realizando la estimación) pero debe ser justificado al momento de > aprobar la estimación. > > > > > > Creo importante que en el tema de estimación de actividades de > pruebas, se estime tambien un tiempo asociado al restesting (por lo > general se ecnuentran errores y estos deben ser probados nuevamente). > Para esta actividad tambien realizamos estimación pero con distintos > pesos y factores. > > > > > > Saludos Cristian M.
Post visible to registered members
Marcelo Bombara
The company name is only visible to registered members.

Re: Estimación tiempo de pruebas
Hector, tu duda es válida; pero creo que si tú método esta basado en la experiencia, un poco de la regla de los cinco dedos, sin una metodología ni proceso establecido de testeo y medición .... va a ser muy dificil que puedas respaldar los tiempos. Siempre van a tener que creer en tú intuición que puede tener un alto grado de certeza o no; y eso no va a estar respaldado por ningún método científico.

Pienso que la estimación respaldada es lograda cuando el grado de madurez del proceso te lo permite, y así y todo va a seguir dependiendo de otros factores que van a influir en el valor final de la estimación.

Mi recomendación es que empieces por introducir metodologías y normas de calidad en el proceso de desarrollo, ya que por tus comentarios el proceso completo carece de formalidad metodológica ( la propia de tú empresa y no específicamente ninguna en especial).

Un abrazo,

Marcelo
- 25 Feb 2008, 1:57 pm
Marcelo Bombara wrote: > Hector, tu duda es válida; pero creo que si tú método esta basado en > la experiencia, un poco de la regla de los cinco dedos, sin una > metodología ni proceso establecido de testeo y medición .... va a ser > muy dificil que puedas respaldar los tiempos. Siempre van a tener que > creer en tú intuición que puede tener un alto grado de certeza o no; > y eso no va a estar respaldado por ningún método científico. > > > Pienso que la estimación respaldada es lograda cuando el grado de > madurez del proceso te lo permite, y así y todo va a seguir > dependiendo de otros factores que van a influir en el valor final de > la estimación. > > > Mi recomendación es que empieces por introducir metodologías y normas > de calidad en el proceso de desarrollo, ya que por tus comentarios el > proceso completo carece de formalidad metodológica ( la propia de tú > empresa y no específicamente ninguna en especial). > > > Un abrazo, > > > Marcelo
Andres Felipe Suarez Piedrahita
The company name is only visible to registered members.

Re: Estimación tiempo de pruebas
Hola hector

Tienes dos frentes por donde atacar la estimación de tiempos de pruebas:

1, debes basarte en los promedios de tiempos ya ejecutados, segun tu experiencia.

2, al momento de estimar los tiempos debes tener en cuenta varios elementos y son:

a, la complejidad del aplicativo, es decir que debes medir que tan complejo es el aplicativo "en mi caso para las pruebas de rendimiento evaluo la complejidad en la cantidad de procesos y elementos que intervienen en ese proceso" si yo se cuanto me demoro para un solo proceso, entonces ese tiempo de estimación de debe aumentar según la complejida y numero de modulos o procesos
- 25 Feb 2008, 9:53 pm
Andres Felipe Suarez Piedrahita wrote: > Hola hector > > > Tienes dos frentes por donde atacar la estimación de tiempos de > pruebas: > > > 1, debes basarte en los promedios de tiempos ya ejecutados, segun tu > experiencia. > > > 2, al momento de estimar los tiempos debes tener en cuenta varios > elementos y son: > > > a, la complejidad del aplicativo, es decir que debes medir que tan > complejo es el aplicativo "en mi caso para las pruebas de rendimiento > evaluo la complejidad en la cantidad de procesos y elementos que > intervienen en ese proceso" si yo se cuanto me demoro para un solo > proceso, entonces ese tiempo de estimación de debe aumentar según la > complejida y numero de modulos o procesos
Rosa María Vázquez
The company name is only visible to registered members.

Re: Estimación tiempo de pruebas
Hola que tal mira en este momento me encuentro desarrollando mi proyecto de tesis y es precisamente sobre la estimacion de los procesos de testing y te puedo mencionar de lo que he investigado que existen muchas metodologias, pero todas se centran en la cantidad de casos de uso, la calificación que se les da a los CU como complejidad alta media y baja y el tiempo en que cada una de ellas fue atendida por el equipo de construccion, el 30% muy seguramente sera el tiempo de pruebas, debes de tomar en cuenta tambien las pruebas de regresión, y el análisis y diseño de los escenarios de prueba.

Espero que no te hayas quedado con mas dudas.
Saludos
Rosy :0)
- 08 Mar 2008, 01:19 am
Rosa María Vázquez wrote: > Hola que tal mira en este momento me encuentro desarrollando mi > proyecto de tesis y es precisamente sobre la estimacion de los > procesos de testing y te puedo mencionar de lo que he investigado que > existen muchas metodologias, pero todas se centran en la cantidad de > casos de uso, la calificación que se les da a los CU como complejidad > alta media y baja y el tiempo en que cada una de ellas fue atendida > por el equipo de construccion, el 30% muy seguramente sera el tiempo > de pruebas, debes de tomar en cuenta tambien las pruebas de > regresión, y el análisis y diseño de los escenarios de prueba. > > Espero que no te hayas quedado con mas dudas. > Saludos > Rosy :0)
Nicolás Facundo Orlando
The company name is only visible to registered members.

Re: Estimación tiempo de pruebas
Héctor, Me sumo algo tarde pero puede que esto te sea útil todavía.

Por un lado veo que tu problemática tiene dos partes, aunque interrelacionadas. Una es la estimación en sí misma. Otra es la potencial justificación ante tus clientes.

En cuanto a la estimación en sí misma de los tiempos de prueba, es evidente que los mismos van a tener una variación dependiendo del tipo de pruebas que hagas y de la tecnología involucrada.

Si supongo bien, como te refieres a software hecho por terceros, debes estar haciendo pruebas de caja negra, por lo que voy a referirme a ellas. Si este no fuera el caso, haz las adaptaciones correspondientes a mi texto o repregúntame lo que necesites.

Dependiendo del número de requisistos funcionales y no funcionales y normas de seguridad que un determinado software tenga, y dependiendo de los objetivos del testing, puedes estimar si robotizar o no la prueba.

El hecho que mencionas de agregar nuevos procedimientos a tu proceso de pruebas tiene varias lecturas.

Una es un proceso de investigación y desarrollo para lograr una mejora contínua, que por ser tuyo, no debiera influir en los clientes, hasta que un proceso depurado les de un valor agregado extra. En ese caso deberías absorver el incremento de tiempos con horas extra a tu cargo.

Otra lectura es que tu empresa no tiene la suficiente experiencia y busca no cómo mejorar lo que ya hace bien, sino aprender cómo deben ser hechas las cosas. Una mala lectura si la hace un cliente.

Como puedes ver ninguna de estas realidades debería llegarle al cliente.

Otra dificultad es el objetivo de la prueba. Puede ser una prueba básica que tome los requisitos funcionales y verifique que éstos se cumplen. Pero puede también ser una prueba de stress o de usabilidad que conlleve formas de prueba absolutamente diferentes.

Al ser una prueba de caja negra, deberás tener en cuenta la tecnología en la que fue desarrollado, para incluir en caso necesario pruebas de secuencia sobre las de función. Sin estas pruebas podrás dar "falsos positivos" que afectan no sólo tu credibilidad sino tu continuidad en el negocio.

Una solución frente a todo lo anterior es hacer una estimación por cada tipo de prueba que se necesite hacer, convirtiendo la prueba original en una batería de pruebas diferentes. Deberás hacer el ejercicio de cuáles son los insumos de cada prueba y cuál es la relación de tiempo promedio, y máximo para elaborar una función que determine a partir de las variables de insumo el lapso de tiempo estimativo. La sumatoria de todos los que son ahora procesos de la prueba única y que pasan a ser pruebas complementarias independientes, dará el tiempo total.

En cuanto a la justificación al cliente este método de partir la prueba en varias pruebas complementarias te dará la posibilidad de que el cliente interactúe en el proceso de selección de qué pruebas necesita y puedes utilizar esto como factor comercial distitntivo, asimismo puede que con personal idóneo en este punto obtengas claves del negocio que hay que probar.

Esta forma acotaría los tiempos de los procesos ya probados como pruebas fijas y nuevos procesos serán nuevos servicios que comercializas. Nadie se va a quejar si piden más servicios y eso le suma más tiempo.

Otra ventaja es que puedes estimar pruebas en paralelo llegado el caso y que puedes avanzar en tu empresa con costos más previsibles, que te permitan un mejor manejo del ROI y una base para una mejor negociación comercial.

Por supuesto, como toda obra humana es perfectible, deberás hacer uso de tecnologías -que cambian y evolucionan- y revisiones o reingenierías de tus procesos.

Espero haberte sido útil.

Saludos,

Nicolás.
- 09 Mar 2008, 11:43 pm
Nicolás Facundo Orlando wrote: > Héctor, Me sumo algo tarde pero puede que esto te sea útil todavía. > > > > > > Por un lado veo que tu problemática tiene dos partes, aunque > interrelacionadas. Una es la estimación en sí misma. Otra es la > potencial justificación ante tus clientes. > > > > > > En cuanto a la estimación en sí misma de los tiempos de prueba, es > evidente que los mismos van a tener una variación dependiendo del > tipo de pruebas que hagas y de la tecnología involucrada. > > > > > > Si supongo bien, como te refieres a software hecho por terceros, > debes estar haciendo pruebas de caja negra, por lo que voy a > referirme a ellas. Si este no fuera el caso, haz las adaptaciones > correspondientes a mi texto o repregúntame lo que necesites. > > > > > > Dependiendo del número de requisistos funcionales y no funcionales y > normas de seguridad que un determinado software tenga, y dependiendo > de los objetivos del testing, puedes estimar si robotizar o no la > prueba. > > > > > > El hecho que mencionas de agregar nuevos procedimientos a tu proceso > de pruebas tiene varias lecturas. > > > > > > Una es un proceso de investigación y desarrollo para lograr una > mejora contínua, que por ser tuyo, no debiera influir en los > clientes, hasta que un proceso depurado les de un valor agregado > extra. En ese caso deberías absorver el incremento de tiempos con > horas extra a tu cargo. > > > > > > Otra lectura es que tu empresa no tiene la suficiente experiencia y > busca no cómo mejorar lo que ya hace bien, sino aprender cómo deben > ser hechas las cosas. Una mala lectura si la hace un cliente. > > > > > > Como puedes ver ninguna de estas realidades debería llegarle al > cliente. > > > > > > Otra dificultad es el objetivo de la prueba. Puede ser una prueba > básica que tome los requisitos funcionales y verifique que éstos se > cumplen. Pero puede también ser una prueba de stress o de usabilidad > que conlleve formas de prueba absolutamente diferentes. > > > > > > Al ser una prueba de caja negra, deberás tener en cuenta la > tecnología en la que fue desarrollado, para incluir en caso necesario > pruebas de secuencia sobre las de función. Sin estas pruebas podrás > dar "falsos positivos" que afectan no sólo tu credibilidad sino tu > continuidad en el negocio. > > > > > > Una solución frente a todo lo anterior es hacer una estimación por > cada tipo de prueba que se necesite hacer, convirtiendo la prueba > original en una batería de pruebas diferentes. Deberás hacer el > ejercicio de cuáles son los insumos de cada prueba y cuál es la > relación de tiempo promedio, y máximo para elaborar una función que > determine a partir de las variables de insumo el lapso de tiempo > estimativo. La sumatoria de todos los que son ahora procesos de la > prueba única y que pasan a ser pruebas complementarias > independientes, dará el tiempo total. > > > > > > En cuanto a la justificación al cliente este método de partir la > prueba en varias pruebas complementarias te dará la posibilidad de > que el cliente interactúe en el proceso de selección de qué pruebas > necesita y puedes utilizar esto como factor comercial distitntivo, > asimismo puede que con personal idóneo en este punto obtengas claves > del negocio que hay que probar. > > > > > > Esta forma acotaría los tiempos de los procesos ya probados como > pruebas fijas y nuevos procesos serán nuevos servicios que > comercializas. Nadie se va a quejar si piden más servicios y eso le > suma más tiempo. > > > > > > Otra ventaja es que puedes estimar pruebas en paralelo llegado el > caso y que puedes avanzar en tu empresa con costos más previsibles, > que te permitan un mejor manejo del ROI y una base para una mejor > negociación comercial. > > > > > > Por supuesto, como toda obra humana es perfectible, deberás hacer uso > de tecnologías -que cambian y evolucionan- y revisiones o > reingenierías de tus procesos. > > > > > > Espero haberte sido útil. > > > > > > Saludos, > > > Nicolás.

Back
Next