CONTEXTO Y ORÍGENES
DEL ASEGURAMIENTO DE CALIDAD (QA)
DE SOFTWARE

Cambiar mitos y reaprender el concepto de QA

En muchos cursos de QA de Software se suele hablar primero de la definición del concepto de aseguramiento de calidad, más allá de la fuente de referencia, desde este primer concepto, quienes empiezan a "aprender" fomentan la creencia de que la gestión de calidad es inherente a la tecnología y privativo de esta, por lo que se percibe como "algo nuevo, propio de la tecnología". Esta creencia de que el QA es algo "nuevo", conlleva a que el camino de aprendizaje sea difícil y no cotidiano.
Lo cierto es que si se conociera el origen de la gestión de calidad, se podría entender que QA no es algo nuevo, por lo que practicarlo y mejorarlo sería natural, solo bastaría con aprender técnicas específicas de control de calidad, relativas al producto de Software, de hecho sería más fácil entender porque QA incluye el Shift Left Testing y el Shift Right Testing, ya que QA no son solo pruebas y resultados , es un concepto más amplio, es una gestión que siempre ha estado y que siempre se ha debido aplicar independientemente de si hablamos de tecnología o no.
Si se conocieran los verdaderos orígenes del aseguramiento de la calidad sería más fácil naturalizar ciertos conceptos que se van aprendiendo, a medida se avanza, en la carrera profesional como QA de Software.
Se trata de una forma de gestión para la eficiencia, que es inherente a las prácticas laborales y la gestión empresarial de forma general.

Para empezar a aprender mejor, se debe recorrer la historia del QA de Software, porque conocer la historia además evita cometer errores que ya pasaron y se superaron, además de que la historia contribuye a formar conceptos estratégicos de calidad.
Pensemos en los inicios, del trabajo como acción humana que se realizaba mucho antes de que el software dominara el mundo, para producir valor. Específicamente voy a partir desde el importante hito de la Revolución Industrial a fines del siglo XVIII, lo que el paso de una economía agraria y artesanal a una dominada por la industria y la producción mecanizada. Este proceso implicó innovaciones tecnológicas, cambios en las estructuras sociales y económicas, esto favoreció la aparición de grandes empresas y fábricas y la gente ya se empezaba a plantear problemas de calidad, puesto que productos "buenos" eran más preciados.
Al principio, era simple, se fabricaba y se debía: revisar que un producto no tuviera defectos visibles. Sin embargo, a medida que aumentaba la demanda, la competencia de mercado y las carreras de negocio, esto demandaba cambios en la forma de fabricar, los productos se volvían más complejos y debían ser certeros en todo lo relacionado con la satisfacción del cliente.
En este ritmo volátil e incremental del comercio y el consumo, surge la necesidad de crear sistemas que aseguraran productos en buen estado, no solo al final, sino que garantizaran desde el principio que el producto se estaba fabricando con calidad y así se aseguraban sus resultados.
Por lo tanto, el Aseguramiento de la Calidad (en inglés: QA) se convierte en una tarea indispensable para asegurar que los productos cumplan con las expectativas de calidad tanto durante los procesos productivos como en los procesos de entrega y que cumplieran con las expectativas de satisfacción de los clientes.
Todo este contexto en la producción de valor mediante el trabajo se amplía en diferentes sectores productivos, así es cómo influye directamente en la gestión de las nuevas industrias de tecnologías computacionales, en especial cuando aparecen grandes empresas como Microsoft en el año 1975, aunque ya antes se notaba la relevancia y el posicionamiento que estaba alcanzando la producción de Softwares en el mercado.

Orígenes de las prácticas de QA

