Arquivo da tag: Testes

O papel do tester em várias fases de um projeto Scrum

O Scrum é composto por várias fases durante o processo de desenvolvimento do software, contando com a criação do Product Backlog, Planejamento da Sprint e muito mais.

Uma das vantagens do Scrum na minha visão é que permite uma maior iteração entre os membros da equipe, incluindo o Tester!

Vale ressaltar que algumas atividades podem variar de acordo como cada equipe trabalha, porém ao meu ver devemos aproveitar ao máximo as pessoas da equipe para que possam atuar cada vez mais no time.

Portanto neste artigo abordarei sobre a experiência que estou passando com meu time atual e minha visão do que mais poderia ajudar.

Vamos começar pelo início do projeto, quando temos nossos primeiros contatos com o cliente, no levantamento para o Product Backlog. Nesta fase o Analista de testes pode auxiliar o Scrum Master levantando dúvidas pertinentes e começando a adquirir um conhecimento sobre o que está por vir para o desenvolvimento do Software.

No Grooming e na criação de critérios de Aceite é uma fase muito importante, pois ajuda a ter conhecimento sobre as Regras de Negócio e as características do sistema. Na minha opinião, se um Critério de Aceite bem elaborado já é melhor que um documento de Caso de Uso para entendimento do negócio, poder participar de uma reunião dessas é melhor ainda! Isso nos auxilia para o planejamento dos Testes futuros e possuir um melhor embasamento para a Planning.

Outro ponto que podemos ajudar é na definição de como o sistema irá funcionar, pois muitas vezes a forma que o cliente especifica o sistema não será de fácil uso, cabendo a nós tentar se passar pelo papel de usuário e dar sugestões para deixar o sistema prático.

Na reunião de Planning, podemos atuar junto ao time na estimativa, ajudando a decidir o que poderá ser feito na sprint. Não é porque não estaremos desenvolvendo que não podemos participar das estimativas, pois temos que levar em consideração a complexidade da funcionalidade e o nosso tempo para planejamento e realização dos testes.

Em alguns casos necessitamos de mais tempo para testar do que desenvolver, pois muitas vezes precisamos testar o layout de uma aplicação Web em vários navegadores, criar vários cenários para garantir que aquela Regra de Negócio esteja correta e retestar os defeitos que foram surgindo durante o desenvolvimento.

Portanto, é muito importante participarmos da planning para que fique claro o motivo da estória X possuir um valor mais alto para o Tester.

Durante a Sprint inicia nosso trabalho de planejamento, identificar e criar nossos cenários para conduzir os testes, além disso podemos acompanhar o desenvolvimento, tentando antecipar caso exista alguns defeitos para que já sejam corrigidos!

Se possível comente com a pessoa que liberou para testes algo que ela criou se realmente ficou bom, principalmente quando é algo difícil e não houve muitos problemas, afinal reconhecer um bom trabalho sempre é bom e não precisa surgir somente de superiores!

Na daily, como todos os outros membros da equipe temos a missão de passar nosso status para o time. Nessa hora é muito importante passar um feedback do status dos testes, como está o sistema, se está surgindo muitos defeitos ou se existe algo que te impede de realizar algum teste, como por exemplo, um defeito impeditivo ou até mesmo o sistema fora por um bom tempo.

Final de Sprint e vamos para a Demo! Nesta fase a atividade é simples e clara, apresentar para o cliente o que foi desenvolvido durante a sprint! Nesta hora também é importante coletar a opinião do cliente para saber se tudo está de acordo como ele deseja e se está satisfeito com o resultado.

Para completar, vamos para a Retro para coletar as considerações de cada membro da equipe sobre a sprint. Nas suas indicações sobre o que temos que continuar e o que precisamos melhorar sobre como foi os testes, como por exemplo, se houve muitos defeitos graves que envolviam regras de negócio ou simples ajustes, como foi a correção dos mesmos, foi rápida e efetiva ou no reteste dos defeitos o problema persistiu ou surgiu outro defeito em consequência, etc.

Como podemos ver, o Tester pode ajudar em várias fases de um projeto que roda Scrum, não ficando somente na atividade de planejar e testar, agora cabe a equipe envolvê-lo mais e claro, haver uma pró-atividade do próprio!

