Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'.
Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes.
No post anterior, justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP):
Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do software pronto, porém, sem tempo hábil para a mínima garantia de qualidade.
Taí uma palavra interessante em todo esse processo: qualidade. Uma pergunta talvez esclareça de uma forma definitiva a necessidade (eu diria obrigatoriedade) de envolver os testes intimamente no ciclo de desenvolvimento de um software: Como garantir a qualidade de um produto se o mesmo não passou por um controle de qualidade (testes de software, no caso) ?
Acho que a partir daqui, não precisamos mais justificar a importância dos testes e podemos iniciar na descrição disciplina propriamente dita. Vamos lá!
O RUP oferece diversos mecanismos para integrar o processo de teste ao esforço destinado ao desenvolvimento do software, segue a lista:
- Fazer com que Teste seja uma disciplina distinta;
- Usar a abordagem iterativa de desenvolvimento;
- Verificar qualidade continuamente;
- Deixar os casos de uso guiarem o desenvolvimento;
- Agendar a implementação baseada em riscos;
- Gerenciar mudanças estrategicamente;
- Usar processo corretamente dimensionado.
Abaixo segue uma análise mais específica dos itens que especificam a disciplina de Testes (marcados em negrito na lista acima):
Fazer com que Teste seja uma disciplina distinta
Como foi explicado no post anterior, em RUP as atividades são organizadas em grupos similares chamados de Disciplinas.
Nesse modelo, Teste é uma das disciplinas. Tal disciplina participa do processo de desenvolvimento tanto como consumidor quanto como fornecedor de artefatos e atividades - cada um desses é claramente definido no RUP. As instruções de como testar em RUP define artefatos, templates, ferramentas mentoras, guias, e pontos de checagem a serem usados. A figura abaixo mosta o workflow da disciplina de Testes:
A interface entre as outras disciplinas e Testes é também claramente definida no RUP. Os artefatos e atividades que outras disciplinas disponibilizam são projetadas e construídas para prover valor (alimentar) a disciplina de Testes. Ou seja, não há necessidade de reformatar documentos ou reavaliar a qualidade dos mesmos, porque desde a construção da documentação é considerada a sua utilização em Testes.
O RUP define não só um papel específico para a disciplina de Testes, define 4 deles. A seguir a figura que os define:
Verificar qualidade continuamente
Verificar continuamente a qualidade é uma boa prática do RUP. Tal verificação é conseguida através de pontos de checagem, inerentes a cada um dos artefatos, atividades e entregas no decorrer do processo. Cada membro do time, com seu respectivo papel, é responsável pela qualidade de seu trabalho e tem as ferramentas necessárias para garantí-la.
Deixar os casos de uso guiarem o desenvolvimento
Podemos dizer que o RUP é 'use-case driven' - guiado pelos casos de uso. Ou seja, os requerimentos funcionais são previamente capturados na forma de casos de uso. Os esforços de design e implementação têm foco voltado para entregar o produto tal como descrito nos casos de uso. Tal característica fica mais evidente quando analisamos a figura a seguir:
A grosso modo, um caso de uso é um diálogo entre um ator (alguém de fora do sistema) e o sistema propriamente dito. Os casos de uso simplificam a visualização do sistema a ser construído pelo time de desenvolvimento; eles organizam os requerimentos do sistema de um modo que os faz mais compreensíveis e utilizáveis por todos os membros do time, e não somente pelos membros que irão implementar tais requerimentos.
Voltando a disciplina de testes, existe uma forma simples de transformar os casos de uso em casos de testes. Tal processo é descrito por Jim Huemann no seguinte artigo: "Generating Test Cases From Use Cases".
Para ler mais sobre RUP, e também sobre a disciplina de Testes, segue o link:
Perguntas?
Até a próxima!
Comentários
Postar um comentário