E quando não há um processo de teste definido, o que fazer? Parte 1

Logo após a minha palestra na Trilha de Testes do TDC 2012 em Florianópolis, eu recebi um e-mail de uma testadora que havia lido os slides da palestra. Ela queria uma ajuda em como conduzir o desafio que foi dado a ela: estruturar o fluxo de testes da equipe de desenvolvimento. Quem aqui que está na área de Teste de Software já não se deparou com um desafio desses?! Pois então, para quem está começando a trabalhar na área tem uma certa dificuldade de dar o primeiro passo. Em uma sequência de 2 posts, irei explanar sobre como iniciar a estruturação do fluxo de testes e também sobre o processo de desenvolvimento como um todo.

** ESTRUTURANDO O FLUXO DE TESTES **

Vou elencar os pontos que eu acredito que sejam primordiais para iniciar este trabalho. Vejamos:

1. Mapear as atividades realizadas pelo time – quando me refiro ao time, quero dizer desenvolvedor + testador/analista de teste. É muito importante observar a forma de como as atividades são executadas, caso elas existam. Isso nada mais é do que mapear a situação atual, mesmo que ela seja informal.

2. Identificar o tempo do ciclo de desenvolvimento – saber quanto tempo o time leva para analisar, desenvolver e testar a demanda solicitada.

3. Verificar o retrabalho do time durante o ciclo de desenvolvimento – a partir dos registros dos bugs encontrados em uma ferramenta de bug tracking, é possível identificar o índice de retrabalho. Aqui destaco outro ponto importante: classificar o retrabalho! Por exemplo:

a) o time teve um retrabalho por causa de uma análise de requisito que não estava contemplando algumas regras de negócio relevantes.

b) o testador identificou um bug por problemas na codificação.

c) outro bug encontrado por causa de configuração de ambiente.

Como disse, esses são apenas alguns exemplos. O ideal é identificar no contexto de seu projeto o que seja mais relevante classificar!

4. Coletar o índice de não conformidade no ambiente de produção – após a publicação da versão no ambiente produtivo, seria interessante monitorar as ocorrências de não conformidade principalmente se forem oriundas das implementações realizadas na versão publicada.

A partir dessas informações, é possível ter um retrato atual do time e identificar pontos de melhoria serem propostos. Crie um plano de ação para registrar a sugestões! Se uma das sugestões é elaborar um processo de desenvolvimento, comece por algo simples e intuitivo! Não pense em modelos de processos, se sua empresa possui projetos de curto e médio prazos. As pessoas têm que enxergar valor no processo, para que ele consiga ser institucionalizado. Ter um processo muito burocrático não é uma boa ideia, pelo menos não neste início de trabalho.

Outro ponto é a questão das ferramentas para a parte dos testes. A primeira ferramenta a ser definida é de bug tracking para registrar o retrabalho e não conformidades em produção. Depois temos a questão da gestão do artefatos de teste. Estes poderão ser elaborados, inicialmente, em formato de planilhas e/ou arquivos.doc. Caso depois optar por utilizar uma ferramenta, seria interessante que estes artefatos pudessem ser importados. No mercado temos diversas ferramentas open source e pagas. Veja a que melhor se adapta à sua realidade.

Gerar métricas é outro ponto importante! É necessário medir para saber como o time está e no que pode melhorar para visar a melhoria contínua. São exemplos de métricas:

• número e/ou índice de não conformidades no ambiente de produção;
• número e/ou índice de retrabalho durante a iteração;
• número de requisitos entregues por iteração.

Sobre a automação de testes funcionais, vale destacar que nem sempre haverão funcionalidades passíveis de automação. Considero importante a priorização das funcionalidades e classificá-las a partir da análise de impacto dentro do nicho de negócio. O que isso significa? Criar testes automatizados dos pontos mais críticos do sistema! E se o projeto é novo? Pode-se considerar a automação de testes de funcionalidades mais estáveis.

Utilizando a Adaptação da Ferramenta 5W2H para Análise de Teste no Contexto Ágil

Uma das coisas que me deparei quando comecei a trabalhar no contexto ágil foi como extrair os requisitos de uma user story e elaborar a minha análise de teste. Bem… para quem já está adaptado a este contexto, isso pode parecer trivial, ou seja,  no a partir dos critérios de aceitação. Entretanto, se coloquem no lugar de quem está iniciando no agile testing… 😉

Depois de participar de treinamentos voltados aos Métodos Ágeis, tive alguns insights para melhorar a qualidade do meu trabalho. Um desses insights foi justamente a ferramenta 5W2H. Eu buscava motivações para evoluir como profissional e agregar qualidade no trabalho do time, tais como:

• —Auxiliar na identificação dos critérios de aceitação dos requisitos;
• —Minimizar possíveis lacunas na análise de requisitos;
• —Melhorar a comunicação;
• —Incentivar a pró-atividade;
• —Melhoria contínua.

