Como inserir o QA na etapa de solução

Publicado por Ana Paula Vale no dia qa

QA na Solução

Até pouco tempo atrás, na maioria das empresas de TI, or QA (Quality Assurance) era aquela pessoa que estava sempre disponível para realizar testes no fim do processo de desenvolvimento a fim de verificar se o que foi entregue está correto ou não.

As maiores empresas do país tendem a adotar essa prática e costumam dividir equipes de desenvolvimento e testes em departamentos diferentes e algumas vezes até em locais diferentes. Aqui na Resultados Digitais trabalhamos QAs e Devs todos no mesmo ambiente e divididos em times que são responsáveis por um determinado número de features em uma vertical de negócio. Sendo assim, conseguimos antever defeitos e agir na etapa inicial do ciclo de desenvolvimento. Desta forma, criamos aplicações com cada vez menos falhas e com o mínimo desperdício possível de tempo com retrabalho.

Comparing Techniques

Fonte: Mapping common techniques to the cost of change curve.

Essa proximidade explica-se pelo modelo de desenvolvimento ágil que aplicamos aqui, em que trabalhamos com a prática de Entrega Contínua e sempre temos algo novo a ser desenvolvido e testado. Assim, os QAs sempre estão dispostos a ajudarem em todo o processo de desenvolvimento de uma nova feature, reportando possíveis defeitos antes mesmo de serem implantados, barateando o custo de desenvolvimento, tendo em vista que bugs que seriam encontrados no fim do processo ou até mesmo pelos próprios clientes, já são encontrados na etapa de solução.

1. O QA na etapa de Solução

Quase todos os nossos times aqui em Produto utilizam uma metodologia ágil para desenvolvimento e, dentro do processo, existe a fase de Solução, em que PM (Product Manager) faz um estudo acerca dos problemas relatados por clientes do software, elabora estórias e as traz para que o UX Designer crie uma solução através de benchmarking e traduza isso para um flow de comportamentos. É aí que começa a participação do QA.

Customer Needs

Participando da fase de solução, o profissional de qualidade pode entender o que será desenvolvido e, a partir disso, ele pode prever quais serão os fluxos alternativos e de exceção possíveis, definindo qual estratégia adotar para a realização dos testes.

2. Testes de Usabilidade com usuário final

Mais uma tarefa bem importante e em que é válida a participação do QA, são os testes de usabilidade. Na RD, esses testes costumam ser realizados pelos UX Designers com clientes,pois eles desenvolvem a solução a partir de telas e assim já podem coletar insights acerca do que os clientes acham do que foi pensado para determinado problema.

A participação do QA nesse teste é bastante vantajosa também para a criação de cenários, já que numa entrevista com um cliente, em que este está vendo e testando tudo o que foi pensado para ele, é possível encontrar mais cenários não cobertos, como se fosse um teste exploratório mesmo, avaliando o que faltou ou não para realizar tal comportamento numa tela desenvolvida, por exemplo.

3. Coleta dos critérios de aceitação

Com as estórias prontas, a primeira atividade é elaborar questões com a intenção de encontrar fluxos e comportamentos inesperados ou que ainda não tenham sido pensados. Algo que auxilia no entendimento das funcionalidades é existir um fluxograma com os passos que um usuário pode realizar, se esse documento não tiver sido elaborado, o QA pode criá-lo utilizando técnicas como mapas mentais, diagrama de fluxos já relatado ou checklists com comportamentos genéricos que o QA espera que o sistema realize, como campos obrigatórios ou telas que podem sofrer impacto com inclusão de novas funcionalidades.

Checklists

O QA Engineer deve sempre ter ciência dos conceitos envolvidos no negócio do software, pois existem muitos casos em que sempre uma funcionalidade nova pode causar impacto no que já existe desenvolvido e, para isso, vale sempre o insight sobre possíveis rollouts (liberações parciais para algumas contas em específico). Por exemplo, uma tela que possui menu disposto na lateral e aos poucos, com rollout, vai sendo exibido na parte superior da tela com novo estilo, diferenciando aos poucos como o cliente vê a tela hoje.