Los primeros registros documentados sobre sistemas para el aseguramiento de calidad en el contexto general, más allá de los softwares, datan desde 1897, con pioneros como: Henry Ford, Walter Shewhart, William Edwards Deming, Joseph M. Juran, Armand V. Feigenbaum, Kaoru Ishikawa y Philip B. Crosby, Vilfredo Pareto y otros .
Estos eran ingenieros, matemáticos y científicos relativos a empresas de manufacturas, fábricas o industrias y los departamentos de investigación en grandes universidades.
Estas personas desarrollaron conceptos y metodologías claves para la gestión de la calidad, que sentaron las bases para el QA moderno en el área de desarrollo de Software. En la actualidad, también se aplican estos aportes en su forma original. A continuación menciono algunos y en especial comento los diagramas, ya que estos permitieron el surgimiento de técnicas de control QA que hoy se utilizan:

• El análisis de variación de procesos, para las bases de las estadísticas de calidad.
• Los 14 puntos para la gestión de la calidad.
• "Plan-Do-Check-Act" (PDCA) , planear, hacer, verificar y actuar.
• La "trilogía de la calidad", que consiste en la planificación de la calidad, el control de la calidad y la mejora de la calidad .
• El concepto de "control total de calidad"que involucra a toda la organización.
• Los conceptos de costos de calidad.

Diagramas	Descripción
Diagrama de Venn, también conocido como Diagrama de conjuntos para la identificación de problemas	Se basa en la teoría de conjuntos, donde se representan conjuntos de elementos, usando círculos para diagramarlos,por ejemplo, si estamos en un proyecto de desarrollo de software y hay problemas con las entregas, quizás hay demoras o bugs en producción, usando el diagrama de Venn se puede primero identificar las causas de estos problemas y luego dibujar círculos donde se agrupen áreas de trabajo (o las fases de trabajo) y las causas relacionadas como conjuntos, luego se dibujan las intersecciones entre los conjuntos, esto permitiría solapar las áreas de trabajo y identificar donde se manifiestan las causas para poderlas solucionar. Este diagrama se vincula directamente con la lógica de las Bases de Datos Relacionales, donde los conjuntos representan las tablas y las intersecciones representan las claves primarias y foráneas. El diagrama de Venn, en general podría ser muy valioso para organizar prácticas de mejoras del mismo QA, ya sea ante la búsqueda de soluciones para problemas como para crear estrategias, para planificar y visualizar diferentes etapas de un proyecto, se pueden dibujar círculos que representen diferentes fases, como la investigación, la planificación y la implementación, y luego superponerlos para mostrar cómo se relacionan y se solapan las diferentes fases
Diagrama de Ishikawa, también conocido como Diagrama Espina de Pescado ó Diagrama de causa y efecto para el desglose de problemas en sus causas	Este modelo permite esquematizar las causas de un problema específico y someterlo a un análisis organizado, este diagrama sienta las bases para las técnicas posteriores de QA como el Grafo Causa-Efecto. El Ishikawa en su representación gráfica es similar al esqueleto lateral de un pez, donde la cabeza se coloca a la derecha y es el problema principal, luego de esta, surge hacia la izquierda la columna vertebral del pez, donde pegado a esta se colocan las costillas y cada una va a representar las causas de la falla, además de cada falla se puede desprender una subcausa. Aplicar este análisis para las técnicas de QA se puede convertir en una herramienta valiosa, en especial si se determinan escenarios de fallas y a partir de estos, poder identificar causas y crear Casos de Prueba para comprobarlos.
Diagrama de Pareto, también conocido como Diagrama de barras para la priorización de problemas	Este diagrama está basado en el principio de Pareto. Se asocia a la identificación de fallas por prioridades de efectos a través de un gráfico para la toma de decisiones en las gestiones organizacionales (aunque también se usa en medicina, política y otras disciplinas). Este diagrama consiste en construir un grafico de barras sobre un eje de coordenadas (x, y), donde las barras se colocan en "x" y representan los problemas o fallas, de tal manera que las de mayor impacto se colocan más a la izquierda y el resto más a la derecha, luego en el eje de las "y" se coloca a la izquierda la frecuencia de ocurrencia de los problemas o su impacto en la organización y a la derecha se colocan las causas a modo de porcentajes. Según la lógica de la teoría de Pareto, cuando se analiza el gráfico se puede identificar dos cosas: 1- Que los problemas con mayor impacto son los "pocos vitales" y los menos "los muchos triviales", lo que se traduce en que hay unos pocos problemas de mayor impacto y muchos con menos valor. 2- Permite establecer el principio de que el 80% de los problemas se atribuyen al 20% de sus causas totales, por lo que si se solucionan este 20% de las causas totales esto va a representar el 80% de las fallas solucionadas. Este diagrama es útil para priorizar y cuantificar problemas para tomar decisiones sobre soluciones eficaces y urgentes.

