Parte I

Fundamentos de Teste e Anlise

Teste e Anlise de Software em Resumo

Antes de considerar as tcnicas e os aspectos especficos de teste e anlise de software, til visualizar o quadro geral da qualidade de software no contexto de um projeto e organizao de desenvolvimento de software. O objetivo deste captulo introduzir a variedade das atividades de verificao e validao de software (V&V) e diretrizes para selecion-las e combin-las em um processo de desenvolvimento de software. Esta viso geral necessariamente superficial e incompleta, com muitos detalhes deixados para os captulos subseqentes.

1.1 Processos de engenharia e verificao

As disciplinas de engenharia alinham atividades de projeto e construo com atividades que verificam produtos intermedirios e finais de forma que os defeitos possam ser identificados e removidos. A Engenharia de Software no exceo: a construo de software de alta qualidade requer a combinao de atividades de projeto e verificao ao longo do desenvolvimento. Atividades de verificao e projeto podem tomar vrias formas, desde aquelas adequadas para a construo altamente repetitiva de itens no-crticos para grandes mercados at aquelas para produtos altamente customizados ou altamente crticos. Atividades de verificao apropriadas dependem da disciplina de engenharia, do processo de construo, do produto final e dos requisitos de qualidade. A repetio e os altos nveis de automao em linhas de produto reduzem a necessidade de verificao de produtos individuais. Por exemplo, apenas alguns componentes cruciais de produtos como telas, placas de circuitos e torradeiras so verificados individualmente. Os produtos finais so testados estatisticamente. O teste completo de cada produto individual pode no ser econmico, dependendo dos custos do teste, da confiabilidade do processo de produo e dos custos de falhas em campo. Mesmo para mercados de consumo em massa, processos complexos ou requisitos de qualidade rgidos podem exigir projetos sofisticados e procedimentos avanados de verificao. Por exemplo, computadores, automveis e avies,

26

Parte I Fundamentos de Teste e Anlise

mesmo sendo produzidos em srie, so verificados individualmente antes da entrega aos consumidores. Outros produtos no so produzidos em srie, mas elaborados individualmente por meio de processos e ferramentas altamente refinados. Residncias, carros de corrida e software no so feitos em srie. Em vez disso, cada casa, carro de corrida e pacote de software , ao menos, parcialmente nico em seu projeto e funcionalidade. Tais produtos so verificados individualmente, tanto durante como depois de sua produo, a fim de identificar e eliminar erros. A verificao de mercadorias produzidas em srie (tais como telas, placas e torradeiras) consiste em repetir um conjunto predefinido de testes e anlises que indicam se os produtos satisfazem aos padres de qualidade. Em contraste, a verificao de um produto nico, tal como uma casa, requer a elaborao de um conjunto especfico de testes e anlises para avaliar a sua qualidade. Alm disso, a relao entre os resultados dos testes e anlises e a qualidade do produto no pode ser definida uma nica vez para todos os produtos, devendo ser avaliada para cada produto. Por exemplo, o conjunto de testes de resistncia para avaliar a qualidade de um piso deve ser feito sob medida para cada piso, e a qualidade resultante depende dos mtodos de construo e da estrutura do edifcio. A verificao se torna mais difcil com a complexidade e a variedade dos produtos. Casas pequenas construdas com tecnologias comparveis em ambientes anlogos podem ser verificadas com procedimentos padronizados. Os testes so parametrizados para cada casa, mas, apesar disso, so rotinas. A verificao de um arranha-cu ou de uma casa construda em uma rea altamente ssmica, por outro lado, no pode ser generalizada, exigindo testes e anlises elaboradas especificamente para cada caso. O software um dos mais complexos e variveis artefatos construdos de forma regular. Requisitos de qualidade de software usados em um ambiente podem ser muito diferentes e incompatveis para outro ambiente ou domnio de aplicao, e sua estrutura evolui e freqentemente se deteriora medida que o sistema cresce. Alm disso, a no-linearidade inerente aos sistemas de software e a distribuio irregular dos erros complica a verificao. Se um elevador pode transportar com segurana uma carga de 1000 kg, ento pode transportar com segurana qualquer carga mais leve, mas se um procedimento ordena corretamente um conjunto de 256 elementos, o mesmo pode falhar para um outro conjunto de 255, 53 ou 12 elementos, bem como para 257 ou 1023. O custo da verificao de software freqentemente corresponde a mais da metade do custo total do desenvolvimento e manuteno. Tcnicas avanadas de desenvolvimento e ferramentas de suporte poderosas podem reduzir a freqncia de algumas classes de erros, mas estamos longe de eliminar erros e produzir software sem falhas. Em muitos casos, novas abordagens de desenvolvimento introduzem novos tipos sutis de erros, que podem ser mais difceis de revelar e remover do que erros clssicos. Este o caso, por exemplo, do software distribudo, que pode apresentar problemas de deadlock ou condies de corrida (race conditions) que no esto presentes em programas seqenciais. Da mesma forma, desenvolvimento orientado a objetos introduz novos problemas devido ao uso de polimorfismo, amarrao dinmica e estados privados que no ocorrem ou ocorrem menos em software procedural.

