COMO SER ÁGIL NO TESTE DE SOFTWARE EM TRÊS PASSOS

Three-Steps-e1412973303266

Olá Pessoal, tudo bem?

Resolvi escrever esse artigo para contribuir um pouco no conceito de como ser ágil em Teste de Software com alguns passos iniciais para ajudar você que busca ter mais agilidade no seu trabalho como testador.

Continuar lendo

Agilidade em Testes de Software – O que é ser Ágil? Parte 02 de 03

agile-glossary

Olá Pessoal,

Dando continuidade ao post ALM – Agilidade em Testes de Software – O que é ser Ágil? – Parte 01 de 03 o que acredito ser um bom caminho desse tema as vezes polêmico.

Particularmente e longe da minha crença/opinião estar certa e além disso, amanhã posso tranquilamente mudar minha opinião, mas hoje creio que agilidade está intimamente ligada muito mais aos indivíduos (time, colaboradores, empresa) que fazem a atividade do que apenas no processo em si.

Claro que há processos que inibem você (que acredita que possui um pensamento ágil, assertivo, etc.) de pular partes desse processo devido a regras estabelecidas, mesmo que você entenda que aquela parte do processo é descartável, devido a uma obrigatoriedade legal como uma ISO ou SOX ou até por determinação da própria empresa.

Continuar lendo

ALM – Agilidade em Testes de Software – O que é ser Ágil? Parte 01 de 03

keep-calm-and-love-agil

Resolvi escrever esse post, depois que recebi um contato de uma amiga me pedindo se eu tinha materiais sobre Testes Ágeis. Então para deixar bem organizado, resolvi escrever um Post de 03 partes que, além de ajudar essa amiga, também deixar disponível caso alguém tenha interesse.

Primeiramente, antes de iniciar a leitura, gostaria de deixar claro que acredito particularmente que, todos os métodos, processos e frameworks são funcionais e bons, e tudo é questão de momento, tendências e realidades, conforme as necessidades de cada empresa e time. Que o objetivo desse post é apenas provocar uma reflexão sobre as tendências, se realmente temos o certo e errado dentro de processos e frameworks mundialmente utilizados e que tanto serviram a seus propósitos ao longo dos anos. E não sou um guru de testes ágeis, nem de DevOps, apenas estou expondo um pouco do que já vi e o conhecimento que tenho de ferramentas e processos.

Continuar lendo

ALM – Conhecendo um Pouco mais sobre ALM – Post 02 de 100 – Criando um Caso de Teste

Introdução

Olá Pessoal, o objetivo desse post é auxiliar na direção de uma criação de um Caso de Teste. Abaixo cito um exemplo de como poderiamos estar ordenando nossos artefatos dentro do nosso processo de desenvolvimento de software, e como eu criaria meus casos de testes. Claramente há diversas formas de abordagens, definições, fluxos, entre outros e cabe a cada empresa usar a sua da melhor forma, e abaixo o que explico, seria apenas, mais um exemplo de como poderia se organizar a criação de seus testes.

Um caso de teste deveria inicialmente ser associado a um requisito que por sua vez é associado a uma feature. A estrutura seria mais ou menos da seguinte forma:

image

Onde:

Feature – Desejo do cliente: Quero que meu carro ande a 220 km/h sem gastar muito combustivel. É muito comum nesse momento o cliente querer definir o requisito, e até poderia, porém seria importante entender bem o desejo dele primeiro. Digo isso, pois seria muito comum uma pessoa chegar a um mecânico e pedir – Instale um turbo no meu carro. E o mecanico instalar o turbo que ele acha que deveria, e não ser a melhor escolha. Por isso é extremamente importante uma conversa para entender os objetivos em questão.

Requirement – Como atingir o objetivo: Instalar um motor turbo no carro à diesel/alcool. Nesse caso é importante um estudo para que você não implemente algo que precisará de uma reavaliação para modificação do requisito em um curto espaço de tempo. Por exemplo, nesse caso, sabemos que a gasolina está para ser reajustada, sendo que se sua escolha seja a implementação de um motor baseado em gasolina, pode inviabilizar o projeto ou alterar o requisito, então é muito importante pensar em alternativas nesse cenário, pois se você não pensar, a concorrência vai!

Task Dev A – Tarefa de Implementação do Requisito – Ações para implementar o requisito: Montar os pistões do motor

Test Case A – Executar a ação desejada do cliente. Acelerar o carro a 220 km/h (baseando-se na Feature)

Test Case B – Avaliar no final de uma rodagem de 10 km, qual foi o consumo de combustivel. Comparar com o consumo de outro carro de mesmo peso, medidas e marca (baseando-se na feature)

