Test Case Lifecycle (Ciclo de Vida de um Caso de Teste)

Eu diria que, como tudo em desenvolvimento de software, o Caso de Teste também possui um Ciclo de Vida. Estas fases se dividem em (OK, não sou muito bom em criar nomes): Business Test Analysis, Macro Test Analysis, Test Case Analysis/Implementation, Test Execution, Test Refactoring e Test Maintenance.

Só para questões de entendimento, não extrai essas informações de nenhum livro, decidi detalhar o que entendo por criação de casos de teste. Os termos que eu costumo utilizar em todos os meus posts são do ISTQB, que, na minha opinião, é a certificação mais consolidada no mercado global (e nacional) de testes.

Diferente de antigamente, hoje as pessoas (ou a maior parte delas) já tem noção da importância dos testes e dos malefícios em abdicá-lo no seu processo de desenvolvimento de software (seja este qual for). E isso, é graças ao esforço praticado pela comunidade de testes no Brasil e no mundo.

Todavia, às vezes nem nós temos consciência do quão complexa pode ser uma "simples" atividade de criar casos de teste. Sendo assim, eu definiria seis fases primordiais:

Business Test Analysis: Visto de maneira mais simples, essa fase do projeto é a simples presença do responsável pelos Testes do projeto na reunião de requisitos, para uma explicação geral sobre o que é a proposta do sistema/componente a ser desenvolvido e como estes serão testados. De forma mais profunda, é nessa reunião que o Analista de Testes vai avaliar quais são requisitos do sistema que estão de acordo com as normas da ISO 9126. Por exemplo, mais obviamente, as funcionalidades do sistema, qual o nível de acurácia, se aderente às leis locais; questões de usabilidade, questões de desempenho, testabilidade (muito importante), portabilidade e outros.

Macro Test Analysis: Definidos os requisitos é o momento de decidir qual estratégia e planejamento que serão utilizados para os testes naquela release, se vão utilizar testes ágeis/exploratórios, se vão utilizar testes baseados em riscos, ou baseados em especificação. É a etapa de testes onde, eu diria, que vai definir a abordagem utilizada e detalhar os cenários de testes (utilizando Test Charters ou Test Conditions - de acordo com a definição do ISTQB).

Test Analysis/Implementation: Essa fase pode ser integrada à próxima fase (Test Execution) se for um projeto ágil. Mas de maneira geral, é a fase onde, com a definição macro dos testes no sistema, as técnicas serão utilizadas e as informações sobre o projeto serão refinadas (lembrando que, uma das atividades de testes é dar informações ao projeto). É nessa fase onde, num projeto iterativo, também serão definidos quais os cenários/casos de teste que serão utilizados nas próximas releases, quais serão selecionados para a fase de testes de regressão, e outros.

Test Execution: Essa fase continua sendo a fase de execução dos casos de teste, reporte de defeitos mas também é importante lembrar nessa fase, que os desvios nos casos de teste devem ser anotados, para, numa fase posterior, serem corrigidos.

Test Refactoring: Depois dos casos de teste executados e finalizados, é muito importante que, com intuito de garantir a longevidade do projeto, esses casos de teste sejam corrigidos e adaptados ao sistema da forma como ele é implementado de fato. Só assim os casos de teste vão espelhando a realidade do sistema a médio prazo, tornando também os Analistas de Teste mais especializados no sistema com o passar do tempo.

Test Maintenance: Eu diria que essa fase está presente em todo o ciclo de vida dos casos de teste. Na verdade eu deveria utilizar a expressão "artefatos de teste", sendo assim, mais generalista e adaptável para qualquer contexto. Bem como o sistema muda o tempo todo (independente da metodologia) os artefatos de teste também devem ser atualizados, garantindo assim a qualidade também dos artefatos de teste.

Só para deixar claro que eu não estou reinventando a roda. Sendo assim, provavelmente ideia do Testcase Lifecycle tenha ficado um pouco nebulosa. O objetivo é criar mais posts detalhando e exemplificando cada fase dos mesmos. Ficando assim, mais claro.

