Calidad del software: Comprender las técnicas, procesos, metodologías y herramientas de prueba

15 de Marzo de 2019

Maicol Peixe

No sería correcto decir que un tema de ese alcance se cubriría en su totalidad en un texto simple, por lo que es importante explicar lo que está por venir. Después de haber dicho, en los dos artículos anteriores,sobre momentos de inversión y madurez, y de las preocupaciones y acciones relacionadas con las pruebas de software que se ajustarían a cada uno de estos momentos, ahora presentaremos, de una manera sencilla y directa, la técnicas, procesos, metodologías y herramientas que se pueden utilizar para garantizar la calidad de un software.

Mi pretexto es transmitiros los pilares de un conocimiento que, créanme, es muy vasto. Y digo más, a menudo contradictorio entre las literaturas, para que uno pueda adquirir un servicio, estructurar un proyecto, entender el contexto y debatir el tema y, sobre todo, poder tomar decisiones con mayor seguridad.

Un punto importante a destacar es que, aunque podemos lograr un nivel aceptable de calidad, incluso sin un proceso de desarrollo maduro, esto no refleja el escenario ideal, especialmente para el reenvío a un tiempo más largo, más costo y, seguro, Estrés mucho mayor. Es importante buscar el equilibrio entre el proceso de desarrollo y el proceso de pruebas de software, para que uno pueda garantizar una solución de alta calidad, con un costo y tiempo adecuados.

Lo que pretendo dar aquí es una visión integral del contexto de prueba, a través del enfoque de diferentes temas. Pero primero me gustaría tocar un punto que es objeto de una gran discusión: la inserción de pruebas en los procesos de gestión de proyectos tradicionales (cascada) y procesos de gestión ágiles.

El tema es objeto de otro artículo con enfoque exclusivo en el tema. Pero para alinearse, por ahora, basta decir que la inserción de un proceso estructurado de pruebas es factible tanto en proyectos que se ejecutan con metodologías ágiles, tal como se desarrollan en metodologías tradicionales, y que, al analizar el conjunto, Las pruebas no se refieren a los gastos, y en el tiempo, sino más bien a la reducción de costos, el riesgo y la ganancia de tiempo.

Así que ahora vamos a entender cómo probar, cuándo probar, qué probar, con qué herramientas y qué prácticas recomendadas puede usar, teniendo en cuenta los siguientes temas:

Hablando de estándares de mercado

Es importante saber qué guías son más utilizadas en el mercado y presentar la ISO 29119 y el Syllabus DE la ISTQB (International Software Testing Qualifications Board). Ambas guías deben utilizarse como documentos junto a la cama para aquellos que quieren trabajar con calidad de software.

Estos documentos se centran más en la estructuración y ejecución de pruebas, a diferencia de los modelos de madurez, que tienen un mayor enfoque en la gestión y el control.

Los modelos más extendidos para las pruebas de software son la MPT.br – mejora del proceso de prueba brasileño, que pude implementar a todos los niveles y tuve el placer de ser el primero en alcanzar el nivel 5 en Brasil en la empresa en la que trabajo, y el TMMI, que, en general, difiere de MPT.Br sólo en el costo de implementación. Otros modelos también cubren el tema de las pruebas de software, pero con menos intensidad y pueden vivir con los citados aquí, por ejemplo: CMMI – Capability Maturity Model Integration    and MPS.br – Process Improvement Software Brasileño.

En general, la principal preocupación con la implementación de estos modelos es la necesidad de estudios, tiempo y dinero que se deben invertir, no sólo en el proceso de estructuración y certificación, sino también en el proceso de mantenimiento para la recertificación. Por supuesto, estos modelos aportan un mayor nivel de control y una visión mucho más madura de lo que tiene antes de pasar por el proceso de certificación.

Hablar sobre el nivel de inversión en las pruebas

En consulta con la literatura que se ocupa de la investigación de materia y mercado, la inversión debe estar entre el 15% y el 40% del valor total invertido en el desarrollo de la solución. Es importante entender que hay varios puntos a considerar, y que el porcentaje, por lo general varía según el nivel de complejidad y con el enfoque del rendimiento del sistema.

Hablar sobre los formularios de evaluación de costos de prueba

Este es un tema complejo, ya que hay varias formas de evaluación, pero para el conocimiento básico de las prácticas más utilizadas, presento las más extendidas:

Hablar de técnicas de prueba

Escuchará acerca de las pruebas de caja NEGRA, las pruebas GRAY BOX y las pruebas DE WHITE BOX, por lo que es importante que conozca los términos. Olvidaré la teoría y presentaré lo más simple posible:

Hablando de fases y técnicas de prueba

Para complicar un poco más, ahora que se conocen los niveles de actuación, desde el exterior (caja negra) en el interior(cajablanca), hablemos de las fases y nomenclaturas utilizadas en el mercado. Por lo general, lo que se encuentra son:

Además de las pruebas presentadas anteriormente, también tenemos pruebas alfa, beta y gamma:

Hablar de pruebas funcionales

Las pruebas funcionales, como su propio nombre indica, son pruebas que validan las funcionalidades de un sistema o aplicación. Las pruebas funcionales pueden ser manuales o incluso automatizadas, pero siempre orientadas a identificar problemas relacionados con la funcionalidad y las reglas de negocio que tiene el sistema.

Hablar de pruebas no funcionales

Las pruebas no funcionales se refieren a aspectos tales como: la apariencia, facilidad de uso, velocidad y robustez del sistema para soportar la cantidad esperada, simultaneidad, velocidad y seguridad. Entre las pruebas no funcionales, podemos citar:

Hablar de procesos de automatización

Especialmente para pruebas funcionales, existe la posibilidad de automatización con la ayuda de herramientas, en las que se pueden crear scripts (códigos) que simulan las operaciones que se realizaron manualmente, con el beneficio de Permita que se ejecute en diferentes plataformas, sistemas operativos, navegadores y tamaños de pantalla. Esto aporta una ganancia muy grande en costos, tiempo, calidad y reducción de riesgos.

Hablar de técnicas de aplicación

Como técnicas de aplicación de prueba, cito la validación de los valores máximos y mínimos para los datos de entrada y salida del sistema, la escritura de los valores presentados en un campo dado, el uso de la partición de equivalencia, con la identificación de agrupaciones de prueba ( por ejemplo, reglas de aceptación de datos entre fechas, etc.).

Hablar de herramientas de gestión y control

Algunas de las herramientas que sugiero, si su pretensión es reunir un equipo, son:

¿Y qué herramientas debo usar? La respuesta es: si tienes dinero para invertir, usa JIRA, porque seguramente tu organización tendrá prácticamente todo lo que necesitas en una sola herramienta; Sin embargo, si la compañía quiere invertir poco, puede salir para un cruce entre Mantis y TestLink, porque ambos son de plataforma abierta, es decir, con coste cero. Hay muchas otras herramientas en el mercado, lo que hice aquí fue citar algunas de las herramientas que entiendo que pueden cubrir la mayoría de los casos.

Hablar de herramientas de automatización

Las opciones anteriores son sólo algunas de las cosas que entiendo son factibles para su uso, y que encajan en cualquier contexto y tamaño de la empresa. También hay muchas otras herramientas en el mercado, como Borland, HP y más. Es importante destacar que tanto Selenium como  Appium son herramientas gratuitas y lo suficientemente potentes como para ser utilizadas en cualquier contexto web o móvil.

Las herramientas para ejecutar pruebas de tensión, carga y  volumen pueden ser JMETER  y  SOAPUI  para pruebas REST y SOAP.

Conclusión y divagaciones sobre el futuro de las pruebas de software

Hasta ahora he presentado los estándares del mercado, los enfoques (cajas blancas, grises y negras), los tiempos de prueba (desde la unidad hasta el postlanzamiento y las nuevas versiones), que son pruebas funcionales y no funcionales, habló de procesos, técnicas y herramientas tanto de Gestión y control, así como automatización, y di una pincelada con respecto a la viabilidad de insertar el proceso de prueba en metodologías de desarrollo ágiles y tradicionales. Por lo tanto, espero que el texto, "una versión simplificada" y "adaptado" de un "conocimiento y conversación", haya sido de valor.   Si el sujeto generó interés, y despertó el deseo de profundizar las lecturas, los interesados verán que hay diferencias entre ISTQB, ISO y otras fuentes, pero lo importante es entender qué se puede, cuándo y cómo se puede hacer. ¡ponerse a trabajar!

Visión general Artículo anterior Siguiente artículo