Test Case C – Medir o óleo inicial e o óleo final consumido. (baseado em experiência, requisito modificado, testes não funcionais).

Em grande parte, um caso de teste é o ato de um usuário de um sistema, principalmente quando falamos de um caso de teste funcional.

Ou seja, a execução de um caso de teste é o retrato de uma atividade feita por um usuário do sistema, e também ações adicionais baseadas no conhecimento da regra de negócio, ambientes e histórico de indicadores anteriores.

Caso de Teste – Duração Curta

Não é regra, porém uma das caracteristicas de um Caso de Teste Funcional é seu tempo de duração ser curto. Ou seja, um Caso de Teste deveria ser, em grande parte, uma ação simples de um usuário, quando seu Caso basear-se em uma funcionalidade.

Tenha em mente que, você é o usuário e deve realizar a mesma ação que o usuário iria realizar, se um usuário demora 02 horas para conseguir gerar um simples relatório, possivelmente você está agrupando em um Caso de Teste, passos ou ações que talvez não fazem parte em si do Caso de Teste ou esse Caso de Teste deveria ser mais granular.

Caso de Teste – Classificação

É importante que você classifique a prioridade e tipos seus Casos de Testes, para que, quando for necessário a reexecução do mesmo, seja em um teste de regressão, revalidação de bugs, ou até um estudo de quanto custaria alterar um Requisito (pois esse custo deverá ser avaliado também no tempo de teste) não seje algo assustador e seus Casos de Testes sejam impedidos de serem executados, devido a questões de prazos de entrega.

image

Por isso mesmo que Casos de Testes são classificados em Funcionais, Não Funcionais, tendo subclassificações em desempenho, stress, usabilidade, entre outros.

image

Casos de Testes – Planejamento

Planeje bem seus testes, principalmente, tente torná-los mais granulares, inclusive com indices de importância para que você tenha condições de tomar decisões em quais testes você poderia abrir mão, quando seu prazo está se esgotando.

image

Por exemplo: Segmente seus testes de relatórios, classificando ou por objetivos similares, ou requisitos compartilhados que afetem seus casos de testes, para que seje bem produtivo esses testes.

Casos de Testes – Criando

Para se criar um Caso de Teste usando o Microsoft Test Manager, acesse esse post que escrevi a um tempo atrás que trás de forma detalhada como proceder.

ALM – Criando um Caso de Teste Funcional

Espero que ajude e até a próxima!

Alan Carlos
Technet Wiki Ninja

ALM – e-Book – Test Manager

Olá Pessoal!

Fiz esse e-Book para quem curte o Visual Studio Test Manager com uma coleção de artigos que escrevi no Blog e no Portal do TechNet Wiki.

Quem tiver interesse no material é só fazer o download, clicando aqui.

capaebooktestmanager

Espero que ajude a todos!

Alan Carlos

ALM – Test Manager – Executando Caso de Teste

Para executar um Caso de Teste no Test Manager, siga os passos:

– Execução do Caso de Testes

Feche todos os programas de sua Workstation que não fazem parte do escopo do Teste –> -Vá no contexto de Test –> Selecione o Caso de Teste –> Execute

image image

– Passos para abrir um BUG

No decorrer dos passos ao encontrar um BUG, tire um Print Screen com o Test Runner

Descreva o BUG de forma bem sucinta, pois o Test Runner coletará os dados como:

– Passos da execução

– Dados do computador e logs

– Telas capturadas

– Aplicações que estavam em execução

image

-Depois de aberto o BUG, assine o mesmo ao responsável, salve e feche seu teste que falhou.

image  image

image

– Relatório e Acompanhamento

Acompanhe a evolução do Requisito associado ao Caso de Teste que você executou e abriu um BUG, observe que no Relatório de Overview de Requisitos, o Requisito teve mudanças, com tarefas já concluídas e BUGS ativos no momento.

-Test Points – Três, devido as configurações de ambientes para um único caso de teste

-Horas completadas – das 27 Horas (Task de Desenvolvimento e Testes), 08 foram concluídas

-Test Results – dos 03 Test Points, 01 foi executado com falha

-No momento há um BUG ativo para o Requisito

image

image

image

Essa rastreabilidade acontece pois:

– Há um Requisito Funcional

– Há Tarefas (Tasks) com Horas de Desenvolvimento e Testes associadas como Child a esse Requisito;

– Há Casos de Testes associados como Tests a esse requisito;

Então, conforme você abre um BUG no Caso de Teste associado, automaticamente o BUG é relacionado ao Requisito e informado no relatório (conforme o ciclo de atualização do Reports do SQL Server do TFS).

image