Captulo 1 Teste e Anlise de Software em Resumo

27

A variedade de problemas e a riqueza de abordagens fazem com que seja um desafio escolher e planejar a combinao correta de tcnicas para atingir o nvel exigido de qualidade satisfazendo requisitos de custo. No h receitas prontas para abordar o problema de verificar um produto de software. Mesmo os especialistas mais experientes no tm solues predefinidas, necessitando projetar uma soluo que seja adequada ao problema, aos requisitos e ao ambiente.

1.2 Questes bsicas

A fim de comear a compreender como abordar o problema de verificao de software, consideremos um caso hipottico. O Comit de Governana da Chipmunk Computadores, um fabricante de computadores (imaginrio), decide acrescentar novas funcionalidades de compras online no site da companhia, a fim de permitir que os clientes comprem produtos configurados individualmente. Vamos assumir o papel do gerente da qualidade. Para comear, devemos responder algumas questes bsicas: Quando a verificao e validao comeam? Quando esto completas? Que tcnicas especficas devem ser aplicadas durante o desenvolvimento do produto para atingir qualidade aceitvel a um custo aceitvel? Como podemos avaliar se um produto est pronto para liberao? Como podemos controlar a qualidade de liberaes sucessivas? Como o processo de desenvolvimento em si pode ser melhorado no decurso de projetos atuais e futuros para melhorar os produtos e tornar a verificao mais rentvel?

1.3 Quando a verificao e validao comeam e terminam?

Embora alguns processos primitivos de desenvolvimento de software concentrem o teste e a anlise no final do ciclo de desenvolvimento, e o cargo de testador em algumas organizaes ainda se refira a uma pessoa que meramente executa casos de teste em um produto completo, hoje em dia amplamente compreendido que a execuo do teste uma pequena parte do processo de verificao e validao necessrio para avaliar e manter a qualidade de um produto de software. A verificao e validao comeam assim que decidimos construir um produto de software, ou mesmo antes. No caso da Chipmunk Computers, quando o Comit de Governana solicita ao gerente de Tecnologia da Informao (TI) um estudo de viabilidade, o gerente de TI considera no apenas custos de desenvolvimento e funcionalidade, mas tambm a qualidade exigida e seu impacto no custo total. O gerente de qualidade de software da Chipmunk participa do estudo de viabilidade, juntamente com outros projetistas, focando particularmente na

28

Parte I Fundamentos de Teste e Anlise

anlise de risco e nas medidas necessrias para avaliar e controlar a qualidade a cada etapa do desenvolvimento. A equipe avalia o impacto de novas funcionalidades e novos requisitos de qualidade no sistema completo e considera a contribuio de atividades de controle de qualidade no custo e prazo de desenvolvimento. Por exemplo, migrar funcionalidades de vendas para o site da Chipmunk ir aumentar a criticalidade da disponibilidade do sistema e introduzir novas questes de segurana. Um estudo de viabilidade que ignore a qualidade pode levar a atrasos e altos custos no-previstos e, muito possivelmente, ao fracasso do projeto. O estudo de viabilidade necessariamente envolve algum projeto preliminar da arquitetura, como, por exemplo, uma diviso da estrutura do software correspondendo a uma diviso de responsabilidades entre uma equipe de projeto da interface e grupos responsveis pelo software central de negcio (a lgica de negcio) e pela infra-estrutura de suporte, e um esboo de plano de construo dividindo o projeto em uma srie de liberaes incrementais. Oportunidades e obstculos para uma verificao eficaz e rentvel so consideraes importantes ao fatorar o esforo de desenvolvimento em subsistemas e fases, bem como na definio das interfaces principais. O projeto geral da arquitetura divide o trabalho e separa aspectos de qualidade que podem ser verificados independentemente nos diferentes subsistemas, facilitando assim o trabalho da equipe de teste assim como de outros desenvolvedores. Por exemplo, a equipe de projeto da Chipmunk divide o sistema em uma camada de apresentao, uma de lgica e a infra-estrutura. O desenvolvimento dos trs subsistemas atribudo a trs diferentes equipes com experincia especializada, cada uma das quais devendo satisfazer restries apropriadas de qualidade. O gerente da qualidade guia o projeto inicial em direo a uma separao de vises que facilitar o teste e a anlise. No site da Chipmunk, uma interface clara entre a camada de apresentao e a de lgica permite uma diviso correspondente entre o teste de usabilidade (que responsabilidade do grupo de interface com o usurio, no do grupo de qualidade) e verificao do funcionamento correto. Uma separao clara entre infra-estrutura e lgica de negcio serve a um propsito similar. A responsabilidade por um ncleo pequeno de funes crticas alocada a especialistas da equipe de infra-estrutura, distribuindo regras eficientemente verificveis de uso consistente dessas funes ao longo de outras partes do sistema. Levar em conta as restries de qualidade durante a decomposio inicial em subsistemas permite uma alocao melhor dos requisitos de qualidade e facilita o projeto detalhado e o teste. No entanto, muitas propriedades no podem ser garantidas por um subsistema apenas. A decomposio inicial das propriedades dada pelo estudo de viabilidade ser detalhada durante o projeto posterior e pode resultar em requisitos de qualidade cruzados entre subsistemas. Por exemplo, a fim de garantir um determinado nvel de segu-