O que é a Ferramenta 5W2H?

—É uma ferramenta de planejamento muito utilizada na área de Administração, que consiste em um checklist contendo determinadas atividades nas quais os colaboradores da organização precisam desenvolver com o máximo de clareza. —Auxilia na eliminação por completo qualquer dúvida que possa surgir sobre um processo ou atividade.

A ferramenta compreende as seguintes atividades:

• What – O que será feito (etapas)?
• Why – Por que será feito (justificativa)?
• Where – Onde será feito (local)?
• When – Quando será feito (tempo)?
• Who – Por quem será feito (responsabilidade)?
• How – Como será feito (método)?
• How much – Quanto custará fazer (custo)?

Adaptando a Ferramenta…

Após analisar a ferramenta vi que precisava fazer algumas adaptações para atender às necessidades do projeto. Claro que não só para a análise de teste, mas também auxiliar no entendimento dos requisitos para o desenvolvimento.

Formato adaptado:

1. Qual é o objetivo do requisito?
2. Por que o requisito deve ser implementado?
3. Onde poderá ser visualizado o requisito?
4. Quais são os pré-requisitos para este requisito?
5. Qual é o perfil de acesso para este requisito?
6. Quais são os critérios de aceitação para este requisito?
7. Quais serão as mensagens de validação para este requisito?

Para facilitar o entendimento, vou dar um exemplo de user story para utilizarmos esta adaptação.

** User Story **

Módulo Compras

Como operador de compras, necessito que seja implementado um ambiente de compra de matéria-prima para a fabricação de medicamentos manipulados, pois assim poderei receber as ofertas dos fornecedores e obter o melhor preço.

Para aceitar:

1. Só poderão participar do processo de compra os fornecedores previamente cadastrados e com acesso ao Módulo Fornecedor liberado.
2. Cada fornecedor deverá apresentar apenas uma cotação por produto.
3. Toda cotação deverá possuir prazo de validade de 72 horas.
4. Cada fornecedor irá receber uma nova solicitação de compra através do Módulo Fornecedor.
5. Um fornecedor será considerado escolhido quando na sua cotação atingir 75% dos itens da solicitação de compra e ter oferecido o menor valor para cada item.

Para considerar:

• O processo de compra deverá ter, no mínimo, 3 fornecedores participantes.
• Para participar do processo, o fornecedor não deverá apresentar no seu histórico atraso na entrega dos produtos superior a 24 horas da data prevista.
• O Módulo compras deverá ser integrado aos demais sistemas da rede.

** Utilizando a Ferramenta 5W2H Adaptada no Entendimento dos Requisitos **

1. Qual é o objetivo do requisito?

Seja implementado um ambiente de compra de matéria-prima para a fabricação de medicamentos manipulados.

2. Por que deve ser implementado?

Para receber as ofertas dos fornecedores e obter o melhor preço.

3. Onde poderá ser visualizado o requisito?

Não está claro na user story.

4. Quais são os pré-requisitos para este requisito?

• O processo de compra deverá ter, no mínimo, 3 fornecedores participantes.
• Para participar do processo, o fornecedor não deverá apresentar no seu histórico atraso na entrega dos produtos superior a 24 horas da data prevista.

5. Qual é o perfil de acesso para este requisito?

Perfil/papel Operador de Compras

6. Quais são os critérios de aceitação para este requisito?

• Só poderão participar do processo de compra os fornecedores previamente cadastrados e com acesso ao Módulo Fornecedor liberado.
• Cada fornecedor deverá apresentar apenas uma cotação por produto.
• Toda cotação deverá possuir prazo de validade de 72 horas.
• Cada fornecedor irá receber uma nova solicitação de compra através do Módulo Fornecedor.
• Um fornecedor será considerado escolhido quando na sua cotação atingir 75% dos itens da solicitação de compra e ter oferecido o menor valor para cada item.

7. Quais serão as mensagens de validação para este requisito?

Não foi descrito na user story.

A partir das informações coletadas, já é possível identificar os cenários de teste. Caso as informações ainda estejam incompletas, é necessário contatar o Product Owner para maiores esclarecimentos. O importante é que antes de identificar os cenários de teste, as dúvidas sejam sanadas e, consequentemente, as perguntas respondidas. Novos dados poderão ser informados e assim ampliar o escopo dos testes.

** Cenários de Teste Identificados **

Em uma visão macro, temos os seguintes cenários de teste para o requisito:

1. Validar a permissão de acesso ao Módulo Compras.
2. Validar o fluxo do processo de compra.

a) perfil dos participantes
b) quantidade de participantes
c) quantidade de cotações por produto dos fornecedores.
d) prazo de validade das cotações.

3.  Validar a integração do Módulo Compras com os demais sistemas da rede.

De posse dos cenários de teste identificados, é hora de elaborar o artefato de teste adequado ao processo de desenvolvimento da sua empresa! 😉

Como Ingressei na Área de Teste?