E conforme você apontar as horas (diminuição ou aumento) em sua Tarefa de Teste (Não Caso de Teste) será demonstrada a evolução no Requisito, até o estágio ser completado.

– Realizando novamente o Caso de Teste

Depois do BUG corrigido, resete o Teste para Ativo e execute novamente.

image image  image

Depois de concluído o caso de teste, finalize a Tarefa de Teste (vinculada ao requisito).

image image

Importante:

O Caso de Teste deve ficar sempre com status de Ready, pois seus estados são:

-Ready: Pronto para ser usado quando desejar

-Design: Está sendo preparado (configurado)

-Closed: Não será usado mais

image

Acompanhamento dos Relatórios

Observe que o Relatório de Overview de Requisitos, se atualizou, demonstrando que o requisito está completo.

image

Depois de concluido todos os testes, e finalizado o Plano de Testes, mude seu Status de In Progress para Completed.

image

image

Pronto, seu Plano e Casos foram executados com sucesso.

ALM – Test Manager – Criando um Plano de Testes (End-to-End)

 

Criando um Plano de Testes (Passo a Passo)

– Montagem do Plano de Testes

Inicie seu Test Manager para criar um novo Plano de Testes;

Dê um Nome ao Plano de Testes;

Associe o Plano de Teste a Versão ou Iteração (conforme definido no planejamento);

image   image

– Configuração do Plano de Testes

Vá na em Lab Center à Test Settings:

– Configure os coletores, conforme a necessidade  do time de desenvolvimento para identificar BUGS com as informações coletadas.

image

Verifique as configurações do Plano de Teste:

-Ambientes que serão homologados (Sistemas Operacionais, Bancos de Dados, Navegadores): Nesse passo, é importante que você tenha um laboratório que tenha templates de ambientes, para que a preparação de um ambiente de testes não leve dias e sim horas ou até minutos!

Obs.: Se você desejar que seu Caso de Teste automaticamente assuma as configurações do TCM, deixe a opção  Default habilitada. Cada ambiente é um Ponto de Teste (Test Point).

image

– Crie as Suites de Casos de Testes

Definido em seu Planejamento, crie as Suítes necessárias. Importante salientar o uso de Clones de Suítes e Casos de Testes, para dar velocidade nessa etapa. Isso é feito no contexto de Planejamento. Nesse Caso, iremos definir uma Suíte Estática baseada em Casos de Testes.

image   image

Exemplo:

Suites de Testes Funcionais  e suas subcategorias:

Adequação, que mede o quanto o conjunto de funcionalidades é adequado às necessidades do usuário;

Acurácia (ou precisão) representa a capacidade do software de fornecer resultados precisos ou com a precisão dentro do que foi acordado/solicitado;

Interoperabilidade que trata da maneira como o software interage com outro(s) sistema(s) especificados;

Segurança mede a capacidade do sistema de proteger as informações do usuário e fornecê-las apenas (e sempre) às pessoas autorizadas. Segurança também pode estar dirigida em, processar gerar e armazenar as informações.

Conformidade trata da padronização, politicas e normas de um projeto.

Importante:

Participe das reuniões de alinhamento das demandas para que o Custo de BUG seja reduzido com Casos de Testes mais próximos a realidade do cliente.

image

Lembre-se que dependendo da abordagem da empresa (Escola de Testes de Software), você deverá validar se a implementação do Requisito foi feita com sucesso, mas também validar se o objetivo do negócio foi atendido, e só participando, conhecendo o negócio e entendendo a demanda (feature) você poderá chegar nesse cenário.

image

– Crie seu Caso de Teste

Crie seu caso de teste, baseado no requisito e no negócio e escreva os passos (pode iniciar com passos básicos). Coloque valores de parâmetros com @ para um futuro Record & Play. O Caso de Teste é a ação de execução de um usuário.

image

Relacione seu Caso de Teste ao Requisito (Tests) –> Mude o Status do Caso de Teste para Ready –> Faça isso para todos os Casos de Testes.

image

Abra o Requisito que está associado ao Test Case –> Crie a Tarefa de Testes (Tasks) –> Estipule o tempo de execução (já definido no Planejamento) –> Associe a Tarefa ao Requisito como “Child”

image

Insira as informações de tempo de execução, estado, disciplina, entre outras informações.

image

image image

Observe a hierarquia de Requisitos à Tarefas:

image image

Observe que no Relatório de Overview de Requisitos, o Requisito está com as horas restantes, pontos de testes e resultados de testes prontos para começarem a ser contabilizados. Conforme as tarefas (vinculadas aos requisitos forem sendo concluídas, o percentagem de horas irá ser carregada e as horas remanescentes serão diminuídas.

image

Pronto, agora é só executar os testes.