Sobre impactos, sempre vale da parte do QA coletar informações sobre como novas funcionalidades se comportam com um grande número de dados. Por exemplo, a exibição de uma listagem de usuários, em que podem ser lançadas questões como: “Até quantos usuários essa lista deve trazer? Se não houver usuários, como a tela se comporta? Se o número de usuários ultrapassar o permitido, é exibida uma paginação para acessar os outros usuários?” Todas essas questões auxiliam na escrita de cenários de testes e detecção de possíveis critérios não cobertos. Além disso, é nesta etapa que o QA pode contribuir com o DoD (Definition of Done) da tarefa e ajudar a clarificar quais são os critérios necessários para que uma tarefa seja considerada entregue.

Com os critérios de aceitação em mãos é possível serem estimadas as tarefas de teste e para isto pode ser usado o quadrante de testes.

4. Definição da Estratégia de Testes (Quadrantes Ágeis)

Depois que cenários de testes são criados, o QA já pode ter uma noção de quais estratégias de testes ele irá utilizar no decorrer do processo. Para decidir qual estratégia tomar, levamos em consideração os quadrantes de Crispin [Crispin, Gregory, 2009]:

Quadrantes Ágeis

Fonte: Agile Testing, pag. 98

As atividades encontradas nos quadrantes Q1 e Q2 existem para que os testes guiem o desenvolvimento e todos do time saibam o que será implementado e testado. No Q1 os devs desenvolvem utilizando técnicas como TDD (Test Driven Development) e no Q2, por meio de cenários de testes mais alto nível, BDD (Behavior Driven Development).

Right Code

Já o quadrante Q3 é voltado às atividades manuais, em que já existe software desenvolvido e pode ser “criticado”, ou seja, podem ser encontrados problemas. É o momento de explorar e validar se o que foi desenvolvido está de acordo com o que o cliente pediu. Nestes quadrantes entram testes manuais, como testes exploratórios e de de usabilidade.

No Q4 estão as tarefas voltadas para os testes não funcionais, como por exemplo testes de carga, performance ou segurança. Geralmente são automatizados e necessitam de ferramentas para isso.

Aqui na RD escolhemos os tipos de testes que serão aplicados a partir da Feature que será desenvolvida com base nos quadrantes ágeis.

5. Elaboração de Cenários antes do desenvolvimento

Existindo mais informações sobre os comportamentos e fluxos, é possível dar início ao desenvolvimento dos cenários de testes. A ideia é que sempre todos os membros do time (PM, UX, Dev, QA) estejam cientes dos critérios de aceitação que o cliente espera que o software apresente. Como também, existindo cenários antes do desenvolvimento, é possível que sempre tenhamos Devs escrevendo o código certo.

Aqui na RD, utilizamos a técnica de escrita de cenários em Gherkin, que mais pra frente no processo podem servir para criação de testes automatizados. Essa técnica existe para especificar o comportamento dos elementos da aplicação, mas em um alto-nível, ou seja, garantir que todos do time, e, às vezes, até os clientes, entendam o que será entregue no final de uma sprint. Além disso, estes cenários devem garantir que todos os critérios de aceitação definidos pelo DoD (Definition of Done) estão sendo cobertos. Exemplo:

1
2
3
4
Dado que exista uma listagem de usuários
Quando eu adicionar um novo usuário
E eu atualizar a tela da listagem
Então devo ver o novo usuário presente na listagem

Nestes cenários sempre são exibidas as pré-condições, com o passo a passo e o resultado esperado, assim como todos cenários de testes que já vimos em processos mais tradicionais. Na RD, para facilitar e agilizar desenvolvimento e testes, alguns times optam pelo pair programming, ou seja, escrever cenários juntamente com os devs para já prepará-los para o desenvolvimento, como também o inverso, devs participando dos testes com o intuito de encontrar defeitos (ou não) e, em seguida, já realizarem a correção.

Conclusão

O trabalho de QA com o time no processo de solução, definindo estratégias e elaborando cenários antes do desenvolvimento, mostra que está sendo investida a garantia da qualidade no sistema, entregando valor mais rápido e barateando o custo que é encontrar erros no início do processo.

Você que participa do processo de solução no seu time, conta pra gente a sua experiência e aprendizados.

Leia mais sobre:

Ana Paula Vale

Ana Paula Vale

Quality Assurance

Comentários