Você está na página 1de 5

Portugus (Brasil)

Conecte-se (ou Registrar)

Itens Tcnicos

Downloads e Trials

Comunidade

Criao e Gerao de Planos de Teste de Software


Ana Paula Andrade, Technical Enablement, IBM Phil Viana , Staff Software Engineer, IBM Resumo: A disciplina de testes de software tem ganhado grande reconhecimento nos ltimos anos por parte da comunidade tcnica. Com o crescimento da complexidade dos projetos e, muitas vezes, o grande nmero de envolvidos no desenvolvimento de um software, torna-se importante uma formalizao da nomenclatura, processos e artefatos utilizados para garantir a qualidade de um software atravs dos testes. Neste artigo abordamos a disciplina de testes de software, apresentando conceitos importantes, ferramentas e algumas das tcnicas utilizadas, bem como um passo-a-passo para a criao de um plano de teste baseado no padro IEEE 829. Data: 03/Dez/2012 Nvel: Introdutrio Atividade: 1813 visualizaes Comentrios: 0 (Visualizar | Incluir comentrio - Conectar) Classificar este artigo 1. Introduo No ciclo de desenvolvimento de softwares, a realizao de testes tem espao desde a fase de design at o lanamento do produto. Eles conferem confiabilidade ao software, reorientam o desenvolvimento do design e do cdigo, e poupam gastos desnecessrios, quando detectam erros nas fases iniciais do desenvolvimento de um software. A necessidade e a importncia dos testes aumentam de acordo com o tipo de uso que o software ter os que podem causar danos vida humana ou levar a grandes perdas financeiras so crticos e devem ser disponibilizados para uso apenas aps um processo de testes criterioso. Alm disso, quanto mais precoce a deteco de falhas ocorre, menores os gastos do projeto com reparos e replanejamento. por esse motivo que a utilizao de ferramentas de suporte a testes tem se tornado uma regra no desenvolvimento de software. A suite de aplicaes Rational um exemplo bastante ilustrativo de quanto as grandes companhias esto interessadas em melhorar o processo de testes como um todo, j que inclui ferramentas para desenvolvimento de casos de teste como o Rational Functional Tester, ferramentas de desenvolvimento com suporte a teste (inclusive desenvolvimento dirigido por testes, ou test-driven development), como o Rational Software Architect, gerenciamento de ciclo de vida de testes e defeitos como o Rational Team Concert e o Rational Quality Manager, entre outros. Os testes tambm fazem parte dos procedimentos seguidos para garantir a qualidade do processo de desenvolvimento de softwares, atravs de certificaes concedidas por organizaes que avaliam o processo considerando modelos de qualidade, como o CMMI (Capability Maturity Model Integration) e a ISO-12207. Alm disso, nos ltimos anos vm surgindo instituies e consrcios que visam delimitar o teste de software como uma rea de conhecimento com vida prpria. O International Software Testing Qualifications Board (ISTQB) uma das instituies mais respeitadas da rea de teste de software, pois prope uma uniformizao dos conceitos e nomenclatura da disciplina. Grandes corporaes, inclusive a IBM, tm boa parte de seus profissionais certificados pelos exames da ISTQB e processos de desenvolvimento que utilizam o modelo ISTQB em seus artefatos e relatrios de testes de software. O ISTQB possui ramificaes no Brasil (BSTQB), Estados Unidos (ASTQB) e Inglaterra (ISEB). Portanto, para que os testes suportem todos esses aspectos do desenvolvimento de softwares, preciso que eles sejam projetados e realizados de acordo com o tipo de software e as necessidades que ele ir atender. Neste artigo vamos tratar especificamente da primeira etapa dos trabalhos de testes no ciclo de desenvolvimento de softwares: a criao de planos de teste. 2. ISTQB/ISEB Foundation Level O plano de teste O plano de testes o documento principal dos testes de software. Nele esto contidas informaes importantes sobre as partes envolvidas no teste, os objetivos do teste, as partes do software a serem testadas, os critrios de aceitao e os passos necessrios para executar os testes. Cada plano de testes possui descrio de um ou mais casos de teste. Um caso de teste compreende no mnimo um conjunto de aes a serem executadas e um critrio de aceitao, que diz se o teste foi bem sucedido ou no. Na maioria das vezes os casos de teste possuem tambm critrios de entrada ou requisitos, e vem acompanhados de uma breve descrio do item a ser testado e dos objetivos que ele busca atingir. medida que a disciplina de testes de software foi se profissionalizando nos ltimos anos, novas sees foram adicionadas aos planos de teste, como sumrio de alto nvel e lies aprendidas. Estas sees tem o intuito de situar o plano de testes e a equipe de testes com relao a outras equipes e ao planejamento do projeto como um todo. 2.2. O padro de plano de testes IEEE 829 O primeiro nvel do exame de certificao ISTQB/ISEB, o Foundation Level, aborda o desenvolvimento e a execuo de testes, alm de administrao e ferramentas para teste. O padro adotado por ambas as instituies para a criao dos planos de teste o IEEE 829, conhecido como 829 Standard for Software and System Test Documentation. Esse padro define a estrutura de vrios documentos relativos a testes de software. A escolha dos documentos que daro o suporte suficiente aos testes depende da complexidade deste, da equipe de testes disponvel e do tempo dedicado aos testes durante o desenvolvimento do software. O plano de teste que ser detalhado neste artigo contm as especificaes do design do teste, dos casos de teste e dos procedimentos de teste. 2.3. Design do teste O design do teste descreve as condies que os testes devem atender e o comportamento que se deve esperar do software a ser testado. Ele pode ser baseado nas requisies do sistema, nas necessidades de negcio ou no fluxo de processos para os quais o software foi projetado. Nesse documento so identificados os atributos a serem testados, as abordagens que sero utilizadas, os testes em si e os critrios de aprovao e reprovao de cada um deles.

