Criar uma Estratégia de Qualidade

Republicado com a autorização da excelente página de Kristin, thinkingtester.

Na minha última publicação, apresentei o conceito do modelo de maturidade da qualidade: uma série de comportamentos associados a atributos de qualidade que ajudam as equipas a alcançar vários atributos de qualidade no seu software.

É importante salientar que a adoção de um Modelo de Maturidade da Qualidade exige que toda a equipa contribua para a qualidade.

A qualidade não é algo que se deva atirar “para o outro lado do muro” aos testadores; pelo contrário, é um objetivo partilhado por programadores e testadores.

Mas como pode conseguir que toda a equipa assuma a responsabilidade pela qualidade?

Uma forma é criar uma estratégia de qualidade. Este é um documento que toda a equipa aprova em conjunto. Pense nele como um contrato que descreve a forma como o software com qualidade será desenvolvido, testado e lançado pela equipa. 

Aqui, abordarei algumas questões que poderá querer responder na estratégia de qualidade da sua equipa.

Criação e refinamento de histórias

Questão: Como decide a equipa em que histórias trabalhar? 

Pode ser uma decisão de toda a equipa ou apenas do responsável pelo produto. Ou a priorização pode ser feita por alguém externo à equipa.

Questão: Quem refina as histórias para as preparar para o desenvolvimento? 

Pode ser toda a equipa ou um subconjunto da equipa. Idealmente, deverá participar pelo menos o responsável pelo produto, um programador e um testador.

Processo de desenvolvimento

Questão: Como decide a equipa quem trabalha em cada história?

Pode acontecer que os programadores possam escolher qualquer história do quadro, ou que cada programador tenha histórias em áreas funcionais específicas entre as quais pode escolher. 

Em algumas equipas, os testadores de software também trabalham em histórias de desenvolvimento simples, como alterar palavras ou cores numa página Web ou adicionar identificadores de automatização para facilitar a automatização.

Questão: Como é que uma história é considerada “Concluída”? É avaliada com base no cumprimento de todos os critérios de aceitação da história? É necessário que o programador adicione testes unitários antes de a história poder ser considerada concluída? Como sabe que uma funcionalidade está pronta para ser testada? 

Em muitas equipas, espera-se que o programador faça alguns testes iniciais para verificar se aquilo que programou está pronto para testes adicionais.

Transição da funcionalidade

Questão: Como será uma história entregue para testes?

Em algumas equipas, isto é feito simplesmente movendo a história para a coluna “Testes” no quadro de trabalho. Noutras equipas, é exigida uma cerimónia de transição mais formal, na qual o programador demonstra a história funcional e fornece sugestões para testes adicionais.

Questão: Quem implementa o código no ambiente de testes? 

Parece algo trivial, mas pode ser, na realidade, a causa de muitos mal-entendidos e de muito tempo desperdiçado. Se o programador pensar que é responsabilidade do testador implementar o código no ambiente de testes, e o testador presumir que o programador já o fez, o testador poderá começar os testes sem se aperceber de que falta o novo código até ter passado uma quantidade significativa de tempo a trabalhar com a aplicação.

Questão: Quem fará os testes? 

Em algumas equipas, os programadores podem assumir histórias de testes simples para ajudar a melhorar a velocidade de entrega do produto, enquanto as histórias mais complexas ficam a cargo dos especialistas em testes.

Criação do plano de testes

Questão: Quem criará os planos de testes? Como serão criados? Onde serão armazenados os planos de testes? 

Algumas equipas podem preferir realizar testes exploratórios ad hoc com documentação mínima. Outras equipas podem ter sistemas elaborados de gestão de casos de teste que documentam todos os testes do produto. Existem ainda muitas outras opções intermédias. 

Seja qual for a sua escolha, esta deverá ser adequada à sua equipa e ao seu produto.

Questão: Quem escreverá a automatização dos testes?

Em algumas equipas, os programadores escrevem os testes unitários e os testadores escrevem os testes da API e da interface de utilizador. Noutras equipas, os programadores escrevem os testes unitários e da API, e os testadores criam os testes da interface de utilizador. Melhor ainda é fazer com que tanto os programadores como os testadores partilhem a responsabilidade pela criação e manutenção dos testes da API e da interface de utilizador. 

Desta forma, os programadores podem contribuir com os seus conhecimentos especializados em gestão de código, enquanto os testadores contribuem com a sua experiência em saber o que deve ser testado.