Primeros pasos hacia el QA de Software

Los aportes antes mencionados se empezaron a extender hacia las prácticas de las empresas en muchas industrias, incluyendo las tecnologías informáticas.
Posterior a estos hallazgos y relativo a la computación, en 1940 se produjo el famoso evento de problemas en el funcionamiento de la computadora Harvard Mark II (modelos antiguos que usaban tarjetas perforadas en lugar de discos para almacenar información) en el laboratorio de la Universidad de Harvard, por lo que esto conllevó a una investigación sobre la falla.
Al frente de este proyecto se encontraba una ingeniera matemática llamada Grace Hopper, quien dirigió a un equipo de operadores para investigar el problema, en este proceso se encontró un insecto atrapado en un relé (interruptor eléctrico usado como puente entre circuitos de diferentes potencias), él cual era la causa del mal funcionamiento. El insecto, que era una polilla, fue adjuntado a un cuaderno bitácora, donde el equipo documentaba sus avances tecnológicos, así quedó registrada la primera falla de software y su origen, el término en inglés de insecto es "Bug" , así se se popularizó el término y quedó registrado para la historia.
Este hecho también está ligado al término "debug", que se refiere al proceso de encontrar defectos o errores en el código que ocasionen fallas en el funcionamiento esperado de un programa y luego corregirlos ó depurarlos.

A pesar de estos hechos y aportes a la calidad, solo se hablaba de buscar errores que causaran mal funcionamiento final y no evitar estos durante todo el proceso productivo, por lo que aún no se hablaba de QA como un proceso de valor agregado con varias prácticas integradas.
Entre los años 50-70 los conceptos de aseguramiento de la calidad ya se empiezan a ir gestando, desde figuras como Joseph Moses Juran, mencionado antes en la introducción, pero necesario especificar en este momento, sus aportes sobre el QA, ya que su investigación se centró en destacar el QA como prácticas integrales y preventivas en el desarrollo de software. Este hombre de origen rumano, graduado en la Universidad de Minnesota, Estados Unidos como ingeniero eléctrico, fue reconocido como consultor evangelista de la calidad y la gestión de la calidad. Juran trabajaba en proyectos para medir estadísticas de mejora de los procesos, extrapoló el uso del "Diagrama de Pareto" al análisis de la calidad: el 80% de los problemas se atribuyen al 20% de sus causas totales, análisis que es muy útil para la toma de decisiones ante fallas en las industrias, pero Juran basado en Pareto resaltó el valor de las causas restantes, asociadas a las fallas "triviales", de tal manera que el 80% de causas que son relativas a esos muchos problemas de menor impacto también eran "útiles" para analizar y no pueden ser ignoradas. Esta visión permitió ampliar la cobertura de las pruebas y el seguimiento del control de la calidad.

