PROCESSO DE TESTE DE SOFTWARE

INTRODUO Com o propsito de tentar buscar um processo de teste de software aplicvel a empresa Spdata foram elaborados alguns tpicos para apresentao de noes da rea de teste de software a partir do curso de testes de software lecionado na Assespro-MG.

MOTIVAO DOS TESTES PORQUE TESTAR O SOFTWARE Custo dos defeitos O custo de um defeito sobe 10 vezes para cada fase de desenvolvimento que detectado. Prazo de entrega O software deve estar apto a ser comercializado e distribudo no tempo que demandado. Percepo de defeitos pelo cliente Um software com muitos erros implica em desconfiana por parte do usurio, e o usurio fundamental no processo de melhor contnua do sistema ele deve se sentir confortvel com a sua utilizao.

MISSO DOS TESTES Definir misso inicial e misso futura. A equipe de testes precisa de uma viso para que mantenha foco e motivao no trabalho executado. Misso inicial: Obter cobertura de testes e mtricas de esforo. Misses futuras: Testes de regresso automatizados, gerncia de configurao.

MELHORES PRTICAS Para conseguir atender a misso especificada devem ser aplicadas as melhores prticas da rea que se no sendo 100% viveis devem servir ao menos como referncia para o sucesso da misso. Cada empresa deve montar seu prprio processo tendo como base os melhores princpios do mercado adotados em larga escala. Dentro de cada prtica podemos adotar suas terminologias e noes. Exemplos: SWEBOK, RUP, ISO/IEC SWEBOK - IEEE (Software Engineering Body of Knowledge) - Define papis para a rea de testes de software. Devem receber atribuies distintas e trabalhar como equipe. Ex.: Gerente de testes, Analista de testes, Testador.

- Artefatos so documentos, relatrios e cdigos que so produzidos, consumidos e manipulados durante todo o processo. Ex.: Plano de testes, Casos de teste, documento de requisitos, etc. - Uma atividade toda tarefa executada pelos papis para criar ou modificar um artefato. Ex.: Gerar casos de teste, planejar, verificar resultados. Fluxo SWEBOK Planejar testes (Gerente de testes) >> Gerar casos de teste (Analista de testes) >> Desenvolver ambiente de testes (Analista de testes + gerente de configurao) >> Executar testes ( Testador) >> Avaliar resultados dos testes (Analista de testes) >> Registrar problemas e Logs (Melhoria de projetos futuros) >> Rastrear defeitos (Testador) RUP - IBM (Rational Unified Process) Define um fluxo de trabalho e as tarefas correspondentes para cada papel. Usa as mesmas terminologias do SWEBOK para os papis servindo como complemento. ISO / IEC 829 Define a padronizao da documentao dos artefatos. Os documentos podem ser personalizados, porm aconselhvel manter a estrutura mnima dos documentos. Ex.: Plano de testes e casos de teste. ARTEFATOS DE TESTE Plano de teste Serve como guia para a conduo de um teste com um mesmo propsito. O plano a ser seguido o da ISO / IEC 829. Para projetos grandes pode-se gerar um plano mster e outros planos correlatos alterando apenas no plano o que pode mudar a cada ciclo de execuo dos testes. Papel responsvel: Gerente de testes Casos de teste Define a sequencia de passos e dados de entrada que devem ser executados e o comportamento resultante do sistema deve ser observado. Durante a elaborao dos casos de dados deve-se pensar na massa de dados aplicvel aos testes. Papel responsvel: Analista de testes Roteiros de teste Sequncia de casos de teste para uma execuo. Pode ser acompanhado de um documento de estratgia de testes onde definido o nmero de ciclos e execues, os tipos de casos de teste. Por isso a importncia do uso de palavras-chave (keywords) na criao dos casos.

Papel responsvel: Analista de testes Relatrio de execuo dos testes Mostra todos os resultados dos testes, os defeitos registrados e os problemas que foram detectados durante a execuo. Papel responsvel: Testador

ESTRATGIAS DE TESTE Serve para definir a forma de conduo dos testes, alm de especificar os tipos, tcnicas e estilos de teste que sero utilizados. Pode-se gerar um documento a parte do plano de testes ou um item integrante ao plano (caso no for especificar). Definir: PF (Pontos de Funo), DC (Defeitos crticos), DN (Defeitos normais), DT (Defeitos triviais). AUTOMAO DE TESTES - Viabilidade Equipe com tempo disponvel para atualizar e aprimorar os casos de teste automatizado assim que sistema for alterado. Controle do sistema de versionamento sobre alteraes e requisitos para rastreabilidade de requisitos. - Vantagens --Rapidez na execuo; --Execuo sistemtica; - Desvantagens --Dificuldade na manuteno --Efeito pesticida --Custo

MODELOS Modelos de desenvolvimento Modelo em V Verificao e Validao Ao passo que cada passo da verificao executada implementa-se um passo da validao de maneira incremental.

Cascata (apenas citou) Modelo em espiral Implementado de maneira incremental e interativo com o modelo V, com a diferena que este contm esforos da anlise e engenharia durante todas as fases do projeto e tambm est includa anlise de risco.

Modelos de maturidade (para certificao) CMMi (Capability Maturity Model Integration) Mais aceito pelas empresas de software; possui 05 nveis de maturidade:

Nvel 0 Incompleto Nvel 1 Executado Nvel 2 Gerenciado Nvel 3 Definido Nvel 4 Melhora contnua. TMMi (Test Maturity Model Integration)

Requer nvel de maturidade 02 do CMMi. Serve para as empresas com processo de desenvolvimento bem definido e quiserem aprimorar a rea de teste do software. MPS-BR (apenas citou)