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


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


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


Como os desenvolvedores aplicam os testes unitários?

Pessoal, o objetivo deste post é saber um pouco mais sobre os Testes Unitários. Neste caso, não vou colocar definições, muita teoria, etc.

A minha intenção é procurar apresentar um pouco mais da prática destes testes, como ele é realizado, como que o desenvolvedor começou a utilizar estes testes e assim por diante.

Para isso, contei com a ajuda de dois experientes desenvolvedores: Jair Rillo Junior e Maurício Hiroshi Nagaoka!

Segue uma entrevista com estes feras:

1. Como foi começar a fazer testes unitários? Vocês decidiram por conta própria ou por exigência de algum projeto, etc?

 Jair: Comecei por conta própria quando estava estudando sobre JUnit e TDD (Test-Driven Development). No primeiro projeto real que eu usei, o seu uso não era obrigatório porém era incentivado pelo time de arquitetura.

No segundo projeto (e o maior que eu já trabalhei) no início comecei a utilizar por conta própria, só que logo depois foi utilizado por todo o projeto.

 Maurício: Eu comecei a fazer testes unitários automatizados por conta própria. Lá pelos idos de 2000, eu trabalhava em um lugar em que tínhamos bastante liberdade p/ experimentar. Foi quando um colega e eu lemos o livro do Kent Beck, Extreme Programming Explained (http://goo.gl/EJyJC), e a gente se empolgou tentando aplicar o máximo possível de práticas do XP que a gente podia.

2. Como você vê a importância de testar o seu código?

Jair: Não importa o tamanho do projeto, sem teste unitário é impossível garantir boa qualidade do mesmo.

Diferente do que muitos pensam, teste unitário não ajuda apenas a testar os métodos de forma automática. Ele ajuda também em um melhor design da aplicação. Design no sentido de organização e utilização de classes/objetos, evitando o alto acoplamento entre as classes.

Quando algum método começa a se tornar dificil de testar, é um sinal claro de alto acoplamento e excesso de responsabilidade do mesmo. Com TDD, isso é descoberto facilmente na fase inicial de densenvolvimento.

 Maurício: Há, no mínimo, três benefícios que são de fundamental importância:

1) o código é testado o mais rápido possível e o mais frequentemente possível evitando o “vôo cego”, em que o programador escreve código durante dias pra só depois começar a testar e descobrir se tem algo funcionando;

2) ao final do desenvolvimento, você terá um conjunto de testes automatizados que podem ser facilmente executados (automaticamente, a qualquer momento) que te darão a “paz de espírito” de saber que o que quer que você tenha alterado/introduzido não quebrou nada do que já funcionava, isto é, que você não introduziu nenhuma regressão;

3) a vantagem principal é que ao pensar em testes logo no início do desenvolvimento, você desenha sua implementação de maneira a facilitar os testes unitários automatizados. Isto faz com que seu código fique melhor modularizado, mais coeso e menos acoplado pois você passa a pensar melhor nas responsabilidades de cada classe e acaba dividindo melhor estas responsabilidades entre as classes.

3. Quanto tempo é reservado para realizar os testes?

Jair: Não dá para mensurar o tempo. Quando se usa prática TDD, o teste é escrito junto com o código. Na verdade, o teste é escrito primeiro que o próprio código em sí.

 Maurício: Normalmente, quando estimamos o tempo de desenvolvimento já está incluído o tempo de se realizar os testes unitários, isto é, de implementá-los, já que eles nada mais são do que programas que utilizam o código que você está escrevendo.  É difícil mensurar quanto tempo é gasto com a elaboração de testes unitários pois ela ocorre simultanemente ao desenvolvimento do código propriamente dito.

4. É possível escrever testes para tudo o que for codificado?

Jair: Depende muito do ambiente que o software irá rodar. Em modo geral, quando se usa algum recurso externo (arquivo xml, banco de dados, etc) a resposta é não. Um exemplo: Se o sistema utiliza banco de dados não dá para fazer um teste unitário simulando uma base de dados, tem que ter, mesmo que em memória, uma base de dados para testes. Esse tipo de teste não é considerado unitário e sim integrado.

Em um mundo perfeito, o ideal é criar uma suite de testes automatizados, composto por teste unitário, integrado e funcional. Esse tipo de prática é bastante divulgada em ALM (Application Lifecycle Management).

 Maurício: É desejável, mas nem sempre possível ou mesmo compensador.