Reflexión: En contextos actuales, por ejemplo, imaginemos que estamos trabajando en un proyecto en la etapa de desarrollo de una nueva funcionalidad, como QA se toma la decisión de priorizar solo las pruebas funcionales a nivel de sistema (UI), esto no está mal, ya que viéndolo desde este análisis, se supone que en una escala de posibles fallas de la funcionalidad se le da mayor valor a las fallas de UI, esta prioridad (según Pareto) significa que estos son los "problemas pocos vitales", por ende si se soluciona el 20% de causas totales de las fallas que pudiera tener el sistema, se cubriría el 80% de los problemas de la funcionalidad. Desde esta perspectiva, otras pruebas de QA en otros niveles se desestimarían, ya que estos serían los otros "muchos problemas triviales".
El aporte de Juran, en cambio permite considerar este resto de problemas y el 80% las causas totales, a las que llama "útiles", por ejemplo: el uso de la memoria, el uso de recursos internos (procesadores), el manejo de peticiones cliente-servidor, la seguridad de los datos, el uso de recursos externos ( disco, red), etc., además pueden ocurrir fallas en la integración de la funcionalidad con otras que ya existan en el sistema.
Este aporte permite que para el QA se sean tomadas pruebas de regresión, integración y performance, con el fin de identificar las fallas de calidad y priorizarlas, ya que se podría estimar una cobertura de calidad más amplia y permite entender entre otros motivos el porqué de las estrategias de pruebas de regresión, integración y hasta de performance.
Este aporte reafirmaba la idea de que el QA era más que detectar errores, se trata de prácticas estratégicas de tomar decisiones de pruebas y considerar la cobertura, entre otras cosas.
En ese entonces, las pruebas para validar la calidad eran solo manuales y no seguían una metodología formal, aunque en los aportes de Juran, permitieron el reconocimiento de conceptos de impacto para la calidad, además que fue un precursor en la formación de directivos sobre la calidad de sus organizaciones, esto conllevó a que las altas direcciones vieran a la gestión de calidad como un proceso de valor agregado.

En el año 1970 Winston W. Royce enuncia por primera vez la metodología Waterfall o en Cascada, en su trabajo titulado The Development of Large Software Systems, la que, sentó las bases al dividir el desarrollo de un software en fases separadas:
Requisitos, Diseño, Desarrollo e implementación, Pruebas, Despliegue ó entrega y Mantenimiento.
Esto división, permitió una mejor organización y control de los procesos, ya que se agrupaban las tareas en fases y se podían incluir tareas de pruebas al Software. Pero como se limitaba a ser un proceso secuencial, el QA solo se concebía como "hacer pruebas" al producto una vez terminado (estamos hablando de un producto de software completo y no de ir entregando partes del mismo e iterar en el producto total, como hacen otras metodologías que surgieron después), en cambio no se ejecutaban prácticas de aseguramiento preventivas en cada fase, antes de encontrar fallas.
Esta metodología también tiene la peculiaridad, de que no se avanza de fase hasta que no culmine la anterior y una vez avanzado no se retrocede, por lo que se medía la calidad como expresión de resultado, y no desde la perspectiva de identificar riesgos ante la posibilidad de cometer errores, mientras se cumplen las tareas de cada fase, lo que se conoce como "Control de Calidad (QC) ". Las consecuencias de no tener un QA eficiente eran costosas, ya que los errores se corregían al final de un producto terminado.
Waterfall, también tenía poca adaptabilidad a los cambios en los requisitos o necesidades del cliente durante el proyecto.
A pesar de sus limitaciones, esta metodología sentaba las bases para el control y documentación en el desarrollo de Software, qué a la actualidad, dicha metodología, también ha evolucionado y mejorado, por lo que se sigue utilizando en la industria.

Las ciencias de la Computación y el QA