Caso você  tenha alguma dúvida sobre Scrum e esteja iniciando seus estudos, você pode conferir um artigo que criei quando comecei a estudar sobre o assunto: Clique aqui.

Gostaria de aproveitar para agradecer a um amigo pela revisão do artigo, obrigado pela ajuda Elton Saheki!

Até a próxima!

Vinicius Sabadoti

Anúncios

Criando Mapas Mentais para planejamento de testes

Primeiramente, gostaria de começar este artigo dando uma prévia sobre os mapas mentais. Segundo o wikipédia, Mapa mental é o nome dado para um diagrama, voltado para gestão de informações. Um mapa mental pode nos ajudar para os estudos, armazenar idéias, auxiliar na criação de manuais e também para a organização de nossos Casos de Testes!

Existem vários programas que auxiliam-nos na criação, dentre eles gratuitos e pagos. Para escolher o seu basta ver de acordo com sua necessidade. Atualmente uso a versão gratuita do Xmind e a única coisa que sinto falta é de poder gerar um PDF dos meu mapas (coisa que a versão paga faz). Se você tiver interesse em ver vários exemplos de Mapas Mentais, basta dar uma “googleada”.

A idéia de usar os mapas mentais surgiu de acordo com a minha necessidade atual, quando comecei a trabalhar com a Metodologia Scrum. Conheci os mapas mentais através de outros amigos da área que trabalham com testes e logo me interessei pela simplicidade.

Diferente de um Caso de testes, onde crio um passo-a-passo para realizar um teste, no mapa mental, escrevo alguns itens que me lembre sobre o que deve ser validado. Se preferir, colocar alguns itens do critério de Aceite podem ajudar também.

A organização pode ser feita como você desejar. Se você estiver trabalhando com SCRUM você pode criar um mapa mental para cada estória, sendo os itens principais cada task de testes. Para cada task, podemos descrever o que deve ser validado.

Para simplificar, veremos um exemplo abaixo, que trata sobre os testes de compatibilidade nos navegadores:

Como podemos ver, na imagem acima coloquei somente o que devo me lembrar para fazer os testes de compatibilidade, onde inclui os nomes dos navegadores.

É possível incluir imagens e símbolos nos mapas mentais que ajudam no controle dos testes. Neste caso, os símbolos com o V em verde, são os testes que já realizei, enquanto os X estão pendentes. Com o símbolo de exclamação, uso-o para identificar que ocorreu um problema, precisei abrir um bug para ele.

Podemos também utilizar para colocar regras de Negócio, validação de Campos, conforme exemplo abaixo:

Na imagem acima, para a primeira task cito todos os campos da página para validação e na segunda task, algumas regras para validação. Uma outra abordagem que poderia ser feita é escrever em forma de Ação>Reação, não seria bem um ponto de Ação e Verificação como em um caso de testes, mas uma coisa mais ampla como: 1. Realizar Compra com Cartão de Crédito Válido>Sistema confirma o pedido e envia e-mail ao cliente informando os dados da compra.

Vejo o uso dos mapas mentais uma alternativa interessante, porém devem ser avaliados de acordo com a situação e a necessidade de cada um. Falo isso como por exemplo no meu caso, onde não preciso ter que necessariamente criar casos de testes, e não preciso ficar evidenciando todos os passos que executo quanto estou realizando meus testes.

Avalie, experimente e se quiser teste esta maneira de mapear seus testes, quem sabe ajude com o seu dia-a-dia!

Abraços e até a próxima!

Vinicius Sabadoti

Obs: Nesta última imagem acabou saindo a primeira também no slide, infelizmente não consegui arrumar no WordPress. Toda vez que insiro mais de uma imagem ele acaba fazendo isso.  Se alguém souber como acertar dá um dica! Valeu ; )

27/02/2011 – Atualizando:

Pessoal estou atualizando o post e inserindo mais duas opções de programas para criação de mapas Mentais. Agradeço ao Maurício e ao Lucas pelas dicas de outros programas:

Freemind: http://freemind.sourceforge.net/wiki/index.php/Main_Page

MindMeister: http://www.mindmeister.com/pt