Esta dificuldade ocorre principalmente com código legado, que não foi escrito pensando-se em “testabilidade”, que acaba ficando monolítico e, por consequência, difícil de ser testado isoladamente. Alguns frameworks (bibliotecas) de desenvolvimento facilitam enquanto outros dificultam a criação de testes unitários automatizados.

Em alguns casos também pode-se chegar à conclusão de que não é compensador o esforço para se testar determinada unidade de código.

5. Que tipo de defeito é identificado nestes testes?

 

Jair: O objetivo do teste unitário é testar a menor parte do software, que no caso, é um método. O objetivo é escrever testes unitários para TODOS os cenários que o método for executado. Idealmente, todas as linhas de código de um software deve ser coberta por um teste unitário.

 Maurício: Em teoria qualquer tipo, mas basicamente o foco é em defeitos de funcionalidade, isto é, se a unidade de código (normalmente a classe, no caso de Java) faz o que deveria fazer.

6. Como você se organiza com os testes unitários? É criado um checklist para validar cada componente, classe, etc?

Jair: Não existe essa organização formal. Como já tido, o teste é escrito antes mesmo do código. Para cada cenário é escrito um teste diferente e o código é executado para verificar se existe erro ou não. Apenas quando não existir mais erro, um novo cenário é escrito.

O fato é que mesmo com testes unitários, não dá para prever todos os cenários na primeira fase de desenvolvimento.

O processo básico é o seguinte: Quando um novo erro é encontrado, seja pela equipe de testes ou pelo cliente, primeiro se escreve um teste unitário para comprovar o defeito e depois é corrigido o código.

 Maurício: Normalmente escrevo código utilizando TDD (Test Driven Development), que nada mais é do que você desenvolver seu código e, em paralelo, os testes unitários para exercitá-lo. Basicamente é um ciclo que se repete com os seguintes passos:

1) escreva um teste (sim, o teste é escrito antes do código!)

2) escreva o código para atender ao teste

3) refatore

4) se há mais coisas para serem testadas ou implementadas, volte ao passo 1; senão, fim.

7. Foi identificado uma melhora no desenvolvimento do sistema da época em que não aplicavam testes unitários em relação a situação atual que é realizado estes testes?

Jair: Embora não dê para mensurar, a melhora foi de fato gigantesca. Não apenas em relação a entrega para a equipe de testes, mas também por causa que defeitos antigos, agora cobertos por testes unitários, não voltaram à aparecer.

Maurício: Minha resposta é subjetiva, mas acho que a melhora mais sensível é a redução do número de ciclos em que o código transita entre o time de testes e o de desenvolvimento devido à redução de bugs que um código mais exercitado, mais maduro, apresenta. Se você pensar de maneira mais imediatista, pode chegar à conclusão que o tempo de desenvolvimento aumenta, afinal gasta-se tempo escrevendo os testes unitários. Mas se você ver um por uma perspectiva um pouco mais ampla, vai perceber que o ganho trazido pela redução na quantidade destes ciclos que mencionei é altamente compensadora.

Muito interessante as respostas, achei bem legal saber da iniciativa de começar a fazer testes unitários por conta própria, isto demonstra uma boa consciência entre a galera de desenvolvimento! Gostaria de agradecer ao Maurício e ao Jair pelas respostas, estão muito boas!

Espero que seja um incentivo para quem ainda não pratica testes unitários!

Para saber mais:

– TDD (Test Driven Development);  (TDD) ou em português Desenvolvimento dirigido por testes é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis.

– ALM (Application Lifecycle management):  Todo o processo que guia a vida útil de uma aplicação desde a sua concepção, passando pela construção, operação e evolução.

 

Abraços.

Vinicius Sabadoti


Extensões para auxiliar os Testes em Software Web

Olá pessoal, neste post gostaria de compartilhar algumas extensões que conheço e que podemos utilizar para o nosso dia-a-dia em testes de sistema Web.

São extensões para os navegadores Firefox e Chrome, que você pode instalar facilmente em seu navegador. Infelizmente
algumas extensões para o Firefox até o momento em que escrevo não funcionam para a última versão (6.0). Mas mesmo assim acho interessante listar pois muitas vezes em nossos testes não podemos utilizar a versão atual do Firefox (o que acontece no meu caso, por exemplo).

Segue abaixo a minha lista:

1. Gerador de CPF e CNPJ.

Para quem utiliza CNPJ e CPF em seus testes muitas vezes precisa ficar sempre acessando um site específico para gerar estes tipos de dados. Com este aplicativo é possível inserir com apenas um clique o CPF/CNPJ.

