Aqui na Monitora nós trabalhamos, entre outras coisas,

com outsourcing de teste de desenvolvimento.

Isso faz com que nós tenhamos que trabalhar conjunto com equipes

geograficamente espalhadas, então nós trabalhamos com equipes na Ucrânia,

no Paquistão, Malta, Londres e outros países.

Isso traz algumas especificidades e exige uma agilidade dos

times de desenvolvimento e de teste diária.

Basicamente os engenheiros de QA,

os engenheiros que trabalham com teste recebem o requisito

conjunto com os desenvolvedores, os programadores daquela funcionalidade.

A partir desse momento os desenvolvedores partem para a programação e os engenheiros

de QA começam a criar casos de testes funcionais para cobrir os cenários

que foram solicitados pelo PO, pelo gerente de projeto, pelo cliente.

No momento que os programadores finalizam a programação eles devem

criar os testes unitários, uma primeira estratégia de teste que nós utilizamos,

os testes unitários para cobrir aquele código, e os engenheiros de QA,

terminando o design dos casos de teste,

preparam ciclos de teste pertinentes para aquela funcionalidade.

O que nós indicamos relação à teste unitário é que os projetos que tenham

interface gráfica tenham pelo menos 50% de cobertura dos testes unitários e para os

projetos que não têm interface gráfica, como o microservices, por exemplo,

que eles atinjam 80% de cobertura.

Feito isso, como nós trabalhamos com builds automáticos,

processos de integração contínua, todo momento que a funcionalidade é "buildada",

os testes unitários são executados e os próprios desenvolvedores já conseguem

identificar e corrigir alguns defeitos.

Quando o desenvolvedor diz que a funcionalidade está ok para os testes

finais, a equipe de teste coloca isso ambiente similar

ao de produção e executa os testes funcionais.

Relação aos testes funcionais, para os engenheiros de QA,

as estratégias que a gente mais utiliza são testes de integração,

testes de sistemas e testes de performance.

Alguns casos, quando o usuário final é mais crítico,

a gente também realiza alguns testes de aceitação com o usuário.

Então quando a funcionalidade está pronta a gente executa os casos de

teste que foram desenvolvidos específicos para aquela nova funcionalidade.

São os testes de sistema e teste de aceitação,

para garantir que aquilo está como esperado.

Feito isso, não tendo defeitos específicos naquele novo código,

a gente passa para o teste de integração do ecossistema.

A maioria dos sistemas que a gente trabalha, ele não é único, ele se integra,

ele consome e expõe informações para outros sistemas.

Então a gente tem que garantir que essas integrações estão funcionando.

Embora não seja integração entre os componentes desse sistema,

é integração entre os sistemas que compõem grande sistema de software.

A gente realiza esses testes de integração para garantir que

tudo está funcionando como o esperado

relação à nova funcionalidade e aos outros sistemas que existem.

Feito isso, não tendo mais defeitos nesse contexto,

a gente passa para os testes de regressão, que é grande desafio.

Os profissionais que estão trabalhando com aquela funcionalidade precisam

entender o ecossistema para identificar os impactos que aquela nova

funcionalidade pode ter e selecionar os casos de teste de regressão,

para garantir que funcionalidades já existentes, que já estão funcionando não

tenham sido quebradas, que defeitos não tenham sido inseridos nessas

funcionalidades que já estão funcionando, produção para os usuários finais.

Feito isso, a gente faz o que se chama de sign-off,

a equipe de QA dá o sign-off na versão e ela está apta a ir para a produção.

Nós criamos uma serie de documentos que vão desde de detalhes técnicos,

as builds que foram criadas, os testes que foram executados,

os defeitos possíveis que foram levantados e foi feito o que a gente chama de bumpar,

decidiram que eles não seriam corrigidos naquela funcionalidade porque são defeitos

que não são críticos, os defeitos que foram levantados e que foram corrigidos.

Então a gente prepara uma especificação técnica para manter o histórico de todas

as versões de determinado sistema e também preparamos uma

documentação para o usuário final.

Quando estamos inserindo uma funcionalidade nova a equipe de

QA é responsável por especificar como aquela funcionalidade está funcionando,

como ela foi implementada, como para executar determinada

ação o usuário tem que lidar com o sistema, e nós repassamos essa

documentação para o gestor do projeto, que é quem lida com o usuário final,

para que ele prepare materiais de treinamento adequado e assim por diante.

Dos grandes desafios, do meu ponto de vista, no contexto de qualidade de

software, para os engenheiros de qualidade de software, para esse ambiente,

uma é que o tempo sempre é curto para todos os profissionais que estão