O ano era 2004. Naquela época eu trabalhava na área administrativa de sucursal de uma seguradora e estava preocupada com a minha vida profissional, pois faltavam 3 semestres para a minha formatura (2005/1). Até então, o máximo de contato que eu tinha tido com a área de TI era quando um colega da infraestrutura saía em férias e eu o substituía. Isso me angustiava demais, pois sabia que, após me tornar bacharel e ainda sem a vivência na área, as oportunidades ficariam mais restritas.

Certa vez conversando com uma colega (minha amiga até hoje) antes da aula, ela me contou que tinha saído do emprego efetivo e que tinha começado a fazer um estágio na área de Teste de Software. Eu achei que ela tinha sido corajosa por ter feito uma escolha dessas. Na realidade era o que eu mais queria fazer, mas me faltava justamente uma coisa: CORAGEM!

Passaram-se alguns meses após essa conversa e, quando me dirigia ao laboratório da faculdade, vi um anúncio de uma vaga de um estágio que não fazia muitas exigências de conhecimentos e experiências. Me interessei e anotei o e-mail para enviar um currículo, mas só que eu não fazia a menor ideia do que se tratava a oportunidade de estágio. Confesso que levei alguns dias para enviá-lo, mas menos de um dia após enviar o currículo, a secretária da empresa me contatou querendo marcar uma entrevista para o outro dia. Nossa… eu nem acreditei! Parecia que tudo estava conspirando a favor, pq justamente naquele dia seria o meu último dia de trabalho na seguradora após um acordo. Me enchi de esperanças, mesmo desconhecendo do que se tratava.

A empresa ficava no Parque Tecnológico da PUCRS (TecnoPUC) e a entrevista estava marcada perto do final da tarde, pois depois eu iria para o laboratório escrever um pouco do meu TCC. Quando cheguei na empresa, eu tive uma grata surpresa: o dono era meu colega em uma das disciplinas daquele semestre! Aí, ele me apresentou a empresa, que era uma empresa incubada (futuramente chamada start up), que havia surgido de um spin-off do Centro de Pesquisa em Teste de Software da Faculdade de Informática da PUCRS (CPTS). O CPTS tinha parcerias com as multinacionais HP e DELL, que estão instaladas no TecnoPUC. Também me explicou a respeito da oportunidade: era para trabalhar com Teste de Software na HP.

Pois bem… além da entrevista, fiz uma prova, que consistia em aplicar os testes na calculadora do windows, que estavam descritos em um plano de testes em inglês. Eu teria que reportar os bugs encontrados, também em inglês, contendo um passo-a-passo. E assim eu o fiz! Como sempre fui uma pessoa muito observadora e detalhista, reportei cada passo que havia feito para encontrar os bugs. Entreguei a prova e me disseram que entrariam em contato, caso eu teria sido a candidata escolhida, pois ainda tinham que entrevistar mais um candidato. Me dirigi para o laboratório para escrever um pouco mais do meu TCC, afinal logo em seguida eu iria encontrar a minha orientadora.

Para a minha surpresa (mais uma vez naquele dia) não demorou muito para receber um retorno do processo seletivo: eu tinha sido a pessoa escolhida para a vaga de estágio! Não acreditei!! Fiquei muito contente, pois um novo recomeço estava por vir. Um dia antes do dia combinado para o início na HP, eu passei por um breve treinamento na empresa. Este treinamento consistia na troca de experiência com os colegas que já estavam trabalhando na HP, de como funcionavam as coisas por lá e o que eu teria o que fazer.

Portanto, eu entrei na área de Teste de Software meio que sem querer! Até porque durante a faculdade eu havia me interessado pela a área de Auditoria de Sistemas e gostaria de trabalhar com isso. No final das contas, as duas áreas estavam relacionadas! Eu não fugi da Programação por não ter afinidade. Eu não tinha tido oportunidade de programar além das disciplinas do curso. A partir disso, eu teria um “novo mundo” para explorar…

Por que ter um blog?

Depois de pensar, pensar… relutar… pensar de novo, optei em ter um local aonde eu pudesse compartilhar um pouco das minhas experiências e, porque não, dilemas que tenho em torno da área que escolhi atuar. Podem estar se questionando: “Mas porque ela relutou em ter um blog?”. Bom… eu não queria ter “mais um blog” sobre Teste de Software.

Na realidade, o que me motivou a criar este espaço foi um post da Katrina the Tester, que foi repassado pelo meu amigo @GpaOliveira, sobre Women in Testing on Twitter. Achei super interessante e, ao mesmo tempo, me fez pensar na atuação feminina da comunidade brasileira de Teste de Software. Então, por que não fomentar uma maior participação feminina dentro da comunidade, não é mesmo? 😉

A minha ideia é ter uma abordagem sutil para assuntos mais técnicos, dúvidas sobre por onde começar, angústias e no que eu puder colaborar. Todas as contribuições serão bem-vindas! 🙂