O design de testes, portanto, a base para a criao dos demais documentos, pois define o escopo do plano de testes, o que ser abrangido e o quais os resultados esperados. Ele definido pelo padro IEEE 829 no Modelo de Especificao de Design de Teste. H trs tcnicas para design de testes: Caixa-preta (ou baseado em especificaes) Caixa-branca (ou baseado na estrutura do software) Baseado na experincia de uso de softwares semelhantes 2.3.1. Caixa-preta O design de testes que se baseia nas especificaes do software (caixa-preta) foca em sua funcionalidade, verifica se ele cumpre o que foi proposto. Geralmente so definidos dados de entrada e os esperados dados de sada. Ao final de cada ciclo de testes, os dados de sada so comparados com aqueles definidos no Plano de Testes e a aprovao depende da paridade entre eles. A tcnica da caixa-preta til para todos os nveis de teste, desde os de componentes at os de sistema e aceitao, pois fundamental que o software atenda suas especificaes. Um exemplo de ferramenta de suporte ao teste de caixa-preta o Rational Functional Tester (RFT). 2.3.2. Caixa-branca J o design baseado na estrutura (caixa-branca) investiga o funcionamento do software e analisa sua estrutura interna, por isso tambm chamado de caixa-branca ou de vidro. Os testes podem se restringir a componentes especficos ou abranger o software como um todo, mas a abordagem depende dos processos executados pelo software. Uma prtica comum escolher processos crticos do software e execut-los de vrias maneiras diferentes, com o objetivo de detectar falhas e medir sua performance em cenrios distintos. Esse tipo de tcnica tambm til em todos os nveis de teste, mas com uma abordagem diferente dependendo do nvel. Para testes de componentes e integrao, a estrutura do software o foco; em testes de sistema e aceitao, a estrutura relativa ao uso do software (como menus e componentes principais) se torna o alvo dos testes. A IBM possui, dentro da suite Rational, a ferramenta Rational Purify que um depurador em tempo de execuo, baseada na tcnica de anlise esttica de cdigo-fonte. Alm disso, algumas funcionalidades que viabilizam testes do tipo caixa-branca podem ser encontradas embutidas no Rational Software Architect e no Rational Application Developer. 2.3.3. Baseado na experincia e conhecimento Por fim, o design de testes baseado na experincia usa o conhecimento e a intuio do engenheiro de testes e usurios experientes para a determinao das condies de teste e a criao de casos de testes. Engenheiros de teste experientes na rea do software a ser desenvolvido tm mais facilidade em imaginar cenrios em que o produto possa apresentar vulnerabilidade. E o envolvimento de usurios enriquece o Plano de Testes, pois eles tm outra perspectiva do software e das necessidades que ele deve atender. Para testes de sistemas de baixo risco essa tcnica costuma ser a nica usada. Nos demais casos, ela complementar s demais, e muito til quando no h uma especificao de software bem definida. Neste caso possvel valer-se de ferramentas de gerenciamento de ciclo de vida e defeitos, como o Rational Team Concert e o Rational Quality Manager, que fornecem informaes valiosas sobre o histrico do desenvolvimento do software. Essas informaes podem ser utilizadas para a criao de casos de teste focados nas reas crticas onde houve maior volume de defeitos, por exemplo. possvel tambm fazer comparaes entre verses diferentes de um mesmo software sob a perspectiva do desempenho, utilizando o Rational Performance Tester. 2.4. Casos de teste Com o documento de especificao do design de teste pronto, parte-se para a criao dos casos de teste e dos procedimentos de teste. O Modelo de Especificao de Casos de Teste do IEEE 829 inclui a descrio do ambiente de testes, as pr e ps condies do teste, a descrio do teste e seus objetivos, os inputs e outputs esperados e as dependncias entre os testes. Ele um documento bem detalhado, que poder ser usado como referncia em todas as etapas do teste e pode sofrer atualizaes para melhor se adequar ao design de testes e ao comportamento que o software apresentar durante os testes. Por fim, a Especificao dos Procedimentos de Teste definida pelo Padro IEEE 829 como o documento que rene o propsito dos testes, seus requerimentos especficos e finalmente o passo a passo detalhado de realizao dos testes. um documento ainda mais tcnico que os demais, que descreve com detalhes e em sequncia os passos a serem seguidos em cada caso de teste, seja ele manual ou automatizado. Ele tambm chamado de script de testes e, juntamente com os demais documentos descritos nesse captulo, faz parte do modelo de Plano de Teste explorado no captulo seguinte. Passo a passo do design do Plano de Teste de software Informaes sobre o documento Sumrio do documento Nome do projeto Nome do componente Autores do documento Data Nmero de pginas Nome Nome Nomes DD/MM/AAAA