envolvidos, mas não conseguimos colocar nada produção sem estar codificado.

Então ainda no dia-a-dia é normal que as pessoas

envolvidas falem "está codificado, está pronto".

Nós temos a sorte de estar ambiente que o teste é mandatório,

não se coloca nada produção sem o teste, mas, pelo negócio,

a prioridade de todo software é entregar valor para business, para negócio,

para uma empresa, para uma companhia que precisa daquela funcionalidade.

Então o tempo do mercado também tem que ser respeitado.

Dos grandes desafios que a gente encontra é selecionar o mínimo suficiente de

casos de teste para encontrar os defeitos mais críticos, priorizar esses defeitos e

ter o conhecimento de todo o ecossistema, de todo o negócio do cliente inclusive,

para poder falar "esse defeito tem que ser corrigido, eu como QA não vou liberar

esse sistema com esse defeito" e também dizer "eu, como QA, entendo que esse

defeito não é crítico para o meu usuário final, então eu posso liberar essa versão

agora e aceitar que esse defeito seja corrigido posteriormente".

Isso exige conhecimento de negócio que muitas vezes nós não estamos preparados.

Nós fazemos faculdade de computação e nós não temos domínio

sobre processo de negócio financeiro, contábil ou processo de negócio inovador.

Nós trabalhamos aqui dos sistemas com a área de aviação e ninguém é experiente

aviação, mas nós temos que aprender com o cliente para podermos tomar essa

decisão por eles, qual é o defeito que vai ter grande impacto produção e qual

é o defeito que eu aceito deixar para uma próxima versão porque eu prefiro colocar

a funcionalidade no ar hoje e deixar esse defeito para corrigir depois porque

observando a empresa como todo, o meu cliente como todo, eu aceito esse risco.

Então esse é desafio para os profissionais da área e para desenvolvimento de

software como todo.

A seleção e priorização dos casos de teste também é

desafio porque a gente não pode encarecer muito o projeto.

Todo mundo que trabalha com teste gostaria de testar tudo sempre, o tempo todo,

mas isso encarece.

Então nós temos que ter mente o objetivo final de software,

que é entregar valor para o cliente.

Sim, nós temos que observar e selecionar os melhores casos de

teste para cobrir os cenários mais críticos e não deixar de maneira

nenhuma que erros críticos sejam encontrados pelos usuários finais,

mas algum defeito, que a gente chama de corner case,

cenário que não é o comum produção, mesmo sabendo que tem algum defeito, a gente

tem que aceitar para que o objetivo final seja alcançado o quanto antes.

Estimar caso de teste indústria é desafio.

Aqui nós trabalhamos com uma ferramenta que chama Zephyr,

é plugin pago de sistema que chama Jira,

que é usado mundialmente, é dos mais famosos para isso,

mas ainda assim eu particularmente sinto falta de ferramentas para estimar casos

de teste ou para que ajude o profissional de teste a estimar os casos de teste.

Nós temos técnicas na literatura e aqui nós tentamos aplicar

as técnicas pontos por caso de teste sempre que possível, mas isso toma tempo,

então é importante que os profissionais estejam muito bem treinados para que eles

consigam executar toda a teoria de teste, bom design de caso de teste,

estimar esse caso de teste baseado uma técnica, caracterizar os casos

de teste de acordo com a estratégia que ele está sendo criado,

reunir os casos de teste nos ciclos adequados,

as switches de casos de teste, para cada uma das funcionalidades,

para cada uma das etapas: aceitação, integração, regressão.

Fazer isso de uma forma rápida porque isso é a qualidade do

trabalho que a gente executa e aí impacta diretamente na qualidade do produto.

Eu acredito que os maiores desafios na indústria ainda sejam os clássicos

desafios de teste: seleção, priorização,

estimativa e design de casos de teste porque exige habilidades técnicas

do profissional, mas também uma habilidade de conhecer do negócio,

entender da feature e o poder de análise, que é algo que, do meu ponto de vista,

a gente só consegue exercitando muito, todos os dias, trabalhando com requisitos,

criando casos de teste e tendo pensamento crítico sobre aquilo que é criado.

Então relação à técnicas, eu acho que na indústria hoje a técnica

funcional é muito mais utilizada do que a estrutural, e de estratégia,

testes unitários, testes de sistemas,

de integração e de performance são essenciais para toda empresa que

quer trabalhar com testes de software e ter processo de software bem definido

para garantir o sucesso do produto final e entregar valor para o nosso cliente.

Convidada: Gerente de Qualidade de Software da Monitora

Introdução ao Teste de Software

Meet the Instructors