Modelo de exemplo de estratexia de proba áxil
Estratexia de proba áxil
Nun ambiente áxil, onde traballamos en sprints curtos ou iteracións, cada sprint céntrase só nalgúns requisitos ou historias dos usuarios, polo que é natural que a documentación poida non ser tan extensa, tanto en número como en contido.
O obxectivo do documento de estratexia de proba áxil é enumerar as mellores prácticas e algunha forma de estrutura que poden seguir os equipos. Lembre, áxil non significa desestruturado.
Aquí botamos unha ollada a unha estratexia de proba áxil de mostra e que incluír no documento.
Unha estratexia de proba normalmente ten unha declaración de misión que podería estar relacionada cos obxectivos e obxectivos comerciais máis amplos.
Unha declaración de misión típica podería ser:
Ofrecer constantemente un software de traballo que cumpra os requisitos do cliente _ mediante _fornimentación de comentarios rápidos _e _prevención de defectos, en lugar de detección de defectos.
Apoiado por:
- Non se pode escribir ningún código para unha historia ata que primeiro definamos os seus criterios / probas de aceptación
- Non se pode considerar unha historia completa ata que pasen todas as probas de aceptación
No documento de Estratexia de proba áxil, tamén incluiría un recordatorio para todos sobre a garantía de calidade
A QA é un conxunto de actividades destinadas a garantir que os produtos satisfagan as necesidades dos clientes dun xeito sistemático e fiable.
En SCRUM (áxil) o control de calidade é responsabilidade de todos, non só dos probadores. O control de calidade é todas as actividades que facemos para garantir a calidade correcta durante o desenvolvemento de novos produtos.
Niveis de proba
Probas unitarias
POR QUE: Para garantir que o código se desenvolve correctamente
OMS: Desenvolvedores / Arquitectos técnicos
QUE: Todo o novo código + recapacitación do código herdado, así como a proba unitaria de Javascript
CANDO: En canto se escribe un novo código
ONDE: Local Dev + CI (parte da compilación)
COMO: Automatizado, Junit, TestNG, PHPUnit
Probas API / servizo
POR QUE: Para garantir que a comunicación entre os compoñentes funciona
OMS: Desenvolvedores / Arquitectos técnicos
QUE: Novos servizos web, compoñentes, controladores, etc.
CANDO: En canto se desenvolva e estea lista a nova API
ONDE: Local Dev + CI (parte da compilación)
COMO: Automatizado, Xabón UI, Cliente de descanso
Probas de aceptación
POR QUE: Para garantir que se cumpren as expectativas do cliente
OMS: Programador / SDET / Manual QA
QUE: Verificación de probas de aceptación das historias, verificación de funcións
CANDO: Cando a función estea lista e se probe a unidade
ONDE: CI / Entorno de proba
COMO: Automatizado (pepino)
Probas do sistema / Probas de regresión / UAT
POR QUE: Para garantir que todo o sistema funciona cando está integrado
OMS: SDET / Manual QA / Analista empresarial / Propietario de produto
QUE: Probas de escenarios, fluxos de usuarios e viaxes de usuario típicas, probas de rendemento e seguridade
CANDO: Cando finalice a proba de aceptación
ONDE: Ambiente de posta en escena
COMO: Probas exploratorias automatizadas (Webdriver)
Atraso de produtos
A causa máis común de fallo no desenvolvemento de software débese a requirimentos pouco claros e a diferente interpretación dos requirimentos por parte dos diferentes membros do equipo.
As historias dos usuarios deben ser sinxelas, concisas e inequívocas. Como boa pauta, o mellor é seguir o modelo INVEST para escribir historias de usuarios.
Unha boa historia de usuario debería ser:
Eu ndependente (de todos os demais)
N egoísta (non é un contrato específico para funcións)
V aluable (ou vertical )
É estimulable (cunha boa aproximación)
S centro comercial (para encaixar dentro dunha iteración)
T estable (en principio, aínda que aínda non haxa proba)
O seguinte formato debería usarse para escribir historias de usuarios
As a [role] I want [feature] So that [benefit] É importante non esquecer a parte 'Beneficio', xa que todos deben ser conscientes de que valor engaden ao desenvolver a historia.
Criterios de aceptación
Cada unha das historias do usuario debe conter criterios de aceptación. Este é posiblemente o elemento máis importante que fomenta a comunicación con diferentes membros do equipo.
Os criterios de aceptación deben escribirse ao mesmo tempo que se crea a historia do usuario e deben inserirse no corpo da historia. Todos os criterios de aceptación deben ser comprobables.
Cada criterio de aceptación debe ter unha serie de probas de aceptación presentadas como escenarios escritos en formato Gherkin, por exemplo.
Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]... Obradoiros de historias / Planificación Sprint
En cada taller de historias, todos os membros do equipo aprenden sobre os detalles das historias para que os desenvolvedores e QA coñezan o alcance do traballo. Todo o mundo debería ter a mesma comprensión de que trata a historia.
Os desenvolvedores deben ter unha boa comprensión dos detalles técnicos que se implican na entrega da historia e o control de calidade debe saber como se probará a historia e se hai algún impedimento para probar as historias.
Prevención de defectos
Nos talleres de contos, Deben estar implicados PO, BA, Dev e QA.
Deberíase pensar nos escenarios (casos válidos, inválidos e límites) (o QA pode engadir un enorme valor aquí pensando abstractamente na historia) e anotarse en ficheiros de funcións.
É importante ter en conta que son os escenarios (máis que calquera outra cousa) os que revelen defectos ao probar o produto, polo que canto máis esforzo e tempo dedicado a esta actividade, os mellores resultados ao final.
Debido a que a maioría dos defectos débense a requirimentos pouco claros e vagos, esta actividade tamén axudará a evitar a implementación dun comportamento incorrecto xa que todos deberían ter a mesma comprensión da historia.
Do mesmo xeito, nas reunións de planificación sprint, as estimacións dadas para unha historia deben incluír tamén o esforzo de proba e non só o de codificación. Tamén debe estar presente o control de calidade (manual e automatización) nas reunións de planificación sprint para proporcionar unha estimación para probar a historia.
Desenvolvemento
Cando se inicia o desenvolvemento, o novo código de produción e / ou a modificación do código herdado deberían estar respaldados por probas unitarias escritas por desenvolvedores e revisado por pares por outro desenvolvedor ou un SDET cualificado.
Calquera compromiso co repositorio de código debería desencadear a execución das probas unitarias desde o servidor CI. Isto proporciona un mecanismo de retroalimentación rápido ao equipo de desenvolvemento.
As probas unitarias aseguran que o sistema funciona a nivel técnico e que non hai erros na lóxica.
Probas de programador
Como desenvolvedor, compórtate coma se non tiveses ningún control de calidade no equipo ou organización. É certo que os control de calidade teñen unha mentalidade diferente, pero debes probar o mellor posible.
Pensas que estás a aforrar tempo ao pasar rapidamente á seguinte historia, pero en realidade, cando se atopa e informa dun defecto, leva máis tempo corrixir o problema que pasar uns minutos asegurándose de que a función funciona ben.
Calquera novo código e / ou refactorización do código herdado debería ter probas unitarias axeitadas que formarán parte da proba de regresión unitaria.
Probas de aceptación automatizadas e probas non funcionais
As probas de aceptación automatizadas inclúen probas de integración e probas de servizo e probas de interface de usuario que teñen como obxectivo demostrar que o software funciona a un nivel funcional e que cumpre cos requisitos e especificacións do usuario.
As probas de aceptación automatizadas adoitan escribirse en linguaxe Gherkin e executarse empregando unha ferramenta BDD como o pepino.
Lembre : Non é preciso automatizar todas as probas.
Debido a que estas probas normalmente requiren comunicación por HTTP, deben executarse nunha aplicación despregada en lugar de executarse como parte da compilación.
Probas non funcionais como as probas de rendemento e seguridade son tan importantes como as probas funcionais, polo que hai que executalas en cada implementación.
As probas de rendemento deben comprobar as métricas de rendemento en cada implementación para garantir que non se degraden o rendemento.
As probas de seguridade deben comprobar as vulnerabilidades básicas de seguridade derivadas de OWASP
É vital que este sexa un proceso completamente automatizado con moi pouco mantemento para sacar o máximo proveito das implementacións automatizadas. Isto significa que non debería haber fallos de proba intermitentes, problemas de guión de proba e ambiente roto.
Os fallos só deberían deberse a defectos de código xenuíno en lugar de problemas de script, polo tanto, calquera proba de fallo que non se deba a fallos xenuínos debería solucionarse inmediatamente ou eliminarse do paquete de automatización, para poder obter resultados consistentes.
Probas de regresión
Non esperaba atopar moitos defectos. O seu propósito é só proporcionar comentarios sobre os que non rompemos as principais funcións. Debería haber unha cantidade moi pequena de probas de regresión manual.
Paquete de fume: non debe pasar máis de 15 minutos
Este paquete só contén funcionalidades de alto nivel para asegurarse de que a aplicación é o suficientemente estable como para un desenvolvemento ou probas posteriores.
Por exemplo, para un sitio web de comercio electrónico, as probas incluídas neste paquete poden ser:
- Busca de produtos,
- Revisión do produto
- Artigo de compra
- Creación de conta / Inicio de sesión de conta
Paquete de regresión completo: non debería exceder 1 hora
Este paquete contén o conxunto completo de probas de regresión e contén todo o que non está incluído no paquete de fume.
Aquí, o obxectivo é obter unha retroalimentación rápida cun maior conxunto de probas. Se os comentarios tardan máis de 1 hora, non son rápidos. Reduce o número de probas usando a técnica de proba por parellas, crea paquetes de probas en función do risco ou realiza as probas en paralelo.
UAT e probas exploratorias
Non hai ningunha razón pola que a UAT e as probas exploratorias non poidan executarse en paralelo coas probas de aceptación automatizadas. Ao final, son actividades diferentes e teñen como obxectivo atopar diferentes problemas. O obxectivo de UAT é garantir que as funcións desenvolvidas teñan sentido empresarial e sexan útiles para os clientes.
O PO (propietario do produto) debería realizar probas de aceptación do usuario ou as probas de aceptación empresarial para confirmar que o produto construído é o que se esperaba e que cumpre as expectativas do usuario.
As probas exploratorias deberían centrarse nos escenarios dos usuarios e atopar erros que a automatización falla. As probas exploratorias non deben atopar erros triviais, senón que deben atopar problemas sutís.
Criterios feitos
Unha vez completadas todas as actividades anteriores e non se atoparon problemas, a historia é Feito!
O anterior son algunhas pautas sobre o que se pode incluír nun documento de estratexia de proba áxil. Obviamente, isto ten que adaptarse ás necesidades da súa organización, pero, con sorte, este modelo axudaríalle a crear o seu propio documento de Estratexia de proba áxil.
