Arquivo da tag: Dicas

Começando a estudar Scrum!

Fala pessoal! Vamos tratar de um assunto que andei estudando bastante últimamente: Scrum! Quando comecei a trabalhar com testes a metodologia para desenvolvimento de projeto sempre foi RUP (Rational Unified Process).

Portanto, meus conhecimentos sobre Scrum eram bem básicos e atualmente estou para começar em um projeto que trabalha com o mesmo.

A partir desse momento que surgiu ainda mais a necessidade de estudar sobre o assunto para estar preparado. Durante os estudos surgiram algumas dúvidas de como estudar, o que estudar e a curiosidade de entender o papel da equipe de testes, de cada tester, Casos de Uso e por fim acabei descobrindo coisas diferentes do que tinha em mente!

Quero colocar neste post algumas referências sobre o assunto e na medida que for aprendendo e descobrindo coisas novas atualizarei na medida do possível. Se você souber de algo interessante que não citei por aqui sinta-se a vontade em deixar um comentário, pois irá me ajudar e a quem estiver começando também!

Primeiramente comecei a procurar literaturas com definições sobre o Scrum, lendo mais de uma vez e não somente uma fonte. Acredito que é muito importante ler em vários meios pois assim o estudo não fica cansativo e é bom para conhecer algumas idéias e a forma que alguns autores trabalham sobre o assunto.

 Até o momento encontrei  estes Artigos interessantes:

Guia definitivo do SCRUM: Este é um guia do Scrum e é mantido pelos seus criadores Ken Schwaber and Jeff Sutherland. Este guia está disponível em vários idiomas inclusive em Portugês.

Artigo SCRUM: Este é um artigo criado pelo Fabrício no blog QualidadeBR sobre o tema.

Scrum em menos de 10 minutos: Vídeo que trata sobre o Scrum bem interessante. Provavelmente você vai precisar ver mais de uma vez, pois ele fala bem rápido mas é bem interessante.

Mapa Mental sobre Scrum: Por fim, achei muito interessante este mapa Mental que aborda um resumo bem legal e fala sobre a diferença com RUP.

Para quem já leu sobre o Scrum nos artigos acima, deparou-se com alguns termos como User Stories, Critérios de Aceite que podem ser conferido nestes dois artigos:

User Stories: O que são? Como usar?

Critérios de Aceitação das User Stories: Uma breve descrição de como criar

Aqui temos alguns artigos que abordam sobre Testes em times Ágeis. Foram nestes artigos que descobri muita coisa interessante e das diferenças do time de testes que trabalha com RUP e testes com Scrum. Como é a atividade, a participação, importância, etc.

O papel do analista de Testes dentro dos processos ágeis – Uma Introdução

Papel do “Time de Teste” em projetos SCRUM

Scrum no Teste de Software: Trabalho de Conclusão de Curso de MBA de Teste de Software.

Vocabulário básico para testadores ágeis: Artigo do Camilo Ribeiro que trata sobre termos Ágeis para testadores.

Uma Abordagem de Construção e Testes orientada pelos Critérios de Aceite

Alguns blogs sobre Scrum e metodologia Ágil que encontrei:

ScrumHalf

Scrum em Ação

Cantinho do Agile

Agile Caelum

O Rogério contribiu indicando o site improveit citando alguns links interessantes:

http://improveit.com.br/sitemap
http://improveit.com.br/scrum
http://improveit.com.br/xp

Alguns livros:

Agile Project Management with SCRUM

Lean Software Development An agile toolkit

Agile Testing: A Practical Guide for Testers and Agile Teams

– Scrum e XP direto das trincheiras: livro disponível para download gratuito (dica da Leciane Marcari 🙂 )

Sites sobre eventos:

Eventos de TI  (possui vários eventos cadastrados e não somente de SCRUM).

Agile Brazil

Revista de testes abordando Scrum:

Revista Testing Experience sobre Agile Testing

Por fim, um podcast do Elias Nogueira em uma entrevista com a Tatiane Fukuda que trabalha no Yahoo! com processos ágeis. Clique aqui para escutar.

Para começo na minha opinião já é um bom guia para poder aprender sobre o assunto e ficar por dentro! Espero que gostem e que possa ajudar a quem estiver no mesmo barco!

Abraços!

Vinicius 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!


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!


Dicas – Criando um CV

Criar um curriculum parece ser fácil, porém há muitas questões. O que realmente devo colocar, como deve ser o modelo, quantas páginas, etc. Estas são algumas das várias dúvidas que muitas pessoas possuem quando vão criar um.

Gostaria de compartilhar com vocês um video do consultor de carreiras Max Gehringer que dá dicas de como montar um Curriculum Campeão.

Gostou do vídeo? Precisa acertar o CV? Então mãos à obra e boa sorte na procura de oportunidades!

Abraços.

Vinicius Sabadoti


Dica – Google incentiva usuários a encontrar bugs no Chrome e Chromium

Hoje navegando pelo site de tecnologia tecnoblog me deparei com a notícia de que o Google anunciou em seu blog oficial que vai pagar aos desenvolvedores ou a qualquer usuário que encontrar bugs no Chrome e Chromium.

Os valores iniciam de US$500,00 e vão até US$ 1.337,00 de acordo com a severidade do defeito. Ao encontrar um bug o usuário não deve relatar publicamente e deve enviar ao Google para ser analisado.

Achei uma iniciativa bem interessante, mas vale lembrar que a Mozilla já incentiva essa prática.

Com essa, quero ver quem que não vai querer que aconteça um problema no seu navegador Chrome para reportar ao Google!

Abraços e até a próxima!

Vinicius Sabadoti