Mapas Mentais no Planejamento de Testes

1 No centro do Dashboard ou em uma folha de papel, centralize o seu projeto ou produto.
2 Os primeiros retângulos sao os mais próximos do circulo, com funcionalidades macro.
3 Depois de definir as funcionalidades macro, deriva itens relacionados a essa funcionalidade.

Este tipo de abstracao ajuda muito para visualizar a quantidade de itens a testar e se preparar para os testes, ambientes e duvidas sobre o que testar.
Usar essa tecnica tambem ajuda o desenvolvimento a pensar em algumas mudancas ou impacto do desenvolvimento.

Plano de Teste e o Ciclo Ágil

Cada tarefa de desenvolvimento deve gerar casos de teste, casos de teste válidos e casos de teste invalidos. Este conjunto de casos de teste são adicionados em um plano de teste, cobrindo todas as possibilidades de uma funcionalidade.
Olhe a imagem. Vamos imaginar que um plano de testes contenha seis casos de teste e que neste momento iniciou a execução dos testes:
1  Esta coluna mostra o plano de teste para um determinado programa ou um conjunto de tarefas desenvolvidas pelo DEV. Plano de testes deve conter o objetivo dos testes e o conjunto de casos de teste.
No exemplo, foi executado um ciclo de testes, tres casos de teste falharam. Isso significa que o aplicativo não está bom para o cliente e precisa de correção.
Os desenvolvedores trabalham nas melhorias e correções e o analista de testes registra os bugs e organizam o segundo ciclo de testes.
2 No segundo ciclo de teste não é necessário testar todos os seis casos de teste novamente. No primeiro ciclo, os teste um, tres e seis foram aprovados. Quando isso ocorre o esforço de teste do segundo ciclo deve ser somento nos testes reprovados. Seria perda de tempo testar novamente o que já está aprovado.
3 O desenvolvimento corrigiu as tarefas reprovadas, geraram um novo APP e enviaram para os testadores
No resultado do segundo ciclo de testes, os casos de teste dois, quatro e cinco foram aprovados com sucesso. Os seis casos de testes depois de dois ciclos foram aprovados. O aplicativos está apto a ser entregue para o cliente.

Em casos especificos, uma correção pode influenciar outros casos de teste. Se o analista de testes tiver a rastreabilidade de uma funcionalidade, pode ser retestados outros pontos da aplicação.
De qualquer forma, o segundo ciclo de testes será sempre a partir do retrabalho. Se o caso de teste um falhar e influenciar o dois e o tres, será testado o um, dois e tres apenas.

Automação de Teste no Processo Ágil de Teste

O bom uso da automação de testes aplica-se em dois casos: Testes de Regressão ou tarefas que exigem uma grande quantidade de repetição. Realizar testes regressivos ocupa tempo e contingente e dentro de um processo ágil de teste seria inviável. No caso das tarefas repetitivas essa demanda só é atendida com automação.

1 Na reunião de planejamento do produto, dependendo das tarefas ficará explicito o uso ou não de automação. Tarefas estressantes só poderão ser feitas com uso de ferramentas. Em alguns casos existe a possibilidade de impacto em uma mudança, onde será necessário fazer testes de regressão.

2 Na parte de automação, será necessário ter alguém dedicado para tarefa. Criar scripts de automação pode levar algum tempo e exige um conhecimento especifico em uma ferramenta.
Enquanto o analista de testes cria os casos de teste funcional, um testador com aptidão na ferramenta ou um outro analista de teste dedica-se na automação.
Scripts de automação pode ser adaptados ou reaproveitados neste nível de criação.

3 Para métodos de teste ágil, automação só se aplica em testes regressivos ou relacionado a teste não-funcional (carga, stress etc) de app já existente. 
Quando uma tarefa do desenvolvimento for concluida, o aplicativo está pronto para receber testes.
Em um ambiente especifico aplica-se os testes automatizado e ao mesmo tempo aplica-se testes funcionais manuais, aumentando a cobertura

Uma boa ferramenta de testes funcionais e recomendo é TestComplete. Essa ferramenta aplica-se testes funcionais em aplicativos desktop, uma ferramenta paga com um excelente custoxbeneficio.
Para automação funcional de teste web recomendo a ferramenta SAHI, gratuita e interage com scripts AJAX.

Ciclo de Correção e Teste

