Arquivo da categoria: Uncategorized

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


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


Curiosidades em TI – Senha mais usada entre os Internautas

Hoje navegando pelo site da globo, me deparei com esta notícia. Esta matéria fala sobre um estudo realizado por uma empresa de segurança de dados dos Estados Unidos e revela que a senha mais utilizada é 123456!

Usar nomes próprios, gírias, palavras conhecidas, etc também são senhas comuns utilizadas pelos internautas sem contar que usam a mesma senha em vários lugares.

Atualmemente com a grande quantidade de sites que pedem cadastro, realmente acho complicado criar uma senha para cada um, porém não é motivo para criar senhas fáceis!

O mais engraçado é que conheço profissionais da área de TI que usam senhas simples assim!

Se você quer ver a matéria na integra, clique aqui

Abraços.

Vinicius Sabadoti