Validação X Verificação

Duas definições bem recorrentes no meio do teste são validação e verificação. Apesar de estarem intimamente ligadas, e contribuírem com o esforço de teste, são atividades diferentes.

Segundo Offutt:

Validação: é o processo de avaliação do software, realizado ao final do processo de desenvolvimento, que garante a conformidade com sua intenção de utilização;

Verificação: é o processo de determinar quando os produtos de uma determinada fase do processo de desenvolvimento preenchem os requisitos estabelecidos durante a fase anterior.

 

Ferramenta de Rastreamendo de Defeitos – Bug Tracking Tool

Cada defeito(bug) encontrado por um caso de teste deve ser registrado num sistema de armazenamento de defeitos nomeado por um identificador único e inequívoco, compondo uma base de dados sobre os defeitos encontrados em determinado produto ou projeto.
Dessa forma, um sistema de rastreamento de defeitos é um programa ou aplicação que permite que a equipe de teste possa criar, armazenar, gerenciar, e analisar os relatórios de defeitos. Esse sistema deve manter esses registros de forma que seja possível inserção, remoção e busca desses defeitos, facilitando a organização das informações sobre o que foi encontrado e o que já foi corrigido.

Nesse sentido, a decisão de qual sistema de rastreamento de defeitos utilizar é extremamente importante! Atualmente estou pesquisando sobre o assunto, e me parece que boas candidatas a escolha são:

Bugzilla

Ferramenta já a um certo tempo no mercado, open source e desenvolvida em Perl. Utilizada por grandes nomes, incluindo NASA, segundo o site da própria ferramenta.

Mantis

Ferramenta também free, desenvolvida em php.

Ambas as ferramentas trabalham com diferentes bancos de dados, e parecem ser bem robustas.

Alem dessas duas ferramentas, uma outra que não é específica para rastreamento de defeitos, mas que vi em alguns lugares que pode ser utilizada para esse fim é o Redmine. Essa ferramenta me interessa um pouco mais pois está implantado na empresa onde trabalho, e creio ser melhor utilizar uma ferramenta que já é utilizada e conhecida pelo pessoal, do que inserir uma nova ferramenta no contexto. Basta saber se o redmine será customizável o suficiente para o propósito que preciso, que é o de rastreamento de defeitos.

EAP – Estrutura Analítica de Projeto

Do inglês, work breakdown structure – wbs pode ser visto como a decomposição de um projeto em componentes menores. Essa estrutura define e agrupa os elementos de trabalho de um projeto de forma a organizar e definir o escopo dos trabalhos desse projeto.

Um WBS ainda pode ser entendido como uma estrutura em árvore que demonstra a subdivisão do esforço necessário para alcançar um objetivo. Esse objetivo pode ser um programa, um projeto, um contrato, etc.

No meu caso, o interesse está no auxílio que essa estrutura provê para o planejamento e execução de um projeto, haja visto a necessidade de gerenciar o projeto de implantação de testes. Para compor essa estrutura, é necessário obedecer uma regra denominada regra dos 100%. Essa regra dita que o WBS deve capturar 100% do trabalho definido para o projeto, e também deve abarcar todos os entregáveis.

Para criar essa estrutura há várias ferramentas, e novamente, busco por ferramentas free. Encontrei uma no Ubuntu as seguintes ferramentas:

FreePlane: http://freeplane.sourceforge.net/wiki/index.php/Main_Page

FreeMind: http://freemind.sourceforge.net/wiki/index.php/Main_Page

Xmind: http://www.xmind.net/

Dessas, a primeira vista, a que mais gostei foi da Xmind. A interface é boa e intuitiva. Irei mexer mais com as outras para ver se condiz com o que preciso.

Pojeto != Programa

Hoje aprendi a diferença entre projeto e programa. Podemos ter um projeto para cada área dentro de um processo de software, ou seja, um projeto de desenvolvimento, um para testes, um para configurações, e assim sucessivamente. Logo, um programa é composto por um apanhado de projetos.

Ferramenta para Teste de Unidade

