Aquí hay un poco sobre la cultura de prueba en Knewton del ingeniero de control de calidad de larga data, Rob Schultheis:
Aquí hay un extracto. Lea el artículo completo aquí donde encontrará otros artículos técnicos de formato largo de nuestros ingenieros: El blog de tecnología de Knewton
Probar la plataforma
La plataforma Knewton está compuesta por muchos servicios componentes. Cada uno de esos servicios es desarrollado por un equipo dedicado, y cada servicio se prueba por sí solo con la unidad estándar, la integración y las pruebas de rendimiento. Este artículo no trata realmente de esas pruebas, sino de cómo probamos la plataforma en su conjunto.
La plataforma Knewton utiliza datos para personalizar continuamente la entrega de contenido de aprendizaje en línea para estudiantes individuales. La plataforma determina las competencias de los estudiantes en niveles extremadamente detallados, proporciona recomendaciones de actividades y genera análisis. Para hacer todo esto, nuestra plataforma debe ser rápida, escalable y confiable. Nuestro equipo debe ser hábil para lidiar con problemas técnicos complejos, mientras mantiene una perspectiva de alto nivel y se enfoca en el sistema más amplio. Las pruebas son parte de cómo mantenemos esta doble perspectiva.
Accesibilidad
La accesibilidad es el criterio más importante que incorporamos en nuestras pruebas para ayudarnos a lograr los objetivos anteriores.
En el contexto de un conjunto de pruebas de pila completa, la accesibilidad para mí significa al menos lo siguiente:
– Cualquiera puede ejecutar las pruebas
– Cualquiera puede leer el informe de prueba y analizar las fallas de prueba
– Cualquiera puede leer, cambiar, ampliar o interactuar con las definiciones de prueba
Hacer accesibles las pruebas y promover esas pruebas accesibles puede ser un desafío cultural difícil, así como un desafío técnico difícil. Pero el costo de fallar en esto es alto. Cuanto más aislado esté su conjunto de pruebas (y los ingenieros que lo crean y ejecutan), menos valor obtendrá de él. Sus pruebas no reflejarán la participación de la organización más grande y, lo que es más importante, la información que generen sus pruebas no se difundirá tan ampliamente en toda la organización como podría ser.
Entonces, ¿cómo se hace “accesible” un conjunto de pruebas?
Cualquiera puede ejecutar las pruebas
Lo mejor que puede hacer con un conjunto de pruebas es hacerlo funcionar en su servidor de integración continua. En Knewton usamos Jenkins como nuestro servidor CI. Cualquier persona de nuestra organización puede usar Jenkins para invocar las pruebas en cualquier entorno de prueba, en cualquier momento, sin ninguna configuración especial en su computadora.
Además, el código de prueba está en nuestro repositorio de Git, y se alienta a todos a revisarlo e invocar las pruebas de manera muy flexible. Los desarrolladores tienen la opción de ejecutar una sola prueba, un conjunto de pruebas relacionadas, pruebas que se correlacionan con un ticket JIRA determinado u otras opciones. Los desarrolladores pueden ejecutar las pruebas en un entorno de desarrollo local o en un entorno implementado. Un conjunto de pruebas que se puede ejecutar de manera flexible es una parte importante de la accesibilidad.
Cualquiera puede leer el informe de prueba
Nuestro conjunto de pruebas produce varios tipos de informes de prueba. El informe que más disfruto mostrando es el informe HTML, que enumera cada prueba que se ejecuta y detalla cada prueba que falla (esta capacidad está integrada en el maravilloso marco de prueba RSpec que usamos). Este informe HTML se archiva en Jenkins con cada ejecución de prueba, por lo que cualquiera puede leerlo para cualquier ejecución de prueba directamente en su navegador. Y debido a que el informe usa un inglés simple, es comprensible para cualquiera que esté familiarizado con las características de nuestra plataforma, desarrolladores o no … “.