Análise de Teste - KarineValenca/ElliotQATest GitHub Wiki

Conjunto de testes por incremento

De acordo com o incremento de software entregue, deve ser realizado o procedimento de teste adequado. Como não é viável testar tudo sempre que um incremento for entregue, deve haver uma boa estratégia de teste para garantir a qualidade do produto entregue, dentro do tempo estimado.

Baseado no Semantic Versioning podemos considerar 3 tipos de incremento de software (major, minor e patch). Para cada tipo de incremento, um conjunto de testes deve ser realizado. A seguir é apresentado os tipos de incremento, com sua descrição e qual é o conjunto de testes que deve ser executado para cada incremento.

Tipo de incremento	Descrição	Conjunto de testes
Major	Alterações de API incompatíveis	Regression testing
Minor	Adição de funcionalidade	Smoke testing e Sanity Testing
Patch	Correções de bugs	Smoke testing e Sanity Testing

Descrição de cada tipo de teste:

• Regression testing: Teste usado para garantir o funcionamento correto de todas as funcionalidades do sistema.
• Smoke testing: Teste que garante que as principais funcionalidades do sistema estão funcionando adequadamente. Os casos de teste incluídos como smoke test, no aplicativo da Elliot, são: Login/logout, compra e venda de bitcoins, depósito de dinheiro na conta Elliot, depósito de bitcoins via QRCode.
• Sanity testing: Teste utilizado para garantir que uma funcionalidade específica tem o funcionamento esperado. Sempre que uma funcionalidade nova ou uma correção de bug for feita, a execução desse tipo de teste vai permitir a verificação do funcionamento correto da funcionalidade. A execução desse teste pode cobrir mais de uma funcionalidade por vez.

Desta forma, sempre que uma grande mudança for realizada no sistema, como por exemplo, uma mudança de arquitetura, deve ser feito o teste de regressão. Além disso, o teste de regressão também deve ser feito sempre antes de uma release ser entregue, para garantir que a junção das funcionalidade implementadas na release não estão afetando uma às outras. O smoke testing e o sanity testing serão feitos na correção de bugs e na implementação de novas funcionalidades, permitindo assim assegurar o funcionamento correto da funcionalidade alterada e o funcionamento das principais funcionalidades do sistema.

Reporte e correção dos problemas

Todos os problemas e melhorias encontrados durante os testes devem ser registrados dentro do pull-request da funcionalidade/correção de bug implementada. Caso seja avaliado que o item de correção ou melhoria não deve ser corrigido nesse próprio pull-request (ou seja, é um bug minor, ou uma melhoria, ou um bug que não está associado ao PR), o item deve ser registrado em uma issue no github, seguindo os modelos de cadastro de issue e de cadastro de melhoria.

Ambiente de testes

Para a melhor execução dos testes, é interessante a criação de um ambiente de testes. Nesse ambiente, será feito o deploy das funcionalidades a serem testadas. Esse ambiente, deve ter características semelhantes ao ambiente de produção, de forma a prevenir que erros não identificados no ambiente de testes apareçam no ambiente de produção.

Esse ambiente também deve ser separado do ambiente de desenvolvimento, uma vez que a massa de dados utilizados pelos desenvolvedores durante a implementação, pode interferir na execução dos testes. Além disso, no ambiente de desenvolvimento, funcionalidades "quebradas" são constantemente incluídas, o que pode atrapalhar no processo de teste. Outro fator importante para o ambiente de teste, é que os dados inseridos nele possam ser excluídos a qualquer momento e que seja um ambiente passível de erros, ou seja, esse ambiente não deve ser utilizado para demonstrações do sistema.

Organização de branchs:

Para auxiliar no processo de teste e agilizar a entrega das releases, é interessante que haja uma organização apropriada de branchs. Na imagem abaixo, é proposto uma organização de branchs que leva em consideração o processo de QA.

Master: contém a versão estável do sistema que está em produção.

Develop: branch com versão estável do código. A partir dessa branch é que as branchs de QA, de correção de bugs ou de funcionalidade são geradas.

QA: branch onde as funcionalidades e correções de bugs são testadas. Quando uma funcionalidade que está na branch Bugfix/Feature é finalizada, essa branch deve ser mergeada na QA para passar pelo teste. Quando a funcionalidade for aprovada, a branch QA pode ser mergeada na branch develop, uma vez que teremos uma versão estável do código.

Bugfix/Feature: branch de desenvolvimento de novas funcionalidades ou correções de bugs.

hotfix: branch para correção de bugs emergenciais que estão afetando diretamente os usuários em produção. É gerada a partir da master. O hotfix pode ser testado na própria branch e assim que for aprovado, será mergeado diretamente na master.

Processo de teste

O processo de teste, então, ocorrerá da seguinte maneira:

• Desenvolvedor cria branch_01 para a nova funcionalidade a partir da branch develop

• Ao finalizar a funcionalidade, desenvolvedor criar um pull-request e notifica time de QA.

• Time de QA faz o merge da branch_01 na branch QA.

• Time de QA realiza os testes na funcionalidade de acordo com o conjunto de testes definido por incremento.

• Caso funcionalidade não passe, time de QA deve notificar desenvolvedor, listando os problemas pelo pull-request. Time de QA deve aguardar as correções e então prosseguir com os testes.

• Caso a funcionalidade seja aprovada, time de QA deve mergear a branch QA na branch develop.

• Ao final de uma release, a branch develop passa pelo teste de regressão.

• Caso haja problemas, o time de QA deve notificar a equipe por meio de issues, aguardar a correção dos problemas e então prosseguir com os testes.

• Caso não seja encontrado nenhum problema, a branch develop é mergeada na master, e a nova release pode ser lançada.

Extra: Boards do ZenHub

O ZenHub pode ajudar a melhorar a visualização do andamento das issues. Os desenvolvedores podem ir movendo as issues para a pipeline adequada de acordo com o andamento da issues. A imagem abaixo tem uma sugestão de board, levando em consideração o processo de QA:

• Backlog: Issues dentro do planejamento da release.

• In progress: Issues que estão sendo desenvolvidas.

• Code Review: Issues que foram finalizadas, mas estão esperando pelo processo de code review.

• QA: Issues que já passaram pelo code review, mas estão esperando pelo processo de QA.

• Done: Issues que passaram pelo QA e que já foram mergeadas na branch develop.

Quando a issue/pull-request for reprovado pelo processo de code review ou pelo processo de qa, ela deve ser movida de volta para a pipeline "In progress" e o desenvolvedor responsável deve ser notificado.