Captulo 1 Teste e Anlise de Software em Resumo

29

rana, a equipe de projeto de infra-estrutura pode demandar a verificao da ausncia de certas brechas de segurana (p. ex., estouros de buffer) em outras partes do sistema. O plano de construo inicial tambm inclui algumas decises preliminares sobre tcnicas de teste e anlise a serem usadas no desenvolvimento. Por exemplo, o prottipo preliminar da funcionalidade de vendas online da Chipmunk no ser submetido a um teste de aceitao completo, mas ser usado para validar a anlise de requisitos e algumas decises de projeto. O teste de aceitao da primeira verso ser baseado, primariamente, no retorno de algumas lojas selecionadas, mas tambm incluir teste para verificar ausncia de brechas de segurana mais comuns. A segunda verso incluir teste de aceitao completo e medidas de confiabilidade. Se o estudo de viabilidade resulta em aprovao do incio do projeto, as atividades de verificao e validao (V&V) comearo junto com outras atividades de desenvolvimento e, assim como o desenvolvimento em si, iro continuar at bem depois da liberao inicial de um produto. As novas funes Web da Chipmunk sero entregues em uma srie de fases, com os requisitos reavaliados e modificados aps cada fase, portanto, essencial que o plano de V&V seja vivel em termos de custos ao longo de uma seqncia de liberaes cujos resultados no podem ser totalmente conhecidos de antemo. Mesmo quando o projeto est completo, o software continuar a evoluir e se adaptar a novas condies, como uma nova verso do banco de dados subjacente, ou novos requisitos, como a abertura de uma diviso europia de vendas da Chipmunk. As atividades de V&V continuam ao longo de cada mudana pequena ou grande do sistema.

Por que combinar tcnicas?

Nenhuma tcnica de teste ou de anlise pode servir sozinha a todos os objetivos. As razes primrias para combinar tcnicas, em vez de escolher uma tcnica melhor, so: Eficcia para diferentes classes de erros. Por exemplo, condies de corrida so muito difceis de encontrar com teste convencional, mas podem ser detectadas com anlise esttica. Aplicabilidade em diferentes etapas do projeto. Por exemplo, pode-se aplicar tcnicas de inspeo inicialmente aos requisitos e representaes de projeto que no so apropriadas para anlises mais automticas. Diferenas de objetivos. Por exemplo, teste sistemtico (no-randmico) busca maximizar deteco de falhas, mas no pode ser usado para medir confiabilidade; para isso, teste estatstico necessrio. Compromissos entre custo e garantias. Por exemplo, pode-se utilizar uma tcnica relativamente custosa para garantir algumas propriedades essenciais de componentes centrais (p.ex., um kernel de segurana), enquanto que as mesmas tcnicas seriam caras demais para aplicar a todo o projeto.

30

Parte I Fundamentos de Teste e Anlise

1.4 Quais tcnicas devem ser aplicadas?