No período de execução de teste o testador terá em mãos o Plano de Testes onde contém os principais objetivos a atingir e também os casos de teste para execução. Todos estes documentos foram criados anteriormente, paralelo as tarefas do desenvolvimento, portanto, não deixe de ler o post o plano de testes e os casos de teste. Recomendo que leia tudo que foi proposto até agora, para entender melhor o processo.

1 Durante a execução de teste é comum encontrar bugs no produto ou inconformidades. Normalmente na execução de um caso de teste é possivel encontrar bugs indiretamente e estes devem ser registrados. Cito um exemplo: O caso de teste é realizar login com sucesso. Durante esta execuçao, foi percebido que o tamanho do campo "nome" é menor do que o nome do login válido. Neste caso, encontramos um bug que não há caso de teste criado.
Quando encontramos alguma diferença entre o esperado e o encontrado, define-se bug.
No nosso processo, o testador registra todo o ocorrido durante a jornada do dia e retorna ao Analista de Teste, pois no nosso exemplo é ele quem irá dar o feedback diário da execução de teste;

2 O desenvolvedor irá corrigir o problema reportado. Em métodos ágeis de desenvolvimento, essa interação costuma ser rápida. Testadores estão sempre em comunicação com desenvolvedores, informando ou levantando informações sobre um possivel bug.

3 Quando o aplicativo estiver corrigido o testador deverá retestar o aplicativo, apenas na correção, sem ser regressivo. Poderá ocorrer testes de regressão baseado no conjunto de tarefas, mas isso varia de acordo com o projeto.
Uma boa prática é reportar todos os bugs encontrados e seguir todo o plano de teste proposto. Ao encerrar todos os testes, cria-se uma nova baseline de execução, com apenas correções, sem necessidade de retestar tudo.

Neste nível do processo, entra em cena uma ferramenta para registro de incidentes. Recomendo o uso da ferramenta Mantis, por ter um excelente custo x beneficio e ser bem completa além de gratuita. Existem bons tutoriais na internet para uso e configuração.
Essa ferramenta é indispensável. Tudo que for encontrado deve ser registrado, nada pode ser perdido ou esquecido. Em relação ao Plano e Casos de Teste, poderia ser substituido por qualquer alternativa, um txt por exemplo, mas o registro de incidente deve ser bem organizado e ser fornte de referência e pesquisas futuras

Processo de Teste Ágil

Antes de prossegir, vou usar a referência "Manifesto para Desenvolvimento Ágil de Software" para relembrar o que vimos nos post anteriores.

- Indivíduos e interações mais que processos e ferramentas 
No nível de planejamento e nas reuniões diárias, o bom diálogo com os desenvolvedores poderá resolver problema de escopo antes de virarem problemas. 
Em termos de processo, a nossa principal equivalência é o planejamento e a criação dos casos de teste, ambos paralelos ao desenvolvimento.
- Software em funcionamento mais que documentação abrangente
Ter bons resultados exige planejamento, mesmo que resumido. Nos métodos ágeis, tarefas com simpes descrição substituem a formalidade da documentação.
Para a qualidade do produto, entender o que será feito na tarefa e onde será feito geram casos de teste. Com o comprometimento da qualidade, é necessário pensar um pouco antes de sair testando, transformar o pensamento em algo descritivo e esse processo não é demorado, pelo contrário, é paralélo ao periodo de desenvolvimento. Criar os casos de teste não será gargalo no Processo de Teste Ágil proposto
- Colaboração com o cliente mais que negociação de contratos
Neste nível, em termos de qualidade do produto, o analista de testes deve se colocar no ponto de vista do usuário final, se o que foi feito de fato vai suprir a necessidade do cliente, ser auto-critico e avaliar a usabilidade. Falo isso porque a qualidade do produto e o desenvolvimento são clientes internos em uma empresa, mas quem de fato aprovará o projeto é o cliente.
- Responder a mudanças mais que seguir um plano
A mudança do requisito comentei no post sobre criação dos casos de teste, que tem alto impacto no Processo de Teste Ágil. Por isso reforço aos analistas e testadores, que tenham bom dialogo com o desenvolvimento do produto, isso ajudará muito no decorrer do processo. Esse talvez seja o pior de todos os problemas proposto, uma mudança radical do escopo de uma tarefa ou projeto inteiro, mas não esqueça que a criação dos casos de teste serão paralelos ao desenvolvimento, é um impacto paralelo e não como um gargalo posterior

