QA best practices
1.0.0
Este es un resumen de las prácticas de QA Futurice usa y recomienda ser utilizado. No se supone que sea una descripción detallada y, a veces, no se puede utilizar completamente de todas las tareas, sino como una descripción general de los procesos de control de calidad más importantes y una lista de buenas prácticas que deben usarse.
Para el propósito de la claridad, este documento no describe un error o proceso de incidente (es decir, se encuentra un nuevo error de la producción).
Todos en el equipo de Futurice tienen responsabilidades de control de calidad, incluso si hay un gerente de control de calidad o especialistas de QA llamados. A Futurice QA significa tres cosas.
En el alto nivel, el trabajo y las prácticas de control de calidad se pueden dividir en dos procesos.
Además, hay otras acciones de control de calidad.
Futurice utiliza métodos TDD y ATDD (desarrollo basado en la prueba de aceptación) cuando corresponde.
El método obliga a la implementación a seguir la arquitectura y considerar módulos que se utilizan. La implementación comienza escribiendo primero la prueba automatizada y luego implementando la funcionalidad para aprobar la prueba.
Futurice utiliza el método de programación de pares cuando corresponde. Esta es una forma muy conveniente de compartir conocimiento y experiencia sobre el proyecto y el software en desarrollo.
Revisar el código ayuda a otros miembros del equipo a obtener información de cierta funcionalidad y brinda la posibilidad de dar retroalimentación a la persona responsable y también garantiza el intercambio de conocimientos entre los miembros del equipo.
La prueba manual se realiza principalmente utilizando la metodología de prueba exploratoria y los errores encontrados se solucionan de inmediato o priorizan y se registran en la herramienta de gestión de tareas/historias/errores. La exploración de la aplicación o servicio se puede iniciar justo después de que algo funcional esté "listo".
Las pruebas exploratorias son una herramienta muy poderosa de prueba de extremo a extremo donde todo el sistema está cubierto por las pruebas. En el método, el probador va más allá de lo que se puede definir en un caso de prueba, aplica el pensamiento similar al usuario, así como intenta romper el sistema mediante varios escenarios de error y nunca se "hacer" con las pruebas.
Alrededor de los requisitos y pruebas funcionales, generalmente hay requisitos no funcionales que se pueden probar aplicando localización, usabilidad, rendimiento y pruebas de carga. Las necesidades y las herramientas son específicos de proyectos. Para pruebas de usabilidad, Futurice tiene un laboratorio de usabilidad móvil para su uso. Para las pruebas de rendimiento, Futurice ha utilizado servicios basados en la web como Browsermob para nombrar uno. Para las pruebas de carga, la carga y el medidor J están activamente en uso para validar las capacidades de servicio en el alto tráfico y encontrar posibles cuellos de botella de servicio.
Los problemas encontrados se registran en una herramienta o placa específica con una información como prioridad, entorno (información de software y dispositivo), pasos para reproducir, resultado esperado, hora y fecha y una captura de pantalla. Herramientas como JIRA, Trello, PivotalTracker, Solicador de solicitud se usan activamente también para el seguimiento de errores.
Uno de los principios de Agile es que la rama del Código Master siempre debe ser potencialmente shippable. Eso significa que debería ser siempre calidad de producción. Esto se logra por los siguientes medios:
Cada historia (o característica) de usuario se desarrolla individualmente en su propia rama de características. El propósito de esto es garantizar que cada actualización a la rama maestra sea al mismo tiempo 1) lo más pequeño posible y 2) una historia completa potencialmente shippable.
Antes de que la rama de características se pueda fusionar con la rama maestra, debe aprobar una lista de acciones, requisitos y prácticas llamada definición de hecho (DOD). Esto se define junto con el PO y el equipo de desarrollo del cliente y se puede modificar durante el proyecto si el proyecto debe cambiar las necesidades.
Los siguientes elementos en el DoD propuesto han sido en negrita debido
El proceso de implementación es un proceso cómo se implementa la nueva versión (o una versión en la rama maestra) en la producción. Para este proceso hay tres entornos relevantes.
El servidor de integración continua (CI) se utiliza para pruebas automatizadas e implementación de código en entornos. Las pruebas automatizadas se ejecutan siempre cuando se actualizan cualquiera de estos entornos.
CI actualiza automáticamente el entorno de prueba, siempre que se haya actualizado la rama maestra. Esto significa que los casos de prueba automatizados también se ejecutan automáticamente cuando se actualiza la rama maestra.
El entorno de prueba es el principal servidor de prueba para Futurice. Se espera que cualquier lanzamiento que se haya probado aquí esté listo para ser empujado a QA o producción (esto depende de la terminología e integraciones utilizadas en el proyecto).
No es necesario ejecutar casos de prueba de regresión manual, al actualizar la prueba. Muy a menudo el tiempo dedicado a las pruebas exploratorias es más beneficioso. Sin embargo, es una buena práctica ejecutar estas pruebas al menos una vez por sprint.
El entorno de QA debe usarse como un entorno para las pruebas de aceptación, demostraciones o cualquier prueba o auditoría de terceros (seguridad, localización, carga, usabilidad, etc.). Este no es el servidor de prueba principal de Futurice (la prueba es). La actualización de QA siempre se acuerda entre los PM del cliente y Futurice.
La razón principal para tener dos entornos de prueba (Test y QA) es cumplir con los requisitos de seguridad e integración. La prueba permite que Futurice desarrolle el servicio utilizando principios ágiles. QA permite tiempo y control para que el cliente ejecute sus procesos de control de calidad actuales.
El control de calidad no debe actualizarse a menos que la versión haya pasado las pruebas en el entorno de prueba.
Prod Environment es el entorno del sitio en vivo (producción).
La buena práctica es implementar y ejecutar pruebas automatizadas en QA al menos, antes de presionar la actualización a ProD. Sin embargo, en la mayor funcionalidad de Prod debe verificarse después de cada implementación.
Se recomienda que el PO también tenga derecho a impulsar una actualización a Prod, sin ninguna prueba en QA (si la versión se pasa en la prueba). Esto es relevante donde la actualización es muy pequeña o simple.
En última instancia, en el desarrollo ágil, cuando el servicio está en desarrollo continuo, el objetivo es tener muchas pequeñas actualizaciones también para producir. Es decir, es más importante que el proceso de implementación sea delgado y rápido que a prueba de balas. Se considera más importante poder hacer correcciones rápidamente que tener un servicio sin errores (obviamente con DoD y pruebas automatizadas, la calidad también debería ser alta). Futurice no recomienda comenzar con este enfoque de inmediato. Sin embargo, esta debería ser la dirección en la que ambas organizaciones quieran ir.
Cada plataforma móvil tiene su SDK específico, conjuntos de herramientas y las mejores prácticas de Futurice.
Para Android https://github.com/futurice/android-best-practices
Para iOS https://github.com/futurice/ios-mood-practices
Para Windows Phone https://github.com/futurice/windows-app-development-best-practices
Las plataformas móviles proporcionan emuladores dentro de su SDK.
Durante la fase de implementación, el desarrollador puede usar dispositivos simulados / emulados para validar los cambios, pero nada puede superar las pruebas de dispositivos reales donde se considera todo el sistema desde la pantalla táctil y la memoria integrada a los procesadores móviles.
Los navegadores móviles también pueden ser probados por servicios basados en la nube como Browserstack.
Futurice tiene una buena variedad de diferentes dispositivos y versiones del sistema operativo en la biblioteca de dispositivos, desde teléfonos básicos hasta tabletas avanzadas.
Para las pruebas de tráfico de datos pesados y la validación de la validación de rendimiento ha estado utilizando Elisa Test Lab (ELISA es un proveedor de servicios móviles finlandeses). Dentro del entorno de laboratorio, se pueden probar diferentes cargas y velocidades en un entorno controlado / aislado sin la necesidad de organizar sesiones costosas y no efectivas de prueba de campo.
Por lo general, la aplicación móvil se conecta a un servicio de backend a través de la red móvil. Para aprovechar al máximo las pruebas, el probador debe tener un control completo del backend donde la aplicación móvil está conectada para prepararse y ejecutar diferentes escenarios de prueba de extremo a extremo.
En los dispositivos móviles, la instalación de compilación de la prueba se puede realizar: localmente por cable utilizando herramientas SDK de desarrollo controladas de forma inalámbrica a través de herramientas de distribución de compilación como TestFlight o HockeyApp. Liberar los marcos generalmente admite la recopilación de registros de bloqueo y los datos de la versión. Las versiones de Dev, Alpha y Beta también se pueden proporcionar para recopilar comentarios antes de liberar la aplicación a las tiendas. Google Play Store tiene la opción de configurar grupos de prueba alfa y beta donde la aplicación específica está disponible solo para los miembros del grupo
En las aplicaciones móviles modernas, el análisis y la recopilación de datos representan una funcionalidad crítica que también necesita pruebas. Futurice considera que esto es una parte importante de las pruebas funcionales.
Debido al hecho de que el proceso de actualización de la aplicación móvil difiere de las aplicaciones web, la configuración de análisis debe ser directamente desde el primer intento o luego se pierden datos valiosos. El proceso de actualización se realiza a través de procedimientos de almacenamiento de aplicaciones, pero si la actualización se realizará o no depende de la configuración y actividad del usuario. Entonces, si la primera versión pierde alguna funcionalidad de análisis crítico y algunos usuarios nunca actualizan la aplicación, se perderán esos datos. La solución puede ser una actualización forzada, donde la aplicación se vuelve inutilizable hasta que el usuario se actualice a la versión más reciente disponible, pero eso podría ser demasiado tarde.
