Não deixe que a falta de planejamento de testes impacte na qualidade da entrega
A importância do planejamento
Uma atividade essencial no desenvolvimento de todo e qualquer projeto é o planejamento. A falta de organização e entendimento correto do que precisa ser feito leva à grandes dificuldades e nos deixam muitas vezes perdidos e em projetos de software não é diferente.
Planejar não é uma atividade trivial, ela necessita de supervisão, tempo, monitoramento, gerenciamento de mudanças, tudo isso para compreendermos se o que foi planejado inicialmente ainda faz sentido ou necessita ser modificado.
Por que devemos planejar?
De acordo com Leonardo Molinari, “Planejamento de testes é um processo e, como tal, possui entradas e saídas. O plano de testes é a principal saída desse processo e, ao mesmo tempo, artefato de manuseio constante do próprio processo.
A essência do planejamento de teste reside em perceber a real importância do desenvolvimento de planos de testes”.
O autor cita algumas razões que justificam essa importância:
- Preparação: garantir que todos os itens necessários para a execução do planos estejam considerados;
- Comunicação e treinamento: realizar treinamento para quem necessita e reforçar a comunicação efetiva entre as pessoas.
- Eficiência: prover um mecanismo que permita perceber de forma clara a necessidade dos testes e as limitações com as devidas justificativas.
- Prudência legal e bom senso: respeitar as normas e regras de cada empresa, pois muitos testes lidam com regras e leis oficiais e devem ser claramente seguidas.
Riscos do não planejamento
Emerson Rios, em seu livro Análise de Risco em projetos de testes de software define bem o conceito de risco: “Quando falamos em risco, estamos pensando na perda que a empresa pode ter devido à sua ocorrência.” Outra definição, extraída do dicionário Houaiss é bastante clara: “risco é a probabilidade de insucesso, de malogro de determinada coisa, em função de acontecimentos eventuais , incertos, cuja ocorrência não depende exclusivamente da vontade dos interessados.”
Em Engenharia de software, podemos ter dois tipos de risco: risco de produto e risco e projeto. O risco de produto está associado à probabilidade e impacto de algo acontecer em uma aplicação. Já o risco de projeto é algo que pode ocorrer e impactar diretamente ao projeto, como por exemplo a saída de um desenvolvedor do time ou uma alta curva de aprendizado de determinada ferramenta.
Quando os testes de API não são bem planejados, os seguintes riscos podem ocorrer:
- QA pode ficar perdido e confuso sobre o que fazer;
- Não realizar corretamente os testes e não exercer uma cobertura mínima destes;
- Falta de apoio da equipe de QA para os Devs, por desconhecimento dos requisitos;
- Sem métricas teremos dificuldades em medir o esforço adequado para a execução das tarefas;
- Atraso na entrega;
- Bugs de caminho feliz encontrados pelo QA no primeiro teste realizado, por falta de alinhamento entre QA e Dev.
Gabriel Santos define muito bem em seu artigo “Testes Baseados em Riscos” , como definir estratégias de mitigação destas situações através de uma análise mais profunda do problema , levando em consideração a probabilidade e o impacto da funcionalidade sendo testada.
Benefícios de um bom planejamento
Um dos grandes benefícios de um bom planejamento é a assertividade nas ações. Quando se sabe onde se quer chegar, perdemos menos tempo com atividades que não são prioritárias e podemos focar no que realmente importa. Poderíamos citar vários benefícios para o planejamento de testes, mas optamos por nos ater a apenas três, que consideramos bastante relevantes:
Redução de desperdícios
Isso se dá quando nós conhecemos o produto, sabemos aplicar corretamente as estratégias de testes, temos métricas para nos basearmos e conhecimento para definir melhor as estimativas. Desta forma, evitamos o desperdício de tempo nas entregas e conseguimos ser mais assertivos no DoD (Definition of Done).
Antecipação de problemas
Quanto mais conhecermos do produto e o quanto antes participarmos do ciclo de vida do desenvolvimento, maiores são as chances de encontrarmos problemas nas fases iniciais. A regra 10 de Myers nos mostra que o custo da correção de um defeito tende a aumentar quanto mais tarde ele for encontrado. Os defeitos encontrados nas fases iniciais do projeto de desenvolvimento do software são mais baratos do que aqueles encontrados na etapa de produção.
Maior alinhamento entre PO, Analista de QA e Devs.
Este alinhamento deverá ocorrer desde o início do projeto, para podermos mitigar riscos de produto e de projeto, e eles possuem probabilidade e impacto. Quem nos diz sobre a probabilidade é a equipe técnica (desenvolvedores) e quem nos diz sobre o impacto é a equipe de negócios (PO).
Boas práticas para um bom planejamento
O DTAR (Descomplicando Testes de API Rest) nos trouxe muitos insumos para adotar boas práticas e realizar um planejamento de testes de API de forma eficiente e eficaz.
Neste treinamento nós aprendemos sobre como exercitar boas práticas e como elas estão interligadas.
Definição das estratégias e abordagens de testes e suas relações:
Alguns itens importantes que devem ser analisados nesta etapa inicial:
Requisitos funcionais e não funcionais
Os requisitos funcionais e não funcionais nos proporcionam insumos para as demais características a serem observadas e devemos nos orientar a partir deles.
Riscos vinculados à Testes de API Rest
Os riscos informam insumos importantes para abordagem dos testes e também para a priorização do que deverá ser executado em um cenário de prazo apertado.
Ambientes de Testes e integrações
Ambientes de teste são um grande problema na maioria dos projetos, pois este pode não ser controlado e possuir uma infra complexa que depende de algum DevOPS dedicado para a operação, inclusive para fornecer acesso à filas e ambientes Cloud. Quando estamos avaliando as integrações, podemos encontrar riscos, pois dependemos da disponibilidade de outras aplicações.
Abordagens de testes
A escolha da abordagem correta dos testes pode evitar desperdício de tempo e testes desnecessários. Precisamos ser bem assertivos nessa escolha. É a partir dela que vamos identificar os cenários.
Automação de testes
Quando falamos em Automação de testes ,estamos falando de um projeto e como tal deve ser tratada. O QA não deverá automatizar apenas “quando tiver tempo”. Deverá haver uma tarefa para tal. Precisamos saber se temos tudo o que precisamos para a execução de tal teste, como por exemplo: conhecimento do produto, saber o que automatizar, ter conhecimento de linguagem de programação, entre outros.
Estimativas e Cronograma
No nosso dia a dia nos deparamos com cronogramas apertados e até irreais de se cumprir e precisamos fornecer estimativas, sendo os mais assertivos possível.
Ferramentas
As ferramentas de testes necessárias precisam estar listadas e disponíveis antes do início do projeto para evitarmos atraso na execução das tarefas e estas devem estar de acordo com a necessidade do projeto.
Uma outra estratégia importante é o MAPA MENTAL. Ele poderá ser feito em conjunto como a equipe através de uma reunião de Brainstorming para se definir as estratégias e abordagens a serem consideradas, bem como cenários, riscos, integrações , etc.
Segue abaixo dois modelos de mapas mentais com o foco nos Testes de API Rest e como resumo do que foi explicado pelo Julio de Lima em uma de suas aulas dentro do DTAR:
Tanto a abordagem como a cobertura de testes detalhadas acima dão um norte sobre como o planejamento e estimativa podem funcionar dentro de um projeto de testes. Pode-se optar por cobrir tudo ou uma parte, dependendo do número de profissionais envolvidos e do tempo disposto. E lembrando que esse exemplo diz respeito apenas aos testes de APIs, o que pode representar uma parcela significativa do desenvolvimento BackEnd de um projeto.
Conclusão
O bom planejamento está totalmente atrelado ao nível de qualidade do produto que o time se compromete junto ao cliente. Negligenciar isso é flertar com o risco da perda de credibilidade das partes mais interessadas e não permitir transparência sobre o que se está desenvolvendo.
É preciso encontrar tempo para trazer estas estimativas ao mundo real, sem medo de fazê-lo. O resultado final é muito compensador.
Referências
1- Testes Funcionais de Software, Leonardo Molinari.
2- Análise de Riscos em Projetos de Testes de Software, Emerson Rios.
3- DTAR (Descomplicando Testes de API Test (Julio de Lima e Antônio Montanha).
4- Gabriel Santos : Testes Baseados em Riscos — Risk Based Testing
Agradecimentos:
Agostinho Bernardes pela Co-autoria deste artigo.
Gabriel Santos e Bruno Pulis pela revisão.