Sumrio de alteraes do Documento Verso Data 0.1 DD/MM/AAAA 0.2 DD/MM/AAAA 1.0 DD/MM/AAAA

Descrio <Primeiro esboo do documento criado> <Documento revisado e editado> <Aprovado>

Responsvel Nome Nome Nome

Aprovadores Nome Nome Nome Nome Cargo <Gerente de Qualidade> <Arquiteto de Software> <Gerente de Projetos>

Documentos de Referncia

Documento <Plano do projeto> <Especificao dos requerimentos> <Design de alto nvel>

Referncia Fonte Fonte Fonte

1 Introduo Na Introduo os objetivos gerais do Plano de Teste so apresentados de forma clara e no detalhada. 1.1 Sumrio de alto nvel O sumrio de alto nvel define o escopo dos testes descritos no Plano em relao ao projeto de desenvolvimento do software como um todo. Ele no contm aspectos tcnicos, pois uma descrio que deve ser entendida por todos os envolvidos no projeto, como executivos e gestores de projeto. Pode incluir restries de recursos relacionados aos testes, escopo do esforo de teste, relacionamento dos testes com outros mtodos de avaliao do software (anlises e revises) e os processos de controle, comunicao e coordenao das atividades-chave. 1.2 Terminologia Essa sesso til para identificar termos tcnicos, comerciais ou prprios da empresa que so utilizados ao longo do documento, como nomes de produtos que so refereciados e processos prprios da empresa. 2 Ambiente e Configurao dos Testes Nesta sesso so descritos o ambiente de testes e as configuraes necessrias para a execuo deles. 2.1 Plataformas Os testes devem ser executados em todas as plataformas suportadas pelo software, pois necessria uma documentao que sustente essa garantia de suporte dada pelo fabricante do software. Cada uma das platoformas a serem usadas nos testes deve ser descrita com detalhe, com foco nas caractersticas mais relavantes ao sotware a ser testado: tipo de mquina, capacidade de processamento, sistema operacional, quantidade de memria disponvel... 2.2 Configuraes Assim como as plataformas, as configuraes usadas em cada ambiente de testes devem ser descritas detalhadamente: softwares relacionados quele a ser testado, drivers necessrios ao seu uso, entre outras. 3 Anlise e Estratgia de Teste A anlise e a estratgia de teste so descritas minuciosamente nesta sesso, que abrange os objetivos, as dependncias, a preparao e finalmente os casos de teste. 3.1 Objetivos dos testes Os objetivos dos testes so pautados pelas caractersticas finais desejadas do software: segurana, integrao com outros processos ou softwares e gerao de determinados dados so alguns exemplos. 3.1.1 Obj 1 - <Definio do objetivo. Exemplo: Segurana> Condio do teste : <Condio que deve ser atendida para que o objetivo seja satisfeito. Exemplo: Somente usurios autorizados devem ter acesso s funcionalidades do software.> Abordagem: <De que forma esse objetivo pode ser avaliado? Exemplo: Devem ser usadas combinaes corretas e incorretas/invlidas de usurio e senha na tela de autenticao do usurio.> Critrio de aceitao: <Critrio que define se o obejtivo foi atendido. Exemplo: O processo de autenticao para uso do software deve negar acesso em caso de combinaes incorretas de usurio e senha e permitir o acesso quando a combinao fornecida for correta.> 3.2 Dependncias dos casos de teste Nessa sesso so descritos os requisitos que devem ser atendidos para a realizao dos testes. Pode ser necessria a preparao de dados de entrada para que o software os reconhea, por exemplo. 3.3 Preparao para os casos de teste Tudo o que deve ser preparado antes de se iniciar a execuo dos testes descrito nessa sesso, como por exemplo a preparao de ambiente, upgrade/downgrade das dependncias, ou qualquer outro passo que necessita estar previamente configurado antes do teste. 3.4 Casos de teste Os casos de teste definem com detalhe os procedimentos a serem seguidos durante a execuo dos testes. 3.4.1 CT 1 - <Nome> Descrio: <Em que consiste esse caso de teste? Exemplo: Verificar se um usurio no autorizado consegue acessar as funcionalidades do software.> Tempo estimado: <Qual a durao estimada desse teste? Exemplo: A verificao para autenticao deve ser feita em at 3 segundos.> Critrio de sada: <Quais aes ou dados de sada so esperados? Exemplo: O acesso deve ser negado e uma mensagem exibida ao usurio.> Requisitos do ambiente : <Quais os requisitos do ambiente para a realizao desse teste? Exemplo: O software a ser testado deve estar instalado no ambiente de testes.> Objetivos mapeados : <Quais objetivos so mapeados com esse teste? Exemplo: Obj 1 - Segurana> 4 Execuo dos Testes

