Qualidade de Software - Parte I

Atualmente, há cada vez mais sistemas controlados por software, fazendo com que a economia de praticamente todos os países seja muito dependente da qualidade dos softwares por eles usados, justificando um investimento significativo nesse setor.

Há alguns anos atrás, desenvolvia-se software de uma maneira completamente artesanal. A partir de uma simples definição dos requisitos do software, partia-se imediatamente para a implementação do mesmo. Hoje em dia, ainda há muitas empresas que desenvolvem software dessa maneira, mas várias outras estão mudando suas formas de trabalho.

A forma artesanal de trabalho, geralmente, não traz grandes problemas para o desenvolvimento de software de pequeno porte, o qual não exige um esforço muito grande de implementação. Porém, para softwares de grande porte, sérios problemas na implementação podem comprometer todo o projeto.

Com o desenvolvimento cada vez maior da tecnologia de hardware e a conseqüente disponibilidade de máquinas cada vez mais potentes e baratas, o uso de computadores tem-se tornado cada vez mais difundido em diversas áreas. Isso tem feito com que aumente a demanda por software cada vez maior e mais complexo. No entanto, a demanda por software tem-se tornado maior que a capacidade do mercado para atendê-la.

Muitos projetos são entregues com um grande atraso, custando muito mais que o inicialmente previsto, sendo não confiáveis, difíceis de manter e/ou não tendo um desempenho satisfatório. Além do mais, na tentativa de se consertar os erros, muitas vezes introduzem-se mais erros. Geralmente, a quantidade de problemas é diretamente proporcional ao aumento da complexidade do software produzido nos dias de hoje. Esses problemas no desenvolvimento de software são conhecidos mundialmente como a “crise de software”. Ou seja, a “crise de software” corresponde à incapacidade da indústria de software de atender prontamente à demanda do mercado de software, dentro dos custos e dos níveis de qualidade esperados.

Desde os anos 1960, quando o termo “crise de software” foi pronunciado pela primeira vez, muitos problemas desta área foram identificados e muitos deles ainda persistem até os dias de hoje, tais como [Gibbs1994]:

Previsão pobre – desenvolvedores não prevêem adequadamente quanto tempo e esforço serão necessários para produzir um sistema de software que satisfaça às necessidades (requisitos) dos clientes/usuários. Sistemas de software são geralmente entregues muito tempo depois do que fora planejado;

- Programas de baixa qualidade – programas de software não executam o que o cliente deseja, conseqüência talvez da pressa para se entregar o produto. Os requisitos originais podem não ter sido completamente especificados, ou podem apresentar contradições, e isto pode ser descoberto muito tarde durante o processo de desenvolvimento;

- Alto custo para manutenção – quando o sistema é construído sem uma arquitetura clara e visível, a sua manutenção pode ser muito custosa;

- Duplicação de esforços – é difícil compartilhar soluções ou reusar código, em função das características de algumas linguagens adotadas, por falta de confiança no código feito por outra pessoa e até mesmo pela ausência/deficiência de documentação das rotinas e dos procedimentos já construídos.

O reconhecimento da existência da crise de software tem provocado uma forte mudança na forma de como as pessoas desenvolvem software de grande porte, visto que o processo de desenvolvimento atual é mais disciplinado do que no passado. Foi proposto que o desenvolvimento de software deixasse de ser puramente artesanal e passasse  a ser baseado em princípios de Engenharia, ou seja, seguindo um enfoque estruturado e metódico. Assim, surgiu o termo Engenharia de Software, que se refere ao desenvolvimento de software por grupos de pessoas, usando princípios de engenharia e englobando aspectos técnicos e não-técnicos, de modo a produzir software de qualidade, de forma eficaz e dentro de custos aceitáveis.

Portanto, a Engenharia de Software engloba não apenas o desenvolvimento de programas, mas também toda a documentação necessária para o desenvolvimento, instalação, uso e manutenção dos programas. O temo “ciclo de vida de software” compreende todas as etapas, desde a concepção inicial do software, até a sua implementação, implantação, uso e manutenção, de modo que, ao final de cada uma destas etapas, um ou mais documentos são produzidos.