O estudo de viabilidade o primeiro passo de um processo de desenvolvimento complexo que deve levar entrega de um produto satisfatrio por meio de atividades de elaborao, verificao e validao. Atividades de verificao direcionam o processo para a construo de um produto que satisfaz os requisitos verificando a qualidade dos artefatos intermedirios, bem como do produto final. Atividades de validao avaliam a correspondncia dos artefatos intermedirios e do produto final com as expectativas dos usurios. A escolha do conjunto de tcnicas de teste e anlise depende das restries de qualidade, custo, prazo e recursos no desenvolvimento de um produto em particular. Para o subsistema da lgica de negcio, a equipe de qualidade planeja utilizar um prottipo preliminar para validar as especificaes de requisitos. Eles planejam utilizar tcnicas automticas para fazer verificaes estruturais simples das especificaes de arquitetura e projeto. A equipe far uma capacitao de pessoal para inspeo de projeto e de cdigo, que ser baseada em listas de verificao (checklists) que identificam desvios das regras de projeto para garantir manutenibilidade, escalabilidade e correspondncia entre projeto e cdigo. As especificaes de requisitos na Chipmunk so escritas em formato estruturado, semiformal. No so adequadas para verificao automtica, mas podem ser inspecionadas por desenvolvedores, assim como qualquer outro software. A organizao compilou uma lista de verificao baseada em suas regras de estruturao de documentos de especificao e em sua experincia com problemas em requisitos de sistemas anteriores. Por exemplo, a lista de verificao para inspeo de especificaes de requisitos na Chipmunk solicita que o auditor confirme que cada propriedade especificada declarada de uma forma que pode ser eficientemente testada. O plano de teste e anlise requer inspeo das especificaes de requisitos, especificaes de projeto, do cdigo fonte e dos documentos de teste. A maior parte das inspees do cdigo fonte e dos documentos de teste so uma simples questo de solicitar uma reviso manual por outro desenvolvedor, embora alguns componentes crticos sejam indicados para uma reviso adicional e comparao de anotaes. Especificaes de componentes de interface so inspecionadas por pequenos grupos que incluem um representante do lado do produtor e do consumidor da interface, novamente, em sua maioria, por meio de revises manuais e troca de anotaes atravs de algum servio de discusso. Um grupo maior e um processo mais detalhado, incluindo uma reunio de inspeo com moderador e trs ou quatro participantes, utilizada para inspeo de uma especificao de requisitos. Os desenvolvedores da Chipmunk produzem testes unitrios de funcionalidade junto com cada tarefa de desenvolvimento, bem como orculos de teste e qualquer outro cdigo necessrio para a execuo do teste. Cdigo de teste consiste em cdigo adicional necessrio para executar uma unidade ou subsistema de forma isolada. Orculos de teste verificam os resultados executando o cdigo e sinalizam discrepncias entre os resultados obtidos e os esperados. Os casos de teste na Chipmunk so baseados principalmente nas especificaes das interfaces; tambm medido o quanto os testes unitrios exercitam a

Captulo 1 Teste e Anlise de Software em Resumo

31

estrutura de controle dos programas. Se menos de 90% de todos os comandos so executados pelos testes funcionais, isso tomado como uma indicao de que ou as especificaes de interface esto incompletas (se a cobertura que falta corresponde a diferenas visveis de comportamento) ou existe uma complexidade adicional de implementao oculta por trs da interface. Em qualquer caso, casos de teste adicionais so elaborados com base em uma descrio mais completa do comportamento da unidade. Testes de integrao e de sistema so gerados pela equipe de qualidade, trabalhando a partir de um catlogo de padres e seus testes correspondentes. O comportamento de alguns subsistemas ou componentes modelado por mquinas de estados finitos, de forma que o time de qualidade possa criar sutes de teste para exercitar caminhos de programa correspondendo a cada transio de estado nos modelos. Cdigo de teste e orculos para teste de integrao constituem parte da arquitetura geral do sistema. Orculos para componentes e unidades individuais so projetados e implementados por programadores usando ferramentas de anotao de cdigo com condies e invariantes. Os desenvolvedores da Chipmunk utilizam uma ferramenta de gerenciamento de testes feita na prpria companhia para vincular cdigo de teste ao cdigo da aplicao, agendar execues dos testes, acompanhar defeitos, organizar e atualizar sutes de teste de regresso. O plano de qualidade inclui atividades de teste e anlise para vrias propriedades alm da funcionalidade, incluindo desempenho, usabilidade e segurana. Embora estas sejam parte integrante do plano de qualidade, seu projeto e execuo, no todo ou em parte, so delegados a especialistas que podem estar locados em outra parte da organizao. Por exemplo, Chipmunk mantm um pequeno time de especialistas em fatores humanos em sua diviso de software. O time de fatores humanos produz diretrizes de aparncia (look-and-feel) para o sistema de compras pela Web, as quais, juntamente com o conjunto maior de regras de construo de interfaces da Chipmunk, podem ser verificadas durante a inspeo e o teste. O time de fatores humanos tambm produz e executa um plano de teste de usabilidade. Partes do portflio de atividades de verificao e validao selecionados pela Chipmunk esto ilustradas na Figura 1.1. A qualidade do produto final e os custos das atividades de garantia da qualidade dependem da escolha das tcnicas usadas para executar cada atividade. da maior importncia construir um plano coerente que possa ser monitorado. Alm de monitorar o progresso do plano, a Chipmunk registra as falhas encontradas em cada atividade, usando isso como um indicador de potenciais fontes de problemas. Por exemplo, se o nmero de falhas encontradas em um componente durante inspees de projeto alto, um tempo de teste adicional ser planejado para aquele componente.