O processo de Teste Ágil quando bem aplicado torna-se produtivo, gerando indicadores e encontrando uma boa gama de defeitos no produto.
Torna-se indispensável o uso de uma ferramenta de gerenciamento, por isso recomendo o TestLink pelo custo x beneficio da ferramenta, possibilidade da criação do Plano , dos casos de teste, dos papeis envolvidos, da execução de teste, do resultado e relatórios finais.

A Execução de Teste

1 O periodo de tempo para criação dos casos de teste inicia no planejamento e vai até o encerramento das tarefas do desenvolvimento. Observando a imagem, é neste período que todo ambiente e artefatos relevantes para o teste devem ser preparados, por exemplo, necessidade de banco de dados, arquivos ou dados especificos para uma execução de teste. Enquanto o Analista de Testes preprar os Casos de Teste, o Testador pode fazer essa tarefa, deixando tudo pronto para execução.

2 Essa linha pontilhada mostra o limite de tempo, imaginando uma linha de tempo de cima para baixo. Tenha sempre como meta trabalhar até este periodo. Quanto mais o Analista de Testes ter isso como regra, melhor será a administraçao do tempo.
Supondo que exista dois executáveis, um está pronto para o teste e outro ainda está em desenvolvimento, o Analista de Testes deverá priorizar os Casos de Teste para o aplicativo pronto e liberar o conjunto de testes para o Testador (Suite de Testes)
Um Plano de Testes pode ter diferentes ciclos de teste, portanto, se a tarefa estiver pronta e os casos de teste também, libere a execução o quanto antes. Lembre-se que tempo no processo ágil é fundamental.








3 Quando um conjunto de tarefas se torna algo executável, os casos de teste e o ambiente estará pronto. Neste nível o esforço será apenas em executar, contando as horas estimadas.
Testadores devem manter o foco apenas em concluir os objetivos do Plano de Teste.

Passe o Plano de Testes com  os Casos de Teste para o Testador e monitore os resultados das execuções, diariamente ou por periodos de horas. Questione sempre o andamento dos Testes, faça um resumo do andamento e entregue ao responsável do Desenvovimento.
A ferramenta TestLink cobre todas essas necessidades.
Processos de Desenvolvimento Ágeis normalmente realizam reuniões de curto prazo (15mim) por dia. Dar retorno do andamento dos testes aos desenvolvedores é tarefa do Analista de Testes.


No post seguinte trataremos de Registro de Incidente e do monitoramento do Processo de Teste Ágil, por isso não vou me aprofundar nestas questões agora.

Os Casos de Teste

1 Visualizando o processo, neste nível não existe nada que seja testável. Desenvolvedores estão transformando tarefas planejadas em aplicativos. É neste periodo que o Analista de Testes começa a criar cada Caso de Teste baseado em uma tarefa. Dependendo da tarefa, deve-se levar em consideração a criticidade, adicionando mais (ou menos) casos de teste. Em média, uma tarefa especifica pode gerar 3 casos de teste, exemplo: Tarefa: Adicionar login na ferramenta. Casos de Teste: Login valido, login inválido, campos em branco. 
Crie sempre Casos de Teste inválidos. A quantidade de bugs se escondem no que é imprevisivel, não vá pelo caminho feliz. 
Crie testes em situação adversas. Usuários constumam fazer qualquer coisa, menos o caminho feliz. Desenvolvedores se preocupam apenas com o que é válido em um processo.


2 As tarefas tornam-se algo testavel em diferentes periodos. Vamos imaginar que cada um dos aplicativos na figura tem um tempo de 2 dias de diferença. Independente do periodo em que eles estiverem prontos, os Casos de Teste estarão prontos para a execução. 
Se uma tarefa (ou conjunto) ficar pronto logo, certamente não era nada complexo e não será um Caso de Teste difícil de escrever. Tarefas simples geram Casos de Teste simples, na maioria das vezes.


3 Em métodos ágeis de desenvolvimento, tarefas podem ser criadas posteriormente ou poderá mudar o escopo. Mudança de escopo é um impacto pesado no nosso processo ágil de teste. Pode ser duas coisas: Faltou uma melhor conversa inicial no planejamento ou o caminho que seria tomado não é viável. Esteja sempre em comunicação com os desenvolvedores. Uma pequena mudança não tem grande impacto mas a mudança por completo de uma tarefa é descartar o trabalho feito e recomeçar.
Caso não seja alteração de escopo e sim adição de tarefas, será necessário a mudança da estimativa de tempo pro teste. Adicione mais 30mim para cada Caso de Teste. Na nossa proposta tinhamos 7:30 mim para testar tudo no projeto, adicionando mais uma tarefa, lá se vão mais 1:30mim (3x 30mim por CT), ou seja, 9horas de teste.