Engenheiros de software devem adotar uma abordagem sistemática e organizada para seu trabalho e usar ferramentas e técnicas apropriadas, dependendo do problema a ser solucionado, das restrições de desenvolvimento e dos recursos disponíveis. Além das técnicas de especificação e implementação de software, os engenheiros de software devem ter conhecimento também de outras técnicas como, por exemplo, de gerenciamento de software. Dessa forma, aumenta-se a probabilidade de produzir software de grande porte com qualidade, ou seja, software que satisfaça os requisitos do usuário, bem como as expectativas de tempo e de orçamento.

As ODSs (Organizações de Desenvolvimento de Software)[1], com o intuito de minimizar os problemas do desenvolvimento do software, têm geralmente adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodológicos para desenvolvimento de software têm sido considerados somente em termos de “um método” de análise/projeto/implementação, isto é, um conjunto de conceitos, técnicas e notações. Essa visão elimina os aspectos tecnológicos, contextuais e organizacionais que potencialmente existem dentro de um processo de software.

Os ambientes tradicionais das ODSs geralmente suportam apenas a engenharia do produto, assumindo um processo implícito e tendo como foco principal o produto. Essa visão tem limitado as ODSs no que diz respeito à tomada de decisões, ao estabelecimento e arquivamento de metas organizacionais, à determinação de pontos para melhoria, à estipulação de prazos para entrega de produtos e à obtenção de uma certificação. O capítulo 2 apresenta os aspectos evolutivos das ODSs e seus produtos de software.

De forma geral, pode-se dividir as funções de uma ODS em três grupos principais [Garg1996][2]:

1.   Definir, analisar, simular, medir e melhorar os processos da organização;

2.   Construir o produto de software;

3.   Medir, controlar, modificar e gerenciar os projetos de software.

Estes três grupos são abordados, respectivamente, pela Engenharia de Processo, pela Engenharia de Produto e pelo Gerenciamento de Projeto.  O relacionamento entre estes grupos é mostrado na Figura 1.1.

Figura 1.1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto

A engenharia de processo tem como meta a definição e a manutenção dos processos da ODS. Ela deve ser capaz de facilitar a definição, a análise e a simulação de um processo, assim como estar apta a implantá-lo, avaliá-lo, medi-lo e melhorá-lo. A engenharia de processo trata os processos de software de uma forma sistemática com um ciclo de vida bem definido. O capítulo 6 aborda este tema discorrendo sobre qualidade de software, um tema cada vez mais relevante e que engloba avaliação e melhoria contínua dos processos da ODS.

O gerenciamento de projeto tem o objetivo de assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessários para um projeto produzir um produto e/ou serviço de acordo com seus requisitos. Todavia, gerenciar projetos de software é uma atividade complexa devido a uma série de fatores, tais como: dinamicidade do processo, grande número de variáveis envolvidas, exigência de adaptabilidade ao ambiente de desenvolvimento e constantes alterações no que foi planejado. Esses fatores dificultam o trabalho das equipes de desenvolvimento na medição do desempenho dos projetos, na verificação de pontos falhos, no registro de problemas, na realização de estimativas e planejamentos adequados. O capítulo 4 aborda esse tema.

A engenharia do produto é encarregada do desenvolvimento e manutenção dos produtos e serviços de software. A principal figura da engenharia do produto é a metodologia de desenvolvimento, que engloba uma linguagem de representação, um modelo de ciclo de vida e um conjunto de técnicas. Os ambientes tradicionais de desenvolvimento de software têm se preocupado essencialmente com a engenharia do produto, assumindo um processo implícito e tendo como foco o produto. Todavia, a engenharia do produto por si só é insuficiente para suprir as necessidades da ODS e torná-la mais produtiva e adequada às exigências do mercado. O capítulo 3 aborda os modelos de ciclo de vida mais utilizados na engenharia do produto. O capítulo 5 descreve as principais atividades da engenharia de produto.

---

[1] Uma ODS representa uma organização independente, ou um departamento ou uma unidade dentro de uma organização, que é responsável por desenvolver, manter, oferecer ou operar um produto ou serviço de software ou um sistema de software intensivo [Wang1999].