1.5 Como avaliar se um produto est pronto?

Atividades de teste e anlise durante o desenvolvimento tm como objetivo principal revelar falhas a fim de que sejam removidas. Identificar e remover tantas falhas quanto possvel um objetivo til durante o desenvolvimento, mas encontrar todas as falhas quase impossvel e dificilmente ser um objeti-

32

Parte I Fundamentos de Teste e Anlise

Elicitao de Requisitos
Planejar e Monitorar

Especificao de Requisitos

Projeto da Arquitetura

Projeto Detalhado

Codificao

Integrao e Liberao

Manuteno

Identitifcar qualidades Plano de teste de aceitao Plano de teste de sistema Plano de teste unitrio & de integrao Monitorar o processo de teste e anlise Validar especificaes

Verificar Especificaes

Anlise do projeto da arquitetura Inspeo do projeto da arquitetura Inspeo do projeto detalhado Inspeo do cdigo Gerar teste de sistema

Gerar Casos de Teste

Gerar teste de integrao Gerar teste unitrio Gerar teste de regresso Atualizar teste de regresso Projeto do cdigo de teste Projeto de orculos

Executar Casos de Teste e Validar Software

Execuo do teste unitrio Anlise de cobertura Gerao do teste estrutural Execuo do teste estrutural Execuo do teste de integrao Execuo do teste de sistema Execuo do teste de regresso

Melhoria do Processo

Coleta de dados de falhas Anlise das falhas e melhoria do processo

Figura 1.1 Principais atividades de teste e anlise ao longo do ciclo de vida do software.

vo economicamente vivel para um produto de software no-trivial. O teste e a anlise no podem durar para sempre. Os produtos devem ser entregues quando atingem um nvel adequado de funcionalidade e qualidade. Precisamos de uma forma de especificar o nvel desejado de dependabilidade* e de determinar quando ele foi atingido.
* N. de T.: Dependability.

Captulo 1 Teste e Anlise de Software em Resumo

33

Diferentes mtricas de dependabilidade so apropriadas em diferentes contextos. A disponibilidade mede a qualidade do servio em termos de tempo em servio versus tempo fora de servio (downtime); o tempo mdio entre falhas (mean time between failures MTBF) mede a qualidade do servio em termos de tempo entre falhas, ou seja, a magnitude dos intervalos de tempo nos quais o servio est disponvel. A confiabilidade (reliability) as vezes utilizada como sinnimo de disponibilidade ou MTBF, mas em geral indica o percentual de operaes (execues do programa, interaes ou sesses) completadas com sucesso. Disponibilidade e confiabilidade so importantes para o site da Chipmunk. A meta de disponibilidade foi definida (um pouco arbitrariamente) como uma mdia de no mais de 30 minutos fora de servio por ms. Como 30 falhas de um minuto ao longo de um dia seriam muito piores que uma nica falha de 30 minutos, o MTBF especificado separadamente em pelo menos uma semana. Adicionalmente, uma confiabilidade de menos de uma falha a cada 1000 sesses de uso foi definida como objetivo, com o requisito adicional de que certas falhas crticas (por exemplo, perda de dados) devem ser extremamente raras. Tendo estabelecido esses objetivos, como a Chipmunk pode detectar quando eles forem atingidos? Monitorar sistematicamente a depurao pode dar uma pista, mas nada mais. Um produto com apenas um nico erro pode ter confiabilidade zero se esse erro resulta em uma falha a cada execuo, e no h motivo para supor que uma sute de teste projetada para encontrar erros representativa do uso e da taxa de falhas reais. A partir da experincia de vrios projetos anteriores, a Chipmunk determinou empiricamente que em sua organizao produtivo comear a medir a confiabilidade quando o teste revela menos de um erro (bug) por dia do tempo de teste. Para alguns domnios de aplicao, a Chipmunk coletou uma grande quantidade de dados histricos de uso para, a partir destes, definir perfis operacionais, e estes perfis podem ser usados para gerar grandes conjuntos estatisticamente vlidos de testes gerados randomicamente. Se a amostra gerada um modelo vlido das execues reais, ento estimar a confiabilidade eficiente a partir da taxa de falhas encontrada nos testes elementar. Infelizmente, em muitos casos este perfil no est disponvel. A Chipmunk tem uma idia de como a funcionalidade de vendas pela Web ser usada, mas no pode construir e validar um modelo com detalhe suficiente para obter estimativas de confiabilidade a partir de uma sute de teste gerada randomicamente. Eles decidem, portanto, usar a segunda abordagem principal para verificar confiabilidade, usando uma amostra de usurios reais. Isto conhecido como alfa teste se os testes so executados pelos usurios em um ambiente controlado, observados pela equipe de desenvolvimento. Se o teste consiste em usurios reais em seu prprio ambiente, executando tarefas reais sem interferncia ou monitorao prxima, conhecido como beta teste. A equipe da Chipmunk planeja um alfa teste bastante curto, seguido de um perodo de beta teste mais longo no qual o software disponibilizado apenas em lojas reais. A fim de acelerar a medio da confiabilidade aps revises subseqentes do sistema, a verso beta ser extensivamente instrumentada, capturando diversas propriedades do perfil de uso.