Anterior a la aparición de Waterfall, se reconocen otros aportes al QA de software, hechos por Alan Turing y Charles Baker, quienes por primera vez, acuñaron el término de "Software Quality", lo que contribuyó a la idea de que la calidad es un proceso más amplio que hacer pruebas para verificar fallas de funcionamiento y luego hacer una simple depuración.
Antes de continuar, considero importante resaltar la figura de Turing en la historia de la computación, recomiendo profundamente investigar sobre Turing y sus trabajos, ya que es fascinante y valioso conocer orígenes de la computación al menos como cultura integral, lo que a su vez, contribuye a familiarizarse con muchos conceptos de tecnologías modernas, en este espacio comento brevemente sus aportes.
Alan Mathison Turing, fue un matemático británico, considerado uno de los padres de la computación, precursor de la inteligencia artificial y la informática teórica. Se reconocen varios de sus trabajos, entre otros, la Máquina de Turing: un modelo matemático de computación que describe una máquina abstracta capaz de realizar cualquier tarea computacional siguiendo un conjunto de reglas. Se trata en esencia de un modelo teórico de una computadora capaz de ejecutar cualquier "algoritmo", independientemente de su complejidad, esto permitió definir formalmente el concepto de algoritmo para referirse a programas informáticos, lo que sentó las bases de las computadoras modernas. Otro dato destacable de Turing, fue que desempeñó un papel crucial en el desciframiento del código de la máquina "Enigma", un aparato de cifrado militar encriptado, que usaban los nazis en la II Guerra Mundial. Según algunas hipótesis, descifrar estos códigos, acortó la duración de la guerra de dos a cuatro años, ya que permitió conocer los planes de los nazis y posiciones de guerra.
Los aportes de Turing para la computación fueron importantes, así como sus menciones de la calidad de Software.

La calidad a nivel mundial: Norma ISO 9001

En la decada de 1980 la ISO publica la Norma ISO 9001: Sistema de Gestión de la Calidad, lo que marcó un hito en la formalización de los procesos de aseguramiento de la calidad, incluyendo el software.
¿Qué es en pocas palabras?
Imagina que es un manual de "buenas prácticas" reconocido a nivel mundial. No te dice qué hacer, sino cómo organizar tu empresa y sus procesos, para que tus clientes siempre reciban productos y servicios de calidad, cumpliendo con todas las reglas. Su secreto se basa en un ciclo muy lógico y potente: Planificar-Hacer-Verificar-Actuar (PHVA), es decir:

• Plan/ Planificar: Planificas lo que vas a hacer.
• Do/ Hacer: Haces lo que planificaste.
• Check/ Verificar: Verificas que los resultados sean los esperados .
• Act/ Actuar: Actúas para corregir y mejorar constantemente.

Este enfoque en los procesos, es la esencia de la gestión de calidad moderna y sentó las bases para la estandarización del QA de Software. Dicho de otra forma la ISO 9001, ofrece un esqueleto que cualquier organización, desde una que fabrica tornillos hasta una que desarrolla software, puede adaptar para buscar la excelencia. En el 2015 se registró la última actualización de la norma, pero su contenido se mantiene.

La esencia de la ISO 9001 impulsa que el software, como producto, sea desarrollado con la máxima calidad porque la calidad del producto está "íntimamente ligada a la calidad del proceso" que se usa para crearlo.
Para lograrlo, la norma se enfoca en principios clave que se extienden y aplican directamente al control de calidad de software:

• Enfoque basado en procesos y estandarización: La ISO 9001 busca que identifiques y gestiones tus procesos clave. Esto significa que, en el desarrollo de software, se deben estandarizar los procesos de diseño, desarrollo y entrega. Piensa en ella como una "lista de verificación para el desarrollo, suministro y mantenimiento de programas informáticos", especialmente a través de la guía ISO/IEC/IEEE 90003, que adapta los principios de la ISO 9001 al software.
• Enfoque al cliente: La norma pone la satisfacción del cliente en el centro. En el software, esto se traduce en la necesidad de entender y cumplir con las expectativas del cliente en cada etapa.
• Mejora continua: La ISO 9001 exige que la organización "mejore continuamente". En el software, esto significa identificar y corregir proactivamente los problemas de calidad, buscando siempre optimizar procesos y resultados.
• Gestión de riesgos: La norma te anima a identificar y abordar los riesgos potenciales. Aplicado al software, esto significa gestionar proactivamente los riesgos para minimizar errores y aumentar la calidad del producto final. Es una "herramienta esencial para garantizar la supervivencia y el crecimiento sostenible" de la empresa. Estas exigencias de la ISO 9001 se manifiestan en prácticas concretas de control de calidad de software:
• Gestión de la documentación y trazabilidad: La norma requiere el mantenimiento de registros como evidencia de cumplimiento. Esto implica una gestión ágil y eficaz de toda la información del proyecto, desde requisitos hasta pruebas. La trazabilidad es fundamental para asegurar que los requisitos se corresponden con el diseño, el código y las pruebas, evitando pérdidas de información o sobre-especificación.
• Pruebas rigurosas: Para asegurar que el software cumple con lo esperado, la norma impulsa la realización de pruebas exhaustivas (funcionales, de rendimiento, seguridad, etc.). Los resultados de estas pruebas son registros clave de la conformidad del producto.
• Auditorías internas: Son esenciales para mantener la certificación ISO 9001. Estas auditorías son procesos sistemáticos para "verificar la conformidad con los requisitos de la norma y la eficacia del Sistema de Gestión de la Calidad". No se trata solo de cumplir un requisito, sino de "identificar puntos relevantes que permitan optimizar y ajustar la operación de los procesos", generando "hallazgos" que pueden ser "oportunidades de mejora, no conformidades y acciones correctivas".

Estándares modernos para el QA de Software

En definitiva, la implementación de la Norma ISO 9001 contiene y fortalece las prácticas de control de calidad de software. Al adoptar la ISO 9001, una organización no solo busca una certificación, sino que cultiva una cultura de calidad donde el software se desarrolla a través de procesos bien definidos, con un enfoque en el cliente, buscando la mejora continua y gestionando proactivamente los riesgos. Esto lleva a una mayor efectividad en los procesos, mejor rendimiento y reducción de costos operativos (por ejemplo, agilizando la gestión documental) y, lo más importante, a la satisfacción del cliente.
En el 1990 aparecen los conceptos de "test-driven development" (TDD,desarrollo conducido por las pruebas), "agile software development"(desarrollo ágil y entregas frecuentes) y "lean software development" (maximizar el valor, minimizar los costos, entrega y mejora continua). Esto propicia el surgimiento de las Metodologías Ágiles para el desarrollo de software, como Scrum y Kanban, que se adaptan a los cambios en los requisitos y necesidades del cliente durante el proyecto, facilitando la entrega de software de calidad, organizan el trabajo y permiten incorporar prácticas de calidad en las diferentes etapas del ciclo de desarrollo, para garantizar entregas continuas, con calidad y productos de valor.
Posterior a esta ISO, hacia los años 80-90 se formaliza el rol del tester y se desarrollan técnicas de prueba más sistemáticas, como la creación de planes de prueba y casos de prueba basados en los requisitos del software. Sobre la década del 90 el QA de Software se convierte en una disciplina más reconocida y las pruebas se vuelven más especializadas, con la aparición de diferentes tipos de pruebas (funcionales, de rendimiento, etc.) y metodologías de pruebas basadas en el desarrollo (TDD, BDD, etc.).

El ISTQB

A finales del siglo XX la tecnología de la información crecía exponencialmente, por la ampliación de los servicios de Internet y el desarrollo de la web, esto demandaba Softwares de alto rendimiento, de mayor calidad y por ende había que marcar estándares de QA para garantizar esto, estas previsiones sobre la tendencia de aumento de la tecnología de la información, propiciaron la gestación de organismos que estaban a la vanguardia en las prácticas de QA y que crearan estándares de valor internacional, para la formación especializada de profesionales enfocados hacia el QA.
Así en 1998 se crea en Escocia y registra en Bélgica el Comité Internacional de Certificaciones de Pruebas de Software (en inglés ISTQB®), como organización internacional sin fines de lucro, formada de forma voluntaria por expertos en el campo de la calidad en calidad de software a nivel mundial, quienes por consenso de la comunidad internacional, validaron desde sus prácticas los estándares las pruebas de software y el QA en general.
Es una organización en constante evolución, enfocada a la innovación y la investigación para la mejora en la eficiencia de las pruebas de Software. Tienen presencia en más de 100 países y 50 comités encargados de mantener el esquema de certificación en diversas regiones como en Latinoamérica que se encuentra el Comité de Hispanoamericano de Certificación de Pruebas de Software (en inglés HASTQB®).
El ISTQB cuenta con un esquema de entrenamiento para el QA profesional y opciones de examen para certificar el profesional.