BVT – Saiba como é o teste de BVT e entenda a sua importância.

O teste de BVT (Build Validation Test) sempre é realizado quando existe uma atualização no código do sistema e será introduzido no ambiente atual.
Esta atualização pode ter sido feita pelo motivo da chegada de uma nova funcionalidade para testes ou até correção de defeitos, para que assim a equipe de teste possa realizar os retestes dos defeitos em abertos.

O intuito do teste de BVT é testar toda a funcionalidade do sistema e podemos definir o escopo de acordo com a necessidade, tempo disponível, etc pois em sistemas de grande porte esta validação poderá durar um dia inteiro ou até mais. Geralmente as verificações são feitas com a maioria dos cenários positivos, com uma atenção maior nas funcionalidades que geram mais impacto, onde houveram a atualização do código e correção do defeito.

Para a execução destes testes geralmente não utilizamos nenhuma ferramenta e não há necessidade de coletar as evidências para tudo o que for validado, mas sim quando um defeito for encontrado.
Para o auxílio do testes, pode ser utilizado uma lista com todas as funcionalidades contendo os itens mais importantes.
Quando um defeito é encontrado é muito importante verificar a criticidade e qual o impacto que ele irá gerar, seja tanto na funcionalidade quanto para a execução dos testes que estão por vir após a BVT.
Quando são encontrados vários defeitos de grande impacto, a melhor decisão é não autorizar o deploy e continuar com o ambiente atual sem a atualização deste novo código.

Com assim, não autorizar nova build?

Isso mesmo, imagine uma situação em que a equipe de testes possui uma grande quantidade de Casos de Testes ainda para executar e a build que está validando possui um defeito que impacta diretamente com os testes e caso a equipe autorize a atualização do ambiente irá impactar e atrasar a execução dos Casos de Testes pendentes.

Mesmo que a equipe fique sem o novo código que liberariam alguns defeitos, ela pode continuar com os testes ainda pendente. Nesta situação será mais vantagem continuar como está do que liberar uns defeitos para reteste.
Porém esta regra vale para o outro lado. Muitas vezes é interessante liberar uma build mesmo que possua um ou mais defeitos encontrados na validação, para isso deve-se avaliar a criticidade dos mesmos e se a build irá liberar mais Casos de Testes do que impactar.

Até agora estamos falando quando encontramos um defeito ou não, agora imagine que a build possui um defeito grave e infelizmente ele não foi descoberto? Isso pode acontecer e com certeza o dano será maior! Então nem preciso falar o quão importante este teste é e que ele deve ser verificado com muita atenção pela equipe de testes.

Por fim, terminada a validação devemos analisar e decidir o que deverá ser feito. Caso a build seja aprovada, basta aguardar o deploy e mão na massa ; )

Abraços!

Vini Sabadoti


Carreiras em TI – Testador de Jogos

Olá pessoal!

Este é mais um post para falarmos sobre carreira! Vamos falar sobre testes, porém sobre testes em Jogos eletrônicos!

