Neste post, vou tentar ensinar vocês a fazer o famoso CHA para o alcance do sucesso profissional. Nosso “Chá” de hoje é feito com a mistura dos ingredientes Conhecimento, Habilidade e Atitude. A falta de algum desses ingredientes enfraquece o Chá do profissional, e este fica vulnerável diante do mercado de trabalho.

Conhecimento

Você precisa conhecer muito bem o mercado a qual está envolvido. Pode ser processos bancários, tecnologia, internet, indústrias em geral. É preciso conhecer o negócio em que você está inserido. O segundo passo é conhecer muito bem aquilo que você foi contratado para fazer (ou que está se candidatando). É preciso estudar sempre e se manter atualizado, se especializar cada vez mais naquilo que a empresa espera de você.

Habilidade

A habilidade nada mais é do que conseguir fazer “muito” bem – na prática – aquilo que se conhece na teoria, por prazer. De nada adianta você conhecer e até gostar, se não tem habilidade para aquilo. A habilidade só se consegue com a prática. E é preciso ter o pré-requisito do Conhecimento, para fazer a coisa certa.

Atitude

A atitude é fundamental para qualquer profissional. Home em dia considero dificílimo se manter em uma empresa se não existe atitude para correr atrás de alguma informação, para estudar, para ajudar um colega, pra resolver um problema e tudo mais. Antigamente a atitude era vista como um diferencial para o profissional. Agora mudou, é um requisito básico e não mais um diferencial.

Principalmente em se tratando de tecnologia, é importante não esquecermos de preparar o CHÁ todos os dias de sua carreira profissional. Esse chá te fortalece e só te faz crescer profissionalmente. Agora, use a criatividade no preraro. Existe diversos tipos de chá. Tem pra todos os gostos. Procure o sabor que combine mais com você e comece já !

O Cobertura é uma ferramenta muito eficiente para apresentação das porcentagens de teste unitário que sua aplicação possui.

Ele apresenta o resultado de duas formas: Um gráfico de builds x porcentagem, detalhando em Classes, Condições, Arquivos, Linhas, Métodos e Pacotes e mostra também em forma de tabela os testes por pacote.

Se você clicar em um dos pacotes listados, ele abrirá nova tela, com um gráfico (agora correspondendo apenas ao pacote) e também classe a classe.

É importante ter em mente que, quanto mais próximo as porcentagens estiverem dos 100%, mais confiável estará sua aplicação.

Para instalar o Cobertura, é preciso primeiramente ter instalado sua ferramenta de integração contínua (sugiro o Hudson).

Agora, na home do Hudson, clique em “Manage Hudson” – “Manage Plugins”. Adicione o plugin “Cobertura Plugin”.

Então só falta você configurar o POM do seu projeto para incluir o Cobertura e na configuração do projeto, marcar o check “Publish Cobertura Coverage Report” e adicionar o XML padrão que o Hudson sugere.

No próximo build, você já vai poder conferir seu relatório de Cobertura.

Segue então pra vocês um exemplo do Projeto Cadun-Admin do meu time de Scrum aqui na Globo.com.

Vamos lá !

Configurando o Hudson:

1 – No hudson, clicar em “Manage Hudson”

2 – Agora clique em “Configure System”

3 – Altere por enquanto apenas os seguintes parâmetros:

- JDKs
name: JDK 1.6 (colocar aqui as suas JDKs)
Java home: /usr/lib/jvm/java-6-openjdk (local de instalação do Java)

- Maven
name: APACHE-MAVEN
maven home: /home/martha/java/apache-maven-2.0.9 (local de instalação do Maven)

- Email notification
SMTP Server: smtpar.globoi.com (exemplo)
Email adress: martha@corp.globo.com (exemplo)

Criando e Configurando seu Job:

1 – Clicar em “new job”

2 – Em Project name, inserir um nome para o seu job

3 – Em “Source Code Management” – CVS, inserir:

3.1 – CVSROOT: :pserver:glb_martha@cvs.globoi.com:/opt/cvs/data (você encontra esse caminho no checkout do NetBeans)
3.2 – Module(s): CadUnIIAdmin (nome do seu projeto no CVS)

4 – Em “Build” , inserir:

4.1 – Root POM: pom.xml
4.2 – Goals and options: -P test test (como está configurado seu Maven)