dependabilidade disponibilidade MTBF confiabilidade

alfa teste

beta teste

34

Parte I Fundamentos de Teste e Anlise

1.6 Como garantir a qualidade de verses sucessivas?

O teste e a anlise de software no param aps a primeira verso. Produtos de software em geral funcionam por muitos anos, freqentemente muito alm do seu ciclo de vida previsto, e sofrem diversas mudanas. Eles se adaptam a mudanas no ambiente por exemplo, introduo de novos drivers de dispositivos, evoluo do sistema operacional, e alteraes na plataforma de banco de dados. Eles tambm evoluem para atender novos requisitos de usurio e alteraes em requisitos. Tarefas de teste e anlise contnuas incluem o teste e anlise de cdigo novo e cdigo alterado, reexecuo de testes de sistema e atualizao extensiva dos registros. A Chipmunk mantm uma base de dados para rastrear problemas. Essa base de dados tem o duplo propsito de rastrear e priorizar falhas conhecidas de programas e sua resoluo, e de gerenciar a comunicao com usurios que reportam problemas. Mesmo na verso inicial, a base de dados normalmente inclui alguns defeitos conhecidos, porque a presso do mercado raramente permite corrigir todos os erros conhecidos antes de liberao do produto. Alm disso, defeitos (bugs) registrados na base de dados no so associados sempre e de forma nica com erros reais do programa. Alguns problemas relatados por usurios so mal-entendidos e solicitaes por novas funcionalidades, e muitos relatos distintos so duplicaes que eventualmente so consolidadas. A Chipmunk chama verses relativamente maiores, envolvendo vrios desenvolvedores, como verses de ponta (point releases) e revises menores como verses a nvel de patch. O processo da qualidade completo repetido em miniatura para cada verso pontual, incluindo desde a inspeo dos requisitos revisados at a elaborao e execuo de novos testes unitrios, de integrao de sistema e de aceitao. Em uma reviso de ponta possvel repetir at mesmo um perodo de beta teste. Revises a nvel de patch em geral so urgentes para alguns clientes. Por exemplo, uma reviso desse tipo normalmente necessria quando uma falha impede alguns clientes de usar o software ou quando uma nova vulnerabilidade de segurana descoberta. O teste e a anlise para verses a nvel de patch abreviada, e a automao particularmente importante para obter um nvel razovel de garantia em um ciclo muito rpido. A Chipmunk mantm um conjunto extenso de testes de regresso. O ambiente de desenvolvimento da Chipmunk suporta o registro, a classificao e a reexecuo automtica de casos de teste. Cada verso de ponta deve ser submetida a um teste de regresso completo antes da liberao, mas revises menores podem ser liberadas com um subconjunto de casos de teste que so executados durante a noite sem superviso. Ao remover um erro, muito fcil introduzir um novo erro ou reintroduzir erros que ocorreram anteriormente. Os desenvolvedores da Chipmunk acrescentam novos casos de teste de regresso medida que novos erros so descobertos e reparados.

verses de ponta verses a nvel de patch

testes de regresso

Captulo 1 Teste e Anlise de Software em Resumo

35

1.7 Como o processo de desenvolvimento pode ser melhorado?