[2] A Engenharia de Software deve considerar estas funções objetivando a produção de software de maior qualidade e a melhoria do desempenho da ODS, ou seja, torná-la mais produtiva.

Lições Aprendidas com Teste Automatizado

Meu nome é Ieda Alves e a quase 3 anos eu trabalho aplicando testes automatizados nos produtos desenvolvidos pela empresa onde eu trabalho.

O que é importante saber sobre o teste automatizado?

Primeiro de tudo, para se realizar esse tipo de teste é preciso fazer uso de uma ferramenta que automatize as funcionalidades do sistema. Existem várias no mercado, porém neste artigo vou me ater a apenas uma para garantir o foco.

Segundo, quem garante a eficiência e cobertura do teste não é a ferramenta e sim o tester, ou seja, você ou a pessoa que utilizará a ferramenta. Como a própria denominação “Ferramenta” já diz, o software de automatização é um utensílio de trabalho, não faz milagre sozinho. Cabe ao testador e gerente de teste programar e planejar a execução da automatização de teste.

Terceiro e não menos importante, o planejamento e priorização do teste farão a diferença na dinâmica de gravação dos testes. Conhecer o sistema que será testado faz parte do planejamento, não saber o comportamento e estrutura do que se pretende gravar provavelmente proporcionará tempo e dinheiro jogado fora.

Ferramenta de automação de testes.

Apesar de existirem N ferramentas existentes por ai no mercado como Arbiter, Selenium, TestComplete entre outras, este artigo tratará apenas da ferramenta proprietária Rational Functional Tester – IBM.

A RFT (Rational Functional Tester) é uma solução de teste funcional e de regressão automatizada para equipes de QA preocupadas com a qualidade de seus aplicativos Java™ baseados na Web, Microsoft® Visual Studio, NET®, baseados em terminal, SAP, Siebel e Web 2.0.

Atualmente a RFT está na versão 8.2.1 e as atualizações são garantidas pelo sistema web da IBM. Claro que como um software proprietário é preciso ter a licença para poder fazer as ditas atualizações. Diga-se de passagem, não é um software barato.

O software utiliza a plataforma Eclipse como suporte às funcionalidades e interface e os testes são executados na ideologia gravar/reproduzir. A gravação é iniciada e basicamente todas as ações do testador no sistema são gravadas na forma de scripts em linguagem Java ou Visual Basic. Os scripts são totalmente editáveis e passíveis de manipulação.

Após a gravação é só mandar reproduzir o script gravado, todas as ações serão repetidas conforme executado pelo testador. A ferramenta fornece um relatório na forma de log dos eventos manipulados pelo escript, inclusive se durante a execução aconteceu algo inesperado.

Também é possível manter revisões dos scripts em um repositório SVN, assim é mantido a rastreabilidade de tudo que foi gravado.

Em conjunto com a RFT utilizo outro software chamado Test Mananger, também da IBM. Este software faz o gerenciamento e a aglutinação dos scripts criados na RFT. É neste momento que a estrutura seqüencial e funcional do teste é criada. São criadas as suítes de execução que por sua vez incorporam os Test Cases (Casos de testes – os scripts). É esta execução em cadeia que garante a qualidade do teste automatizado.

Nesta ferramenta também é possível configurar e recolher evidências dos testes, como por exemplo, logs de execução, gráficos e relatórios populados, o que agrega grande valor a execução do teste automatizado, uma vez que comprova as funcionalidades do sistema testado, na forma de documentação também automática.

Experiência do testador.

Tudo isso parece uma maravilha, porém não é esse “mar de rosas não”, as ferramentas são "temperamentais" e é ai que entra as habilidades dos testadores. O que está descrito no site de especificações das ferramentas não ajudam muito, o que vale mesmo são as lições apreendidas durante o projeto piloto.

Existem muitos detalhes que não são nada intuitivos e alguns comportamentos que as ferramentas não tratam, incompatibilidade com o browser é uma delas, e isso precisa ser contornado.  Sem falar na oneração do processamento e acumulo de cache.