Buildando seu Job:

1 – Na lista de jobs, clicar sobre o link do job que você deseja buildar.

2 – No menu a esquerda, clicar em “build now”

Vai ser demorado, porque o Hudson vai fazer agora o checkout do seu projeto no Netbeans. Ao fim do build, você pode clicar sob o link dele, que o Hudson irá exibir o resultado dos testes para você.

Utilizando o Subversion

1 – Na configuração do job, ao invés de inserir o caminho do CVS, selecione a opção Subversion

2 – Inserir a url no campo Repository Url. Exemplo: http://svn.globoi.com/repo/cadun/trunk/cadun

3 – Inserir também o local module: Exemplo: cadun-authenticator-ws

4 – Agora é só continuar o passo a passo default, como se usasse o CVS.

Caso nao consiga visualizar, clique aqui

Bom, posso começar falando que mudei bastante minha forma de trabalhar. Na equipe de QA, tínhamos processos, planilhas, relatórios e todos foram abortados. No início resisti um pouco a abdicar dos artefatos de teste, mas percebi que realmente era necessário abortá-los. Posso dizer que o primeiro e principal papel do tester no time é definir processo de trabalho com o time.

- Relatórios: Não foi mais preciso gerar relatórios já que a proximidade do time é boa, sentamos todos próximos o bastante para uma boa comunicação. Tudo o que é preciso dizer é dito na hora, ou no daily ou nos reviews/retrospectives.

- Planilhas: Casos de teste e planilhas de bugs não existem mais. Com a proximidade do tester com os desenvolvedores, não tem motivo algum pra se registrar um bug no Jira. Ganha-se tempo e o entendimento é bem melhor. Os casos de teste são registrados no wiki junto com os respectivos bugs apenas para não perdermos o controle (bem mais prático).

- Processos: Cada time de scrum tem sua forma de trabalhar. Alguns automatizam testes. Alguns fazem TDD. Alguns fazem teste unitário. Não existe mais processo a ser seguido, já que cada time possui sua forma de trabalhar. Após definir o processo de qualidade com o time, o papel do analista de teste é mostrar por A + B, a importância de um TDD, de testes unitários, de um teste automatizado.

Passando dessa primeira fase de adaptação, o papel do testador é “evangelizar” o time. Ele testa, testa e testa e …. com o passar do tempo consegue provar ao time que NÃO existe sistema ZERO bug, mas que basta um esforço em equipe para se chegar bem próximo a excelência em qualidade.

O papel do tester é ser insistente. Não é fácil convencer desenvolvedor a testar (e testar bem). Só o tempo e a persistência é que vão fazer você chegar lá. Você vai encontrar bugs, o time vai gastar tempo para corrigir, e de tanto isso ocorrer, o time vai apostar na idéia de automatizar os testes.

Outro papel do analista de teste é passar seu conhecimento sobre técnicas de teste, conceitos de QA em geral, para que todo o time consiga ter qualidade nos testes, não só o especialista. O tester é muitas das vezes um tira-dúvidas do time. Ele deve mostrar o caminho para se alcançar a qualidade. Pode-se fazer apresentações, reuniões, pair-testing etc.

Além de todas as atividades que mencionei aqui, não posso deixar de falar também sobre estudar sempre novas técnicas de teste, tanto teste manual quanto teste automatizado, adaptando-se sempre ao mercado e trazendo novidades que possam aprimorar a qualidade ao time.

Resumindo:

1) Definir processo de trabalho com o time;

2) Evangelizar o time a nível de qualidade como um todo;

3) Jamais desistir. O caminho é longo até o QA entrar no sangue de todos do time;

4) Transmitir o conhecimento de QA ao time;

5) Buscar novidades no mercado em relação a testes manuais e automatizados;

Enfim, esses são os cinco mais importantes papéis do analista de testes em um time de Scrum, segundo meu ranking. Scrum é a tendência do mercado. É necessário se adaptar. O resultado vale a pena. Pode confiar.

Até a próxima….

Um outro ponto que vejo é conseguirmos automatizar scripts diariamente. Imaginem a situação em que uma determinada funcionalidade é desenvolvida e que todos os cenários de teste previstos para ela foram automatizados com sucesso. A dificuldade nesse caso é que, quando ocorrem os testes manuais dessa mesma funcionalidade, descobre-se outros cenários de teste alternativos e bugs são encontrados. Porque a dificuldade ? Porque no momento do teste manual dessa funcionalidade, já está ocorrendo o desenvolvimento de outra funcionalidade e não temos a cultura de voltar a estória para gravar os novos cenários encontrados.