Primeiramente gostaria de agradecer ao Bruno Cicanci do blog Game Developer (http://gamedeveloper.com.br/blog/) por ter me passado o contato de um profissional da área, o que permitiu que eu fizesse a entrevista!

O segundo agradecimento é ao Ronaldo Coimbra que dedicou um tempinho e paciência para responder algumas perguntas.

Atualmente Ronaldo é QA Lead e Preload Content Manager na GLU Mobile do Brasil.

Vamos ao que interessa! Segue abaixo a entrevista:

1. Como você entrou na área de testes de jogos? 

No terceiro semestre da faculdade de Jogos Digitais (Unisinos – São Leopoldo), começei a procurar mais sobre as oportunidades de carreira na área de jogos. Depois de um tempo, você percebe que existem duas grandes portas de entrada: QA (quality assurance – tester) e programação. Apesar da minha faculdade dar ênfase à programação, sempre tive mais interesse em design e acabei optando por entrar como QA mesmo, pra entender mais sobre os jogos e o processo de certificação (aprovação) desses jogos. O que fiz, então, foi avaliar empresas brasileiras que mais se encaixassem com meu perfil e mandei currículos (fui muito seletivo e mandei para umas 4 empresas apenas). Ter um bom portfólio e saber se relacionar e tratar bem outras pessoas faz uma grande diferença na hora de conseguir um emprego. Acabei vindo para São Paulo, onde havia mais ofertas na área e empresas mais bem estruturadas e fui escolhido para trabalhar na GLU Mobile como tester. A empresa chegou a me chamar para ser programador, mas realmente não houve interesse de minha parte.

2. Como é a diferença entre testar um Software e um Jogo? 


O primeiro passo aqui é diferenciar um software comum de um jogo. A primeira diferença é a subjetividade que está presente nos jogos. Você não tem um objetivo bem definido de armazenar e manipular dados (seja um banco de dados ou um programa de arte como photoshop). O objetivo varia com o jogo que deve envolver o usuário psicologicamente ao promover um desafio, geralmente atrelado a uma história e mecânicas de jogo (usabilidade e interatividade) que variam bastante de jogo pra jogo. Então, a primeira diferença é que um teste de jogo não só precisa passar por testes padrões que sejam aplicáveis a qualquer software, mas também por testes subjetivos que são exclusivos de cada jogo pra verificar quão divertido, desafiador e acessível está o jogo.
Outra grande diferença é que jogos são softwares que abrangem uma série de áreas diferentes de conhecimento. Enquanto a maioria dos softwares são especializados em determinadas tarefas, jogos visam um público de massa e equilibram uma série de conhecimentos num só aplicativo: arte, programação, design, música, roteiro, direção, marketing, hardware… Isso significa que o tester precisa ser mais versátil e avaliar o produto sob várias perspectivas. A grosso modo, um software de música precisa agradar músicos. Um jogo precisa agradar músicos, professores, cientistas, crianças, velhos… Enfim, o objetivo é promover lazer para quem tiver interesse.

3. Vocês seguem alguma metodologia para realizar os testes nos jogos? 

Sim. Não posso entrar muito em detalhes porque existem regras de proteção dentro da empresa onde trabalho com relação a isso, mas basicamente, o jogo passa por uma avaliação subjetiva intensa e, quando está aprovado nesse quesito, passa por avaliações padrões de software. Todos os procedimentos são estruturados em planilhas de testes que são constantemente atualizadas usando informações que são coletadas ao longo dos projetos. Existem diversas ferramentas que são utilizadas também, com os mais diferentes objetivos: Ferramenta de distribuição de testes, ferramenta de armazenamento de informações, ferramenta de emulação de software, ferramenta que analisa hardwares (lembrando que minha empresa trabalha com jogos para celulares e por isso precisamos entender cada aparelho – hardwares diferentes – tamanho de tela, memória, processamento, media player, etc).

4. Que tipo de testes são realizados em um jogo? Exemplo: Verificar cores, colisões, etc 

Primeiro, a análise subjetiva analisa diversão, grau de desafio e acessibilidade. Cada jogo tem sua própria metodologia, pois cada jogo é único.
Em segundo, é feita uma análise mais básica de software: instalação, usabilidade/interatividade, aparência, som, interrupção (quando alguém recebe uma ligação no meio do jogo, por exemplo), testes específicos relacionados às especificações dos aparelhos.

Enquanto isso tudo ocorre, a equipe de Marketing está sempre atenta em relação a nichos de mercado, oportunidades e capacidade de vendas. Apesar disso não ser um teste em si, se for determinado que o jogo não vai vender, ele provavelmente vai ser cancelado ou às vezes será deixado “on hold” (em espera), dependendo em que etapa do processo esteja.

5. Para qual plataforma de jogos você prefere realizar os testes? (Mobile, Web, Console, etc). 

Eu particularmente não tenho muita preferência na hora de testar (se o assunto fosse desenvolvimento e não testes, minha opinião seria bem diferente). Cada um tem suas especificidades mas, no fundo, todos acabam sendo interessantes e divertidos. Algo que muda muito de uma plataforma pra outra é a quantidade de testers necessária. Um jogo de console geralmente precisa de vários e vários testers e ainda assim, algumas empresas fazem os chamados “open betas” onde usuários interessados nos jogos podem experimentá-los desde que dêem feedbacks e reportem bugs para a empresa. Mobiles geralmente são jogos mais simples que usam de 2 a 5 testers por jogo. Web… bom, temos empresas que nem tem testers e isso fica por conta dos próprios programadores.
Outra diferença é que, como jogos para consoles são mais demorados e grandes em termos de ambiente e mecânicas, cada tester geralmente fica focado num aspecto específico ou num momento específico do jogo. Já Web e mobile, os testers geralmente passam por todo o jogo. Vale citar que as diferenças entre Consoles e Mobiles vem diminuindo, com lançamentos como Iphone e Android. Jogos mobile estão ficando mais acessíveis, rendendo muito dinheiro e tendo possibilidades de se transformar em big hits, devido à melhoria na tecnologia mobile. Há pouco tempo atrás, jogávamos snake (aquele jogo da cobra que tem que pegar os pontos ou frutas na tela). Hoje, já temos jogos em 3D e com física.

6. Qual é o defeito que vocês mais encontram quando realizam os testes em um jogo? 

Certamente é interrupção. A GLU faz jogos para mais de 400 aparelhos. Fazer um jogo para cada celular seria impossível, então geralmente agrupamos devices parecidos que usam uma “build” em comum. Build é uma versão especial do jogo preparada para funcionar em determinado grupo de aparelhos. Cada celular tem sua forma de manipular eventos no aparelho (como receber uma ligação no meio da execução de um aplicativo), então apesar dessa estratégia de grupos dar bem certo em relação a memória, tamanho de tela, som, etc, acaba deixando a desejar na parte de interrupção.

7. Quais são os requisitos para quem deseja começar a trabalhar na área? 
Essa é a parte boa da história! Você só precisa ter boas características pessoais: Vontade, garra, boa comunicação, pró-atividade, disposição, entre outras. E, claro, existem algumas coisas que são bonus: jogar bastante, ter uma formação na área, saber programar, ter experiência com testes… Acontece muito da empresa estar em busca de novos talentos e convocar pessoas nas próprias universidades e, para medir o potencial dos candidatos, usamos algumas técnicas e dinâmicas em grupo. Muita gente tem medo de dinâmicas de grupo mas, como tester, você precisa no mínimo reportar bugs para os programadores. Saber conversar, dialogar, mostrar sua opinião e aceitar a opinião dos outros é totalmente necessário em uma equipe e ponto final.

Resumindo, funciona da seguinte maneira: Processos, nomes e ferramentas, a empresa ensina. Já educação, pró-atividade, empenho e disposição, a empresa precisa muito, pode ajudar a conseguir, mas não tem como ensinar do zero 😉

Pessoal, espero que vocês tenham gostado assim quanto eu! Aproveito para agradecer novamente ao Bruno e ao Ronaldo!

Abraços!


Primeiros passos com Testes de Performance

Pessoal, neste post gostaria de fazer uma pequena introdução sobre testes de performance. Neste caso, não irei falar muita teoria e sim alguns itens essenciais para iniciar os estudos.

Atualmente estou participando de uma célula de estudos referente ao assunto e irei aproveitar pra postar um pouco no blog o aprendizado, pois não é que falam que quando ensinamos aprendemos duas vezes? Acredito que sim.

A minha intenção é criar vários artigos relacionados ao tema, e manter sempre atualizado este post, pois ele será o “start up”, um guia para começarmos os estudos.

Segue abaixo alguns itens que na minha visão é necessário para começar a estudar performance, caso alguém que já atua na área quiser sugerir algo, fique a vontade para colocar nos comentários, será de grande valor a ajuda.

Bom, chega de balela e vamos começar a falar sobre o assunto e conhecer do que precisamos para entrar no mundo dos testes de performance:

Gostar de leitura.

Não há como fugir! Existe muito conceito teórico sobre testes de performance, e se você quer ser um profissional da área, é obrigatório a leitura. Tenho certeza que você não vai querer ficar “boiando” quando conversar com algum profissional da área e discutir alguns conceitos como: load balancer, Throughput, Think Time, entre outros (sentiu o drama né?).

Inglês.

A maioria dos materiais de qualidade sobre o assunto que você encontrar na internet estão em inglês, portanto quanto mais conhecer o idioma melhor. Sem contar que a maioria das ferramentas pelo meu conhecimento estão em inglês. A ferramenta da Rational, Rational Performance Tester, até possui o idioma português, porém mesmo assim o interessante é utiliza-lá em inglês para praticar o idioma.

Conhecimento em programação.

Para executar estes tipos de testes é necessário um bom conhecimento em programação.

Neste caso, é importante saber programação, pois para alguns testes você irá reparar que não basta somente gravar um script de testes.

Há a necessidade de fazer um código, por exemplo, para gerar o CPF para inserir no sistema toda vez que o teste for executado, e você não vai poder colocar sempre o mesmo valor (é ai que entra a programação, você irá criar um código customizado para o seu script fazer esta tarefa).

Se você utilizar a ferramenta Rational Performance Tester (Ferramenta IBM), você utilizará a linguagem Java para codificar e caso utilize o LoadRunner (Ferramenta HP), poderá optar pelas linguagens C, Java ou Visual Basic.

Conhecimento em várias áreas de TI

Existem várias razões que podem impactar a performance de um sistema, seja uma query que foi mal elaborada, um problema na rede, consumo da memória do computador, etc. Portanto, neste caso quando você se deparar com algum determinado problema que ocorre, ficará fácil direcionar sua pesquisa ao foco do problema.

Infra-estrutura:

Diferente do mundo da programação, para os testes de performance instalar a ferramenta não siginifica que você conseguirá estudar e fazer exercícios práticos. Pois precisamos de uma aplicação, onde toda a funcionalidade dela esteja OK (de nada adianta testar performance se ela possui problemas em sua funcionalidade).

Sem contar que envolve toda uma infra-estrutura necessária (hardware potente, boa rede, servidor, etc).

Até o momento da minha jornada, deparei com estes itens para continuar com os meus estudos, porém conforme eu vou descobrindo novidades irei atualizando este post.

No próximo artigo sobre testes de performance irei citar algumas leituras e tentarei abordar o assunto mais para o lado técnico.

Até a próxima!

Abraços.


8 dicas para uma escrita de Casos de Testes

Para as execuções dos testes funcionais, é comum a Criação de um Caso de Teste para a execução de cada condição de teste identificada pela equipe.

Geralmente este documento inicia falando sobre o objetivo do teste, seguido por uma pré-condição, que lista todos os itens ou condições que devem estar disponíveis para realizar o teste.

Em seguida, descrevemos a pós-condição que possui uma breve descrição do que deverá acontecer no término do teste.

Finalmente, partimos para a descrição do passo-a-passo, onde para cada passo descrito deve conter um ponto de verificação citando o resultado do passo executado.

Descrevendo desta maneira, temos a impressão de que tudo parece ser muito simples e fácil, basta seguir os passos descritos e os testes poderá ser executado facilmente.

Muito bom se fosse verdade! Se o Caso de Testes não for bem escrito, poderemos correr o risco de perder uma execução do teste e recomeçar tudo novamente.

Abaixo, cito 8 itens que acho interessante ficar atento quando criamos um Caso de testes:
1. Defina bem a pré-condição do teste:

Na minha opinião, definir muito bem a pré-condição poderá garantir 50 % da execução dos testes. Quando ela é bem descrita não corremos o risco de perdermos o teste, pois é muito desconfortável deparar com um passo pedindo para executar uma ação no sistema que pode não estar preparada, pois não foi citada na pré-condição. (simples exemplo: pedir a exclusão de um usuário específico cadastrado, e na pré-condição não citar a criação de um usuário para excluir).

Escreva de forma clara a pré-condição, se necessário faça como se fosse um passo-a-passo mesmo. Cite em ordem de prioridade as ações que devem ser feitas, como deve ser criada a massa de dados para o testes e o que deve ser feito por primeiro, segundo, etc.

Deste maneira o testador não irá descobrir somente no momento da execução o que devia ter preparado antes de iniciar os testes.

2. Escreva os Casos de Testes conforme citado no Caso de Uso.

O Caso de Uso contém todas as informações necessárias de como o sistema deve funcionar. Portanto, desenvolvedores e testadores não precisam imaginar ou supor como deve funcionar o sistema (salve exceções, em que há necessidade de discustir algumas regras).

Crie os Casos de Testes baseado no Caso de uso, assim a chance do sucesso dos testes será grande.

Um bom ponto de atenção, é que devemos sempre estar atentos com as atualizações dos Casos de Uso, pois muitas vezes as regras são alteradas e consequentemente pode ser necessário atualizar os Casos de Testes.

Nem todo Caso de Uso pode ter sido escrito de forma clara e conter todas as informações necessárias, neste caso não tenha medo de procurar o Analista de Requisitos que escreveu o documento.

3. Defina um bom título para o Caso de Testes.

Sei que não é uma tarefa fácil escrever em poucas palavras um bom título para o caso de Testes. Se possível coloque no Caso de Testes se cenário a ser testado é uma condição positiva ou negativa e o que será feito.

Muitas vezes o sistema a ser testado possui uma grande quantidade de Caso de Testes criados, portanto definir um bom título poderá permitir um acesso fácil para eventuais consultas destes documentos.

4. Cuidado com o português (escrita).

Este é um ponto que não só devemos tomar cuidado com o português na escrita do Caso de Testes, e sim com o nosso dia-a-dia. Muitas vezes, os Casos de testes são revisados por um membro da equipe e chegando até ao cliente do sistema para revisão do mesmo.

5. Numerar os Passos.

Esta é uma boa forma de organizar melhor os passos, auxiliando durante a execução dos testes. A numeração nos passos permite o testador se organizar melhor com os passos e caso ocorra a necessidade de parar os testes por um minuto, ele saberá em qual passo voltar.

6. Escreva os passos na forma imperativa

Use as palavras na forma imperativa, como “Digite um nome no campo”, “Escolha uma opção”, etc. Utilizando estes termos passamos a mensagem de que realmente deve ser feita uma ação e organizamos melhor nossos casos de testes seguindo um padrão na escrita.

7. Seja claro com os pontos de verificação.

Nunca deixe dúvidas com os pontos que devem ser verificados. Troque frases como: “o sistema PODE exibir uma mensagem” por “o sistema DEVE exibir uma mensagem”. Desta maneira não deixamos dúvida do que pode acontecer ao executar aquele passo e se acontecer algo diferente do descrito, teremos um defeito.

8. Atenção ao colocar imagens e nome de Campos.

Se o Caso de Teste não possuir o objetivo de verificar a usabilidade e o layout do sistema, tome muito cuidado ao citar os nomes do campo.
Como já citado, os Casos de Uso podem sofrer por atualizações que são impactadas no sistema, fazendo com que seja necessário mudar algum layout do sistema ou campo fazendo com que fique diferente do citado no Caso de Testes.

Por mais que alguns pontos citados parecem ser óbvios, quem já passou pela execução e criação de Casos de Testes sabe que na realidade é diferente. Sempre busque melhorar os Casos de Testes, pois com certeza todos da equipe tem a ganhar.

Não tenha medo de escrever demais, ou deixar o Caso de Testes comprido, desde que haja a necessidade. É melhor as vezes pecar pelo excesso do que deixar faltando algo!

Caso queiram citar mais algum ponto sintam-se livres para citar nos comentários que será muito bem-vindo!


Aplicando a Técnica 5W1H no processo de abertura de defeitos

Aplicando a técnica 5W1H em abertura de defeitos.

Semana passada participei de uma pequena reunião com a minha líder do projeto, onde ela apresentou a técnica 5W1H e discutiu sobre o processo de abertura de defeitos. Ela nos apresentou uma técnica que surgiu na área de qualidade que pode ser aproveitada em nosso dia-a-dia e achei interessante compartilhar neste artigo.
Primeiramente vamos ver um pouco sobre a importância de abrir um defeito com qualidade e em seguida sobre a técnica 5W1H e como podemos utilizá-la no processo de abertura de defeitos.

A importância de especificar um defeito com qualidade.

De nada adianta o testador realizar um bom teste e na hora de reportar um defeito para o programador não o fazer com eficiência. O defeito a ser aberto deve ser claro e possuir informações realmente necessárias.
Quando o defeito é objetivo e claro, a equipe ganha tempo e evita desgastes desnecessários, pois o defeito é validado com facilidade pela pessoa responsável e é enviado ao programador que compreende logo o defeito e trabalha na solução.
A maneira da escrita do defeito varia de cada profissional e acaba sendo em minha opinião uma espécie de identidade do testador. Identidade? Sim! Pois ao longo do trabalho o programador/gerente de defeito vai conhecendo o trabalho do testador que ao ler a descrição do defeito sabe quem o reportou.
Por outro lado, mesmo que cada um possua sua “identidade” nos defeitos, existem itens essenciais que não podem faltar na descrição do mesmo e para isso podemos utilizar a técnica 5W1H.

A Técnica 5W1H:

Esta técnica é muito conhecida na área de qualidade, marketing, TI, entre outras. O 5W1H ajuda na investigação do problema e com as informações obtidas com as 6 perguntas básicas, oferece uma respota clara e objetiva. Com esta técnica podemos adaptá-la com o processo de abertura de defeitos.

Ela é composta por seis simples perguntas:

What: O que?
When: Quando?
Who: Quem?
Why: Porque?
Where: Onde?
How: Como?

Agora vamos pensar na visão da abertura de um defeito e fazer estas simples perguntas:

What: Qual?

Qual é o problema que aconteceu no sistema?
O que ocorreu?

Ex: Sistema não realiza a venda do produto.

When: Quando?

Quando isto ocorre?
Quando não ocorre?
Este problema já vinha acontecendo?

Ex: Quando o sistema possui muitos produtos no pedido do cliente.

Who: Quem?

Quem é impactado?

Ex: Usuários que possuem um cadastro recente. Usuários finais, etc.

Why? Porque?

Porque o problema ocorre?
Porque deve ser resolvido logo?

Ex: Este problema ocorreu porque era uma grande quantidade de produtos

Where: Onde?

Onde ocorreu o problema?
Qual link/funcionalidade do sistema que ocorreu?
Qual ambiente/hardware?

Ex: Problema ocorreu no aplicativo móbile de celular.

How? Como?

Como aconteceu?
Como chegou a este problema?

Desta maneira, podemos utilizar estas perguntas para nos auxiliar a compor um defeito, tornando-o claro para o desenvolvedor:

Exemplo prático:

Severidade do defeito: 2

Headline:
Usuário final não efetua compra de uma grande quantidade de produtos através do software para móbile.

Descrição:

1. Acessar o aplicativo InfoLoja do Iphone e realizar o login com os seguintes usuários:
Login: vinisabadoti
Senha: as78dj098k
2. Preencher o carrinho de compras com mais de 5 produtos e fechar o pedido.
3. Informar os dados do pagamento com cartão de crédito e confirmar compra.

Resultado esperado: Sistema exibe mensagem da confirmação do pedido informando o número do pedido para futura consulta.

Resultado obtido: Sistema não confirma a compra e direciona o usuário para página inicial.

Verificar passo nº X da evidência em anexo.

Como no exemplo citado acima, fica muito fácil para a pessoa que irá validar o defeito entender e juntamente com uma evidência em anexo, comprova com imagens que o defeito foi encontrado conforme os passos descritos.
Desta maneira, quando o defeito foi validado e chega ao desenvolvedor, ele poderá entender facilmente o defeito. Claro que não são em todos os defeitos que é possível aplicar todas estas perguntas, porém podemos analisar quais se encaixam para reportá-los com maior qualidade.

Espero que tenham gostado e que esta técnica possa ajudar a vocês de alguma maneira, ajudando assim a fazer um trabalho com qualidade.
Afinal, não adianta exigir qualidade do software que testamos se em nosso próprio dia-a-dia não aplicamos qualidade no serviço em que fazemos.
Gostaria de agradecer a Lyamara Bonvechio pelo conhecimento transmitido e por deixar eu escrever um pouco sobre a técnica e compartilhar ela aqui no blog!

Caso queiram saber mais sobre a técnica, segue abaixo alguns links interessantes:

http://nccur.lib.nccu.edu.tw/bitstream/140.119/35210/7/35602807.pdf
http://www.mindmapinspiration.com/using-5w-1h-as-a-90-10-solution-finder/
http://www.canallmarketing.com/uploads/2/7/7/6/2776543/5w1h.pdf