4.1 Cobertura Essa sesso lista as funcionalidades do software que so cobertas pelos testes do Plano, alm de outros aspectos, como usabilidade, performance e segurana. Ela no deve ter um carter tcnico, e sim deve ser feita sob o ponto de vista do usurio, abordando o que interessar a ele e refletindo o que ser testado atravs dos casos de teste. 4.2 Resultados A importncia de se registrar os resultados dos testes muito grande: eles so a base para a criao de itens de trabalho para reparo e replanejamento durante o desenvolvimento. E, ao final do desenvolvimento, a compilao dos resultados dos testes bem-sucedidos so um indicativo relevante da confiabilidade daquele software. 5 Lies aprendidas O registro das lies aprendidas durante os testes realizados um material de consulta muito til para a criao de novos Planos de Teste, especialmente para pessoas que no participaram dos testes definidos nesse Plano, e para testadores com menos experincia na rea. Essa uma sesso que resume o que pode ser feito de forma melhor em novos testes, especialmente em Planos de Teste de Software semelhantes ao testado. Bibliografia Foundations of Software Testing: ISTQB Certification Chapter 4: Test Design Techniques, Dorothy Graham et al. Test Plan Outline (IEEE 829 Format) Foundation Course in Software Testing - Prepared by Systeme Evolutif Limited, accessed in August, 2012 at http://www.computing.dcu.ie/~davids/courses/CA267/ieee829mtp.pdf Boris Beizer - Black-Box Testing - Techniques for functional testing of software and systems . William E. Perry - Effective Methods for Software Testing

