Ir al contenido principal

Aseguramiento de la calidad – (QA)

Un QA (Quality Assurance), del inglés aseguramiento de la calidad, es el encargado de realizar los procesos que comprueben que un producto cumple con las especificaciones y la calidad esperada por el cliente.
Fuente

El ingeniero en QA participa en todas las etapas del desarrollo y puede hacer distintas actividades como:
·         Diseñar casos de pruebas.
·         Verificar y validar los requerimientos del proyecto.
·         Descubre errores.
·         Genera Métricas.
Hay que señalar que un QA no es un simple tester (puede realizar funciones), el ingeniero ofrece más que eso. Los roles que un ingeniero en QA puede ocupar pueden ser de Tester, diseñador de prueba, ingeniero en automatización, consultor, arquitecto etc.
La metodología básica que sigue un QA en los proyectos es un ciclo con lo siguiente:
·         Planificación de Test
·         Especificación de Test
·         Ejecución de Test
·         Resultados de Test
·         Evaluación
El QA realiza distintas pruebas como las de regresión, verificación de errores, pruebas a requerimientos funcionales, los Smoke Testing que prueban cada cierto tiempo las funcionalidades criticas, las llamadas pruebas de estrés que buscan los puntos de caída del programa, Test de seguridad entre otras más.
 Algunos principios básicos sobre la automatización de pruebas son los siguientes:
·         Diseñar Test Cases.
·         No todo se automatiza.
·         Automatizar pruebas no reemplaza al QA.
·         Los Test Cases deben ser cortos.
·         Utilizar buenas prácticas de programación.
·         Los Test Cases deben ser independientes.

Los QA anteriormente eran simples testers de programas, pero posteriormente fueron evolucionando adquiriendo otras funciones que vinieron hacer del QA parte fundamental del desarrollo de los proyectos y parte del éxito del programa de cara al cliente y usuario es debido a ellos.

Comentarios

Entradas populares de este blog

Diagrama de Secuencia del Sistema (DSS)

Existen diferentes formas de explicar un sistema de software que se esté desarrollando, por ejemplo, los casos de uso, estos nos muestran una función específica que realiza el sistema, pero estos pueden ser explicados de una forma diferente por medio de los diagramas de secuencia del sistema. Los DSS es un modelo que muestra al sistema como una caja negra para un caso de uso específico, donde se muestran los actores externos que participan en él, también el orden de los eventos que suceden durante la ejecución del caso de uso. Se dice que debería haber un DSS para cada caso de uso de un proyecto de software, esto debido a que cada DSS se deriva directamente de un caso de uso. Se puede decir que los DSS explican los casos de uso de una forma diferente mostrando las secuencias de eventos que suceden en los casos de uso, estas secuencias comúnmente inician con un verbo, ya que describen una acción que sucede. En los diagramas como tal, el tiempo avanza hacia abajo respetando el

Requerimientos Volátiles y Estables

Los requerimientos de un proyecto de software se pueden clasificar de formas distintas por ejemplo cuando identificamos los requisitos funcionales, no funcionales y los de información, pero también es posible clasificarlos de una forma distinta, más específicamente en volátiles y estables. Requerimientos Volátiles: Estos requisitos volátiles (Cambiantes) tienen una alta probabilidad de sufrir cambios durante el proceso de desarrollo del software, pero también pueden cambiar fuera de dicho proceso cuando el software está terminado o incluso cuando ya está en uso por parte del usuario. Estos requisitos tienen subclasificaciones ya que son muy diversos, los cuales son los siguientes. ·          Mutables: Reciben este nombre los requisitos que se ven afectados por cambios que puedan presentarse en el ambiente con el que opera la organización. ·          Emergentes: Estos aparecen cuando el proceso de diseño de los requerimientos, facilitan el entendimiento del sistema y le perm

StakeHolders

La palabra stakeholders se utiliza para definir a las personas, grupo de personas o empresas que están interesados en un proyecto especifico, en nuestro caso un proyecto de software. El termino stakeholders se puede traducir como “interesados”, estos interesados son empresas o personas que tienen relación de alguna forma con el proyecto y no necesariamente trabajan en el. Algunos ejemplos son los siguientes: Empresas y Organizaciones: En algunos casos los proyectos necesitan de la aprobación de otras empresas u organizaciones para poder desarrollarlo, como financiamientos, seguros, aprobación de licencias etc. Usuarios: Son las personas a las cual va dirigido el proyecto, son los usuarios del programa informático en un proyecto de software, estas personas pueden estar de acuerdo o en desacuerdo con el proyecto. Afectados: Son personas u organizaciones que están indirectamente involucrados en el proyecto, y tampoco son el objetivo de los resultados del proyecto, p