Conheço times em que o próprio P.O., só dá seu accepted na estória quando visualiza a estória automatizada. Para ele, é uma garantia maior de que o produto entregue tem qualidade.

Uma última questão que é importante levantar neste tópico é como o analista de testes consegue “controlar” os scripts que estão sendo gravados no meio de um time com vários desenvolvedores que automatizam. Como saber se todos os cenários planejados foram gravados, em que momento isso pode ser aceito ? Há algum tempo já tenho pensado nisso e uma sugestão minha é que, assim que qualquer integrante da equipe termine de gravar algum bloco de scripts, que o analista de testes seja informado para dar seu “aceite”. Daí pra frente, esses blocos de scripts que foram aceitos são automaticamente utilizados como scripts de regressão.

Considero que para termos um controle da automação e até que isso não entre no sangue dos times, apenas homologar as estórias que estiverem com todos os scripts possíveis automatizados.

É normal e compreensivo que os testadores não verifiquem novamente todos os casos a cada mudança significativa do código; é deste cenário que surgem os erros de software, trazendo prejuízo para as equipes de desenvolvimento que perdem muito tempo para identificar e corrigir os erros e também prejuízo para o cliente que, entre outros problemas, sofre com constantes atrasos nos prazos combinados e com a entrega de software de qualidade duvidosa.

Mas o aspecto mais crítico deste cenário é o efeito “bola de neve”. Como é necessário muito esforço para executar todo o conjunto de testes manuais, dificilmente a cada correção de um erro, a bateria de testes será executada novamente como seria desejável. Muitas vezes, isso leva a erros de regressão (erros em módulos do sistema que estavam funcionando corretamente e deixam de funcionar). A tendência é este ciclo se repetir até que a manutenção do sistema se torne uma tarefa tão custosa que passa a valer a pena reconstruí-lo completamente.

Testes automatizados são programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verificações automáticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem, é que todos os casos de teste podem ser facilmente e rapidamente repetidos a qualquer momento e com pouco esforço.

A reprodutibilidade dos testes permite simular identicamente e inúmeras vezes situações específicas, garantindo que passos importantes não serão ignorados por falha humana e facilitando a identificação de um possível comportamento não desejado.

Além do exemplo de mapeamento de funcionalidades e casos de teste que apresentei no post anterior, vale a pena informar que também existe a versão Mindmeister, que importa nossos arquivos gerados pelo Mindmap, e os torna colaborativos via web.

É muito interessante usá-lo e compartilhar o planejamento de testes com o time de scrum, que os utilizará como base para gravação de testes unitários e automatizados via Selenium. Assim conseguimos ter melhor controle e sabermos se o que o tester planejou foi ou não automatizado.

Estamos começando a usar esse método nesse sprint. Mais tarde, posto para vocês o resultado da nossa experiência.

Mais informações no site do aplicativo:
Acessar Mindmeister

Um exemplo de arquivo do tipo Mindmap importado no Mindmeister.
Exemplos

Para amenizar essa situação, sugiro a utilização do Mindmap, ferramenta gratuita em que você consegue fazer um mapa da funcionalidade a ser testada.

Vejam abaixo um exemplo bem interessante de uma funcionalidade mapeada no MindMap.

Mais ou menos em outubro de 2007, surgiu na Globo.com a primeira iniciativa de implantação do scrum, por termos a nossa frente um Projeto BBB e a falta de tempo. Foi uma experiência e tanto …

E assim, com o sucesso do projeto, foi o início de tudo. Menos de 6 meses após o término do projeto BBB, já tínhamos times de scrum sendo formados por toda a empresa.

Agradeço aos meus gestores por terem me dado a oportunidade de participar do scrum desde o início, lá no primeiro projeto, até hoje.

Muita coisa mudou para mim como profissional de testes: A forma de trabalhar, os desafios de participar de um time, o contato direto com o desenvolvimento, a adaptação a nova metodologia e muito mais.

Superei muitos desafios em 2008 e espero poder disseminar todo meu conhecimento aqui com vocês em 2009.