Si tuviera que comenzar un proceso de prueba en una empresa, ¿dónde comenzaría?

TL; Versión DR:

Examine lo que está en su lugar ahora. Tomar con calma. Trabaja un área a la vez. Cree confianza en su plan permitiendo que las personas lo vean funcionando. Esperar resistencia. La automatización no es mágica.

Cuando acabes. Empezar de nuevo. Las mejoras continuas son críticas.

• Tengo 24 años, ¿puedo especializarme en negocios y seguir trabajando con TI?
• Startups: ¿Cómo puedo ir a Silicon Valley desde India para una startup?
• ¿Es una buena idea que una startup renuncie a un fundador técnico y contrate a un equipo externo? ¿Especialmente el que estuvo a su lado durante 7 meses y sacrificó casi todas las oportunidades por solo una participación del 5% y una pequeña paga?
• ¿Qué necesito antes de comenzar una startup?
• ¿Cuáles son algunos de los mejores libros para emprendedores en estas categorías?

Versión completa:

Por donde empiezas Primero hablemos de algunos supuestos. No lo menciona, pero supongo que están entregando código y arreglando errores que sus clientes mencionan. Incluso pueden estar agregando características y entregando nuevas versiones.

Comience mirando sus procesos existentes. Tienen que tenerlos. ¿Cómo saben qué características agregar? ¿Cómo solucionan los problemas que vienen de los clientes?

* La clave para poner en orden esta tienda serán los cambios ‘pequeños’ incrementales.

* No puedes resolver esto de la noche a la mañana. Va a ser trabajo. Entonces, piensa en los resultados finales para cada área que desea impactar y comienza con pequeños pasos que conducen hacia la meta.

Cada paso en el camino será TONELADAS de trabajo extra para USTED. Una vez que está funcionando, puede comenzar a mostrar el valor de la pequeña cantidad de trabajo adicional que otros tienen que hacer para reducir una gran cantidad de trabajo adicional que están haciendo actualmente.

