Software Testing

El proceso de prueba de software, aunque no es exactamente el mismo para todas las metodologías, puede generalizarse para contener los puntos principales y más importantes que nos ayudan a tener una experiencia de prueba efectiva.

Primero necesitamos definir la estrategia de prueba y el plan de prueba. Algunas de las cosas que puede utilizar para describir el alcance de prueba de su proyecto son:

Sistemas que deben probarse
Características y funciones específicas del proyecto
requerimientos no funcionales
Herramientas
Y muchos más


Sin estrategia y plan, cada proyecto tendrá dificultades para ser productivo. Esto le ayudará a definir sus criterios de entrada y salida para las pruebas, que son importantes como control para su equipo. Si los requisitos carecen de especificidad, no entrarán en prueba. Si el código probado no cumple con los estándares de calidad específicos, el código nunca pasará a la siguiente fase.

En segundo lugar, necesita el diseño de prueba. Aquí tendrá una colección de casos de prueba necesarios para validar el sistema. El diseño de la prueba se basa en la experiencia de la prueba, el conocimiento de los probadores del sistema que se está probando y las prácticas de prueba predominantes. Se centra en descubrir y corregir errores importantes, en lugar de otros aspectos o defectos superficiales.

La tercera fase es la ejecución de la prueba. Hay muchas formas en las que puede ejecutar pruebas, para este paso tendrá que adaptar sus pruebas a la cantidad adecuada de pruebas hasta que esté seguro de que su sistema es completamente funcional y en su mayoría libre de errores. Comprender los requisitos de su entorno de prueba es clave para poder decidir su estrategia de prueba.

Finalmente, tenemos el cierre de la prueba. Aquí es donde entran en juego sus criterios de salida porque indican la finalización del ciclo de prueba y la preparación para el lanzamiento de su producto. Para garantizar el cierre de la prueba, se deben cumplir todos sus requisitos, tanto técnicos como comerciales. Debe haber aprobado un porcentaje mínimo de aprobación, la mejor práctica es apuntar al 90% de las pruebas aprobadas. Cada defecto crítico debe arreglarse.

Estos pasos son solo una vista general de cómo debería ser su proceso de prueba.

Hay cuatro niveles de prueba de software que debe tener en cuenta. Estos son:

Prueba unitaria: el programa se somete a evaluaciones que se centran en componentes específicos del software para ver si son completamente funcionales. El propósito de esta ronda de pruebas es determinar si el software funciona según lo diseñado. Una unidad puede referirse a una función, un programa individual o un procedimiento.


Prueba de integración: esto permite a las personas la oportunidad de combinar todas las unidades en un programa y probarlas juntas. Está diseñado para encontrar defectos de interfaz entre cada módulo o función.


Prueba del sistema: el nivel de prueba del sistema es el primero en el que se prueba la aplicación como un todo. Su objetivo es evaluar si el sistema ha cumplido con todos los requisitos y ver si cumple con los estándares de calidad.


Prueba de aceptación: este es el nivel final de prueba y se utiliza para determinar si un sistema está listo para su lanzamiento o no. Los requisitos pueden cambiar durante el ciclo de desarrollo, por lo que debe realizar una prueba para ver si el proceso satisface las necesidades de la empresa. Una vez superado este nivel, el software se puede entregar a producción.

Hay varios roles y actividades que se deben realizar en las pruebas, cada uno de los cuales tiene ciertas responsabilidades que deben realizarse. Los roles principales son:

Administrador de pruebas: el administrador de pruebas generalmente se contrata cuando hay muchos grupos de prueba. Algunas de las funciones principales de un administrador de pruebas son: preparar la estrategia de prueba, preparar el presupuesto de prueba, definir los niveles y ciclos de prueba, desarrollar la estrategia para la documentación de prueba, métricas e informes, y muchos más.