Sobre os autores Ana Paula comeou um curso focado em bancos de dados em 2011 e se juntou IBM como estagiria, para trabalhar com a equipe de consultores do DB2 Migration. A partir de 2012, Ana comeou a trabalhar com a equipe de desenvolvedores, realizando testes das ferramentas de migrao (Database Conversion Workbench DCW), e pouco depois foi contratada como parte da equipe de testes do DCW. Atualmente ela est se juntando ao time de InfoSphere Optim e Guardium, como habilitadora de parceiros de negcio da IBM. Perfil My developerWorks. Phil ingressou na IBM em 2009 na rea de qualidade de software para sistemas de gesto de informao. Trabalhou no desenvolvimento do InfoSphere Balanced Warehouse, DB2 10 para Windows, Linux e Unix, Optim Query Capture amp; Replay, e atualmente trabalha no time de testes sistmicos do IBM PureData System for Operational Analytics, com foco em storage. Atualmente faz mestrado em arquiteturas distribudas na Escola Politcnica da Universidade de So Paulo, onde possui tambm diploma de Engenheiro de Computao. Perfil My developerWorks. Fechar [x]

developerWorks: Registre-se
IBM ID: Precisa de um ID IBM? Esqueceu seu ID IBM? Senha: Esqueceu sua senha? Alterar sua senha Mantenha-me conectado. Ao clicar em Enviar, voc concorda com os termos de uso do developerWorks.
Enviar Cancelar

Na primeira vez que voc efetua sign in no developerWorks, um perfil criado para voc. Informaes selecionadas do seu perfil developerWorks so exibidas ao pblico, mas voc pode edit-las a qualquer momento. Seu primeiro nome, sobrenome (a menos que escolha ocult-los), e seu nome de exibio acompanharo o contedo que postar. Todas as informaes enviadas so seguras. Fechar [x]

Selecione seu nome de exibio


Ao se conectar ao developerWorks pela primeira vez, criado um perfil para voc e necessrio selecionar um nome de exibio. O nome de exibio acompanhar o contedo que voc postar no developerWorks. Escolha um nome de exibio de 3 - 31 caracteres. Seu nome de exibio deve ser exclusivo na comunidade do developerWorks e no deve ser o seu endereo de email por motivo de privacidade. Nome de exibio: (Deve possuir de 3 a 31 caracteres.)

Ao clicar em Enviar, voc concorda com os termos de uso do developerWorks.


Enviar Cancelar

Todas as informaes enviadas so seguras. 1 estrela 1 estrela 2 estrelas 2 estrelas 3 estrelas 3 estrelas 4 estrelas 4 estrelas 5 estrelas 5 estrelas
Enviar

Incluir comentrio: Conectar or registre-se para deixar um comentrio. Observao: elementos HTML no so suportados nos comentrios.

Notificar-me quando um comentrio for adicionado1000 caracteres restantes

Postar

H um problema na recuperao dos comentrios. Atualize a pgina mais tarde.


Imprimir esta pgina Compartilhe esta pgina Siga o developerWorks

Sobre Ajuda Entre em contato conosco

Feeds

Relatar abuso Termos de uso Privacidade

Acessibilidade (Ingls) IBM Academic Initiative IBM PartnerWorld Industry Network