Após a instalação, a extensão adiciona um ícone no canto inferior direito do navegador (versão Firefox). Quando você desejar informar um CNPJ, basta escolher o campo desejado e clicar com o botão direito do mouse em cima do ícone. Para incluir o CPF basta fazer o mesmo procedimento, porém clicando com o botão esquerdo em cima do ícone.

Caso você não tenha selecionado um campo, o sistema exibe um pop-up com o CPF ou CNPJ conforme clicado pelo usuário.

Para a versão do Chrome, a extensão fica instalada do lado da barra de endereços do navegador e você pode clicar sobre o ícone e é apresentado uma caixa com as opções de CPF ou CNPJ. Você pode também clicar com o botão direito do mouse sobre o campo que deseja incluir o valor e escolher a opção desejada.


Firefox: https://addons.mozilla.org/pt-BR/firefox/addon/gerador-de-cpf-e-cnpj/
(Segundo o site as versões que suportam esta extensão são: Firefox 3.0 – 3.6)

Chrome:

https://chrome.google.com/webstore/detail/ieifkajhcbdlbmmjkbmpomooeepmciin

2. Selenium Expert (Selenium IDE)

Se você precisa preencher algum formulário simples esta extensão pode te ajudar bastante. Para usar, você deverá primeiro apertar o botão que simboliza o REC que conhecemos e preencher o formulário conforme desejado. Após o terminar o preenchimento dos campos basta clicar novamente no ícone para que deixe de gravar as suas ações. Após terminar a gravação, basta acionar o Play quando desejar preencher novamente o formulário.

O que achei ruim deste aplicativo é que muitas vezes ele não identifica o campo na hora da gravação (ou pode ser por falta de experiência minha). Portanto quando você aciona a extensão para executar o que foi gravado algumas vezes ele poderá falhar

No meu caso, uso o aplicativo para preencher os campos de um teclado virtual. Isto ajuda bastante, já que o teclado virtual sempre muda a ordem das letras e oculta às teclas que estão ao lado do mouse quando passa pelo teclado.

Links:

Firefox: https://addons.mozilla.org/pt-BR/firefox/addon/selenium-expert-selenium-ide/
(Segundo o site as versões que suportam esta extensão são: Firefox 1.5 – 6)

3. iMacros.

O iMacros possui a mesma função que o Selenium. A vantagem que vejo aqui no Imacros é que possui a opção de Loop. Com esta opção você pode decidir quantas vezes o script gravado vai ser executado.
Alguns campos que não foram identificados no Selenium foram possíveis preenchê-los pois a extensão reconheceu os campos. Porém em algumas situações o que acontece ao contrário!

Links:
Firefox: https://addons.mozilla.org/pt-BR/firefox/addon/imacros-for-firefox
(Segundo o site as versões que suportam esta extensão são: Firefox 3.0 – 7.0a1)

Chrome: https://chrome.google.com/webstore/detail/cplklnmnlbnpmjogncfgfijoopmnlemp?hl=pt-BR

4. Firebug.

Este aplicativo é mais voltado para desenvolvedores, porém uma das finalidades dele é ajudar a encontrar defeitos de HTML, CSS e JavaScript. Ao acionar o Firebug ele permite você verificar o código da página e editar os campos.

Links:
Firefox: https://addons.mozilla.org/pt-BR/firefox/addon/firebug/
(Segundo o site as versões que suportam esta extensão são: Firefox 3.6 – 5)

Chrome: https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench?hl=pt-BR

5. Captura de Tela

Esta extensão infelizmente está disponível somente para o Google Chrome. Ela permite você tirar screenshot do site.
Ela te oferece 3 opções: Selecionar a área em que deseja tirar o screenshot, Capturar a parte visível do site no momento, ou seja, você está no início do site, a imagem será a área que aparece para você. Por último, a opção que eu mais gostei! Tirar o screenshot do site inteiro.

Após realizar a captura da imagem, ela é apresentada em uma nova aba e permite você editar a imagem antes de salvá-la. Portanto se você deseja marcar algum elemento, colocar uma seta ou inserir um texto é possível.

Links:
Chrome: https://chrome.google.com/webstore/detail/alelhddbbhepgpmgidjdcjakblofbmce?hl=pt-BR#

Bom pessoal, no momento as que mais uso são estas. Se alguém quiser compartilhar mais alguma extensão fique a vontade para colocar nos comentários! Será de grande valor. Espero que tenham gostado e que possam ter ajudado de alguma maneira.

Abraços e até a próxima!

Vinicius Sabadoti


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!


Seguir

Obtenha todo post novo entregue na sua caixa de entrada.