Líder de prueba: cada grupo de prueba debe estar dirigido por un líder de prueba. El líder de la prueba desempeña los roles de administrador de la prueba cuando está ausente y tiene sus propias responsabilidades, que incluyen: preparar el plan de prueba en cada nivel de prueba, definir los objetivos, asignar roles y proporcionar horarios a los probadores, etc.


Probadores: El grupo de probadores puede tener diferentes niveles de probadores y roles como probadores de rendimiento, probadores de automatización, etc.

Algunas de sus responsabilidades son: recopilar los requisitos de prueba, configurar y verificar el entorno de prueba, automatizar las pruebas y muchas más.

Y para qué sirve el testing? – Educacion IT

Revisión de Código (Revisión por pares / Inspección de código)

Empecemos sencillo que significa revisión de código:

La revisión de código es un examen sistemático del código fuente del software, destinado a encontrar errores y estimar la calidad del código.

El proceso de revisión del código contiene las siguientes etapas:

  • Mejores prácticas: identificar formas más eficientes de completar cualquier tarea.
  • Detección de errores: encontrar errores lógicos.
  • Exposición a vulnerabilidades: identificación de las vulnerabilidades más comunes.
  • Descubrimiento de malware: un tipo especial de revisión de código que se utiliza para detectar los fragmentos de código sospechosos o para encontrar las puertas traseras y cualquier malware integrado en el software.

Pero para que realmente necesitamos la revisión de código

Hay varias razones por las que hacer una revisión de código es una parte necesaria del desarrollo.

La primera razón es reducir los riesgos. Por ejemplo, si tiene algún software codificado por un profesional independiente o una agencia, pero no está seguro de la calidad del trabajo porque incluso los buenos desarrolladores pueden perder algo. Por lo tanto, la doble verificación siempre es una buena idea.

Además, mientras trabajan juntos para examinar el código, cada miembro del equipo puede sugerir soluciones más inteligentes que mejorarían el rendimiento general del proyecto.

Lo principal que debe recordar acerca de la revisión de código es que debe realizarse ANTES de que su nuevo equipo de desarrollo adopte una nueva base de código o proyecto. Verificar el código antes de comenzar un proyecto le da a su equipo la oportunidad de familiarizarse con él y determinar si el código está limpio o requiere alguna modificación.

Existe una metodología para la revisión de código llamada “Revisión por pares”(Peer Review) esta consiste en :

La revisión por pares es la evaluación del trabajo por una o más personas con competencias similares a las de los productores del trabajo (pares). Funciona como una forma de autorregulación por parte de miembros calificados de una profesión dentro del campo relevante. Los métodos de revisión por pares se utilizan para mantener los estándares de calidad, mejorar el desempeño y brindar credibilidad. En el ámbito académico, la revisión por pares académicos se utiliza a menudo para determinar la idoneidad de un artículo académico para su publicación. La revisión por pares puede clasificarse por el tipo de actividad y por el campo o profesión en el que ocurre la actividad, por ejemplo, revisión médica por pares.

En pocas palabras

Un autor le pide a un compañero que lea, comente y critique un artefacto. Si el artefacto de trabajo es código, el revisor leerá el código e incluso puede desarrollar y ejecutar algunas pruebas unitarias para verificar que el código funciona como se anuncia.

Verificación y Validación de Software

En la gestión de proyectos de software , las pruebas de software y la ingeniería de software , la verificación y validación ( V&V ) es el proceso de comprobar que un sistema de software cumple con las especificaciones y cumple con su propósito previsto.

También puede denominarse control de calidad del software . Normalmente es responsabilidad de los probadores de software como parte del ciclo de vida del desarrollo de software .

En términos simples, la verificación del software es: “Suponiendo que deberíamos construir X, ¿nuestro software logra sus objetivos sin errores ni lagunas?” Por otro lado, la validación del software es: “¿Era X lo que deberíamos haber construido? ¿X cumple con los requisitos de alto nivel?”

