Muito se fala na evolução dos testes e como temos que caminhar, qual conhecimento adquirir, o que estudar e para que lado nossa profissão está caminhando. Hoje identifico que temos dois caminhos mais claros: Quality Control ou Quality Assurance.
Não entrarei em detalhes de cada um, mas falarei sobre o que acredito que trará mais conhecimento e satisfação de se trabalhar com testes. Falo isso pois considero o “Quality Assurence” como o futuro de nossa profissão, fazendo com que sejamos realmente necessários no projeto e nos considerem de vez parte do time, olhando para qualidade como um todo e não apenas para um Tester como o profissional que é citado como “gargalo” e o único à olhar para a qualidade.
Com isso cheguei a dez itens que são importantes um Tester dominar para se tornar um QA (Quality Analyst) que todos querem no time.
1. Elaborar testes antes da funcionalidade ser desenvolvida.
Este é o ponto base para que tudo comece a funcionar, e faz com que a responsabilidade seja dividida com todo o time. A intenção é não ter o elemento surpresa, isto é, esconder um cenário de teste e quando identificar um bug surgir a situação de “Te Peguei! Não pensou neste cenário hein…”. Esta visão de mostrar o caminho que o Tester fará antes do desenvolvimento, pode guiar o time para evitar bugs, o que evitará desperdício de dinheiro, evitará conflitos internos, evitará falta de conhecimento no negócio, e melhorará a qualidade do produto final.
Também existe uma técnica que pode ajudar, é chamada de “Los Três Amigos”, onde o P.O./B.A. (Product Owner/Business Analyst), mais o Tester e mais o Desenvolvedor olham para os cenários juntos, cada um com sua visão e sua técnica, e deixam mais completo os caminhos que podem ser utilizados pelo usuário final, tornando claro o comportamento que o software deve ter.
2. Realizar Automação de Testes Funcionais e Não Funcionais
Automação de testes deve ser comum para os Testers, é onde se pode ganhar e muito com relação aos ciclos que serão repetitivos durante todo o projeto, seja no agile ou no waterfall, uma nova funcionalidade pode quebrar uma implementação já finalizada e para não ter que retestar tudo deve se automatizar as funcionalidades mais críticas.
Também deve se atentar aos testes Não Funcionais, dependendo da aplicação é claro, pois dará uma visão dos riscos que a aplicação pode correr e quais são as contingências caso um risco se torne um problema (por exemplo, se a sua memória chegar no limite, como sua aplicação se comportará até que alguma ação seja tomada)
3. Realizar testes de Rotas/APIs/Serviços
São testes importantes e que não devem passar despercebidos pelos Testers, pois podem ser criados a partir da documentação de uma implementação (documentação de uma API por exemplo), sem nem mesmo ela ter sido desenvolvida. Já vi casos da automação dos testes ser finalizado ao mesmo tempo que a aplicação foi entregue para ser testada. Então bastou o Tester executar a automação e já falar o que precisaria ser ajustado. É um grande ganho para todo o time, já que na maioria das aplicações, a camada de negócio está neste “back-end”, e o mesmo pode ser testado sem ter o front-end entregue.
4. Fazer a passagem de conhecimento entre P.O. => Dev => SysAdmin
Este item também é de extrema importância, pois a falha de comunicação mesmo sendo menos técnica entre P.O. e Dev, ou totalmente técnica entre o time do Projeto com os SysAdmins (que irão manter a aplicação quando estiver em produção), pode atrapalhar a velocidade de um “entregável”. Além de prejudicar o projeto por não ter identificado riscos de negócio (P.O.), riscos técnicos (Dev) e riscos de arquitetura / monitoria (SysAdmins), que são normalmente visualizado quando está na fase final do projeto por falta de um alinhamento durante o projeto.
Os perfis dos três grupos são diferentes, um pensa na entrega, outro pensa na agilidade da implementação e o outro em como não ter problemas após a entrega e como manter saudável o software. E cabe aos Testers, ajudar no alinhamento entre estas três áreas, para ter uma evolução com qualidade na visão de todos.
5. Participar da elaboração dos testes unitários
No início de meu caminhar como Tester imaginava que isso era uma utopia, que os Testers jamais iriam participar de testes unitários e que isso era obrigação exclusiva de desenvolvedor. Hoje já penso diferente, vejo o Tester como parte do time, e ajudar o desenvolvedor neste item é totalmente viável e possível. Também vejo que poderemos parear com Devs na elaboração dos testes, evitando até possíveis repetições de testes futuros por saber o que já foi testado e automatizado em fases anteriores.
6. Realizar testes exploratórios de qualidade.
Os testes no final do projeto não deixarão de existir, mas teremos os mesmos em uma quantidade bem menor do que muitos projetos realizam, pois os principais testes na funcionalidade foram trabalhados em fases anteriores. Com isso, podemos utilizar técnicas de testes exploratórios, onde um exemplo seriam os testes baseados em sessões, o que um Tester levaria em torno de 1h30min utilizando de sua criatividade e técnica em identificar bugs. E deixaria de ser o que muitos fazem hoje (somente testes no final, o famoso “testa aí”…), onde um teste de uma funcionalidade pode levar até dois dias (ou mais) para ser finalizado.
7. Conhecer integração contínua
Integração continua hoje é obrigatória para um sistema, principalmente se for web, pois o retorno rápido é necessário para uma resposta quase imediata do desenvolvedor. Nomes como Jenkins, Hudson, Bamboo, Travis… devem ser comuns entre os Testers. Saber como estas ferramentas funcionam, e quais as facilidades que elas possuem para ajudar na qualidade do desenvolvimento é essencial para a qualidade do produto.
Também deve se atentar a gerencia de configuração, onde existem ferramentas (como Git, SVN, CVS…) que são essenciais para controle e gerenciamento das entregas no projeto.
8. Ter como objetivo o Continuous Delivery / Continuous Deployment
A passagem da aplicação entre os ambientes até chegar em produção tem que ser controlada e principalmente ser rápida, isto é, a partir do momento que se é “commitado” uma alteração e finalizada uma implementação pelo desenvolvimento, a aplicação deve passar pela integração continua com testes unitários, passar por bibliotecas/Gems/Apps que garantam a qualidade, além de todos os testes que são automatizados até chegar em produção sem ter uma intervenção manual (continuous deployment), ou se tiver que seja o mínimo possível (continuous delivery).
A passagem pelo ambiente de Dev, depois pelo ambiente de QA, e finalmente a entrega em produção deve ser rápido e com uma garantia de qualidade que faça qualquer risco ser minimizado ao máximo, e caso necessário ter uma resposta rápida para uma correção imediata.
9. Participar de pequenas implementações no projeto
Hoje os Testers devem conhecer de desenvolvimento de software, da arquitetura da aplicação, da linguagem que será utilizada no projeto. Tudo isso para que possam ajudar no que for necessário, e até realizar pequenos ajustes sem necessidade do trabalho dos desenvolvedores.
Por exemplo, uma pequena correção, como ajustar uma palavra escrita errada, como ajustar um elemento na tela, ou até mesmo uma regra de negócio simples, deve ser de conhecimento de um Tester para ajudar o time no dia a dia.
Um exemplo claro que já ocorreu em projetos que participei foi o Tester desenvolver a rota de monitoração de uma aplicação, ele uniu o conhecimento de desenvolvimento com a visão de qualidade para ajudar a manter a saúde da aplicação no ambiente de QA e principalmente no ambiente de produção, com uma monitoração funcional (ver se a aplicação responde corretamente e está “on”) e não funcional (verificar se as portas necessárias para acessar a aplicação estão liberadas pelo firewall) da aplicação.
10. Identificar e implementar bibliotecas que possam garantir a qualidade do projeto.
Para finalizar, é necessário estarmos atentos à bibliotecas e ferramentas que possam ajudar a manter a qualidade de nosso projeto, isso falando em código principalmente.
Hoje temos diversas ferramentas que nos ajudam a verificar e validar o código em si. Vou citar algumas no mundo de desenvolvimento em Ruby, mas que podem ter similares em outras linguagens de programação:
- Rubocop: verifica a padronização do código e critica se tiver algo fora do padrão.
- Ruby Criticals: analisa o código e mostra a complexidade do mesmo.
- Rcov: Analisa a cobertura de testes (unitários) do código.
- Mutant: Altera o código para que um teste unitário quebre e avalia se não está ocorrendo um falso positivo, isto é, algo que deveria falhar e não está falhando.
Existem muitas outras bibliotecas que podem ajudar, mas o importante é olhar para a realidade do projeto e ir utilizando o que melhor se adaptar, para evitar que os defeitos do que foi desenvolvido passem para a próxima fase e sejam corrigidos o quanto antes. Além de ter a visão que devemos ajudar a evitar que os bugs sejam criados por algum equivoco na implementação.
Claro, temos outros itens que poderia colocar aqui, mas creio que esta é a base que um QA deve ter, onde poderá ajudar o time do projeto e implementar a qualidade em todos os pontos do desenvolvimento da aplicação, desde o levantamento inicial até a entrega em produção.
Imagens:
[1] http://3.bp.blogspot.com/-_HsPildwvP4/VDicuNXyRsI/AAAAAAAAWEs/YMq2hQxlwoQ/s1600/Home-Seller-Checklist.png
[2] http://www.testingexcellence.com/wp-content/uploads/2014/04/automated-testing-best-practices-agile.png
[3] http://www.hascode.com/wp-content/uploads/2011/09/rest-service-testing-logo.png
[4] http://4.bp.blogspot.com/-eZbLYwUy1JA/VS6QknXYsdI/AAAAAAAAKr8/3J3Dp8CCi-s/s1600/Passagem%2Bdo%2BConhecimento.jpg
[5] http://www.beilers.com/wp-content/uploads/2010/03/moz-screenshot-2.png
[6] https://mundoautista.files.wordpress.com/2010/02/imagemmundo.jpg
[7] http://www.methodsandtools.com/archive/CI1.jpg
[8] http://blog.crisp.se/wp-content/uploads/2013/02/continuous-delivery-deployment-sm.jpg
[9] http://1.bp.blogspot.com/-OBypUXOAaqM/VQWlR3zuFpI/AAAAAAAAPsQ/a4VKobsHvqI/s1600/matematica-para-programadores-de-jogos.png
[10] http://librarysciencelist.com/files/2013/04/Library-Science.jpg