Novedades del sitio

¿Qué es una buena prueba de software? BRR I TV

 
Picture of System Administrator
¿Qué es una buena prueba de software? BRR I TV
by System Administrator - Thursday, 24 August 2017, 1:53 PM
Group Colaboradores y Partners

¿Qué es una buena prueba de software? BRR I TV

por Matt Heusser | Traducido automáticamente con Google

La semana pasada estuve en CAST, la Conferencia para la Asociación de Pruebas de Software, conocida por desafiantes sesiones de preguntas y respuestas conocidas como "temporada abierta".

Una de las preguntas fue "¿Qué aspecto tiene una buena prueba de software?", que me pareció fascinante.

Tome dos equipos. Uno tiene herramientas fuertes que se ejecuta para cada compromiso, que se desplaza a una cuadrícula de 256 servidores simultáneos, dando retroalimentación en cinco minutos. Otro equipo tiene una arquitectura de componentes; Hacen pequeños cambios y los despliegan de forma independiente. El segundo equipo tiene una gran confianza de que un cambio solo afecta a un componente, los "contratos" automatizados para verificar la corrección, pero no las verificaciones de GUI de extremo a extremo. En cambio, el equipo dos realiza el despliegue, comprueba algunos flujos en la producción en una cuenta de prueba y se basa en un despliegue incremental y una supervisión intensa para detectar problemas.

Ambos podrían ser excelentes pruebas de software en contexto. Para el caso, las buenas pruebas para un marcapasos o controles de aviónica también podría verse muy diferente. Quiero describir un modelo, una especie de lista de verificación, para ver si las pruebas son "buenas" y qué vacíos existen.

Entre la pregunta y las conversaciones relámpago más tarde ese día, me ocurrió con BRR I TV:

 

Así es como se rompen.

Resaca. Si la información de la prueba al desarrollo está volviendo como incapaz de reproducirse, o necesita más información, probablemente no es una buena prueba. Las buenas pruebas tienen un bajo retrolavado.

Pertinente. Si la información de la prueba es relevante, es probablemente una buena prueba. Si existe la preocupación de que la prueba encuentre "errores erróneos", pasar tiempo en "cosas equivocadas" o que los errores vuelvan a aparecer como WONTFIX o NOTABUG, existe un riesgo real de que la prueba sea irrelevante. Del mismo modo si la prueba produce documentos grandes e informes que nadie realmente lee - que no es una buena señal.

Reacción del equipo extendido. La gente observará a los probadores en acción. Si la preocupación es que los probadores están perdiendo tiempo, gastando mucho tiempo documentando cosas que no importan o simplemente "traduciendo" del lenguaje de especificación al lenguaje de los documentos de prueba, entonces hay un problema.

Importancia. ¿Los probadores encuentran defectos que importan? Si los bugs importantes de show-stopper se encuentran constantemente en la producción, entonces el grupo podría no estar haciendo buenas pruebas. Nota: Cuando la relevancia es el tiempo perdido en cuestiones que no son de importancia, la importancia se refiere a cuestiones que faltan.

Es hora de obtener comentarios. ¿Cuál es el período de tiempo desde la compilación disponible para la prueba hasta la información que fluye de vuelta al desarrollo? Si se mide en minutos, el equipo probablemente esté bien. Si los programadores de violín durante días o semanas esperando la retroalimentación, incluso si pueden avanzar en otros proyectos, puede haber un problema.

Es hora de liberar. Suponiendo que no hay tapones de show, ¿cuánto tiempo se tarda desde construir listo para implementar a aprobado para implementar? Más corto es mejor.

Volumen de retroalimentación. Este es el elemento más sensible al contexto. A veces, sólo sabiendo que hay 3 errores encontrados, dos de los cuales son bloqueadores, es todo lo que el propietario del producto quiere o necesita. Generalmente, sin embargo, más información es mejor. Los probadores que hacen que la información sobre la usabilidad, la experiencia del usuario, el rendimiento y las tendencias de rendimiento a lo largo del tiempo sean más valiosas. Por ejemplo, supongamos que el rendimiento sigue estando dentro de los puntos de referencia, pero ha ido disminuyendo. Si la tendencia continúa durante tres sprints más, el rendimiento llegará a un estado "amarillo" o moderadamente insatisfactorio. O tal vez los personajes internacionales están fuera del alcance, pero la aplicación sigue degradándose cada vez más cuando se utilizan. Siempre y cuando el cliente quiere este tipo de información, es probable que sea mucho más potente que una lista de errores rectos. Igualmente,

Poniéndolo todo junto

Brr I TV es una heurística; Es una guía para analizar sus pruebas. Si su equipo puede describir su proceso de prueba golpeando todas esas bases, entonces usted está en una posición mucho mejor que un equipo con "agujeros".

Entonces de nuevo esos agujeros son una oportunidad de mejorar, así que usted puede utilizar BRR I TV como modelo de la evaluación.

Y, por supuesto, existe la realidad de que recientemente acabo de inventar esto. Es probable que falte dimensiones enteras de rendimiento. Es un comienzo, una colección de cosas que tienden a ver en los equipos de alto rendimiento y no pueden ver en los bajos.

 Link: http://itknowledgeexchange.techtarget.com