Questão: Quem realizará outros tipos de testes, como testes de segurança, desempenho, acessibilidade e experiência do utilizador? 

Algumas empresas maiores podem ter engenheiros dedicados à segurança e ao desempenho que tratam destes testes. As pequenas empresas em fase inicial podem ter apenas uma equipa de desenvolvimento responsável por tudo.

Ferramentas de teste

Pergunta: Que ferramentas serão utilizadas para os testes manuais e automatizados? 

A seleção das ferramentas de teste é muito importante quando se pretende que toda a equipa assuma a responsabilidade pelos testes. É muito provável que os programadores prefiram utilizar ferramentas que recorram à mesma linguagem que utilizam no desenvolvimento, pois isso minimiza a necessidade de alternar entre contextos.

Manutenção dos testes

Pergunta: Quem é responsável pela manutenção dos testes? 

É incrível a rapidez com que a automatização de testes pode ficar desatualizada. A alteração de uma única palavra numa página pode resultar num teste falhado. Idealmente, uma equipa deverá adotar uma política de “quem o avaria, corrige-o”, em que os testes são corrigidos pela pessoa que integrou o código que os fez falhar.

Se isso não for possível, certifique-se pelo menos de que todos os elementos da equipa compreendem como funcionam os testes e como corrigi-los numa situação em que seja necessária uma correção rápida.

Erros e dívida técnica

Pergunta: Como são tratados os erros quando são encontrados durante os testes? São discutidos pelo programador e pelo testador, avaliados por toda a equipa ou registados numa lista de pendências para serem analisados mais tarde?

É frequentemente uma boa ideia corrigir os erros assim que são encontrados, porque o programador já está a trabalhar nessa secção do código.

Pergunta: Como irá a equipa lidar com a dívida técnica?

A equipa tem um acordo para assumir uma determinada quantidade de dívida técnica por sprint? Algumas equipas têm uma política segundo a qual, quando um programador fica sem histórias em que trabalhar, escolhe itens de dívida técnica da lista de pendências.

Lançamentos

Pergunta: Que tipo de testes serão realizados antes de um lançamento? Haverá um plano de testes de regressão que toda a equipa possa executar em conjunto? E quanto aos testes exploratórios?

Uma equipa de elevado desempenho que conheço reúne-se para realizar testes exploratórios imediatamente antes do lançamento. Com esta estratégia, descobriram erros complexos e corrigiram-nos antes de o software ser lançado em produção.

Pergunta: Como será lançado o software?

Em algumas empresas, existe um gestor de lançamentos responsável por executar o lançamento. Noutras empresas, os membros da equipa alternam entre si o lançamento do software. Uma técnica muito útil é a implementação contínua, em que o software é implementado automaticamente e os testes são executados automaticamente para verificar a implementação em cada ambiente, poupando tempo e esforço a todos.

Leitura relacionada: COMO EXECUTAR TESTES DE FUMAÇA DE API NO SEU PIPELINE DE IMPLEMENTAÇÃO CONTÍNUA

Manutenção

Pergunta: Como irá medir o sucesso do lançamento? 

Depois de o software ser lançado, é fácil as equipas de desenvolvimento esquecerem-se dele; no entanto, é nessa altura que os utilizadores começam a trabalhar com ele. Que tipos de métricas poderá utilizar para medir o desempenho do seu produto? Poderá acompanhar os defeitos comunicados pelos clientes ou analisar os registos à procura de erros inesperados.

Pergunta: Como irá monitorizar o estado da sua aplicação?

Seria boa ideia configurar alertas para poder tomar conhecimento dos problemas com a sua aplicação antes dos seus utilizadores. 

Pergunta: Que tipos de comportamentos deverá procurar?

As estratégias de qualidade podem ser tão variadas como os flocos de neve. Imagine as diferenças entre uma pequena empresa emergente com dez pessoas a desenvolver uma aplicação móvel de conversação e uma empresa com vinte mil pessoas a conceber software para fazer aviões voar. Estas duas empresas precisarão de estratégias muito diferentes! 

Pode conceber uma estratégia de qualidade que funcione bem para a sua equipa discutindo estas questões em conjunto e redigindo uma estratégia com a qual todos possam concordar.

Para conhecer ferramentas e tecnologias que podem ajudar nos seus processos, consulte esta lista das 10 MELHORES FERRAMENTAS DE GESTÃO DE DADOS DE TESTE.