Hola Mi nombre es Misha y soy Senior QA con experiencia comercial de más de 6 años. Ahora trabajo en Provectus, pero comencé mi camino de evaluador como estudiante cuando participé en pruebas alfa y beta de varios juegos. En algún momento pensé: "¿Por qué no empezar a hacer esto profesionalmente?" Y nos vamos. Durante este tiempo, logré participar en varios proyectos: desde nuevas empresas hasta empresas, desde pequeños juegos de unidades educativas hasta grandes aplicaciones con una sólida lógica de negocios.
Pero a menudo me presentaron en equipos pequeños, en los que había 5 desarrolladores para 1-2 probadores y, como regla, había mucho calor en el proyecto. En realidad, quiero compartir con ustedes cómo aprender a comprender dónde se encuentran y cómo comenzar a avanzar en la formulación de procesos de control de calidad.
En primer lugar, debe comprender en qué proyecto se encuentra.
Habiendo adquirido experiencia participando en proyectos, los dividiría condicionalmente en 3 tipos:
- proyectos sin pruebas;
- proyectos con pruebas injustas;
- Proyectos de prueba.
En el momento de mi participación, cada uno de ellos estaba en su etapa de desarrollo. Comencé a observar estas situaciones y comencé a desarrollar mi visión: cómo promover procesos de prueba en ellas. Después de un tiempo, me topé con el Modelo de Madurez, y ella se acostó uno a uno en mi trabajo preliminar. Esto fortaleció mi creencia de que este es el lugar para estar.
¿Qué es el modelo de madurez?
Y aquí estoy, muy hábilmente, inserte una cita de
Wikipedia :
Capability Maturity Model Integration (CMMI): un conjunto de modelos (metodologías) para mejorar procesos en organizaciones de diferentes tamaños y actividades. CMMI contiene un conjunto de recomendaciones en forma de prácticas, cuya implementación, según los desarrolladores del modelo, le permite alcanzar los objetivos necesarios para la implementación completa de ciertas áreas de actividad.
En resumen y simple, este es un conjunto de modelos que muestran qué tan bien organizados están los procesos en la organización de acuerdo con ciertos criterios. Al tener tal evaluación, uno puede evaluar sobriamente si vale la pena dar una u otra orden a un contratista en particular.
En realidad, a partir de esto comenzó el desarrollo del Modelo de Madurez. En los años 80, el Departamento de Defensa de los Estados Unidos se dio cuenta de que no podía evaluar con precisión la calidad del trabajo de los contratistas de desarrollo de software. Y dado que esta estructura de gobierno también es de tal nivel, esto es inaceptable. El dinero es propiedad del estado, los plazos están claramente delineados y un software confiable para armas permitirá que todos duerman más tranquilos. En base a esto, el Ministerio instruyó al Instituto de Ingeniería de Software para crear dicho sistema de calificación y un año después se creó el primer cuestionario, y 4 años después se creó la primera versión del modelo.
Niveles de modelo de madurez
Estos son 5 niveles, dentro de los cuales se evalúa el trabajo / confiabilidad / estabilidad de la empresa.
Dónde en el modelo de madurez está probando
Para los probadores hay un MM especial, se llama TMMi. También contiene 5 niveles, en los que me gustaría profundizar más y considerar lo que es típico de cada uno de ellos.
El primer nivel es "Principiante"En el primer nivel, las pruebas no son estructuradas y caóticas. No hay un entorno estable para soportar los procesos de prueba. El equipo no presta atención a la planificación y los estándares.
El objetivo principal es entregar el producto a tiempo sin problemas críticos, porque las pruebas se usan aquí solo para mostrar que la aplicación funciona sin fallas graves. A menudo, el éxito de tales proyectos depende únicamente del heroísmo y las habilidades de los individuos, en lugar de los procesos establecidos.
Como resultado:
- sin documentación de prueba;
- el producto es inestable;
- rechazo de procesos durante situaciones problemáticas;
- las pruebas no son más que asistencia de depuración.
Segundo nivel - "Repetible"En el segundo nivel, las pruebas se convierten en un proceso controlado. La disciplina y el progreso realizado aseguran que estas prácticas se mantengan durante el estrés. Las pruebas aún se consideran como la actividad que sigue al desarrollo. Los planes de prueba se desarrollan e implementan, con la ayuda de los cuales determinan claramente qué tipo de prueba es necesaria, cuándo y por quién.
El objetivo principal es asegurarse de que el producto cumpla con los requisitos especificados.
Como resultado:
- existen los principales tipos y tipos de pruebas (integración, modular, regresión, aceptación);
- planes de prueba implementados;
- las actividades de prueba son monitoreadas y controladas;
- El proceso está documentado y puede repetirse.
Tercer nivel - "Definido"En el tercer nivel, las pruebas ya no se consideran actividades después de la programación. Las pruebas están completamente integradas en el proyecto. La planificación de la prueba se lleva a cabo en etapas anteriores y se fija en el plan maestro. Se están introduciendo pruebas no funcionales (por ejemplo, usabilidad).
Como resultado:
- la prueba comienza con la fase de requisitos;
- se agregan actividades que le permiten trabajar de manera más eficiente (capacitaciones internas, revisiones adicionales);
- Se están introduciendo pruebas no funcionales.
Cuarto Nivel - "Medible"En el cuarto nivel, las pruebas son un proceso bien definido, bien establecido y medible. Las pruebas se perciben como una evaluación y consisten en todas las operaciones del ciclo de vida de desarrollo de software. Se está introduciendo la práctica de medir la calidad de las pruebas. Estas medidas se utilizan para predecir el rendimiento y el costo de las pruebas.
Como resultado:
- prueba como un proceso medible;
- las mediciones se usan para pronosticar;
- El equipo está buscando formas de hacer que el proceso de prueba sea más eficiente.
Quinto nivel - "Innovador"En el quinto nivel, todos los enfoques y procesos están bien establecidos. El equipo no se detiene en esta etapa, sino que continúa mejorando sistemáticamente los procesos, tratando constantemente de reducir el tiempo del ciclo de prueba y el tiempo de comercialización sin comprometer la calidad del proyecto. Las pruebas se centran en la prevención. Se agrega automatización para un uso más eficiente de los recursos.
Como resultado:
- mejora continua del proceso;
- centrarse en la prevención y la optimización.
Cómo ayuda el conocimiento de esta estructura
Caso No. 1. Pruebas injustasUna vez llegué a un pequeño proyecto donde las pruebas fueron realizadas por un cliente, sus amigos o un gato. Después de evaluar la situación y observar el modelo, podemos entender que estamos en el nivel 1 y que debemos centrarnos en el nivel 2 durante la planificación de la actividad. Después de ordenar a Jira, donde había una gran cantidad de errores (la mayoría de los cuales eran duplicados o no reproducibles), comencé a compilar la documentación de la prueba en forma de listas de verificación y a organizar los procesos básicos de prueba. Tales como pruebas de regresión y controles de cordura durante cambios importantes.
Caso No. 2. Sin pruebaEn mi opinión, los proyectos de este tipo pueden ser en tres casos:
- el proyecto recién comienza;
- no había necesidad de un probador en el proyecto mientras había poca funcionalidad;
- El equipo completo cerró la falta de probadores con revisión de código de calidad y pruebas de desarrollo.
Una vez en cualquiera de estos proyectos, a menudo puede ver el beneficio del hecho de que está en un nivel secreto de cero. Podemos saltar sobre el primer nivel e inmediatamente hacer todo cualitativamente con un buen sentido, sentimiento, disposición, guiados por los objetivos del segundo. A menudo podemos implementar planes de prueba, sobre la base de los cuales se realizarán todos los tipos de prueba necesarios. Puede identificar inmediatamente el mismo flujo de trabajo con el equipo de desarrollo, que falta en los proyectos del primer caso.
Caso No. 3. La prueba fueEn verdad, el caso más raro: un hombre, debido a ciertos eventos, decidió cambiar su equipo / departamento / trabajo y le da sus propias ideas. En esta situación, ya tiene un sistema establecido de interacción con los desarrolladores, una cierta base de documentación de prueba. Las rutas de desarrollo adicionales pueden incluir mejorar el proceso establecido o pasar al tercer nivel: introducir pruebas en etapas anteriores o agregar pruebas no funcionales.
Caso número 4. Tres en unoCuando llegué a mi proyecto en Provectus, me enfrenté a una situación en la que solo había un poco de los tres casos descritos anteriormente. Como en el caso número 1, lo primero que debía hacer era poner a Jira en orden. Como en el segundo caso, se decidió hacer todo de inmediato con alta calidad para guiarse inmediatamente por el segundo nivel. Por lo tanto, inmediatamente comencé a desarrollar documentación de prueba e implementar herramientas de administración de prueba. También intenté exprimir al máximo los artefactos de las iteraciones pasadas, como fue el caso en el tercer caso.
Después de un tiempo muy corto, puedo decir con seguridad que ya estamos yendo deliberadamente al tercer nivel, incluso las pruebas conectadas en la etapa de requisitos comerciales :)
Conclusiones
En mi experiencia, la mayoría de los proyectos ucranianos, así como los proyectos que no están diseñados durante mucho tiempo, se pueden poner en marcha con éxito en el nivel 3. Pero si tiene un proyecto a largo plazo, las posibilidades de mejorarlo son infinitas y puede guiarse con seguridad por los logros de los niveles más altos.
En conclusión, me gustaría decir que el propósito de este artículo fue mostrar no tanto cómo trabajar con el clásico MM o TMM en sí, sino que con su ayuda puede comprender claramente en qué etapa del proyecto está involucrado, y qué movimientos tomar y cuáles no valen la pena. Además, tomando sus principios como base, puede crear su propio modelo, que puede aplicarse no solo en el desarrollo, sino también en diversas áreas de la vida. Y lo más importante: está probado y funciona :)