ISO / IEC / IEEE 12207 Ingeniería de software y sistemas: los procesos del ciclo de vida del software es un estándar internacional para los procesos del ciclo de vida del software.

Introducido por primera vez en 1995, pretende ser un estándar primario que define todos los procesos necesarios para desarrollar y mantener sistemas de software, incluidos los resultados y / o actividades de cada proceso.

Les comparto igual un ejemplo de un documento para la planeación de un V&V plan este esqueleto lo pueden encontrar en internet es de uso libre.

Modelos y estándares para la mejora de procesos de software

En este blog hablaremos acerca de los modelos y estándares que tenemos en la industria para la mejora de procesos de software.

Por lo que tocaremos diferentes de estos tales como:

  • CMMI (Modelo de Madurez de Capacidades de Integración)
  • TSP/PSP
  • ISO-15504
  • MOPROSOFT
  • IDEAL method

CMMI (Modelo de Madurez de Capacidades de Integración)

Este modelo tiene las mejores practicas de la industria dentro del desarrollo de software, tanto para el desarrollo del mismo, como para su mantenimiento, adquisición y operación de productos y servicios.

¿Qué es CMMI?

Es el modelo esencial para que los procesos de negocios de las mismas sean efectivos, este modelo esta inspirado por el modelo de madurez Manufacturing Maturity Model de Crosby.

Un dato curioso de este modelo es que inicialmente solo se utilizaba para los programas de defensa pero con el paso del tiempo se fueron adaptando para diversos ámbitos mas allá del software.

¿Por qué es importante usar un modelo para el desarrollo de software?

La importancia de usar un modelo en un proyecto es comprender cuales son los elementos que tenemos que tener en una organización. Todo esto nos da una ventajas que se mencionara:

  • Permite que los usuarios puedan enfocarse específicamente en la mejora, ya que ayudan a que no pierdan la idea global.
  • Ayudan a mejorar la satisfacción del cliente.
  • Permiten producir productos y servicios de alta calidad.

Bienvenidos al curso de Software Quality and Testing (TC3045)

Este es el primer blog para darles a la bienvenida a este conjuntos de blogs para que me acompañen a este camino con el curso de Calidad de Software y Testeo, en el cual veremos unos de los principales topicos del tema.

Male Engineer Using CAD Programming Software On Laptop

Al igual podrán ver algunos de los principales exponentes del tema, que estarán compartiendo algunas de sus experiencias por medio de una videollamada que se estará teniendo los días viernes y los días sábados se subirá el blog del exponente, entre ellos tenemos a grandes exponentes como Kent Beck, nuestro profesor Ken Bauer y entre otros.

Así que cualquier duda o comentario pueden dejar sus opiniones en la sección de comentarios, los estaré leyendo y subiendo blogs de estos temas que se estarán viendo.

Saludos Masharelli.

First impressions

When I first saw my study plan, I wasn’t sure of what we were going to be learning in this class or didn’t know its purpose. The first week helped me get an idea of what topics we will be looking at this semester. I have to be honest, when I first learned this class was 6 hours a week I was a bit distraught. How can a class require 6 hours of work plus 6 additional hours outside of class? Seemed exaggerated and I still think it is. Thankfully, our teacher explained the course the class is taking and, in my opinion, it makes more sense and seems more helpful than having to sit for 3 hours 2 days of the week to “learn” about quality and testing. I like that most if not all of the second classes of the week will be talks with a guest. This makes the class much more interesting. We get the insight from someone who has much more experience than all of us in the industry and we get to ask them questions. This gives the class a realistic approach and makes the time of class much more tolerable.

This method is especially relieving during the pandemic. There are other teachers who do not change their methods of teaching at all and paying attention becomes even harder in online classes. I’d much rather have the talks and self-learning assignments that this class provides us. In conclusion, my first impressions of the class were good and I hope it continues this way for the rest of the semester.