Conceitos Básicos de Teste de Software - Parte 1

Conceitos Básicos de Teste de Software - Parte 2

Conceitos Básicos de Teste de Software - Parte 3

Conceitos Básicos de Teste de Software - Parte 4

Gestão de Defeitos

A gestão de defeitos é uma das atividades mais importantes de um processo de teste de software. Através da gestão de defeitos podemos acompanhar a qualidade do software em teste com base nos defeitos cadastrados pelos testadores ao longo de um ciclo de testes.

Podemos então, para realizar o controle e a gestão dos defeitos no sistema, utilizar sistemas automatizados que nos auxiliem. Estas ferramentas devem possuir um local aonde os testadores cadastram os bugs de forma organizada, devem possuir também um local para acompanhar o ciclo de vida dos defeitos e emitir relatórios de gestão.

Entre as ferramentas de gestão de defeitos temos três que são bastante utilizadas no mercado. Entre elas temos o Bugzilla, o Jira e o Mantis.

O Jira será excluído da comparação, pois o projeto não é um projeto livre e sim pago para projetos Comerciais. Ficamos então com a comparação entre o Mantis e o Bugzilla.
Comparando as duas ferramentas vemos então que o Mantis é mais simples de instalar e de utilizar, e possui segundo a matriz acima um workflow configurável o que o torna mais extensível. Minha escolha cai sobre o Mantis então por sua simplicidade e também por ser bastante robusto. A simplicidade ajuda a usuários não técnicos executar o cadastro de defeitos.
Entre as diversas funcionalidades oferecidas pelo Mantis temos:
• Pode ser executado em qualquer plataforma.
• Suporta vários bancos de dados.
• Suporta múltiplos mecanismos de autenticação.
• Ciclo de vida personalizável.
• Gerador interno de relatório de defeitos.
• Controle de acesso e permissão por usuário.
• Mecanismo para a criação de campos personalizáveis.
• Notificação por meio de e-mails automáticos.
• Integração com ferramentas de controle de versão.
• Interface webservices para integração com outras ferramentas.

Gestão de Teste

A gestão de testes é a parte principal de um processo de testes. A gestão é importante para o planejamento e controle das atividades de um projeto de teste. A gestão de testes pode ser implementada por meio de ferramentas automatizadas (test management system).

Estas ferramentas devem oferecer um repositório central e padronizado aonde os lideres de testes poderão criar suítes com os casos de teste, atribuir os casos de testes aos testadores, acompanhar o status da execução dos testes e emitir os relatórios com métricas e estatísticas.

Entre as ferramentas que auxiliam na gestão de testes temos:
• TestLink
• RTH
• Testopia
• TestMaster
• Testitool
• Test Case Web
• QaManager
Gosto de utilizar a ferramenta TestLink e o RTH. A escolha do TestLink é hoje a escolha mais apropriada, pois seu desenvolvimento é o mais ativo e por ser uma ferramenta mais utilizada no mercado.

O TestLink é uma aplicação Open Source cujo principal objetivo é gerenciar as atividades de teste de um projeto tais como test cases e test suítes. Ele é útil, pois é possível organizar os requisitos, associar os test cases aos requisitos garantindo então a rastreabilidade entre eles. Outra vantagem é a integração com a ferramenta de gestão de defeitos Mantis que será também utilizada no sistema.
Outra vantagem é o sistema ser desenvolvido em php e utilizar a base de dados mysql, que também é a plataforma utilizada por outras ferramentas do sistema o que demandará menos recursos.

Profissão Tester de Software

