Testing - Marco teorico Jira - QA en Jira
- 2. A la hora de planificar y ejecutar pruebas de software es recomendable tener un marco conceptual y un conjunto de principios. A continuación un ejemplo de principios solo para ejemplificar. No existe ingeniería ni calidad de software sin pruebas. Las pruebas demuestran la presencia de defectos, no su ausencia. No se pueden hacer pruebas exhaustivas. Se busca hacer foco en un 20% del código que abarque el 80% de defectos. Buscar variabilidad de pruebas. Las pruebas dependen del contexto. Siempre habrá errores.
- 3. Pruebas de Software 3 Service Producer (Microservice, ...) Service Consumer (App frontend, ...) API Integration Test Unit Test Integration Test Unit Test Contract Test UI Tester System Test Functional Test Functional Test Non-Functional Test Non-Functional Test Acceptance Test User UAT alpha UAT beta Integration Test Exploratory Test Exploratory Test UAT QAT E2E testing Regression testing Smoke testing UI test Existen diferentes tipos de prueba:
- 4. Testing continuo 4 Software Service API Repository Data base UI Component State API Client UI Screen UI Screen UI Screen Unit test Unit test Unit test Unit test Unit test Contract Contract test Contract test E2E test UI test Integration test Integration test Functional test Service API Repository Data base UI Component State API Client Integration test flow flow Cada tipo tiene su alcance: Performance test Performance test
- 5. Quienes prueban 5 Tester Acceptance Test User Acceptance Test User Team Organization/Habilitador Market Software Test En los equipos ágiles, el testing es una práctica que hacen todos los miembros del equipo. Luego para las pruebas de aceptación, participan miembros de la organización y los usuarios reales del producto/servicio. También habilitador especializado en testing. QA SME *SME: Subject-Matter Expert En algunos equipos puede haber algún rol especializado (ya sea interno del equipo o como SME) como QA-Automation, Tester, QA- Engineer, etc. QA Team
- 6. Ambientes de prueba 6 El testing para el aseguramiento de calidad se hace en varios ambientes. Mientras más testing hagamos en los ambientes pre-productivos menos defectos hallaremos en producción. Development QA | UAT Pre-Prod | Staging Production Testing Testing Testing Testing QA Un ambiente refiere a hardware y software donde se ejecuta una aplicación. Dependiendo del proceso de desarrollo la cantidad de ambientes por los cuales iremos propagando una aplicación desde desarrollo hasta producción. Cada ambiente tiene su propia base de datos y su copia de los binarios de la aplicación de forma que no haya interferencias en los ambientes y entre los diferentes participantes en la construcción del software.
- 7. Testing continuo 7 Unit Test Code Inspection Integration Test * Performance Test Functional /E2E Test Acceptance (UAT PO) QAT UAT alpha UAT beta UAT alpha Dev QA Staging Production Test Plan Test Plan Test Plan Performance (& Resilience) Test Performance (& Resilience) Test Performance (& Resilience) Test
- 8. Estrategia ágil de Pruebas 8 Cycle test plan QA Cycle test plan Tester Release QA PROD QA Cycle test plan Tester QA Cycle test plan Tester QA Cycle test plan Tester QA QA El equipo ágil debe desarrollar una estrategia de prueba iterativa e incremental alineada a la estrategia de salida al mercado.
- 9. Testing continuo en ciclo de vide de un producto 9 UAT UAT UAT QAT QAT QAT QAT Deliverable: MVP Deliverable: Other Deliverable MVP MMF
- 10. Flujo de pruebas 10 TEST PLAN Lista de Test-cases Estrategia de plan Plan de calidad Sprint Plan TODO IN PROGRESS DONE Ejecución de TEST CASES Datos de prueba Configuración de entornos Relevamiento de información Plan ejecutado: Results Report Bugs / Defects El testing debe ser planificado (principalmente el testing manual). Y por lo general incluye un conjunto de casos de test o escenarios a ser probados. El flujo de un plan de pruebas como de sus test cases debe definirse según el proceso de trabajo.
- 11. EstrategiAS Estrategia 1: Un plan de pruebas Estrategia 2: Historias de usuario con sus pruebas Podemos tener varias estrategias para hacer pruebas
- 12. Planes de prueba Plan de Prueba Escenario de Prueba Tiene uno o varios Tiene uno o varios Acciones/pasos Resultado esperado Resultado real Precondiciones Datos de prueba Caso de Prueba El plan de pruebas tiene como objetivo orientar el esfuerzo de pruebas, identificando y detallando las pruebas más importantes. Nosotros podemos ver, de forma práctica, el plan de pruebas como un conjunto de casos de prueba para uno o varios escenarios posibles.
- 13. Plan de Prueba: ejemplo Escenario Test Case
- 14. 14 Ciclo de vida de un plan de pruebas Software Testing Life Cycle - STLC
- 15. 15 Estrategia 1: Plan de Pruebas Sprint 2 - 4 Weeks Potentially Shippable Product Increment Product Backlog Sprint Backlog Roles Events Artifacts Team Kanban DOR DOD Burndown-chart daily Velocity Test Plan: Test case Test case Test case …. Un plan de prueba es un conjunto de casos de prueba a ejecutarse en un sprint o iteración en uno o más ciclos de ejecución. Un equipo Scrum planifica sus ‘planes de prueba’ en las plannings para ser ejecutados en sus Sprints Los casos de prueba validan los criterios de aceptación de las historias por medio de escenarios o representan escenarios específicos de prueba.
- 16. 16 ejecución de casos de prueba Resultado Esperado Resultado Obtenido failed pass Bug ? TEST IN PROGRESS TEST CYCLE PLAN Oráculo Oráculo: ● User Story ● Flows ● Wireframe ● Prototype ● etc... Environment Test-case Dado <Precondiciones> Cuando <Pasos> Entonces <Resultado esperado>
- 17. 17 UNEXECUTED TEST IN PROGRESS PASS FAIL RETEST Bug 01 Bug 02 Story 0023 Story 0026 relates to relates to causes causes Subtasks Cycle number: 1 Cycle number: 2 Ticket en Jira Ticket en Jira Ticket en Jira Ticket en Jira Link en Jira Link en Jira Estrategia 1: Ciclo ejecución de casos de prueba
- 18. 18 Estrategia 2: casos de prueba x Historia Sprint 2 - 4 Weeks Potentially Shippable Product Increment Product Backlog Sprint Backlog Roles Events Artifacts Team Kanban DOR DOD Un equipo Scrum planifica sus historias de usuario incluyendo sus pruebas como casos de prueba. Burndown-chart daily Velocity User Story: Test case Test case Test case …. Una historia de usuario puede tener asociada subtareas de tipo casos de prueba (Test Case). Los casos de prueba validan los criterios de aceptación de la historia.
- 19. 19 Estrategia 2: casos de prueba x Historia UNEXECUTED TEST IN PROGRESS PASS FAILED RETEST Bug 02 Story 0023 Story 0026 causes causes Subtasks Cycle number: 1 Ticket en Jira Link en Jira Story 20 Bug 01 causes Subtasks Subtasks