En mis primeros meses como especialista de control de calidad allá por el año 2006, asistí con uno de mis nuevos compañeros a un evento de QA llamado Brighton Test, donde gente de todo Reino Unido se congregó para presentar, discutir o debatir los conceptos de QA y el de testing entre otros. Mi compañero era uno de los ponentes. Me impresionó mucho su manera de exponer la definición que él tenía de QA y testing, básicamente hizo hincapié en el hecho de que el trabajo de un tester consistía en encontrar la manera de demoler el trabajo del desarrollador, como un niño desmonta el barco de Lego que montó su padre horas antes 😅
Es interesante ver cómo jugaba con dos conceptos que son inherentes a la esencia del QA, a saber: desmontar jugando y jugar a desmontar.
Pero QA no solo consiste en testear un producto y encontrar errores, y siempre he tenido la sensación de que la mayoría de las personas con las que he trabajado, no entienden realmente en qué consiste nuestro trabajo. Por eso me propuse a escribir este pequeño artículo que espero aclare y defina qué es lo que realmente hacemos la gente que trabaja en el control de calidad de software ¡Vamos allá!
Errar es humano. Algunas veces cometer un error nos puede llevar a lugares en los que nunca hemos estado o aprender nuevos conceptos, lo que es maravilloso; pero otras veces nos puede hacer perder mucho tiempo y recursos, especialmente si hablamos de desarrollo de software. Para evitar que esto ocurra y que una pieza de software sea segura y funcione como se espera, se crea al concepto de calidad del software, que se puede definir como el grado de conformidad a ciertos requisitos o expectaciones que se han definido de forma previa al desarrollo. Aquí entraría lo que se conoce como los niveles de calidad del software, que se identificarían dependiendo de si los requisitos son implícitos o explícitos:
– Funcional: donde se produce la conformidad del producto con los requisitos funcionales (explícitos) y las especificaciones de diseño. Este aspecto se centra en el uso práctico del software, desde el punto de vista del usuario: sus características, rendimiento, facilidad de uso, ausencia de defectos.
–No funcional: que versa acerca de las características internas y la arquitectura del sistema, es decir, los requisitos estructurales (implícitos). Esto incluye la mantenibilidad del código, la comprensibilidad, la eficiencia y la seguridad.
Mientras que el mantenimiento de la parte no funcional siempre suele caer en manos del equipo de ingenieros, desarrolladores o arquitectos; la parte funcional es mantenida a través de prácticas de calidad que denominaremos QA (Quality Assurance), QC (Quality Control) y Pruebas (Testing).
Quality assurance se puede definir como “la mejora continua y consistente y el mantenimiento del proceso que permite el trabajo de control de calidad”[1]. Se enfoca sobre aspectos organizativos y de monitorización del proceso productivo.
Quality control (control de calidad) se entiende como el “proceso a través del cual una empresa busca garantizar que la calidad del producto se mantenga o mejore y que los errores de fabricación se reduzcan o eliminen”[2]. Es algo similar a escoger un objeto al azar de una cadena de montaje y ver si funciona de acuerdo con las expectativas técnicas que se definieron para su fabricación.
Testing es la actividad básica destinada a detectar y resolver problemas técnicos del software y evaluar la usabilidad, el rendimiento, la seguridad y la compatibilidad generales del producto. Es una actividad que se hace en paralelo al desarrollo, considerándose así, parte del ciclo de vida del desarrollo del producto.
En el siguiente cuadro intento mostrar cómo, cuándo y quién ha de encargarse de cada concepto definido arriba:
| QA | QC | Testing | |
| Propósito | Establece los procesos adecuados, introduciendo los estándares de calidad para prevenir los errores y fallos en el producto | Asegura que el producto corresponda a los requisitos y expectativas definidas con anterioridad a su acabado | Detecta y soluciona errores y fallos |
| Foco | Procesos | Producto como un todo | Código, diseño, usabilidad… |
| Qué | Prevención | Verificación | Detección |
| Quién | El equipo incluyendo los stakeholders | El equipo | Testers y desarrolladores |
| Cuándo | Durante todo el proceso | Antes de la subida a un entorno | Mientras el proceso de desarrollo |
Se formularon hace más de 40 años y son las normas que rigen el proceso de testeo o prueba. Utilizaré como fuente el manual de Fundations of Software Testing: ISTQB Certification
Las pruebas muestran la presencia de errores. Las pruebas tienen como objetivo detectar los defectos dentro de una parte de un software. No importa cómo de minuciosas sean. Nunca podemos estar 100% seguros de que no haya defectos. Solo podemos usar las pruebas para reducir la cantidad de problemas no encontrados.
Las pruebas exhaustivas son imposibles. No hay manera de probar todas las combinaciones de entradas de datos, escenarios y condiciones previas dentro de una aplicación. Por ejemplo, si una sola pantalla de aplicación contiene 10 campos de entrada con 3 posibles opciones de valor cada uno, esto significa que, para cubrir todas las combinaciones posibles, los testers tendrían que crear 59.049 escenarios de prueba. Para no pasar semanas creando millones de estos escenarios menos posibles, es mejor centrarse en los potencialmente más significativos.
Pruebas tempranas. El coste de un error crece exponencialmente a lo largo de las etapas del desarrollo, es importante comenzar a probar el software lo antes posible para que los problemas detectados se resuelvan y no se multipliquen.
Agrupación de defectos. Esto significa que aproximadamente el 80% de todos los errores generalmente se encuentran en sólo el 20% de los módulos del sistema. Por lo tanto, si se encuentra un defecto en una parte específica del software, es probable que haya otros defectos. Por eso tiene sentido probar a fondo esa zona del producto.[3]
Paradoja del pesticida. Ejecutar el mismo conjunto de pruebas una y otra vez no ayudará a encontrar más problemas. Tan pronto como se corrigen los errores detectados, estos escenarios de prueba se vuelven inútiles. Por lo tanto, es importante revisar y actualizar las pruebas regularmente para adaptarse y así, potencialmente encontrar más errores.
Las pruebas dependen del contexto. Dependiendo de su propósito o industria, las diferentes aplicaciones deben probarse de manera diferente.
Falacia de ausencia de errores. La completa ausencia de errores en su producto no significa necesariamente su éxito. No importa cuánto tiempo se haya dedicado a pulir el código o mejorar la funcionalidad, si el producto no es útil o no cumple con las expectativas del usuario, no será adoptado por el público objetivo.
A día de hoy, son 3 los pasos más importantes en el proceso de testeado de software. A saber: planificación, ejecución e informe. Veamos el siguiente cuadro:
3.1 Planificación
Cuando se habla de planificación el objetivo principal es asegurarse de que el equipo comprenda los objetivos del cliente, el propósito principal del producto, los posibles riesgos que deben abordar y los resultados que esperan lograr. La estrategia también ha de ser considerada parte de la planificación “para aclarar las principales tareas y desafíos del proyecto de prueba”[4]. Hay muchísima información para identificar las distintas estrategias que se pueden seguir, en el siguiente link, dejo las más comunes: LINK
El test plan tiene un enfoque más práctico ya que describe con detalle aquello que se va a probar y cómo hacerlo. Es un documento vivo que se va actualizando según se avanza en el ciclo. Me gusta mucho el enfoque que tiene James Whittaker, Technical Evangelist en Microsoft, cuando habla de esto en su The 10 minute test plan[5], dice: “centrarse primero en lo esencial, eliminando toda la pelusa mediante el uso de listas y tablas simples en lugar de párrafos largos de descripciones detalladas […] la idea de reducir y limitar el tiempo de planificación en sí es muy razonable. Como resultado, el 80 por ciento de la planificación se puede terminar en solo 30 minutos”.
3.2 Ejecución
Para saber qué se ha de ejecutar en las pruebas, el equipo de QA debe crear casos de prueba o test cases, que describan los pasos a seguir y las condiciones y resultados esperados que comprobar, para que una prueba sea satisfactoria.
El siguiente paso en la ejecución de la prueba es configurar el entorno de prueba. El criterio principal para esta parte es asegurarse de que el entorno de prueba sea lo más parecido posible al entorno real del usuario final. Esto tiene dos sentidos específicos. Que el entorno no varíe mientras se hacen las pruebas y que el tester haga las veces de usuario y pruebe con esos ojos, de aquí el perspectivismo del que se hablaba en la introducción.
El proceso de prueba de software identifica dos grandes categorías: pruebas estáticas y pruebas dinámicas, pero esto lo trataremos en otro artículo, que hablará además de los métodos del software testing.
3.3 Documentación
Sabemos que no hay un producto perfecto y que el testeo no se completa al 100% ya que es un proceso siempre vivo y en curso. Por este motivo se introdujo el concepto de “exit criteria” o informe de cierre, que define si se realizaron suficientes pruebas, en función de la evaluación de riesgos del proyecto. Existen puntos comunes que se suelen usar para establecer el exit criteria[6] que nombro a continuación:
No hace falta decir que estos principios pueden ser modificados en relación con las necesidades de cliente, tiempo, recursos o producto, pero sí hay que tener en cuenta que siempre se deben establecer algunos.
Ambos, informe de pruebas e informe de estados, se documentan durante todo el proceso de ejecución de la prueba. Cada defecto encontrado en el producto debe informarse y manejarse en consecuencia. El resumen de la prueba y los informes de cierre de la prueba se preparan y se proporcionan a las partes interesadas. El equipo realiza una reunión retrospectiva para definir y documentar los problemas que ocurrieron durante el desarrollo y mejorar el proceso.
Normalmente un producto posee distintas capas de componentes separados e integraciones con otros productos, por eso el foco del testeo debe ir más allá de la simple búsqueda de errores, lo cual es un prejuicio muy común dentro de la concepción generalizada que se tiene sobre el QA. Por este motivo, se crearon los niveles de prueba:
Pruebas de componentes:
Este nivel de prueba tiene como objetivo examinar cada unidad individual de un sistema de software para asegurarse de que cumple con los requisitos originales y funciona como se esperaba. Las pruebas unitarias suelen ser realizadas al principio del proceso de desarrollo por los propios ingenieros, no por el equipo de pruebas.
Pruebas de integración:
Su propósito es detectar errores en las interacciones entre las unidades dentro de un módulo. Existen dos maneras de realizarlas; probando primero las combinaciones más simples y después las más complejas; y marchando desde lo más complejo a la unidad.
Pruebas de sistema:
El producto es testeado como un todo. Esta etapa sirve para verificar el cumplimiento del producto con los requisitos funcionales y técnicos y los estándares generales de calidad.
Pruebas de aceptación:
También conocidas como User Acceptance o aceptación de usuario. El producto se valida contra los requisitos del usuario final. El tester se convierte aquí en un usuario, se transforma. Este paso final ayuda al equipo a decidir si el producto está listo para ser enviado o no, desde un punto de vista general.
En este artículo he querido definir y aclarar los conceptos más básicos que ocupan mi trabajo de día a día, definirlos a muy alto nivel. No entro en tipos de testeo o en debates sobre metodología o métodos a seguir. Hay mucha bibliografía al respecto acerca de los procesos de QA, toda ella llena de distintas opiniones y modos de hacer; para este artículo me he basado en una bibliografía bastante general, que he querido incorporar al texto a través de las notas a pie de página. Recomiendo la lectura de esas notas, para mayor profundización sobre el software testing. Este artículo tiene una 2ª parte, en la que aclaro y profundizo en otra terminología distinta a la que explico aquí👉Atrévete a conocer qué es QA (2ª parte): más conceptos sobre el sotfware testing
[1] Google Testing Blog: The difference between QA, QC and Test Engineering, Allen Hutchison and Jay Han, 2007 (https://testing.googleblog.com/2007/03/difference-between-qa-qc-and-test.html)
[2] Investopedia, Quality Control, Adam Hayes, 2021 (https://www.investopedia.com/terms/q/quality-control.asp)
[4] James Bach, Rapid Software Testing Methodology (https://www.satisfice.com/rapid-testing-methodology)
[5] James Whittaker, The 10 Minute Test Plan, 2011 (https://testing.googleblog.com/2011/09/10-minute-test-plan.html)
[6] RCV Academy, Evaluating Exit Criteria and reporting (https://www.softwaretestingmentor.com/evaluating-exit-criteria-and-reporting-in-testing-process/)
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)
