(del Tester Story Cycle )Hola a todos Como habrás notado, la intensidad del lanzamiento de cursos en OTUS aumenta cada mes, y en marzo hay especialmente muchos de ellos. Hoy queremos coincidir con el lanzamiento del curso
"Automatización de pruebas web" , que comienza a mediados de marzo. Que tengas una buena lectura.
Todavía veo muchos probadores que hablan sobre la cantidad de errores y vulnerabilidades encontradas, como una medida del éxito de las pruebas. Recientemente, vi un punto de vista diferente, que decía que la esencia está realmente en la calidad de los errores, pero no en su cantidad. Sin embargo, con esta medida también vale la pena tener cuidado. Ahora hablaremos de esto.
La idea principal es que el método de prueba está determinado por el tipo de errores que necesita encontrar.
Ya hablé sobre algunos aspectos del tema de hoy anteriormente en la
conversación sobre la búsqueda de errores . No quiero repetirme, así que intentaré ser breve. Formalizaré mi tesis de pensamientos y en relación con el equipo en el que trabajo.
Lo que es importante para mí en las pruebas es el impacto en los usuarios para que tomen las decisiones correctas más rápido. Para hacer esto, debe usar un ciclo de retroalimentación ajustado para acortar el tiempo entre los desarrolladores que cometen un error y posteriormente lo corrigen. Estos errores son áreas donde hay varias cualidades: comportamiento, rendimiento, seguridad, usabilidad, etc. - ausente o empeorado.
Definitivamente, esto no se mide por el número de errores encontrados, pero la naturaleza del error juega un papel importante. Mi tarea es encontrar los errores que más amenazan la integridad y la calidad del desarrollo. Esto probablemente puede atribuirse a la "calidad" de los errores, es decir, estos errores son tanto más importantes cuanto más amenazan la integridad.
La clave para la corrección efectiva de errores, en mi opinión, es encontrar estos errores lo más rápido posible, idealmente tan pronto como aparezcan. Aunque desde mi punto de vista, incluso la "calidad del error" está lejos de ser la medida más alta.
Damos tanta importancia a la calidad del error, pero ¿es realmente que su número es generalmente insignificante?
De hecho, la cantidad de errores es importante si está muy obsesionado con reducir la cantidad de tiempo para buscarlos. Digamos que el sistema tiene 10 errores críticos. ¡Y rápidamente encontré dos de ellos, y es realmente genial! Se encontraron dos errores críticos antes de que se introdujera el producto. Pero no encontré otros antes del despliegue. Esto significa que no se encontraron 8 errores críticos. En este caso, el número de errores es una medida clave, incluso si no lo entendimos en ese momento.
Es importante pensar de una manera ligeramente diferente. El número de errores o su calidad no es tan importante como los mecanismos por los cuales ocurren y, en consecuencia, los mecanismos para su búsqueda. Hay muchas opciones disponibles:
- Mecanismos que son buenos para encontrar errores, pero que funcionan durante demasiado tiempo;
- Mecanismos que encuentran mal los errores, pero funcionan muy rápidamente;
- Mecanismos que están "inclinados" a notar errores de cierto tipo, pero al mismo tiempo no ver a otros;
- Mecanismos que no son muy populares entre los probadores, pero que realmente funcionan y no los usan, porque nadie los conoce en el equipo, por lo que lo que se puede encontrar queda por encontrar;
- Mecanismos que pueden funcionar bien y rápidamente, capaces de encontrar muchos errores, pero la respuesta de ellos es tan confusa que las personas no pueden tomar decisiones basadas en su producción.
Centrarse en estos aspectos, no menos que en otros conocidos, es importante porque ayuda a sortear algunos problemas que surgen tradicionalmente. Por ejemplo, aquellos cuando ejecutó cien pruebas, pero no encontró un solo error. Y esto puede ser bueno, pero solo si realmente no hay errores. Pero si existen, entonces esto es malo si los métodos de prueba aplicados no pueden identificarlos. O la situación cuando ejecuto un montón de pruebas, encuentro errores menores, mientras omito los más difíciles.
Mi equipo y yo debemos tomar ciertas decisiones basadas en las pruebas realizadas. Esto significa que debemos creer cuáles son los resultados de las pruebas de las que se nos informa, por lo tanto, inicialmente debemos confiar en los métodos de detección que se implementan en estas pruebas.
Algunos métodos de detección provienen de las pruebas mismas, en términos generales, de lo que están buscando y cómo se ven. Otros métodos de detección deben ser inherentes al entorno mismo y a la capacidad de prueba, que definimos para determinar cuán probable y posible, en principio, que las pruebas causen un error, si existe.
Al final de mis breves pensamientos, quiero resaltar el hecho de que no determino el éxito de las pruebas por ningún factor específico. Pero si aún desea determinar esto de alguna manera, debe determinar no por la cantidad de errores y vulnerabilidades encontradas y no por la calidad de estos errores, sino por su capacidad específica de los mecanismos de prueba para detectarlos.
Descubrí que los evaluadores sin experiencia, después de leer esta nota, no verán una diferencia significativa entre la idea de detectar habilidades y los resultados obtenidos después de resaltar estas características. En cuanto a los especialistas, deberían diferenciarlos extremadamente.
Al poder comprender y formular esta diferencia, los evaluadores pueden ir más allá de las diferencias inútiles (solo la opinión del autor) entre "verificación" y "prueba" y, en cambio, construir una comprensión constructiva de los métodos de detección, tanto humanos como automatizados, que permiten pruebas para ayudar a las personas a tomar mejores decisiones más rápido.
Aquí hay un material aparentemente simple pero bastante útil. De acuerdo con la tradición establecida, esperamos sus comentarios y lo invitamos a
un seminario web abierto , que tendrá lugar el 11 de marzo
Mikhail Samoilov , la herramienta de automatización de pruebas líder en el Grupo-IB.