Teste unitário, ou teste de desenvolvedor, independente de como é chamado, um fato sobre ele é a necessidade de uma boa ferramenta para realizá-lo. Nesse sentido, quando se pensa em ferramentas para teste, há uma gama incrível de ferramentas proprietárias que dizem realizar um bom trabalho.

Apesar da existência dessas ferramentas proprietárias, onde trabalho, e até mesmo em parte por política própria, priorizo a busca por ferramentas free ou open. Com base nessas observações, ao procurar informações, duas ferramentas sobressaem quando se fala em teste de unidade, e são elas:

JUnit: http://www.junit.org/

Jabuti: http://www.labes.icmc.usp.br/site/content/jabuti

Ao se decidir por uma ferramenta, várias condições devem ser levadas em consideração:

• Sua equipe está familiarizada com ela? se sim, ótimo! se não, haverá gasto de tempo e $$ com treinamentos ( sem contar a possível resistência de aprendizado de alguma ferramenta nova).
• A ferramenta é mantida por uma comunidade ativa? possui alguma empresa que auxilia a manter essa atividade? possui bom suporte? uma comunidade pouco ativa implica em ferramenta desatualizada, defasada. Sem uma grande empresa para movimentar essa comunidade, talvez a comunidade por si só não consiga se manter. Quanto a suporte, a ausência de boa documentação, bons fóruns, dificulta não só o aprendizado, mas também a resolução de problemas novos.
• Qual o grau de integração dessa ferramenta com outras ferramentas? por exemplo, essa ferramenta é um plugin? ou ela existe por si só?

Essas são apenas algumas, das várias questões a serem levantadas quando se escolhe uma ferramenta para determinado fim. Sendo assim, preciso de mais pesquisa para decidir qual delas utilizar.

Sugestões de Livros para Aprendizado de Teste de Software

Durante a escrita da minha monografia utilizei vários livros para aprender sobre teste de software, alguns deles eu utilizei por mais tempo, e por mais vezes. O primeiro deles, e único em português diga se de passagem, é um no qual o meu orientador foi co-autor:

Introdução ao teste de software. DELAMARO, Márcio Eduardo (Org.) ; MALDONADO, José Carlos (Org.) ; JINO, Mario (Org.) . 1. ed. Rio de Janeiro – RJ: Editora Campus, 2007. v. 1. 394 p.

http://compare.buscape.com.br/introducao-ao-teste-de-software-autor-delamaro-marcio-eduardo-editora-elsevier-editora-ltda-isbn-9788535226348.html

Esse livro é bom para ter uma visão geral sobre teste de software, e ter uma introdução sobre o assunto. A segunda referência que gostaria de indicar, e também muito bom para aprender conceitos, de uma forma mais resumida, é o livro:

Introduction to Software Testing. Paul Ammann and Jeff Offutt.

http://cs.gmu.edu/~offutt/softwaretest/

Após aprender os conceitos básicos sobre teste, para aprender sobre o processo de teste de uma visão mais prática, o que considero favorito é o livro do Rex Black:

Managing the Testing Process, 3 ed. Rex Black.

https://store.rbcs-us.com/index.php?option=com_ixxocart&Itemid=6&p=product&id=43&parent=4

 

Requisitos de Teste

A definição de Requisito de teste, segundo Amman, Offut. é: “um elemento específico de um artefato de software que um caso de teste deve satisfazer ou cobrir”. Esses requisitos podem ser pensados como condições a serem testadas, ou seja, as possibilidades de entradas e ações a serem testadas.

Os requisitos de teste podem ser derivados – criados, obtidos – a partir de diferentes fontes de informação como: documento de requisitos, documentos de modelagem, e até mesmo o código fonte da aplicação sob teste.

Com base nesses requisitos de teste, é que os casos de teste são gerados. Dessa forma, o conjunto de teste deve ser criado para satisfazer, se possível, todos os requisitos de teste. O “se possível” na frase anterior é dito pois podem haver requisitos de teste que sejam inalcançaveis em um produto de software de modo que seja impossível satisfazê-los.