Como parte de um programa geral de melhoria de processo, a Chipmunk implementou um programa de melhoria da qualidade. No passado, a equipe de qualidade encontrava os mesmos defeitos em um projeto aps o outro. O programa de melhoria da qualidade rastreia e classifica os erros a fim de identificar as falhas humanas que os causam e fraquezas no teste e na anlise que permitem que esses erros permaneam indetectados. Os membros do grupo de melhoria da qualidade da Chipmunk so escolhidos dentre desenvolvedores e especialistas em qualidade em diversas equipes de projeto. O grupo gera recomendaes que podem incluir modificaes nas prticas de desenvolvimento e teste, ferramentas e tecnologias de suporte, e prticas gerenciais. A ateno explcita ao estouro de buffers em aplicaes de rede resultado da anlise de falhas em projetos anteriores. A anlise de erros e a melhoria de processo compreendem quatro fases: definir os dados a serem coletados e implementar procedimentos de coleta; analisar os dados coletados para identificar classes importantes de erros; analisar as classes de erros selecionadas para identificar pontos fracos nas mtricas de desenvolvimento e de qualidade; e ajustar o processo de qualidade e de desenvolvimento. A coleta de dados particularmente crucial e, em geral, difcil. Tentativas anteriores efetuadas por equipes de qualidade da Chipmunk para impor prticas de coleta de dados de erros falharam tristemente. A equipe de qualidade no tinha atrativos nem estmulos* para motivar desenvolvedores pressionados pelo prazo. Um programa geral de melhoria de processo adotado pela diviso de software da Chipmunk forneceu uma oportunidade para melhor integrar a coleta de dados de erros com outras prticas, incluindo o procedimento normal para atribuir, acompanhar e revisar tarefas de desenvolvimento. A melhoria do processo da qualidade diferente do objetivo de melhorar um produto individual, mas a coleta inicial de dados integrada no mesmo sistema de acompanhamento de defeitos que, por sua vez, integrado ao sistema de gerenciamento de configurao e controle de verses utilizado pelos desenvolvedores da Chipmunk. O grupo de melhoria da qualidade define a informao necessria para que os dados sobre defeitos sejam teis assim como o formato e a organizao dos dados. A participao dos desenvolvedores na elaborao do processo de coleta de dados essencial para equilibrar o custo da coleta e anlise dos dados com sua utilidade, e para obter sua aceitao entre os desenvolvedores. Dados de vrios projetos ao longo do tempo so agregados e classificados para identificar classes de falhas que so importantes por ocorrerem com freqncia, por causar defeitos particularmente graves ou por terem alto custo de reparo. Essas falhas so analisadas a fim de compreender como so introduzidas e por que escapam deteco. As etapas de melhoria recomendadas pelo grupo
* N. de T.: Em ingls, carrots and sticks.

36

Parte I Fundamentos de Teste e Anlise

de melhoria da qualidade podem incluir etapas especficas de anlise ou teste, a fim de uma rpida deteco de erros, mas tambm podem incluir regras de projeto e modificaes no desenvolvimento, e at mesmo nas prticas gerenciais. Uma parte importante de cada prtica recomendada uma recomendao de acompanhamento a fim de mensurar o impacto da mudana.

Resumo
O processo da qualidade possui trs objetivos distintos: melhorar um produto de software (atravs da preveno, deteco e remoo de erros), avaliar a qualidade de um produto de software (em relao a metas explcitas de qualidade) e melhorar a qualidade e rentabilidade a longo prazo do processo da qualidade em si. Cada objetivo requer a integrao de atividades de garantia da qualidade e de melhoria no processo de desenvolvimento como um todo, desde a concepo do produto e ao longo de sua instalao, evoluo e remoo. Cada organizao deve elaborar, avaliar e refinar uma abordagem adequada organizao e ao seu domnio de aplicao. Uma abordagem adequadamente projetada invariavelmente combinar diversas tcnicas de teste e anlise, distribudas ao longo das fases do desenvolvimento. Um conjunto de tcnicas de deteco de falhas distribudo ao longo das fases de tal forma que as falhas sejam removidas o mais cedo possvel. O custo total e a relao custo-benefcio das tcnicas dependem fortemente do grau em que elas podem ser incrementalmente reaplicadas medida que o produto evolui.