1. Seguimiento de problemas : tienen que tener alguna forma de obtener comentarios sobre cuándo los sistemas fallan en un cliente. (correo electrónico, llamada telefónica?)
1. Comience a trabajar en una adición liviana como Bugzilla o Jira. Una ubicación centralizada para almacenar los problemas entrantes.
2. Deberá comenzar a realizar el trabajo adicional para comenzar a compilar los problemas a medida que se presentan. Obtenga actualizaciones sobre su progreso a medida que se van trabajando.
3. Finalmente, capacite a las personas para que usen el sistema y les muestre formas en que puede ahorrarles trabajo. (Problemas perdidos en el correo electrónico debido a vacaciones, o porque están sobrecargados, o múltiples hilos de correo electrónico para un solo problema).
2. Pruebas de regresión : esto es más desafiante. Sin embargo, si ha trabajado diligentemente para implementar el Seguimiento de problemas y ha comenzado a que no solo los desarrolladores lo usen, sino también a sus clientes. Ahora está comenzando a acumular un conjunto de fallas de software, errores, problemas y muchas fallas de conocimiento del usuario.
1. Revisar estos es el trabajo adicional que tiene para la parte 2. Debe comenzar a organizar los problemas que se están encontrando y cuándo, clasificarlos, clasificarlos en grupos. Es hora de comenzar a encontrar los patrones de los errores. Estos patrones le dicen cosas sobre la naturaleza rigurosa de la unidad, la integración y las pruebas funcionales que se están realizando.
2. Usando el conocimiento adquirido durante el paso anterior, comenzará a identificar las áreas ‘problemáticas’ de su software, sistemas y personas.
3. Tome las áreas que son más problemáticas, generan la mayor cantidad de reelaboración o la visibilidad más negativa con la base de clientes. Expanda las pruebas que cubren estas áreas. Divida la prueba en partes cada vez más pequeñas hasta que prueben las secciones de componentes más pequeñas y aún así proporcionen valor. Estas pruebas se convierten en el núcleo de su conjunto de regresión.
4. Si recibe una notificación anticipada de la nueva funcionalidad, genere un conjunto completo de pruebas para ella, pero las primeras pruebas deberían ser las ‘pruebas de humo’. Conéctelo. ¿Chispea y humea? La idea es ejecutar algunas de las funciones básicas con los valores buenos más básicos conocidos. Estos proporcionan una garantía de que la nueva función está funcionando como se esperaba. Agregue estos al conjunto de regresión central cuando la nueva función se agregue a la base.
5. La parte más larga y compleja de este paso es encontrar el tiempo para volver sobre el producto central y encontrar áreas que hayan estado funcionando de manera tan sólida que no tenga errores ni pruebas. Expandiendo la suite de Regresión con pruebas que cubren estas áreas.
3. Pruebas unitarias : esencialmente, este es un problema del desarrollador. Puedes hablar con ellos todo lo que quieras, pero llevarlos a la “Prueba de Unidad” no será fácil. Los desarrolladores y el control de calidad no “piensan” en las cosas de la misma manera. Los desarrolladores están bajo presión para ‘hacerlo funcionar’. Están profundamente inmersos en el código y han concentrado sus pensamientos en el código con demasiada fuerza para pensar fuera de él y encontrar las ingeniosas formas en que los usuarios lo descifrarán.
1. Lo mejor que puede hacer es compartir con los desarrolladores los tipos de problemas que se encontraron durante la creación de la suite de regresión, así como los errores que se encontraron durante el lanzamiento inicial de la producción.
2. A veces, incluso podrá obtener una idea del nivel de calidad y las áreas de debilidad para desarrolladores específicos. (Nunca he encontrado la forma ‘correcta’ de contarles estas debilidades que no los dejaron enojados y a la defensiva. Desea trabajar juntos para una mejor solución. Quizás tenga una mejor manera con las personas y pueda resolverlo). Para mí, la solución era simplemente probar aquellas áreas que sabía que iban a fallar para un desarrollador en particular Inmediatamente cuando entregaron el código para probar. Dejándolo caer sobre ellos con una lista rápida de fallas. Con suerte, comenzarán a ver los mismos tipos de fallas que se informan y trabajarán para asegurarse de que esas áreas estén cubiertas antes de que devuelvan el código por tercera o cuarta vez. Eventualmente, esto será parte del hábito que desarrollan para sus pruebas unitarias.
3. Además, proporcionar un plan de prueba de prueba y un desglose de escenario para lo que probará en las nuevas versiones al comienzo del ciclo puede ayudar a los desarrolladores a pensar sobre el tipo de prueba unitaria que deberían estar haciendo para evitar el retroceso inmediato. Algunas personas querían evitar este paso. ‘Guardar el secreto’ de dónde buscarán. No se sienta tentado a seguir de esta manera. Hágales saber dónde está hurgando. Permítales resolver los problemas antes de que entre en Control de calidad. Esto a menudo hará que los problemas de prueba de unidad más simples se resuelvan temprano y les dará a los evaluadores aún más tiempo para profundizar en las áreas más complejas con más detalle. Aquí es donde se esconden los errores reales.
4. Automatización : he encontrado que los gerentes piensan que esto es una especie de bala de plata. Una solución mágica para evitar la necesidad de un equipo de prueba. Su valor real es que permite que las pruebas serviles, mundanas y redundantes se transfieran a un sistema y deja que los evaluadores trabajen en la Nueva Funcionalidad de una versión y en las áreas del código que no se han probado que podrían interactuar con el nuevas funciones
1. El trabajo de base que establezca en el trabajo 1 y 2 y 3 comenzará en esta etapa a dar sus frutos. Desea comenzar de a poco con el conjunto de automatización que requerirá la menor cantidad de mantenimiento.
2. La Suite de regresión son las pruebas que se ejecutarán con mayor frecuencia. (Cada versión). La Suite de regresión será el conjunto más estable de casos de prueba. (La funcionalidad existente generalmente sigue siendo la misma entre las versiones). La Suite de regresión también debería dividirse en los casos de prueba más pequeños posibles y ejercer la unidad más pequeña de funcionalidad e integración.
3. Comience a automatizar la suite de regresión y, después de cada lanzamiento, también se deben agregar las pruebas de humo para la nueva funcionalidad.
4. Si tiene un conjunto de pruebas que no forman parte de la funcionalidad principal, pero son áreas en las que encuentra problemas al principio del ciclo de prueba. Intente agregarlos a la suite de automatización.
5. Integración / entrega continua : esto para mí es como pruebas unitarias, más relacionadas con el lado de los desarrolladores.
1. La información que ha estado recopilando durante todo el proceso debería permitirle proporcionar la información necesaria sobre el personal de desarrollo existente y el ciclo para ayudarlos a ver un beneficio al implementar esta solución para ayudarlos a mejorar su eficiencia.
2. Todo el trabajo anterior debería haber dado al equipo de prueba la capacidad de encontrar eficiencias en su flujo de trabajo para permitirles involucrarse mucho antes en el ciclo: recopilación de requisitos, revisiones de diseño, etc.
3. La forma de ayudar a guiar esto sería ayudar a desarrollar un flujo más eficiente que permitiría a los desarrolladores volver a lo que hacen mejor. Desarrollo del sistema y la próxima característica. En lugar de “perder el tiempo” solucionando todos los problemas que el Control de Calidad sigue encontrando.

Si llegaste hasta aquí, felicidades . No has terminado.

Comience en la parte superior y comience a trabajar en todo, nuevamente.

El objetivo cada vez que reinicia es encontrar la siguiente capa de complejidad que está causando la mayor cantidad de dolor. Encuentre formas de aislarlos y controlarlos y, finalmente, incorporarlos a los conjuntos de pruebas existentes y, en última instancia, a las pruebas automatizadas.