Foi publicado na revista TI Digital de fevereiro, na matéria "Contrata-se", sobre o mercado de trabalho em tecnologia da informação:
"Uma novidade é que estão aparecendo cada vez mais vagas específicas para testador de software, o que não era tão comum há alguns anos. Isso reflete a maturidade do mercado e a preocupação cada vez maior das empresas em entregar produtos de qualidade atestada".
Bom, podemos não acreditar na maturidade do mercado. Olhando de perto, vemos situações assustadoras em termos de qualidade, mas muitos concordam nos outros pontos: falhas de software que afetam o grande público agora são assunto no Jornal Nacional. Estas têm impacto direto no caixa e na imagem das empresas e órgãos públicos.
Também se percebe o crescimento da demanda por serviços profissionais de teste, e a pressão para que desenvolvedores e outros perfis em TI passem a incorporar os testes em sua rotina diária. Na mesma publicação, as médias salariais levantadas foram um pouco maiores para analistas de teste que para desenvolvedores Java. Outras publicações falam em crescimento do mercado de testes da ordem de 30% ao ano.
O pré-requisito é conhecer lógica de programação e o básico da tecnologia web, e o público é de profissionais de teste de software e de desenvolvedores interessados em ingressar nessa área. A necessidade de conhecimento de programação é devida ao foco na automação.

Então este mês vou trabalhar vários tópicos no meu blog sobre estratégia de testes, em que são discutidas as premissas da qualidade de software e do papel dos testes no desenvolvimento. Nestes tutoriais vão ser abordados tópicos sobre: ferramentas para automação de testes web, abertas, disponíveis sob licença open source e implementadas na plataforma Java.
Há os módulos de teste de unidade, apoiado em JUnit, de teste de interface usuário, apoiado nas ferramentas da família Selenium, de teste de negócio e especificação executável, apoiado em FitNesse, de montagem de ambiente de testes e de testes de desempenho com JMeter. Em resumo, forma e conteúdo ideais para surfar no mar do teste de software, em cima de uma prancha moderna e ágil.

Lock otimista com Hibernate numa aplicação web

Lock otimista com Hibernate numa aplicação web from Caelum on Vimeo.

Geraçao Y - Jornal da Globo parte 1

Geraçao Y - Jornal da Globo parte 1



Geraçao Y - Jornal da Globo parte 2


Geraçao Y - Jornal da Globo parte 3



Geraçao Y - Jornal da Globo parte 4



Geraçao Y - Jornal da Globo parte 5

Primeiros passos em JPA e Hibernate

O vídeo é introdutório, sobre a Java Persistence API (JPA), para quem ainda não teve a oportunidade de testar a tecnologia. É um passo a passo que vai desde o início, mostrando como fazer o download das bibliotecas necessárias, montar um projeto no eclipse, preparar o banco de dados (MySQL), mapear uma classe em tabela, salvar entidades, carregar entidades e customizar os padrões adotados pela tecnologia (nomes e tamanho de colunas, por exemplo).

Como implementações da JPA entram em cena tanto o Hibernate quanto o Oracle Toplink.

Para esse primeiro screencast, o feedback fica por sua conta! Só é possível haver a continuidade com outros vídeos mais avançados, mais simples, com diferentes abordagens, ou abordando outros tópicos, se isto for realmente agregar algo à comunidade. Esse é o primeiro vídeo produzido e com certeza ainda há muito o que melhorar.

Começando com a JPA e Hibernate from Caelum on Vimeo.

Cursos online - Cursos Gratuitos da Intel

Quem está lutando pra ter um emprego bacana (ou ganhar uma promoção) sabe o quanto vale um certificado de curso/mba/pós bem legal. Dependendo da empresa, o valor dado pra esse tipo de requisito é tão grande que você pode ser descartado na triagem se caso não possuir nada mais do que o seu curso de faculdade no curriculum.

Pensando nisso, quero compartilhar uma descoberta bem bacana que achei na internet: cursos gratuitos online de TI com certificado. Tudo isso patrocinado pela Intel.

Dentre os cursos mais legais (que irei fazer) estão:

Cloud Computing
E business
Empresa Digital
Integração
Storage
Virtualização
Web 2.0
Web Services

Como pode-se notar, são assuntos bem modernos e atuais que podem ser úteis inclusive para consultores ou quem está querendo se aventurar em abrir uma micro empresa. E veja bem: eu só listei os cursos que achei interessantes pra mim, pq ainda tem uma boa quantidade de outros assuntos cobertos pelo site.

Os cursos são basicamente apostilas de conteúdo com vários capítulos, seguidos de testes objetivos. Ou seja, facilmente vc pode concluir vários desses cursos em 1 mês.