O testador precisa mais do que nunca do seu perfil investigativo, pois é difícil trocar experiências a respeito da RFT. O Site da IBM muitas vezes se transforma em um labirinto, principalmente no início, quando se está começando. Até se encontrar algo útil levam-se horas. Ir a fundo nas configurações algumas vezes pode estragar com tudo, por isso deve sempre anotar ou guardar as configurações originais ou seja, aquele backup sempre será uma boa idéia. Precaução e bom senso são as palavras.

Planejamento dos Testes

Para se automatizar um sistema é preciso que o mesmo esteja estável, pois o  objetivo principal do teste automatizado é homologar um produto garantindo que os recursos já validados em uma versão anterior continuam funcionando após a inclusão de novas melhorias/requisitos.

O teste automatizado começa antes da gravação propriamente dita, o mais importante na hora de automatizar um sistema é conhecê-lo. Saber o seu fluxo de funcionamento, suas dependências entres registros, entrada e saídas. Assim é possível criar um roteiro de gravação.

O roteiro de gravação é um documento que serve como guia e recolhimento de informações acerca do sistema. Nele devem estar relatadas as dependências entre registros, ou seja, os pré-requisitos para cada registro a ser gravado, além disso, deve estar descrito o fluxo que se deve seguir dentro do sistema, por onde começar e todas as etapas críticas que precisam ser gravadas.

Uma técnica também muito utilizada é chamada de "stubs", que consiste em popular os registros / telas mais simples e com poucos campos através de scripts e/ou congelando a base de dados já com esses dados inseridos. A automatização de um sistema deve ter como foco garantir o fluxo principal e os requisitos crítico do sistema em automatização.

Com base no roteiro de teste fica muito mais fácil criar os Casos de Testes. Cada script pode ser um caso de teste, isso vai depender da métodologia adotada pela área de teste, porém criar scripts muito logos nãp são uma boa idéia, principalmente na hora de manutení-lo.

Por enquanto esse artigo fica por aqui, espero futuramente contribuir mais sobre as peculiaridades do teste automatizado e da ferramenta RFT com as minhas experiências e rotinas de trabalho.

Ieda Alves.

Como priorizar falhas / defeitos?

A Matriz GUT (Gravidade, Urgência e Tendência) é uma ferramenta utilizada na priorização das estratégias, tomadas de decisão e solução de problemas de organizações/projetos.

Gravidade: impacto do problema sobre coisas, pessoas, resultados, processos ou organizações e efeitos que surgirão, caso o problema não seja resolvido.

Urgência: relação com o tempo disponível ou necessário para resolver o problema.

Tendência: potencial de crescimento do problema, avaliação da tendência de crescimento, redução ou desaparecimento do problema.

A pontuação de 1 a 5, para cada dimensão da matriz, permite classificar em ordem decrescente de pontos os problemas a serem atacados na melhoria do processo.

Após atribuída a pontuação, deve ser multiplicado GxUxT e achar o resultado, priorizando em ordem decrescente, de acordo com os pontos obtidos.

Critérios GUT
Pontos	Gravidade	Urgência	Tendência
5	Prejuízo / Dificuldade é extremamente grave	Necessária ação imediata	Se nada for feito, agravamento será imediato
4	Muito grave	Com alguma urgência	Vai piorar em curto prazo
3	Grave	O mais cedo possível	Vai piorar em médio prazo
2	Pouco Grave	Pode esperar um pouco	Vai piorar em longo prazo
1	Sem Gravidade	Não tem pressa	Não vai piorar ou até pode melhorar

Matriz:

		Organização'
		Processo:
Problemas			G	U	T	Total	Priorização
1
2
3
4
5
6
7

A partir da matriz GUT pode ser desenvolvida uma nova matriz que contemple as necessidades de cada organização. Abaixo estarei mostrando outro exemplo na qual acredito que atenderá a boa parte dos casos:

Detectabilidade
Opções	Critérios de definição
1-Alta	Alto grau de certeza de que o erro será detectado pelo usuário durante a operação normal do sistema em suas funcionalidades mais elementares / usuais.
2-Moderada	O erro é percebido apenas em situações específicas ou funcionalidades não essenciais do produto.
3-Baixa	Erro detectado em situações extremamente específicas e que necessitam de uma rara combinação de fatores para que ocorra. O erro raramente será percebido pelo usuário.