Apenas para reforçar, essas horas estimadas é de esforço de teste, somente execução dos Casos de Teste. Considere que o ambiente foi montado lá no inicio do projeto, são paralelos ao desenvolvimento. 9 horas é apenas o tempo em que o Testador executará os Casos de Teste. 
O tempo que temos para criar os casos de teste, praticamente terá uma data limite ao invés de uma hora estimada. Nosso periodo de criação começa após reunião inicial e vai até ter um aplicativo, algo testável. 
Este periodo é suficiente para planejar bons Casos de Teste e sobra tempo (experiência).


Na criação dos Casos de Teste é que começaremos a ter uma noção maior do projeto. Muitas vezes, as estimativas mudam e o Plano de Testes poderá ser alterado, como foi exemplificado na imagem.

O Plano de Testes

Já temos noção de que levará 2 semanas para a conclusão deste projeto. Sabemos também quais tarefas e qual importância de cada uma delas. Para obtermos um melhor resultado, iremos organizar toda a informação obtida na reunião (Sprint Meeting) em um Plano de Testes.
O Plano de Teste é o documento que estará presente em todas as fases do teste, sendo bem objetivo e dinâmico, irá conter informações necessárias e diretas para execução dos testes. Observe a imagem:

1 Com os dados obtidos na reunião, o Plano de Testes deverá conter o objetivo do projeto e o ambiente necessário. Alguns projetos são dedicados à determinados ambientes, outros exigem que sejam executados em ambientes especificos. Tendo essa informação, mobilize a equipe (ou alguém) para montar o ambiente especifico (caso ele não exista). Deixe tudo pronto, adiante o quanto antes o ambiente e não perca tempo. Antes de executar um caso de teste, o ambiente deve estar pronto para receber o novo EXE.
Gostaria de lembrar que estamos tratando de um método dinâmico de teste (Agile Testing), portanto, vamos focar no que é principal para o andamento, até mesmo no Plano de Testes.

2 O Plano de Testes deve conter uma estimativa de Casos de Teste e tempo pra testar. Eu sempre sugiro 3 casos de teste: 1 válido, 2 inválidos. Sendo assim, se neste projeto tiver 5 tarefas, resultará em 15 casos de teste. Estime 30 mim para execução de cada um deles.
Será utilizado 7:30mim para execução dos 15 casos de teste, correspondendo a 1 ciclo de testes. Lembre-se: isso é apenas estimativa.
Dependendo da criticidade de um projeto, mais casos de testes especificos pode ser adicionados, com técnicas especificas, Análise de Valor Limite por exemplo.
Testes não-funcionais (exemplo: carga, stress etc) podem ser adicionados como estimativa.

3 Este documento dirá quanto esforço de teste é necessário para atingir o objetivo do projeto,
para que um aplicativo atenda o requisito (tarefa ou mais de uma). O retrabalho gerado será trabalhado neste projeto. 
Se um aplicativo (conjunto de tarefas) não atenderem o proposto, o desenvolvedor irá corrigir o aplicativo e será feito um novo ciclo de testes, focado nas tarefas reprovadas.  Trataremos disso mais tarde.

A Ferramenta

Utilizaremos a ferramenta de gestão do ciclo de testes, Testlink. Não vou me aprofundar na ferramenta, pois ela é bem simples de usar, de fácil instalação e é gratuita. Existem bons tutoriais na internet que irão auxiliar na instalação e configuração.
Recomendo esta ferramenta pelo custo/benefício, pois ela antende todo o ciclo de teste, relatórios com gráficos, armazenamento, integração com bug trackers e sem nenhum custo para a empresa.

Todo o andamento de agora em diante terá como peça chave o TestLink, pois é nela que iremos registrar e criar cada documento necessário para a gestão deste projeto.

O Planejamento de Testes

Para que  o processo de teste seja eficiênte, ele deve começar  junto com o planejamento do produto. Normalmente as empresas tratam o Teste de Software como uma tarefa no final do processo. Em muitos casos, o teste em uma aplicação acaba tornando-se um gargalo ou sendo pouco eficiênte pelo curto prazo proposto pela empresa.
No nosso caso, temos apenas 2 semanas para trabalhar e não vamos aguardar o aplicativo estar pronto para começar a trabalhar nele. Mas como?
Observe a imagem:

Processo de Teste e Processo de Desenvolvimentos estão juntos mas são projetos distintos, nunca esqueça isso. Serão clientes um do outro, mas o desenvolvimento com um e qualidade com outro.
1 Quando os desenvolvedores se reunem pela primeira vez, para definir o que será feito, estará presente o Analista de Teste. Dependendo da empresa, existe mais papeis como Gerente de Teste, Coordenador , entre outros. Como estamos tratando de um método ágil de teste, irei propor aqui o Analista de Teste, supondo que exista Analistas e Testadores.
Mesmo sendo uma conversa (caso de métodos ágeis), irá gerar muitas informações, como ambiente, criticidade, impacto na mudança, integração. Tudo isso é valor e informação útil para um bom planejamento de testes.
Ter em mente e estar a par dos assuntos do desenvolvimento trará melhores resultados. 

Comunicação nesse tipo de método é fundamental, portanto, é obrigação do Analista de Testes questionar o desenvolvedor em reunião, de forma amigável, sempre com o compromisso com a qualidade, nunca pessoal. Boas conversas geram mudanças de escopo de grande valor, principalmente nesta fase inicial. Essa mudança agora evita retrabalho futuro, portanto, o trabalho do teste já começou.
 Lembre-se que o método é Teste Ágil (agile testing), não go-horse!


Será definido aqui a quantidade de tarefas e horas para cada aplicativo. Para o nosso planejamento, cada tarefa do desenvolvimento irá gerar Casos de Teste, que serão criados antes da execução (EXE).
 

O Desenvolvimento do Produto

No nosso exemplo de desenvolvimento ele funciona da seguinte forma:

1 Este é o inicio do Projeto de Desenvolvimento, onde os desenvolvedores se reunem para decidir como proceder e como será feito as alterações nos executáveis. No nosso exemplo, 3 aplicativos estão em questão. Durante a reunião de planejamento, é discutido tudo que se deve levar em conta em cada aplicativo e quais são os objetivos deste projeto.  Essa é a primeira etapa equivalente ao Planejamento do Escopo de Desenvolvimento, ou seja, a parte mais importante.
 O projeto de desenvolvimento tem um ciclo que se encerra a cada 2 semanas. Nesta reunião define-se a quantidade de esforço para cada aplicativo atingir seu objetivo.

2 Para cada aplicativo, serão necessárias tarefas a serem desenvolvidas e acrescentadas nos executáveis. Cada um dos itens, que pode ser correção, adição o melhoria gera uma tarefa. Dependeno do aplicativo, pode envolver muitas tarefas ou apenas uma. Como o processo de desenvolvimento é ágil, a única informação é o que será feito em cada tarefa

3 Ao concluir todas as tarefas, temos uma executável pronto. Quando todos os executáveis estiverem prontos, o projeto estará concluido, hipotéticamente em 2 semanas.


Esse processo pode parecer organizado. Tirando a imagem e apenas levando em consideração o escopo, essa é a realidade de muitas empresas de TI. Será neste exemplo ilustrado que irei apresentar o Teste Ágil (agile Testing). 
Imaginamos esse exemplo como um desenvolvimento ágil em um ciclo de pouco tempo, mas se você observar, qualquer método de desenvolvimento segue este padrão acima, sendo muito ou pouco formal em cada uma das etapas.

O Cenário

Vamos partir de um princípio, no qual é realidade de muitas empresas: Desenvolvimento sem documentação, sem um setor de Testes ou Qualidade do Produto bem definido, atendendo uma demanda alta de projetos e de muitas reclamações da parte de clientes, relacionado com bugs nos aplicativos que ela entrega. Essa empresa, tentando atingir um melhor resultado, passa a utilizar um método ágil de desenvolvimento. Desta forma segue desenvolvendo sem documentação, atendendo as reclamações e sem um setor de Teste definido.
 Este é o cenário que vamos partir para fazer o estudo do Teste Ágil (agile testing), evoluindo a cada post, mostrando hipoteticamente os erros e acertos mais comuns das empresas e a qualidade do produto.

Essa é a minha proposta, uma análise em um cenário critico. Pretendo postar também os assuntos de forma dinâmica, sem textos longos, com imagens e explicações quando necessário.
Gostaria de dizer a todos  que é possível  ter um setor de testes eficiênte, documentado , com niveis e fases bem definidos e com tarefas equivalentes a cada estágio de desenvolvimento.
O Teste Ágil (agile tesing) pode ser uma excelente alternativa nas empresas de TI de pequeno e médio porte ou em pequenos projetos especifico de uma grande empresa.