• Evaluaciones: correspondientes esquema internacional de certificación profesional denominado "ISTQB Certified Tester"
• Programa de Estudio y el Glosario: en los cuales se definen los estándares internacionales por nivel (inicial, avanzado y experto)
• Guías para la acreditación: guías y tutoriales de evaluación de los profesionales de las pruebas de software a cargo de los comités de cada país

Seguir los estándares internacionales del ISTQB en la práctica, es contar con un una guía certera para el desempeño de las personas que se dedican al QA de software, digamos que es un "ABC", aunque no una "una camisa de fuerza", por el contrario es un punto de partida probado y validado, recomiendo acceder a su sitio oficial en el siguiente enlace: https://www.istqb.org/, allí aparecen las referencias validadas por el ISTQB para cada nivel y para profesionales de habla española.
Esta formación se puede complementar con otros conocimientos intrínsecos de las IT y nuestras propias experiencias.
En cambio estar certificados por esta organización no es obligatorio, requiere una inversión, pero si podría abrir muchas oportunidades profesionales, porque significaría que una organización de reconocimiento está validando tu competencia en el área a ojos de la industria.
Aclarado todo esto, ya podemos plantear que el aseguramiento de la calidad es una gestión y una forma de pensar con estrategia para garantizar el éxito de una empresa, un producto o servicio, independientemente del sector que sea y en toda gestión de calidad se aplica la misma lógica:
"la calidad del producto final depende directamente de la calidad del proceso usado para crearlo".
Para esto hay que planificar,documentar,estandarizar,evaluar y mejorar continuamente los procesos de aseguramiento de la calidad,digase: metodologías, métodos, técnicas, procedimientos, herramientas y prácticas en general.

Actualidad

En pleno siglo XXI se puede decir que las prácticas de QA han seguido evolucionando a la par de la aceleración de nuevas tecnologías, por lo que de prácticas Manuales se ha pasado a la incorporación de prácticas Automatizadas, con lo cual se busca automatizar las pruebas de software para reducir el tiempo de ejecución y aumentar la eficiencia. Esto se convierte en un principio clave para mejorar la velocidad de las pruebas. Además las metodologías Agiles y otras metodologías iterativas impulsan la necesidad de pruebas continuas y la integración de pruebas en el ciclo de vida del desarrollo de software, para garantizar calidad y optimizar los tiempos de entrega de productos de valor para el cliente.
Actualmente el QA de Software se sigue adaptando y evolucionando a la par de las nuevas tecnologías, como por ejemplo la integración de prácticas como el DevOps, que buscan una mayor colaboración entre desarrollo y operaciones para garantizar la calidad del software.
Por supuesto que no puedo dejar de mencionar la nueva definición que marca esta era tecnológica las Inteligencias Artificiales ó "AI" , donde saberlas usar es un desafío pero a a la vez puede resultar muy beneficioso para las prácticas de QA, aunque también debemos recordar que estos son Softwares que también demandan calidad, por ende estudiarlos como un objetivo más de QA y no solo verlos como un asistente pudiera ser el verdadero provecho para los QA. Incluye además múltiples ramas de los niveles del testing, donde las pruebas de Big Data se podría incluir a mi juicio como un nivel más.