Quem tiver interesse, acesse http://www.nextg.com.br/

Fica a dica (:

Como não aprender Java e Orientação a Objetos: getters e setters.

Muitas pessoas perguntam “como aprender OO?“. Há várias maneiras de aprender OO, creio que não tenha uma melhor, mas existem maneiras de não aprender.

Uma das práticas mais controversas que aprendemos no início é a geração indiscriminada de getters e setters. Os exemplos básicos de centenas de tutoriais java estão recheados com getters e setters da pior espécie: aqueles que não fazem sentido algum. Considere:
class Conta {
double limite;
double saldo;
}

Rapidamente os tutoriais explicam o private para o encapsulamento. Mas aí como acessar? Getters e setters nela!
class Conta {
private double limite;
private double saldo;

public double getSaldo() {
return saldo;
}

public void setSaldo(double saldo) {
this.saldo = saldo;
}

public double getLimite() {
return limite;
}

public void setLimite(double limite) {
this.limite = limite;
}
}

Qual é o sentido desse código? Para que esse setSaldo? e esse setLimite? e o getLimite? Você vai usar esse métodos? Nunca crie um getter ou setter sem sentir uma real necessidade por ele. Isso é uma regra para qualquer método, mas particularmente os getters e setters são campeões: muitos deles nunca serão invocados, e grande parte do restante poderia ser substituído por métodos de negócios. Códigos do tipo conta.setSaldo(conta.getSaldo() + 100) se espalharão por todo seu código. Segue então a nossa classe Conta reformulada de acordo com essa necessidade:
class Conta {
private double saldo;
private double limite;

public Conta(double limite) {
this.limite = limite;
}

public void deposita (double x) {
this.saldo += x;
}

public void saca(double x) {
if(this.saldo + this.limite >= x) {
this.saldo -= x;
}
throw new IllegalArgumentException("estourou limite!");
}

public double getSaldo() {
return this.saldo;
}
}

E nem estamos falando de test driven development! Testando a classe Conta rapidamente você perceberia que alguns dos getters e setters anteriores não têm uso algum, e logo sentiria falta de alguns métodos mais voltados a lógica de negócio da sua aplicação, como o saca e o deposita acima. Esse exemplo é muito trivial, mas você pode encontrar por aí muitas classes que não tem a cara de um java bean que expõem atributos como Connection, Thread , etc, sem necessidade alguma!

Existem sem dúvida práticas piores: utilização de ids para relacionar os objetos, arrays não encapsuladas como estruturas, código fortemente baseado em comparação de Strings hardcoded (que o Guilherme Silveira sarcasticamente carinhosamente batizou de POS, ou programação orientada a strings), milhares de métodos estáticos, entre outros. Todas essas práticas são muito comuns quando estamos começando a quebrar o paradigma procedural, e confesso já ter sido um grande praticante de muitas delas. Um professor sempre me disse que você só vai utilizar bem o paradigma da orientação a objetos depois de errar muito.

O Phillip Calçado tem um artigo simplesmente incrível que de certa forma aborda esse tema: classes fantoches (puppets). Uma classe fantoche é a que não possui responsabilidade alguma, a não ser carregar um punhado de atributos! Onde está a orientação a objetos? Uma grande quantidade de classes fantoches são geradas quando fazemos Value Objects, entidades do hibernate, entre outros.

“Mas o que colocar nas minhas entidades do hibernate e nos meus VOs além de getters e setters?“. Antes de tudo, verifique se você realmente precisa desses getters e setters. Para que um setID na sua chave primária se o seu framework vai utilizar reflection ou manipulação de bytecode para pegar o atributo privado, ou se você pode passá-la pelo construtor? Sobre value objects, você realmente precisa dos seus setters? Em muitos casos VOs são criados apenas para expor os dados, e não há necessidade alguma para os setters… bastando um bom construtor!

No hibernate costumo colocar alguns métodos de negócio, algo parecido como na classe Conta. Minhas entidades possuem uma certa responsabilidade, em especial as que dizem respeito aos atributos pertencentes a elas.