Esto, no ha sido siempre lo más acertado y existen bastantes detractores sobre estos estándares y del porque no debe de existir algo así. Una de las líneas más defendidas es que depende del perfil que realice las pruebas o las pautas, estas se realizarán de una manera o de otra y tendrás más o menos profundidad.
Aún teniendo diferentes prácticas o formas de realizar las pruebas, estas evolucionan y hay conceptos que hay que remarcar, mejorar o profundizar y que la costumbre que tenemos en la realización de alguna pauta ya no aplica como lo hacía hace varios años. Para ello, es importante hacer una revisión progresiva de la estrategia de pruebas que se están realizando y comprobar que aplican adecuadamente, son válidas o hay que darles una vuelta para poder adaptarlas a los nuevos tiempos.
Dentro de estas pautas o prácticas que ya no deberíamos de volver a hacer o al menos, intentar no aplicarlas más, son estas:
1. Conteo de errores y el desempeño de la persona.
Hace unos años, los tester se dedicaban, única y exclusivamente en abrir defectos, gestionar su ciclo de vida y comprobar que las pantallas eran adecuadas y correctas en base a que no se encontraran estos problemas.
Actualmente, el perfil ha ido evolucionando hacía otros terrenos que son más de acompañante de un proceso de calidad adecuado que a verificar estas pantallas, por lo tanto, no debemos seguir juzgando la calidad del perfil o la experiencia del mismo por la cantidad de defectos que abre o encuentra en una entrega concreta.
Esto también ha cambiado con la introducción de estrategias de automatización, ya sean funcionales o en entornos de desarrollo y la detección temprana de defectos que se capturan de manera automática, evita que lleguen entregas a la persona de una manera catastrófica.
Actualmente, los tester tienen un abanico de habilidades mayor, pudiendo abarcar desde el arranque inicial del proyecto, verificando que los requisitos se están realizando adecuadamente o como cerciorarse de que la puesta en producción se hace adecuadamente y se pasan todos los baremos o métricas de calidad dentro de una herramienta de gestión de la calidad del código, son tantas las posibilidades, que seguir viendo el rendimiento de estos perfiles con tan solo la apertura de defectos es un gran error.
2. Verificación de los porcentajes de aprobación y error del plan de pruebas.
Si te dedicas a probar, tienes que saber que la mayoría de los errores se encuentran fuera de los caminos felices habituales. El caso, es que los equipos de pruebas, se dedican en gran medida a realizar grandes cantidades de casos de prueba antes de tan siquiera acceder a una versión determinada y que, tras ello, habrá bastantes condiciones no documentadas que tendrán defectos y que, aunque, la tasa de “verdes” o de OKs sea muy alta, en un porcentaje muy pequeño de funcionalidad pueden existir cientos de defectos que han de ser solucionados.
Ahora mismo, no es una de las mejores tácticas el tener un caso de prueba por cada defecto encontrado, si no que debemos de ser capaces de elevar la tasa de confianza de los equipos de trabajo. Si realizamos unos paneles de control donde marquemos la cobertura, confianza, análisis y estado actual y lo comenzamos a compartir, cada persona se hará responsable de su trabajo y elevará la tasa de código correcto y adecuado.
La confianza de las personas está por encima de cualquier tipo de cobertura o de prueba que queramos realizar, siempre y cuando, la funcionalidad crítica esté cubierta del todo y si que pueda ser puesta en producción con total garantía.
3. Verificación final del equipo de pruebas
Como se suele decir, aunque no aplicar, en la mayoría de los casos, la calidad es responsabilidad de todos y los tester dan fe de los resultados que les llegan, pero no son los responsables directos de la calidad global de un producto, si no que ayudan a que la calidad se eleve.
En un porcentaje extremadamente grande, el equipo de proyecto espera a que las personas de QA den su visto bueno, pero esto solo debe de ser una parte del mismo y no el OK definitivo. La calidad se puede asegurar de manera global y enfocándose desde todo el equipo, por ejemplo:
• Se define una línea base de calidad con controles medibles que verifican que todo se esté cumpliendo.
• Cada equipo es responsable de la calidad de su entrega y toma las medidas necesarias para cumplirla y entregar con total garantía. Además de verificar ciertos estándares de calidad predefinidos en el proyecto.
• Romper las barreras entre roles de cada a trabajar colaborativamente y ayudándose mutuamente.
• Se implementa una cultura de calidad para cada equipo y se transfiere entre personas que deben de aplicarla y cumplirla.
Un proceso de pruebas y de calidad es siempre la mejor garantía para que algo salga como debe de salir, siempre y cuando todas las personas del proyecto trabajen unificadamente y mano a mano, si no, posiblemente, el resultado no será el que esperamos, en tu caso,
¿Qué experiencias has tenido? Puedes dejarnos tu comentario en la comunidad o aquí, en el propio artículo.
0 Comentarios