Severidade
Opções	Critérios para Definição	Exemplos
1-Crítico	- Falha geral da aplicação. - Perda de dados. - Instabilidade da aplicação ou de seus serviços. - Impede a continuidade dos testes ou do uso da aplicação como um todo. - Build da aplicação corrompido. - Funcionalidades principais da aplicação seriamente comprometidas.	- O erro não permite a continuidade dos testes ou compromete severamente o resultado dos mesmos. - Erros de Java, PHP, SQL, etc. - “Fatal error”. - Funcionalidade desenvolvida em desacordo com os requisitos especificados (desvio significativo). - Problemas graves de desempenho. - Incompatibilidade com o browser ou outros itens de ambiente. - Links quebrados. - Loops infinitos. - Produtos cartesianos em consultas/relatórios.
2-Grave	- Sério comprometimento de funcionalidade (funcionalidade impossível de ser utilizado, sistema travando ou se comportando de maneira não prevista). - Bug em funcionalidade essencial do produto com workaround complexo. - Comprometimento moderado da continuidade dos testes.	- Funcionalidade desenvolvida em desacordo com os requisitos especificados (desvio moderado). - Problemas perceptíveis de desempenho com razoável impacto no uso normal da aplicação. - Regras de validação de campos não aplicadas corretamente (data inválida, valor fora da faixa, etc.).
3-Moderado	- Problemas moderados em funcionalidades do produto. - Existe um workaround simples. - Baixo impacto nos testes. - Ergonomia razoavelmente comprometida e com viabilidade de melhoria.	- Layout de tela/relatório fora dos padrões. - Layout de tela/relatório ergonomicamente inadequado. - Falta de valores padrões para campos quando aplicável. - Navegação fora de ordem entre os componentes da tela. - Teclas de atalho padrão não desenvolvidas corretamente. - Foco setado incorretamente. - Imagens não carregadas. - Erros de ordenação/quebra em consultas e relatórios. - Termos inadequados/fora do contexto.
4-Cosmético	- Não chegam a comprometer o objetivo final da funcionalidade. - Afetam a aparência na forma de erro, não de melhoria.	- Layout de tela/relatório esteticamente inadequado. - Erros de documentação. - Erros de ortografia/digitação. - Alinhamento de campos. - Falta de clareza em mensagens para o usuário.
5-Melhoria	- Não são erros, mas oportunidades de melhoria identificadas no uso do sistema durante a fase de inspeção. - Existe grande probabilidade de o cliente sugerir a mesma melhoria no futuro. - Ação pró-ativa.	- Telas/relatórios com layout adequado, mas com oportunidade de melhoria. - Sugestão de termos. - Cores.

			Prioridade
MATRIZ DE PRIORIZAÇÃO PARA CORREÇÃO						Detectabilidade
						Alta	Média	Baixa
Severidade				Crítico		P1	P1	P1
				Grave		P1	P1	P2
				Moderado		P2	P2	P3
				Cosmético		P3	P3	P4
				Melhoria		P4	P4	P4
Prioridade		Prazo Correção			Definição
P1		x Dias úteis (de acordo com seu SLA)			Resolver imediatamente Desenvolvimento posterior e/ou teste não pode ocorrer até que o defeito tenha sido reparado. O sistema não pode ser usado até que o reparo tenha sido efetuado.
P2		x Dias úteis (de acordo com seu SLA)			Dar alta prioridade O defeito deve ser resolvido o mais rápido possível porque está prejudicando as atividades de teste e/ou desenvolvimento. O sistema vai ser severamente afetado até que o defeito seja reparado.
P3		x Dias úteis (de acordo com seu SLA)			Fila normal O defeito deveria ser resolvido no curso normal das atividades de desenvolvimento. Ele pode esperar até que uma nova edição ou versão seja criada.
P4		x Dias úteis (de acordo com seu SLA)			O defeito pode ser postergado indefinidamente. Pode ser resolvido em uma revisão maior do sistema no futuro ou nem resolvida.