Leitura complementar
Este livro trata principalmente do teste e anlise de software, a fim de incrementar e avaliar a dependabilidade do mesmo. No que outras qualidades alm da dependabilidade sejam menos importantes, mas porque elas exigem suas prprias tcnicas e abordagens especializadas. Oferecemos aqui alguns pontos de partida para considerar outras propriedades cruciais que interagem com a dependabilidade. A obra The Design of Everyday Things de Norman [Nor90] uma introduo clssica ao projeto visando usabilidade, com princpios bsicos que se aplicam a artefatos tanto de software quanto de hardware. Uma referncia bsica em usabilidade para software interativo, e particularmente para aplicaes Web, Designing Web Usability de Nielsen [Nie00]. O texto Computer Security: Art and Science de Bishop [Bis02] uma boa introduo aos aspectos de segurana. A introduo mais abrangente robustez do software o livro Safeware de Leveson [ Lev95].

Exerccios
1.1 Philip estudou mtodos de produo industrial just-in-time e est convencido de que deveriam ser aplicados a todo aspecto do desenvolvimento de software. Ele defende que o projeto de casos de teste deve ser

Captulo 1 Teste e Anlise de Software em Resumo

37

realizado imediatamente antes da primeira oportunidade de execut-los, nunca antes. Que conseqncias positivas e negativas voc v nesta abordagem de projeto just-in-time? 1.2 Um gerente de projeto recentemente contratado na Chipmunk questionou o motivo do gerente de qualidade estar envolvido na fase de estudo de viabilidade do projeto, em vez de juntar-se equipe apenas aps o projeto ter sido aprovado, como na companhia anterior do gerente. Que argumento(s) o gerente da qualidade pode oferecer a favor de seu envolvimento no estudo de viabilidade? 1.3 Os procedimentos da Chipmunk exigem reviso por pares no apenas de cada mdulo de cdigo, mas tambm dos casos de teste e do cdigo de teste para os mdulos. Anita argumenta que inspecionar sutes de teste um desperdcio de tempo; o tempo usado para inspecionar um caso de teste elaborado para detectar uma determinada classe de falhas pode ser melhor empregado na inspeo do cdigo fonte para detectar esta mesma classe. O gerente de projeto de Anita, por outro lado, defende que inspecionar os casos de teste, bem como o cdigo de teste, pode ter uma boa relao custo-benefcio quando considerado no ciclo de vida completo do produto de software. Que argumentos o gerente de Anita pode oferecer a favor de sua concluso? 1.4 O modelo em espiral de desenvolvimento de software prescreve uma sequncia incremental de fases de prototipao para reduo de riscos, comeando com os riscos mais importantes do projeto. O projeto da arquitetura visando testabilidade envolve, alm de definir especificaes de interfaces testveis para cada mdulo, a definio de uma ordem de gerao de verses que suporte um teste aprofundado aps cada etapa de construo. Como o desenvolvimento em espiral e o projeto visando testabilidade podem se complementar ou entrar em conflito? 1.5 Voc gerencia um servio online que vende arquivos de vdeo de filmes clssicos para download. Um download tpico dura uma hora, e um download interrompido deve ser reiniciado do comeo. O nmero de usurios baixando arquivos em um dado instante varia de 10 a aproximadamente 150 durante horrios de pico. Em mdia, o sistema sai do ar (cancelando todas as conexes) cerca de duas vezes por semana, por trs minutos cada vez em mdia. Se voc puder duplicar a disponibilidade ou duplicar o tempo mdio entre falhas, mas no ambos, qual voc escolheria? Por qu? 1.6 Na falta de um perfil operacional a priori para avaliao de confiabilidade, a Chipmunk depende de testes alfa e beta para avaliar se a funcionalidade de vendas online est pronta para liberao. O beta teste ser efetuado em lojas de varejo, com os funcionrios, e depois com clientes assistidos por funcionrios. Como esse beta teste ainda pode ser errneo no que diz respeito confiabilidade do software quando usado

38

Parte I Fundamentos de Teste e Anlise

em casa ou no trabalho por clientes reais? O que a Chipmunk pode fazer para remediar potenciais problemas devido a essa estimativa incorreta da confiabilidade? 1.7 Os projetistas de teste junior da Chipmunk incomodam-se com os procedimentos para salvar casos de teste juntamente com cdigo de teste, resultados dos testes e documentao associada. Eles culpam o esforo adicional necessrio para produzir e armazenar esses dados por atrasos no projeto e execuo dos testes. Eles defendem a reduo dos dados a serem salvos ao mnimo necessrio para reexecutar os casos de teste, eliminando detalhes da documentao de teste e limitando os resultados do teste informao necessria para gerao de orculos. Que argumento(s) pode(m) ser usado(s) pelo gerente da qualidade para convenc-los da utilidade de armazenar toda a informao?