ESCOLA SUPERIOR ABERTA DO BRASIL ESAB PÓS-GRADUAÇÃO EM ENGENHARIA DE SISTEMAS PERON REZENDE DE SOUSA AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB

Transcrição

1 ESCOLA SUPERIOR ABERTA DO BRASIL ESAB PÓS-GRADUAÇÃO EM ENGENHARIA DE SISTEMAS PERON REZENDE DE SOUSA AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB VILA VELHA ES 2008

2 PERON REZENDE DE SOUSA AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB Monografia apresentada à ESAB Escola Superior Aberta do Brasil, sob orientação do Dr. Jaime Roy Doxsey e da Me. Beatriz Christo Gobbi. VILA VELHA ES 2008

3 PERON REZENDE DE SOUSA AUTOMAÇÃO DE TESTES EM SOFTWARES E SITES WEB Aprovada em... de... de 2008 VILA VELHA ES 2008

4 Dedico este trabalho à DEUS por me proteger em todos os meus caminhos; À minha adorável esposa por sua paciência, compreensão e amor; À minha mãe por me orientar e motivar desde a infância; E à minha tia por ter possibilitado, há 16 anos atrás, o inicio dos meus estudos na área da informática.

5 AGRADECIMENTOS À minha esposa, pela revisão ortográfica e gramatical deste trabalho. Aos meus orientadores, Dr. Jaime Roy Doxsey e Me. Beatriz Christo Gobbi; aos colaboradores Bruno Otero, Alvaro Mendes, Cláudio Carvalho e Mario Calleri, da REDEA/RJ, e a Helio Leão, da RSI Informática.

6 Somos o que repetidamente fazemos. A excelência, portanto, não é um feito, mas um hábito. (Aristóteles)

7 RESUMO Este trabalho faz uma breve apresentação da disciplina de testes, citando os tipos, comentando o processo e o vinculo de testes com a qualidade, passando por questões relacionadas ao ambiente, controle de versionamento e diversas questões envolvendo o equilíbrio entre custos, prazos e qualidade, chegando a um roteiro para aquisição de ferramentas destinadas a automação, que evita equívocos gerados pela grande variedade de contratos de venda. Também apresenta os tipos e técnicas de automatização e uma grande variedade de ferramentas comerciais, livres e orientação sobre a construção de uma ferramenta própria. Evidencia a importância das ferramentas para geração automática de casos, massa e para os testes de stress. Conclui que, para obter a máxima eficiência no processo é necessário combinar as técnicas de automação; em alguns casos pode ser preferível o teste manual; e que os custos do processo automatizado podem estar concentrados em fatores diversos, como a montagem e manutenção de um ambiente, e não nas ferramentas.

8 LISTA DE FIGURAS Figura 1 Gestão de ambientes...23 Figura 2 Ambientes...23 Figura 3 Baseline...26 Figura 4 Possíveis níveis de maturidade previstos no modelo CMM...31 Figura 5 Exemplo de script...34 Figura 6 Aplicação da técnica keyword-driven...60 Figura 7 Estratégia de testes caixa-branca e caixa-preta...78 Figura 8 Visão do modelo de processo de qualidade de software em U...81 Figura 9 Funcionamento de uma ferramenta de testes...83

9 LISTA DE GRÁFICOS Gráfico 1 Custo hipotético (em horas) para diferentes processos de teste...36 Gráfico 2 Teste manual x teste automatizado do módulo de Promoções...37 Gráfico 3 Teste manual x teste automatizado do módulo de Atend. a Clientes..38 Gráfico 4 Esforço dedicado à correção de defeitos...41 Gráfico 5 Esforço gerencial para alcançar níveis maiores de maturidade...42 Gráfico 6 Regra de 10 de Myers...43 Gráfico 7 Custo de correção de defeitos...44 Gráfico 8 Risco de teste numa aplicação de TI tradicional...46 Gráfico 9 Risco de teste numa aplicação web...47 Gráfico 10 Tempo de resposta x nº de usuários (como descobrir gargalos)...61

10 LISTA DE TABELAS Tabela 1 Métricas coletadas para o módulo de Promoções...36 Tabela 2 Linha ilustrativa de Ganho...37 Tabela 3 Métricas coletadas para o módulo de Atendimento a Clientes...38 Tabela 4 Comparativo entre testes manuais e automatizados...45 Tabela 5 Distribuição do esforço em testes...48 Tabela 6 Distribuição do esforço em legados (implantação)...48 Tabela 7 Custos das atividades de uma revisão...50 Tabela 8 Teste por palavras-chave...59 Tabela 9 Custo/esforço em projetos novos...84 Tabela 10 Custo/esforço na manutenção de sistemas...85 Tabela 11 Custo/esforço na montagem em ambiente de homologação...86 Tabela 12 Exemplo de requerimento num quadro comparativo...87 Tabela 13 Cadastro de clientes...89 Tabela 14 Transferência...89 Tabela 15 Verificação de saldo...89

11 LISTA DE QUADROS Quadro 1 Histórico dos testes de software...16 Quadro 2 Evolução dos conceitos de qualidade...16 Quadro 3 Evolução do processo de qualidade e de testes de software...17 Quadro 4 Exemplo de priorização das categorias de testes...20 Quadro 5 Características para um software de qualidade...21 Quadro 6 Normas de qualidade em desenvolvimento de software...30 Quadro 7 Automação x teste manual...35 Quadro 8 Alternativas na execução dos testes...46 Quadro 9 Alternativas na conferência dos testes...51 Quadro 10 Tipos de automação...53 Quadro 11 Ferramentas de teste/depuração para programas concorrentes...71 Quadro 12 O que automatizar?...82 Quadro 13 Visão Comercial...88 Quadro 14 Visão Acadêmica...88 Quadro 15 Novas Tendências...88 Quadro 16 Ferramentas da Borland para a automação de testes de software...90 Quadro 17 Ferramentas da IBM para a automação de testes de software...90 Quadro 18 Ferramentas comerciais...91 Quadro 19 Características apresentadas pelas ferramentas de teste OO...92 Quadro 20 Melhores ferramentas Open Source para gestão e automação...93

12 LISTA DE SIGLAS ANSI BSTQB CAST CLI CMM CMMi DLL DoD EPD FSW FTS GE GUI HP IEEE ISO MDS MFC MPI OLE POO OSI PF PQS PSM PVM QA QAI RAD American National Standards Institute Brazilian Software Testing Qualifications Board Computer-Aided Software Testing Command Line Interface Capability Maturity Model Modelo integrado que poderá substituir o CMM no futuro Dynamic Link Library Departamento de Defesa Norte-Americano Evolução do Processo de Desenvolvimento Fábrica de Software Fábrica de Testes Grava/Executa Graphical User Interface Hewlett-Packard Institute of Electrical and Electronics Engineers International Standards Organization Metodologia de Desenvolvimento de Sistemas Microsoft Foundation Class Library Message Passing Interface Object Linking and Embedding Programação Orientada a Objetos Open Source Initiative Pontos de função Processo de Qualidade de Software Pratical Software Measurement Parallel Virtual Machine Quality Assurance Quality Assurance International Rapid Application Development

13 REDEA/RJ Representação de desenvolvimento de aplicativos do Rio de Janeiro ROI Returno of Investiment SBQS Simpósio Brasileiro de Qualidade de Software SDLC Software Development Life Cycle SEI Software Engineering Institute SLA Service Level Agreement SPICE Software Process Improvement and Capability determination SWEBOK Software Engineering Body of Knowledge TSL Test Script Language UAT User Acceptance Test UML Unified Modeling Language XML extensible Markup Language XP extreme Programming

14 SUMÁRIO INTRUDUÇÃO...14 CAPÍTULO I CONCEITOS BÁSICOS DE TESTES HISTÓRICO ESTRATÉGIAS PROGRESSIVIDADE E REGRESSIVIDADE CATEGORIAS TIPOS AMBIENTES MASSA VERSIONAMENTO...25 CAPÍTULO II O PROCESSO DE TESTES PADRÕES DE QUALIDADE...29 CAPÍTULO III AUTOMAÇÃO DE TESTES CUSTOS E PRAZOS Adquirindo uma ferramenta TIPOS DE AUTOMAÇÃO Capture/Playback (Captura e executa) Scripts estruturados Data-Driven (Técnica orientada a dados) Keyword-Driven (Técnica orientada a palavras-chave) Teste de estresse FERRAMENTAS Suites Software Sites web...65

15 3.3.4 Estrutural Mutação Orientados a objetos e de componentes Orientados a aspectos Concorrentes Open Source Faça você mesmo...72 CONSIDERAÇÕES FINAIS...73 REFERÊNCIAS BIBLIOGRÁFICAS...74 GLOSSÁRIO...76 ANEXOS...78

16 14 INTRODUÇÃO Palavras-chave: automação, testes, software. Em 2008, o mercado tem consolidado o ideal de qualidade seja por força da competitividade ou até pela necessidade de redução de custos. Porém, o desenvolvimento e a manutenção de aplicações corretas, confiáveis e seguras têm enfrentado a escassez de profissionais qualificados em testes, de publicações na área e a falta de divulgação das ferramentas de automação. A maioria das suites de linguagens de programação não traz em seus pacotes ferramentas para automatizar os testes e o fornecedor, talvez por falha no treinamento da equipe de vendas, não costuma divulgar a existência delas aos compradores da suite e não patrocinam a divulgação junto aos autores que escrevem sobre suas linguagens. O resultado desse quadro é uma grande quantidade de informações dispersas em vários lugares, obrigando o desenvolvedor a um verdadeiro garimpo para achar as ferramentas que possam atender as suas necessidades e não ter que reinventar a roda. Isso quando o desenvolvedor já ouviu falar sobre o assunto, pois muitos nem tem conhecimento sobre a existência das ferramentas para automatizar testes. Por essas razões escolhemos este tema. Desejamos examinar as técnicas atuais de automação de testes em software e sites web, além de fazer um levantamento das aplicações disponíveis no mercado. Queremos conhecer as dificuldades encontradas no processo e as vantagens da automação de testes quanto a redução de custos, prazos e aumento de qualidade do produto final. Apresentaremos um breve resumo sobre a disciplina de testes, sobre todas as implicações financeiras envolvidas no processo, as principais técnicas e uma rápida referência sobre o que é oferecido pelo mercado. Este trabalho foi elaborado com base nas metodologias de pesquisa exploratória e bibliográfica.

17 15 CAPÍTULO I CONCEITOS BÁSICOS DE TESTES Abordaremos neste capitulo a disciplina de testes e sua evolução, mas sem maiores detalhes, antes de entrarmos no tema central deste trabalho. Também apresentaremos algumas boas práticas que são válidas tanto para a execução manual dos testes quanto na automação e veremos o que considerar durante o processo, para a garantia da qualidade no desenvolvimento de software e sites web. 1.1 HISTÓRICO Podemos definir os testes como uma atividade, que tem como objetivo verificar se o software construído está de acordo com sua especificação e se satisfaz as expectativas do cliente e/ou utilizador do sistema. Testes é parte integrante do processo de Validação e Verificação (V & V) da Engenharia de Software (Anexo D), sendo considerada a técnica dinâmica que exercita a implementação, Sommerville (apud CORREIA, 2004, p.1). Para complementar a definição acima, vejamos o que um dos guias de boas praticas, na área de engenharia de software, o SWEBOK ( define como teste: Teste de software consiste na verificação dinâmica do comportamento de um programa, através de um conjunto finito de casos de teste, adequadamente selecionado a partir de um conjunto infinito de possibilidades, contra um comportamento esperado especificado. SWEBOK (apud ARGOLLO, 2008). Esse guia traz diversas orientações sobre a organização de todo o processo de desenvolvimento, inclusive sobre testes e qualidade. É interessante ressaltar que às vezes os termos teste e qualidade se confundem e nesse guia podemos identificar facilmente que existe diferença entre qualidade de software e teste de software.

18 16 Tanto a qualidade quanto os testes devem estar presente em todo o processo de construção da aplicação, mas a qualidade se estende por todas as outras disciplinas, sendo seu escopo mais abrangente em diversos aspectos se comparado ao de testes. O estudo da qualidade se aperfeiçoava por meio dos processos industriais (qua.2) antes mesmo de se imaginar o conceito de software. O estudo dos testes de software tem pouco mais de 50 anos, mas só começou a ganhar uma maior atenção do mercado nos últimos 10 anos. Veja o quadro a seguir: Quadro 1 Histórico dos testes de software 1957 O teste de software torna-se um processo 1970 Com a engenharia de software aumenta a importância da disciplina de testes 1972 Ocorre a primeira conferência sobre testes na Universidade da Carolina do Norte 1979 Myers produz um dos primeiros trabalhos sobre o processo de testes 1980 Primeiros conceitos de qualidade de software, criação dos padrões: IEEE (Institute of Electrical and Electronics Engineers) ANSI (American National Standards Institute) ISO (International Standards Organization) 1990 Começam a ser desenvolvidas as ferramentas de teste Fonte: Bartié (2002, p.3-4) O interesse pela qualidade só começou a se intensificar devido ao crescimento exponencial dos programas em linhas de código e também pelos níveis de complexidade que estavam sendo alcançados a cada dia. Quadro 2 Evolução dos conceitos de qualidade 1900 Inspeção pós-produção Avalia o produto final, depois de pronto 1940 Controle estatístico da produção Avalia os subprodutos das etapas de produção 1950 Procedimento de produção Avalia todo o procedimento de produção 1960 Educação das pessoas Avalia as pessoas envolvidas no processo 1970 Otimização dos processos Avalia e otimiza cada processo 1980 Projeto robusto Avalia o projeto de produção 1990 Engenharia simultânea Avalia a própria concepção do produto Fonte: Oshiro (2007, p ) A principio, técnicas foram utilizadas para separar os códigos em módulos menores, mas em pouco tempo os analistas estavam se vendo envolvidos com centenas, algumas vezes até milhares, de módulos que dificultavam a visão do todo (qua.3). Com o tempo ficou difícil prever se uma simples alteração na funcionalidade de um dos módulos, causaria problemas em cascata em outras.

19 17 Quadro 3 - Evolução do processo de qualidade e de testes de software Características Tamanho do software Pequeno Médio Muito grande Complexidade do software Baixa Média Alta Tamanho da equipe de desenvolvimento Pequeno Médio Grande Padrões e metodologias de desenvolvimento Interno Moderado Sofisticado Padrões e metodologias de qualidade e testes Interno Moderado Sofisticado Organizações de qualidade e testes Bem poucas Algumas Muitas Reconhecimento da importância da qualidade Pequeno Algum Significante Tamanho da equipe de qualidade e testes Pequeno Pequeno Grande Fonte: Bartié (2002, p.5) Depois se seguiram às incompatibilidades decorrentes de sistemas operacionais, versões de DLL, erros no uso do polimorfismo, hardware, etc. Atualmente muitas empresas ainda não amadureceram a idéia de que é necessário investir na disciplina de testes, apesar de todas essas questões. Algumas só investem nos testes manuais, alegando que testes automatizados é um luxo desnecessário, pois conhecem casos em que a automação não representou ganho para o processo de desenvolvimento. Certamente o problema se encontra mais na definição dos processos do que na automação em si. [...] as empresas acabam atuando na automação de teste sem a definição de objetivos e expectativas claros e reais e sem a aplicação de técnicas apropriadas. Por conseqüência, têm-se constatado um grande número de insucessos nos esforços para a automação de teste [...] (FANTINATO, 2004, p.2) Independente da forma como os testes devem ser feitos, insistir em considerá-los uma atividade que não agrega valor e que é cara, só ira comprometer a sobrevivência da empresa em um mercado que se apresenta cada vez mais competitivo. Quanto ao dilema de automatizar ou não, voltaremos a esse assunto mais a frente.

20 ESTRATÉGIAS A estratégia de testes caixa-branca (testes estruturais) verifica o software internamente, seu código fonte, estrutura de banco de dados, seqüência lógica de execução de tarefas, etc. Trata-se, portanto de um procedimento complexo que exige do testador um bom conhecimento sobre as tecnologias usadas no desenvolvimento do sistema, Bartié (2002, p ). Na estratégia de caixa-preta (testes funcionais) trabalha somente com os dados de entradas e os resultados produzidos pelo sistema (Anexo A), sem se preocupar em como o programa chegou àqueles resultados. Nesse caso o testador não precisa saber como o sistema foi construído. Essa estratégia é utilizada pelos testes baseados em requisitos e é responsável pela maioria das ferramentas de automação disponíveis no mercado. Antes de se falar em automação podemos concluir que os testes caixa-branca são realizados pelo desenvolvedor e que os testes caixa-preta podem ser realizados por qualquer pessoa, pois trata se apenas do uso da aplicação. Atualmente, a automação que trabalha com o conceito de caixa-preta pode exigir que o testador tenha conhecimentos em programação. O testador comum deve continuar existindo, só que fora do ambiente de desenvolvimento. As maiorias das MDS enxergam esse testador na fase de homologação, na figura do cliente e/ou do usuário final. 1.3 PROGRESSIVIDADE E REGRESSIVIDADE Progressividade consiste em avaliar um sistema novo ou apenas a parte nova de um sistema antigo. Todos os programas novos passam por testes de progressão, somente quando algo é modificado que podemos realizar um teste de progressão ou de regressão.

21 19 O teste de regressão consiste em avaliar todo o sistema após uma modificação de código e/ou configuração de ambiente, podendo ser uma nova versão ou release, pois aplicar somente o teste de progressão pode ocultar problemas gerados em outras partes do sistema em decorrência da ultima alteração. A automação de testes mostra-se com maior eficiência quando utilizada nos testes de regressão. Principalmente, quando pouco esforço é necessário na adaptação dos scripts antigos, para rodar novamente todos os casos de testes antigos e novos. Com testes manuais o tempo para realizá-los seria muito maior e ainda estaríamos expostos às falhas de um processo moroso e cansativo, Bartié (2002, p ). Em resumo, seu principal objetivo é verificar que o sistema continua a realizar as mesmas funções e da mesma maneira que na versão anterior, Pfleeger (apud CORREIA, 2004, p.2). 1.4 CATEGORIAS A separação dos testes em categorias, descrita por Bartié (2002, p ), não se trata apenas de uma conceituação acadêmica. Essa separação realmente ajuda na elaboração de casos mais abrangentes. Evitando com isso que, no momento do levantamento sobre o que testar, alguns itens acabem esquecidos. A importância de cada categoria (qua.4) varia de um projeto para o outro. Por exemplo, não temos uma preocupação acentuada no quesito Carga e Concorrência para um projeto de editor de texto, onde somente um usuário usa o editor por vez. Até podemos nos preocupar com Volume relacionando-o ao trabalho com textos extensos. Apesar das possíveis divergências, a importância definida por Bartié adequa-se perfeitamente a grande maioria dos sistemas.

22 20 Quadro 4 Exemplo de priorização das categorias de testes Tipo Importância Descrição da categoria Funcional Essencial Visa garantir que não haverá diferença entre os requisitos funcionais e o software desenvolvido. Performance Médio impacto Checa o desempenho do programa, ou seja, verifica se ele mantém um tempo de resposta aceitável mesmo em condições extremas. Monitora o programa por um tempo para identificar Confiabilidade e Alto impacto interrupções (confiabilidade) e mensurar o tempo para Disponibilidade solucionar o problema (disponibilidade). Simula invasões com o intuito de obter informações Segurança Essencial sigilosas ao que possam prejudicar o funcionamento do Carga e Concorrência Usabilidade Compatibilidade Configuração Contingência Instalação Volume Recuperação Alto impacto Médio impacto Essencial Fonte: Bartié (2002, p.120) Baixo impacto Alto impacto Médio impacto Alto impacto Alto impacto sistema. Também conhecido como teste de stress ele funciona simulando situações atípicas no sistema, como aumento no tráfego da rede, transações sucessivas e simultâneas, entre outras. Verifica a navegação nas telas, clareza das mensagens, facilidade para obter ajuda, entre outros itens relacionados à interação com o usuário. Testa o comportamento em função de alterações no versionamento de componentes de hardware e software. Também conhecido como teste de portabilidade, testa o comportamento do programa em ambientes diferentes, tanto de hardware quanto de software. Analisa os procedimentos que a equipe deve adotar em caso de falhas. Analisa o comportamento do sistema, durante o processo de instalação, nas mais diversas possibilidades, por exemplo: nova instalação, reinstalação, variação de alternativas para instalação. É semelhante ao teste de carga, porém esse não trabalha com oscilações e sim com o crescimento contínuo da base até o limite suportado e com isso verificar o funcionamento do programa nessas condições. Alguns autores chamam esse teste de teste de distribuição. Avalia a capacidade do sistema em poder voltar a operar normalmente após a ocorrência de um erro. Verificando o conteúdo da NBR (qua.5), que é a versão brasileira da ISSO/IEC 9126, vimos que esse padrão de qualidade relaciona itens a serem observados no desenvolvimento de aplicações, para a obtenção de um produto de qualidade, que são muito semelhantes às categorias descritas por Bartié. Entre as diferenças vale observar o item Testabilidade, da característica Manutenibilidade, pois aumenta nossa visão do produto final para além da percepção do usuário.

23 21 Quadro 5 - Características para um software de qualidade Característica Sub-característica Pergunta chave para a sub-característica Adequação Propõe-se a fazer o que é apropriado? Funcionalidade Acurácia Faz o que foi proposto de forma correta? (satisfaz as Interoperabilidade Interage com os sistemas especificados? necessidades?) Conformidade Está de acordo com as normas, leis, etc.? Segurança de acesso Evita acesso não autorizado aos dados? Maturidade Com que freqüência apresenta falhas? Confiabilidade Tolerância à falhas Ocorrendo falhas, como ele reage? (é imune a falhas?) Recuperabilidade É capaz de recuperar dados em caso de falha? Inteligibilidade É fácil entender o conceito e a aplicação? Usabilidade Apreensibilidade É fácil aprender a usar? (é fácil de usar?) Operacionalidade É fácil de operar e controlar? Eficiência Qual é o tempo de resposta, a velocidade de Tempo (é rápido e execução? "enxuto"?) Recursos Quanto recurso usa? Durante quanto tempo? Analisabilidade É fácil de encontrar uma falha, quando ocorre? Manutenibilidade Modificabilidade É fácil modificar e adaptar? (é fácil de modificar?) Estabilidade Há grande risco quando se faz alterações? Testabilidade É fácil testar quando se faz alterações? Adaptabilidade É fácil adaptar a outros ambientes? Portabilidade Capac. para ser (é fácil de usar em instalado É fácil instalar em outros ambientes? outro ambiente?) Conformidade Está de acordo com padrões de portabilidade? Capac. para substituir É fácil usar para substituir outro? Fonte: NBR (apud OSHIRO, 2007, p ) 1.5 TIPOS Existe uma infinidade de tipos de testes, cada um com suas respectivas técnicas. Alguns se misturam, outros são apenas sinônimos. Cada autor costuma ter sua lista particular dos mais importantes, mas os principais conjuntos de teste são os de unidade, integração, sistema e validação. Não é o objetivo desse trabalho discorrer sobre todos os tipos possíveis de testes. Apenas apresentaremos alguns conceitos, durante a apresentação de alguns temas, conforme sua relevância para o contexto desse estudo. Como podemos ver nos Anexos B e C, a muito para considerar quando da elaboração de um plano de testes.

24 22 Com a crescente complexidade da disciplina de testes o mercado já começa a exigir especialistas para essa tarefa. Os cursos que se propõe a capacitação profissional e as certificações começam a se proliferar. Algumas pesquisas argumentam que esta será uma das áreas com maior demanda de emprego num futuro próximo e, conseqüentemente, maior valorização salarial. A Computer World dedicou um post para falar das 6 áreas de TI que são a prova de recessão, com base em uma pesquisa, da JobFox, realizada em julho deste ano. O documento faz uma ressalva na área de testes: Especially good for those with automated testing expertise, ou seja, especialmente bom para aqueles com conhecimento em automação de testes, Eudescosta (2008). 1.6 AMBIENTES O ambiente de testes pode ser do tipo ativo ou por demanda. Quando construímos um ambiente e o mantemos, mesmo depois do término do projeto que o originou (sempre disponível para simular a produção, através de rotinas eventuais, diárias, quinzenais, mensais, anuais), estamos utilizando o tipo ativo. Esse tipo também é o melhor para testes de interfaces por parte do homologador 1, pois não o colocamos em contato com o ambiente de desenvolvimento (fig.1) e não corremos o risco de comprometer o ambiente de produção. Outra vantagem é que ele promove a integração entre plataformas sem que se tenha o trabalho de reinstalar todos os sistemas envolvidos e reproduzir as massas de testes de cada um a cada novo projeto ou evolução de aplicação. Esse ambiente também nos possibilita aperfeiçoar um controle rígido de acessos. Uma vez preparado, o ambiente ativo proporciona uma redução nos custos a médio e longo prazo, além de possibilitar uma melhora na performance do processo. O ambiente por demanda é construído de acordo com os pedidos e conforme a necessidade. Em termos de hardware, a disponibilidade dos equipamentos pode 1 Cliente e/ou usuário final.

25 23 tornar esse custo tão alto quanto o do ambiente ativo, mas é comum apenas a requisição de espaço em disco em máquinas já existente, tanto do ambiente de desenvolvimento quanto do ambiente de produção, para a realização dos testes. Em alguns casos não chega nem a ser um ambiente, apenas um quebra-galho. Figura 1 Gestão de ambientes Fonte: Bartié (2002, p.165) Na construção de um ambiente de testes separado do ambiente de produção e de desenvolvimento devemos ter em mente o seguinte: quando implantamos um sistema nesse ambiente devemos nos questionar se existe algum tipo de integração com outros sistemas (seja ela do tipo real-time, on-line e/ou batch) e se eles também estão implantados nesse mesmo ambiente. A realização dos testes no ambiente de homologação é conhecida como teste alpha (fig.2). Quando os testes ocorrem no ambiente de produção recebem o nome de teste beta. Ambiente de desenvolvimento Desenvolvimento Fontes Estrutura interna Teste: Unidade Integração Categoria: Funcional Usabilidade Ambiente de teste e homologação Teste: Sistema Teste: Categoria: Aceitação Funcional Carga Categoria: Performace Aceite formal Instalação Alpha-teste Segurança Ambiente de produção Teste: Aceitação Produção Categoria: Beta-teste Em desenvolvimento Figura 2 Ambientes Fonte: Bartié (2002, p ) Em teste Em homologação Em produção

26 24 Bartié (2002, p.159) também lembra que, outra característica do teste alpha é realização em ambiente simulado da empresa desenvolvedora da aplicação, fisicamente separado do ambiente de desenvolvimento. A equipe encarregada da preparação também deve observar todas as questões relativas à compatibilidade entre o ambiente de homologação e o de produção, para evitar o funcionamento incorreto da aplicação devido a problemas de versionamento, portabilidade, recursos de hardware, etc. 1.7 MASSA Em algumas livrarias virtuais, quando informamos nossos dados para realizar uma compra, após digitarmos o CEP, a aplicação web se encarrega de preencher automaticamente no endereço o nome da rua, bairro, município e UF. As informações que constam no banco de dados da aplicação antes de qualquer pessoa te-la utilizado são conhecidas como carga inicial. Muitas vezes, para testar uma aplicação em todo o seu potencial, é necessário que o sistema já contenha dados que vão além da carga inicial e que simulem o uso por parte do usuário, ao longo de algum tempo. Esses dados são chamados de massa de testes. Incluir manualmente esses dados, além de ser uma tarefa demorada, é muito monótono para qualquer pessoa. Já existem diversas ferramentas que se encarregam de gerar a massa de testes e que utilizam técnicas de redução, para uso de um registro de cada tipo (file-aid rdx), e descaracterização, para proteger dados pessoais e evitar que, em caso de algum acidente, esses dados sejam revelados (data solution). Em qualquer um dos casos é recomendável que utilizem apenas dados fictícios ou de domínio público para compor essas massas.

27 25 Com relação ao uso de ferramentas para automação do processo testes, tenha preferência pelas que possibilitem o retorno da massa ao momento zero, ou seja, quando terminamos de testar a aplicação pode ser interessante fazer a massa de testes retornar ao seu estado inicial, para poder reproduzir os mesmos testes com a garantia de obter os mesmos resultados. 1.8 VERSIONAMENTO Quando as aplicações começaram a conversar entre si, principalmente na interação entre aplicações via automação OLE, começaram a ocorrer problemas decorrentes da incompatibilidade de versões, devido às muitas variações de rotinas, que em tese deveriam atender tanto as chamadas que utilizam as novas características quanto as antigas. Esses problemas também se estenderam aos sistemas operacionais, as DLL de uso geral, sobre recursos da própria aplicação, polimorfismo de POO, hardware, etc. Já os browsers (navegadores para internet) são um caso a parte, pois sofrem com a variabilidade dos padrões e das interpretações dadas aos mesmos. Todos esses fatores obrigam os desenvolvedores a atentar para um rigoroso controle de configuração em caso de mudanças, seja pela simples instalação em computadores diferentes ou pelo upgrade da aplicação. A utilização de um processo automatizado de testes pode garantir uma considerável economia de recursos, quando é necessário testar o produto em diversos tipos de configuração. Na atualização também podemos ter uma boa economia, quando pouca coisa é modificada ao nível da interface, mas convêm avaliar todo o software novamente (teste de regressão). Quem já adquiriu um software e checou antes a configuração mínima percebe a importância desses procedimentos.

28 26 Mesmo quando é utilizado ferramentas para automação dos testes, muito tempo pode ser perdido quando não se tem o cuidado de guardar a baseline, como veremos a seguir. As idéias defendidas pelas categorias Compatibilidade e Configuração (qua.4) devem ser adotadas e seus registros acompanhados e controlados. Tanto projetos novos quanto as mudanças corretivas e/ou evolutivas devem possuir registros da configuração do ambiente, artefatos, hardware, etc. Decorrente do controle do versionamento surgiu à expressão baseline. Baseline é [...] o resultado do esforço de criação de um ambiente inicial pronto para sofrer o processamento dos testes planejados. (BARTIÉ, 2002, p.169). A IBM desenvolveu uma ferramenta chamada ClearCase, que faz parte da suite do Rational. Ela trabalha com o seguinte entendimento sobre baseline: imagine quatro artefatos sendo desenvolvidos paralelamente, que foram evoluindo e recebendo cada um versões particulares. Neste caso, baseline seria o conjunto de artefatos, com versões especificas, para que uma aplicação maior pudesse funcionar a contento. A figura a seguir ilustra melhor essa definição: Figura 3 Baseline

29 27 Para implantar o projeto e documentá-lo devemos considerar o Pacote 1 V.2, Pacote 2 V.1, Pacote 3 V.3 e Pacote 4 V.2, conforme determina a baseline. O objetivo do baseline é [...] validar a cópia dos componentes do ambiente de produção para o ambiente de homologação. (BRITO, 2000, p.43). No exemplo anterior citamos artefatos, mas o conceito de baseline também é utilizado em outros casos, como ambiente e hardware. O baseline torna-se muito útil quando precisamos restabelecer um sistema para testes corretivos e/ou evolutivos. Pensando nisso, Ungarelli (2007) definiu baseline como sendo a configuração tomada em um momento estratégico do projeto com o objetivo de servir como referência para as atividades posteriores identificadas conforme o plano de gestão de configuração. Quanto às modificações ele também lembra que, quando uma ocorrência é resolvida, o teste que deu origem à mesma deverá ser novamente executado sendo que, para isso, deve ser gerado um novo baseline com a versão corrigida do documento ou sistema. O controle do versionamento também ajuda a evitar problemas derivados da falta de equalização entre ambientes. Essa falta de equalização geralmente ocorre quando uma solicitação emergencial provoca uma mudança diretamente no ambiente de produção, e por falta de acompanhamento, não se efetua o acerto nos ambientes de desenvolvimento e homologação.

30 28 CAPÍTULO II O PROCESSO DE TESTES O processo de testes deve ser iniciado junto com o projeto e deve acompanhá-lo no decorrer das demais etapas do desenvolvimento, isso garante uma redução nos custos em virtude da prevenção de problemas já no inicio do desenvolvimento. Plano, estratégia, cenário, roteiro, casos, massa e evidências de testes são os principais artefatos elaborados e revistos ao longo do processo de avaliação (Anexo D). Nesse processo também encontramos as atividades de inspeção e auditoria de código-fonte, que, inclusive, podem utilizar ferramentas de automatização. Quanto aos artefatos, a automação tem sido mais utilizada junto aos casos e a massa de testes. Como já falamos sobre a massa de testes, vejamos os casos. Segundo Ungarelli (2007) os casos de teste especificam entradas, resultados esperados e condições de execução estabelecendo o que será testado. Para Correia (2004, p.2) a qualidade de um caso de teste é descrita através de quatro atributos: 1. Capacidade de encontrar defeitos; 2. Capacidade em exercitar mais de um aspecto reduzindo assim a quantidade de casos de teste requeridos; 3. Baixo custo necessário para a realização do caso de teste incluindo o esforço de desenho, execução e análise dos resultados de teste; 4. Baixo esforço de manutenção necessário sobre o caso de teste a cada alteração do sistema. Estes quatro atributos devem ser balanceados de forma a ter casos de testes com boa qualidade. Os dois primeiros atributos independem da forma de teste (automática ou manual). Quanto aos dois últimos veremos mais a frente diversas situações que demonstram em que casos uma forma é melhor que a outra. O esforço de construção e de

31 29 manutenção requerido para um teste automático é normalmente maior do que para um teste manual equivalente, mas uma vez construído, o automático tende a ser mais econômico que o manual. O esforço de execução e de verificação de resultados será uma pequena fração do esforço de construção e consideravelmente menores que a forma manual. 2.1 PADRÕES DE QUALIDADE Igualmente ao que ocorre na indústria, o segmento de TI vem sendo contemplado com diversos tipos de certificações para quem se propõe a garantir ao mercado a qualidade dos processos usados no desenvolvimento de suas aplicações. Adotar um padrão de qualidade não é uma tarefa simples, mas é possível colher bons frutos. Veja a seguir alguns comentários sobre os problemas e benefícios referentes a implantação de uma cultura de qualidade, segundo Bartié (2002, p.50-64): Problemas enfrentados: Ausência de gerência de qualidade independente Ausência de procedimentos de testes automatizados Qualidade é sempre aplicada tardiamente no desenvolvimento Ausência de profissionais capacitados em qualidade de software Falta de um modelo corporativo de qualidade Foco em testes progressivos aumenta os riscos Deficiência no planejamento dos testes Sob pressão, os testes são sacrificados Ausência de um ambiente de testes isolado Transferir o planejamento ao analista de sistemas Dificultar o acesso do analista de testes ao software Benefícios alcançados: Torna o ciclo de desenvolvimento confiável

32 30 Garante ações corretivas no ciclo de desenvolvimento Evita a ingerência do projeto de software Amplia as chances de sucesso do projeto de software Amplia a produtividade do desenvolvimento o Fator desorganização o Fator retrabalho Evitam a propagação de erros Automação de testes reduz custos do projeto Citamos abaixo os principais órgãos certificadores de qualidade no desenvolvimento de software: IEEE (Institute of Eletrical and Electronics Engineers) ANSI (American National Stantards Institute) ISO (International Stantards Organization) Na seqüência veja um quadro com algumas das normas definidas por estas instituições: Quadro 6 Normas de qualidade em desenvolvimento de software Norma Comentário ISO 9126 Características da qualidade de produtos de software. NBR Versão brasileira da ISO 9126 ISO Guias para a avaliação de produtos de software, baseados na utilização prática da norma ISO 9126 ISO Características de qualidade de pacotes de software (software de prateleira, vendido com um produto embalado) IEEE P1061 Standard for Software Quality Metrics Methodology (produto de software) ISO Software Life Cycle Process. Norma para a qualidade do processo de desenvolvimento de software. NBR ISO 9001 NBR ISO NBR ISO CMM Sistemas de qualidade - Modelo para garantia de qualidade em Projeto, Desenvolvimento, Instalação e Assistência Técnica (processo) Gestão de qualidade e garantia de qualidade. Aplicação da norma ISO 9000 para o processo de desenvolvimento de software. Auditoria de Sistemas de Qualidade (processo) Capability Maturity Model. Modelo da SEI (Instituto de Engenharia de Software do Departamento de Defesa dos EEUU) para avaliação da qualidade do processo de desenvolvimento de software. Não é uma norma ISO, mas é muito bem aceita no mercado. SPICE ISO Projeto da ISO/IEC para avaliação de processo de desenvolvimento de software Ainda não é uma norma oficial ISO, mas o processo está em andamento. Fonte: Oshiro (2007, p.151)

33 31 O CMM (Capability Maturity Model) da Software Engineering Institute esta se tornando o padrão no mercado, sua classificação em níveis possibilita ao mercado um visão sobre o que esperar de determinada empresa. Por exemplo, a SEI (Software Engineering Institute) estima que as empresas que se encontram no Nível 1 (fig.4) do modelo CMM gastam cerca de 55% (gra.4) dos esforços em correção de defeitos oriundos do projeto de desenvolvimento. NÍVEL 5 OTIMIZADO OTIMIZADO FOCO NO APERFEIÇOAMENTO DO PROCESSO NÍVEL 4 GERENCIADO MENSURÁVEL PROCESSO MEDIDO E CONTROLADO NÍVEL 3 DEFINIDO PADRONIZADO PROCESSO CARACTERIZADO E BEM ENTENDIDO NÍVEL 2 REPETITIVO CULTURAL TAREFAS "MESTRAS" PODEM SER REPETIDAS CONTINUAMENTE NÍVEL 1 INICIAL ANÁRQUICO PROCESSO IMPREVISÍVEL E POUCO CONTROLADO Figura 4 Possíveis níveis de maturidade previstos no modelo CMM Fonte: Bartié (2002, p.9) Existem outros dois modelos de qualidade em software que ainda não atingiram uma maior popularidade: O PSM e o SPICE. O PSM (Pratical Software Measurement) é um modelo para mensuração de projetos de software. Criado em 1994 sob o patrocínio do DoD (Departamento de Defesa Norte-Americano), o PSM foi publicado pela primeira vez O modelo vem sendo atualizado por profissionais da área de Software Process Improvement e foi utilizado como base para a elaboração da Process Area Measurement and Analysis do CMMi (modelo integrado que poderá substituir o CMM no futuro), Calleri (2005, p.20).

34 32 O SPICE (Software Process Improvement and Capability determination) teve desenvolvimento iniciado em 1993 e sua primeira versão foi liberada em Ele não foi proposto como modelo de qualidade ou de implementação, e sim como meio adequado à avaliação do processo de desenvolvimento de software, Spice Project (apud CALLERI, 2005, p.30). Seu projeto visava o desenvolvimento de uma norma internacional para avaliação de software; coordenação e análise de sua utilização; aprimoramento e sua consolidação como norma. Como resultado, foi criada a norma internacional ISO/IEC (International Electrotechnical Commision) 15504, Sepin (apud CALLERI, 2005, p.30).

35 33 CAPÍTULO III AUTOMAÇÃO DE TESTES A crescente complexidade nos sistemas informáticos juntamente com os métodos de desenvolvimento rápido e incremental como por exemplo, Rapid Application Development e Extreme Programming, que prometem intervalos de entrega mais freqüentes requerem testes de qualidade que possam ser rapidamente executados sempre que necessário. Em tal cenário os testes manuais são pouco vantajosos, visto que muitos testes são re-executados a cada release do sistema. (CORREIA, 2004, p.1). Podemos até falar em qualidade utilizando testes manuais, mas só o uso de ferramentas de automação pode fazer com que alta produtividade e qualidade andem juntas. As funcionalidades mais propícias à automação são aquelas que envolvem a execução de tarefas repetitivas e cansativas, facilmente suscetíveis a erros, ou impossíveis de serem realizadas manualmente, Fantinato (2004, p.14). Segundo Argollo (2008), a automação de testes tem como principais características: Diminuição do esforço; O foco não é repetir um teste bem sucedido, mas melhorá-lo; Repetir quando algo é alterado (software e/ou ambiente). Não é possível automatizar tudo, mas podemos atingir um bom nível de automação quando utilizamos as ferramentas basicamente para controlar a execução dos testes e comparar os resultados obtidos com os resultados esperados, além de relatar os resultados obtidos. Como veremos mais adiante algumas ferramentas podem oferecer suporte às linguagens que manipulam scripts, com o objetivo de apoiar o processo de automação. Esses scripts servem, principalmente, para simular ações, alterar valores e verificar o conteúdo dos objetos da interface gráfica. Eles também contam com recursos similares aos oferecidos pelas linguagens de programação como C, Java e Delphi. Um desses recursos é a possibilidade de incluir comandos para

36 34 controle de fluxo (if, while, case) e com isso diminuir o tamanho do código de controle. Veja a seguir um exemplo de script e seu resultado na tela: Figura 5 Exemplo de script Fonte: Argollo (2008) Window.Localizar.ProcurarPor.TypeText( automação ); Window.Localizar.Diferenciar.Click(); Window.Localizar.Localizar.Click(); MainWindows.Document.ChechSelText( automação ); Para Argollo (2008), os scripts também apresentam algumas limitações, como por exemplo: Scripts são dependentes dos elementos da interface gráfica: Se a interface mudar, o script para de funcionar; As linguagens de testes normalmente reconhecem somente os elementos básicos da interface gráfica. Algumas ferramentas ainda apresentam um terceiro fator negativo que é a impossibilidade de reaproveitamento do código em outro caso de teste. Voltaremos a falar de scripts e como superar essas limitações mais adiante. Já mencionamos que nem tudo pode ser automatizado, no entanto podem ocorrer casos em que determinada ferramenta de automação existe, mas não deve ser utilizada, ou seja, não devemos apenas atentar para o que pode ser automatizado?, mas também para o que deve ser automatizado?. Essa decisão deve envolver os desenvolvedores e os gerentes de projeto. No Anexo E, segue um roteiro com questões que podem orientar a decisão. Tanto as questões do Anexo E, quanto os apontamentos a seguir, tratam sobre a escolha entre os testes manuais e os automatizados, e servem apenas para orientar,

37 35 pois ainda que se tenha a consciência de que um determinado procedimento de teste automatizado deva ser adotado o equilíbrio com os custos e os prazos acabam se tornando o ponto crucial de toda a questão. O próximo tópico tem como foco justamente isto e vai apresentar diversos fatores que muitas vezes fazem com que algumas palavras diferentes pareçam sinônimas, como custo, investimento e economia. Quadro 7 Automação x teste manual Quando a automação de testes faz sentido? Quando focar em teste manual? Para valer a pena, devemos observar as Para valer a pena focar em testes manuais, seguintes questões: devemos observar as questões seguintes: Os testes que usarem técnicas de regressão Quando se faz uso de testes de instalação, ou de confirmação. Quando precisa constantemente do trabalho de repetir. por exemplo, que envolvam hardware (ex.: setup, operações muito específicas, como, Quando se faz uso de testes aleatórios instalação de componentes de equipamentos). Isto inclui manutenções em geral. (random ou monkeys testes) que utilizam caminhos aleatórios gravados por dentro da Faz uso de testes de configuração e de compatibilidade. Este tipo de teste geralmente aplicação e de grande quantidade de dados de testes. requer muita intervenção humana. Testes de carga, volume, capacidade. Como O mesmo vale para testes de error handing responder se o sistema funcionará com 50 (tratamento de erros) e de recuperação. Novamente este tipo de teste trabalha com er- mil usuários simultâneos? Performance e confiabilidade. Com a chegada dos sistemas web, cada vez mais vemos ficar caro. ros forçados de maneira que repeti-los pode este tipo de sistema fazer uso de ferramentas de performance. é preciso intervenção humana para o devido Testes de usabilidade. Mais um caso em que Quando se faz teste de componentes (unidade) os quais devem ser retestados várias O mesmo anterior vale para documentação e julgamento e validação dos testes. vezes. help. Fonte: Molinari (2003, p.105) No gráfico a seguir (gra.1) podemos ver que os testes manuais tornam-se mais dispendiosos que os diversos tipos de automação, porém a opção pelo teste manual pode ser determinada pelo tempo disponível e pela complexidade do teste, Molinari (2003, p.105). Aconselhamos aos que irão implantar a automação de testes, que busquem definir estratégias de coleta e análises métricas relacionadas ao processo de teste de software, isso ajudará a justificar o investimento aplicado e a otimizar cada etapa, Fantinato (2004, p.8). Vejamos um caso prático, o uso do framework AutoTest que foi desenvolvido sobre a plataforma IBM Rational Functional Tester for Java and Web.

38 36 O processo foi utilizado em um sistema desenvolvido pela empresa CPqD Telecom & IT Solutions, por meio da DSB Diretoria de Soluções em Billing. A equipe de desenvolvimento era formada por cerca de 160 pessoas, das quais 25 trabalhavam na atividade de teste Manual CaptureReplay Scripts ActionWord ModelBased Design Phase Release 1 Release 2 Release 3 Release 4 Release 5 Release 6 Release 7 Release 8 Release 9 Release 10 Gráfico 1 Custo hipotético (em horas) para diferentes processos de teste Fonte: Mark Utting (apud ARGOLLO, 2008) Analisaremos apenas os dados colhidos nos módulos Promoções e Atendimento a Clientes. Do total de casos de teste projetados, primeiramente foram executados apenas os casos de teste mais críticos de forma manual. Tabela 1 Métricas coletadas para o módulo de Promoções Tipo de métrica Teste manual Teste automatizado Número de casos de teste executados Cobertura funcional dos casos de teste 1 65% 88% Erros detectados Tempo de projeto de teste 101 h 101 h Tempo de uma execução completa dos casos de teste 123 h 14 h Análise dos resultados e registro de erros 34 h 28 h Fonte: Fantinato (2004, p.10)

39 , , , , ,00 Manual Automático Ganho 1.200,00 - Evolução Re-execução 1 Re-execução 2 Re-execução 3 Re-execução 4 Re-execução 5 Re-execução 6 Re-execução 7 Re-execução 8 Re-execução 9 Re-execução 10 Gráfico 2 Teste manual x teste automatizado do módulo de Promoções Fonte: Fantinato (2004, p.11) Analisando primeiramente os resultados do módulo Promoções e comparando as formas (tab.1), vemos que o aumento na identificação de erros (+33) pode estar relacionado ao aumento do escopo, mas não há como ignorar o fato de que o teste automatizado é realizado 15 vezes mais rápido que o manual. Essa diferença se torna mais evidente quando consideramos a repetição dos testes (gra.2). Tabela 2 Linha ilustrativa de Ganho Gráfico 7 Gráfico 6 Serviço Ganho Serviço Ganho Projeto 0% Evolução -68% Execução inicial -131% Re-execução 1 2% Re-execução 1-61% Re-execução 2 30% Re-execução 2-28% Re-execução 3 45% Re-execução 3-9% Re-execução 4 55% Re-execução 4 4% Re-execução 5 62% Re-execução 5 13% Re-execução 6 66% Re-execução 6 20% Re-execução 7 70% Re-execução 7 25% Re-execução 8 73% Re-execução 8 29% Re-execução 9 75% Re-execução 9 32% Re-execução 10 77% Re-execução 10 35% Fonte: Fantinato (2004, p.11-12) A linha que representa o Ganho (gra.2 e gra.3) é apenas ilustrativa (tab.2), serve para mostrar o desempenho do teste automatizado em relação ao teste manual.

40 38 Tabela 3 Métricas coletadas para o módulo de Atendimento a Clientes Tipo de métrica Teste manual Teste automatizado Número de casos de teste executados Cobertura funcional dos casos de teste - 71% Erros detectados - 18 Tempo de projeto de teste h Tempo de uma execução completa dos casos de teste 525 h (estimado) 4 h Análise dos resultados e registro de erros 100 h (estimado) 62 h Fonte: Fantinato (2004, p.12) Quanto ao módulo Atendimento a Clientes, por se tratar de um módulo em evolução (tab.3), as planilhas de teste não foram criadas durante a atividade de projeto de teste, mas apenas adaptadas a partir do projeto anterior para cobrir as funcionalidades adicionadas ou alteradas , , , , ,00 800,00 600,00 400,00 200,00 - Projeto Execução inicial Re-execução 1 Re-execução 2 Re-execução 3 Re-execução 4 Re-execução 5 Re-execução 6 Re-execução 7 Re-execução 8 Re-execução 9 Re-execução 10 Manual Automático Ganho Gráfico 3 Teste manual x teste automatizado do módulo de Atendimento a Clientes Fonte: Fantinato (2004, p.12) A diferença de 525 horas para 4, no tempo de execução, é justificada por se tratar de um módulo com uma grande quantidade de operações, que demandam muitos acessos ao banco de dados, via SQL, tanto para preparar os testes quanto para analisar resultados.

41 39 Não houve teste manual para este módulo, por isso que apenas foram estimados os valores para efeito de comparação. Outros autores também realizaram comparações entre os testes manuais e os automatizados, para Linz e Daigl (apud CORREIA, 2004, p.2), após investimentos iniciais de criação de infra-estrutura, o gasto em testes automáticos representa 40% do gasto com testes manuais. 3.1 CUSTOS E PRAZOS Não pense em automação como um mecanismo para diminuir o prazo da realização dos testes, mas como uma forma de aproveitar melhor o tempo para obter um produto mais confiável. (ARGOLLO, 2008). As palavras de Argollo nos lembrar da filosofia Kaizen, que prega a melhora continua dos processos. Também encontramos esse ideal nas empresas de nível 5 do CMM (fig.4). Todas as pessoas envolvidas com testes devem ter esse horizonte como meta, pois a simples repetição dos mesmos de forma automática não é suficiente para extrair um verdadeiro ganho econômico nas atividades de teste, é necessário uma melhoria contínua, para que possam ser executadas rotinas que não foram consideradas anteriormente. Por isso é importante adquirir ferramentas que possibilitem a reutilização de casos de testes, seja por meio de scripts ou por outra técnica qualquer. Devemos buscar a reutilização, porque esse é um dos grandes benefícios da automação. Ela possibilita a execução de um teste de regressão completo em todo o programa com um mínimo de esforço e o máximo em qualidade. As empresas que fazem uso dos testes manuais tendem a fazer apenas testes de progressão, devido ao alto custo dos testes de regressão quando realizados manualmente. Como

42 40 podemos ver a seguir Bartié (2002, p.45 e 193) reconhece o custo, mas é um dos que enfatizam a importância dos testes de regressão: O risco de que as novas alterações tenham comprometido as funcionalidades anteriores tende a aumentar ainda mais à medida que o software vai se tornando mais complexo.... Os custos relativos à execução dos testes de progressão não são importantes. São importantes os custos de execução dos testes de regressão, pois estes devem ser continuamente executados ao longo da vida do software. Por outro lado, não investir na qualidade do software pode gerar prejuízos de diversas ordens. Conforme estudos apresentados por Bartié (2002, p.6): Mais de 30% dos projetos são cancelados antes de serem finalizados. Mais de 70% dos projetos falham nas entregas das funcionalidades esperadas. Os custos extrapolam em mais de 180% os valores originalmente previstos. Os prazos excedem em mais de 200% os cronogramas originais. Não podemos generalizar, considerando que todos esses problemas têm sua origem na deficiência do processo de testes. Requisitos mal elaborados, falhas no acompanhamento do cronograma ou sub-estimativas de prazos e custos, também são fatores que causam problemas ao projeto, mas o processo de verificar antes para depois validar (Anexo D) ajuda a minimizar esses efeitos além de toda uma cultura de qualidade. Também não podemos ignorar o fato de que a atividade de teste é cara e repetitiva. Dependendo do risco e da complexidade da aplicação, a parcela do esforço de desenvolvimento alocada ao teste varia entre 30% e 50%. O custo do teste na maioria dos sistemas comerciais varia entre 40% e 50% do custo total de desenvolvimento, Argollo (2008). Até o processo de obtenção de uma certificação, em um órgão internacional de qualidade, costuma ser bem caro. O CMM (Capability Maturity Model) é um desses padrões de qualidade. Para defender a tese de que vale a pena investir em um padrão de qualidade a SEI

43 41 (Software Engineering Institute) realizou uma pesquisa, com base nos dados e em sua experiência ela estimou alguns valores para as empresas que adotam o CMM. Inclusive já citamos essa pesquisa, quando mencionamos que as empresas que se encontram no Nível 1, do modelo CMM, gastam cerca de 55% dos esforços em correção de defeitos oriundos do projeto de desenvolvimento. Veja agora o gráfico completo: 60% 55% 50% Esforço de correção 40% 30% 20% 10% 35% 20% 10% 5% 0% Nível de maturidade Gráfico 4 Esforço dedicado à correção de defeitos Fonte: Bartié (2002, p.14) Muitos gerentes vêem o processo de automação de testes de software como algo que pouco agrega valor. (MOLINARI, 2003, p.102). Por que será que, mesmo diante do gráfico anterior, os gerentes continuam tendenciosos a dispensar investimentos em testes? Provavelmente esse fato esta relacionado ao alto grau de investimentos e esforços necessários no inicio da implantação de um programa de qualidade. Veja o próximo gráfico com mais alguns dados levantados pelo SEI:

44 42 30% 25% 25% Esforço gerencial 20% 15% 10% 15% 10% 5% 0% 5% 0% Nível de maturidade Gráfico 5 Esforço gerencial para alcançar níveis maiores de maturidade Fonte: Bartié (2002, p.15) Não há gerente que não se pergunte A empresa está preparada para receber uma nova cultura? Será que isso vai dar resultado?. Podemos considerar que o gerente deve observar os seguintes custos, associados à implantação de um processo de testes automatizado: Aquisição da tecnologia, hardware gasto na instalação das ferramentas; Recursos necessários à escolha dos tipos de ferramentas (planejamento, performance, teste de regressão, funcional, de monitoração, etc); Recursos necessários à compra e instalação das ferramentas; Treinamento; Custos de uso da tecnologia. Licenças / quantidade de usuários das mesmas ferramentas; Recursos necessários à automação (desenvolvimento de scripts); Recursos necessários à manutenção dos scripts; Suporte do fornecedor.

45 43 Para piorar o quadro a experiência mostra que o esforço necessário para criar, verificar e documentar um teste automático é de 3 a 10 vezes maior do que o necessário para criar e executar o teste manualmente, Argollo (2008). Seja o teste manual ou automatizado, o custo associado à definição, documentação e execução de um processo de teste é recuperado ao permitir a detecção e correção dos defeitos nas fases iniciais do desenvolvimento de um sistema, diminuindo os ciclos de desenvolvimento. Seguindo o modelo de PQS em U (Anexo D), identificamos as atividades de verificação no inicio do ciclo. Essas verificações são importantes na redução dos custos ao longo do processo, tanto que resultaram na regra de 10, formulada por Myers (gra.6). Segundo Myers um erro não identificado nas fases iniciais do desenvolvimento ocasiona prejuízos exponenciais à medida que o projeto avança Requisitos Análise e modelagem Código Teste de software Produção Gráfico 6 Regra de 10 de Myers Fonte: Bartié (2002, p.31) Veja a seguir um gráfico que apresenta levantamento feito por Argollo, sobre os custos da propagação dos defeitos e quanto foi gasto nas correções em cada fase do projeto.

46 , , , , , , , ,00 - Requisitos Projetos Codificação Teste Manutenção Fases de desenvolvimento Gráfico 7 Custo de correção de defeitos Fonte: Argollo (2008) Não chega a ser igual ao idealizado por Myers, mas podemos notar que ele se aproximou muito da realidade. Esses gráficos mostram a importância da qualidade e que ela não se aplica apenas a fase de testes. Ela deve existir em todas as etapas, verificando a conformidade dos trabalhos realizados. Quanto à opção por um teste manual ou automatizado, vamos ver a seguir um caso apresentado por Argollo na SBQS O relato envolve o desenvolvimento de um sistema da área de seguros, a gerência teve que decidir entre qual esforço empregar no processo de testes, veja os dados disponibilizados a gerência: Execução dos testes manuais: 5 p/m (5 pessoas x 4 semanas) Automação dos testes: 18 p/m (3 pessoas x 6 meses) Podemos ver que o esforço para os testes automáticos é bem maior que a realização dos testes manuais, porém devemos perceber que esse esforço só será

47 45 feito uma única vez e o tempo necessário à execução automatizada dos mesmos é de apenas uma semana, exigindo um esforço de 1,25 p/m. Os gerentes também consideraram a possibilidade de repetir a avaliação, nesse caso o investimento seria recuperado em cinco ciclos e a diferença poderia ser reinvestida no aprimoramento dos testes. A escolha foi pela automação e o resultado foi o seguinte: O número de incidentes no sistema em produção caiu de 80% a 90%; A economia para empresa ao término de um ano foi superior ao orçamento anual do departamento de teste. Continuaremos a comparar os testes manuais e os automatizados. Veja a próxima tabela, ela apresenta os custos de testes referentes à preparação do ambiente, de execução e de conferência: Tabela 4 Comparativo entre testes manuais e automatizados Etapas dos testes Teste manual Teste Melhoria automatizado (%) Planejamento % Definição dos casos de testes % Execução dos testes % Conferência dos testes % Gerenciamento do erro % Relatórios finais % Duração total (em horas) % Fonte: The Newsletter of the Quality Assurance (apud BARTIÉ, 2002, p.64) Esta tabela demonstra um estudo que envolveu casos de testes e 700 defeitos existentes. À medida que re-executamos os testes, o ganho de tempo, controle e confiabilidade fica claro. A mera repetição não deve ser o único fator para a opção pelos testes automatizados e a adoção destes sem aplicá-los em testes de regressão total também é algo que deixa a desejar.

48 46 Podemos ver no quadro a seguir que a regressão parcial usando testes automatizados não reduz o risco de não cobertura, apenas reduz o custo e em alguns casos nem isso. Teste Manual Teste Automatizado Fonte: Bartié (2002, p.196) Quadro 8 Alternativas na execução dos testes Regressão Total Regressão Parcial Baixo risco de não-cobertura Alto risco de não cobertura Alto custo de execução Custo de execução menor Execução lenta Execução lenta Reutilização zero Reutilização zero Interferências humanas Interferências humanas Baixo risco de não-cobertura Baixo custo de execução Execução rápida Reutilização total Sem interferências humanas Alto risco de não cobertura Menor custo de execução possível Execução mais rápida possível Reutilização total Sem interferências humanas A equipe responsável pelos testes deve ter a preocupação de reduzir os riscos ao máximo e em cada uma das categorias (qua.4) Funcionalidade Performance Segurança Usabilidade Disponibilidade Operabilidade Gráfico 8 Risco de teste numa aplicação de TI tradicional Fonte: Molinari (2003, p.180) Como já mencionamos anteriormente, o nível de importância de cada categoria pode mudar em função do projeto e dos riscos envolvidos.

49 47 Essas diferenças podem estar no formato da aplicação em si, ou seja, se é um projeto de software ou site web. Mesmo na escolha do titulo deste trabalho tivemos a preocupação de enfatizar essa diferença. Molinari (2003, p.180) realça essa diferença ao apresentar uma maior distribuição dos riscos nos projetos web (gra.8 e gra.9). Quando comparamos uma aplicação web com uma aplicação que funciona sobre uma estrutura cliente/servidor as diferenças na distribuição dos riscos diminuem Funcionalidade Performance Residência Segurança Itens de Performace do Site Integração Infra-estrutura Usabilidade Localização Disponibilidade Pós-entrega Gráfico 9 Risco de teste numa aplicação web Fonte: Molinari (2003, p.181) Uma boa pratica em testes é separar a equipe que testa da equipe que desenvolve. Pensando nisso muitas empresas contratam uma FSW (fábrica de software) para desenvolver e uma FTS (fábrica de testes) para testar. Isso não significa que a FSW não vai fazer testes, ela inclusive se preocupa bem mais com os erros em uma situação assim, pois, caso a FTS ache erros, a FSW, além de ter o custo de consertá-los, arca com o custo de reenvio a FTS para o re-teste.

50 48 A FSW é responsável, principalmente, pelos testes de unidade, integrado e de sistemas. Esses testes não são feitos pela FTS, mas podem passar pela inspeção desta. Segue abaixo um quadro com um exemplo de distribuição de esforço para as atividades da FTS: Tabela 5 Distribuição do esforço em testes PROJETO MANUTENÇÕES Atividade Percentual de Esforço Percentual de Esforço Auditoria de Código-Fonte Inspeção de artefatos de teste 5% 5% Planejamento de Teste 32% 15% Execução e Evidenciação de Teste sobre uma entrega parcial de software 28% 30% Execução e evidenciação de teste de Aceite de um Serviço de Desenvolvimento e/ou Manutenção de 22% 35% Software Publicação de Ocorrências de Teste 3% 5% Automatização de teste 10% 10% Fonte: Carvalho (2008, s.16) Quando a empresa contratante resolve adotar um ambiente ativo para homologação, a FTS pode ser contratada para a tarefa de montar nesse ambiente os mesmos sistemas que se encontram em produção. A distribuição de esforço para essa tarefa pode ser visto a seguir: Tabela 6 Distribuição do esforço em legados (implantação) Atividade Percentual de Esforço Planejamento de Teste 20% Acompanhamento da montagem do sistema no ambiente de homologação 30% Execução e evidenciação de teste sobre sistema legado 40% Automatização de teste 10% Fonte: Carvalho (2008, s.17) Consideremos o seguinte exemplo: A FSW vai desenvolver um projeto 700 PF (pontos de função). Considerando que a FTS cobra R$ 50,00 2 para uma produtividade de 3 pf/h (pontos de função por hora) em caso de projetos novos, teremos um custo total, com um processo automatizado de testes, de R$ ,00, veja o Anexo G. No Anexo H e I, apresentamos exemplos de cálculos sobre serviços 2 Os valores são fictícios, mas muito próximos do que é cobrado no mercado atualmente (Set/08).

51 49 de manutenção e preparação de ambiente, respectivamente. Os valores calculados em horas podem ser utilizados facilmente na montagem de cronogramas em programas como o MS Project da Microsoft. Vimos até aqui diversas razões para optar pelo processo de testes automatizado, mas quando nos deparamos com um custo de quase cem mil reais é natural ter certo receio. Afinal sabemos agora quanto custa, mas não sabemos quanto dinheiro economizamos ao adotar essa prática. Molinari (2003, p.40) propôs a seguinte fórmula para medir o custo de um defeito encontrado: Custo médio do defeito = (nº de pessoas envolvidas * nº de dias gastos) * custo por pessoa-dia (nº de defeitos resolvidos) Esta fórmula pode ajudar a complementar as avaliações de custos futuros com base em dados históricos e estimar uma produtividade em pontos de função, mas não chega a dizer quanto economizamos com o uso dos testes. Isso não significa que este tipo de informação não deva ser registrada, podemos inclusive usar ferramentas bug tracking para esse trabalho, conforme aconselha Ungarelli (2007): É desejável, para o acompanhamento e controle dos bugs registrados, a utilização de uma ferramenta de bug tracking assim, características importantes de um registro poderão ser facilmente resgatadas. Seguem algumas características importantes: gravidade do bug, prioridade do bug, status, versão do software ou artefato, a fase que bug ocorreu, histórico, relator e responsável pela resolução, etc. Da mesma forma que acreditamos que não é possível automatizar tudo também acreditamos que não é preciso medir tudo, para não tornar essa tarefa burocrática e cara demais. Todo o esforço para encontrar, mensurar, quantificar e analisar falhas em uma aplicação só vai fazer sentido se o erro for corrigido, Molinari (2003, p.52) lembra bem o caso do processador Pentium da Intel que apresentou um Bug em A Intel havia descoberto o problema através de seus engenheiros de teste, antes do chip ser lançado, porém, por decisão gerencial, houve o lançamento do produto, pois

52 50 havia o entendimento que o problema não era severo. Por exemplo, ao tentar fazer o cálculo: ( / ) * / Se a resposta fosse zero 3, o computador funcionava; caso contrário, aparecia um bug no chip que travava a máquina. No dia 30 de outubro de 1994, Dr. Thomas R. Nicely do Lynchburg College (Virginia - EUA) rastreou um resultado inesperado devido a problemas de divisão. O problema foi jogado na internet, mas a Intel não considerava um bug de fato e ela tentou vender isso a imprensa, mas acabou amargando um prejuízo de mais de US$ 400 milhões com reposição de chips. Queremos ilustrar com essa história que os testes feitos pelos engenheiros da Intel, certamente, custaram bem menos que os milhões gastos na substituição dos processadores. O custo dos testes pode ter sido mais baixo do que se imagina, caso a falha tenha sido identificada no inicio do processo, conforme principio de Myers (gra.6), pois não ficou claro em que momento o erro foi encontrado nos laboratórios da Intel. Brito (2000, p.47), chama a atenção para o simples ato de fazer uma conferência do que foi realizado em determinada etapa. Ela cita um caso em que uma revisão de requisitos foi efetuada com a participação do seguinte quadro de funcionários: Tabela 7 Custos das atividades de uma revisão Profissional Quantidade Custo/Hora Tempo Estimado Total Analista Pleno 3 28,11 04:30 379,49 Programador 1 21,48 04:30 96,66 Líder de Projeto 1 36,28 06:00 217,68 Total 693,83 Fonte: Brito (2000, p.47) 3 O cálculo dessa equação retorna 1 nos processadores atuais

53 51 Essa tabela tem o objetivo de fornecer rapidamente a informação sobre os custos despendidos com uma revisão. Ainda que fossem realizadas 5 revisões, um número exagerado, para uma única especificação de requisitos, o custo de R$ 3.469,05 é aceitável se comparado ao valor do projeto que estava em questão (R$ ,20), pois as revisões evitam que, no momento da homologação, sejam descobertos erros de requisitos funcionais que inviabilizam sua implantação. Causando assim um prejuízo maior na forma de retrabalho, caso o cliente ainda deseje o produto e concorde em aguardar sua correção. Brito não cita como essa verificação foi feita, pois ainda podemos encontrar diferenciais entre a forma manual e automática nessa questão. Veja o quadro a seguir: Quadro 9 Alternativas na conferência dos testes Conferências Manuais Conferências Automatizadas Planejamento mais simples Planejamento mais complexo Maior custo de re-execução Menor custo de re-execução Execução mais lenta Execução mais rápida Reutilização zero Reutilização total Com interpretações humanas Sem interpretações humanas Fonte: Bartié (2002, p.198) Nas fases iniciais pode ser preferível adotar conferências manuais, como a revisão de requisitos. Principalmente quando não temos a intenção de fazer uma nova verificação Adquirindo uma ferramenta Existem opções para empresa de qualquer porte, desde caríssimos elefantes brancos até as chamadas Open Source. Quando a dúvida aparece Molinari (p ) sugere fazer o seguinte: Definir requerimentos iniciais (Quais problemas a ferramenta deve resolver? Que recursos a ferramenta precisa ter para ser efetiva no seu ambiente? Quais são suas regras de utilização, custo, etc?)

54 52 o Itens de compatibilidade (sistema operacional, linguagem de programação, outros softwares) o Audiência com a ferramenta (Solicitar uma apresentação da ferramenta; Quem usará a ferramenta no dia-a-dia? Quanto é necessário em tempo e energia para treinamento? Como se espera que a automação de testes seja paga?) o Regra financeira (Determinar o budget (orçamento) antes de ir as compras; Inclui quantas licenças, treinamento, manutenção e implementação?; Necessidade de aquisição de máquinas exclusivas para testes; Quais os benefícios esperados, são quantificáveis e mensuráveis? Qual o ROI (returno of investiment)) o Requerimento de negócio (veja Anexo J) Investigar as opiniões (Internet, NewsGroups, literatura disponível, veja o que outras pessoas adotaram, em que a ferramenta é melhor ou pior que a concorrência?) Refinar os seus requerimentos (discuta com quem vai usar) Refinar a lista (selecione as três melhores com base na lista de requerimentos) Avaliar os finalistas (ver os softwares de demonstrações ou hands-on) Implantação da ferramenta escolhida (treinamento, piloto, inicie medições, acompanhe o processo, comunicação clara) As ferramentas Open Source tem como positivo o preço, mas as soluções comerciais 4 se defendem argumentando que as ferramentas gratuitas não oferecem integração. Entre as ferramentas Open Source o OpenSta da Cyrano tem oferecido alguma integração, mas ainda é limitado. Apesar dessas limitações o Watir (Web Application Testing in Ruby) e o Selenium tëm ganhado força no mercado. Entre os grandes fornecedores de soluções comerciais temos a integração como ponto positivo e negativo o preço e adequação. Outras ferramentas serão mencionadas mais adiante. 4 Vamos chamar de solução comercial as ferramentas que não são gratuitas.

55 TIPOS DE AUTOMAÇÃO Da mesma forma que não há um consenso entre os autores sobre os tipos de testes, suas classificações e inter-relações, o mesmo ocorre com os tipos de automação, mas concordamos em dizer que As principais técnicas de automação de teste apresentadas na literatura são: record & playback, programação de scripts, data-driven e keyword-driven. (FANTINATO, 2004, p.2). Vamos apresentar também a visão de outros autores. Caetano (2007) agrupou os tipos de automação em dois paradigmas, os testes baseados na interface gráfica e os baseados na lógica de negócio. Veja o quadro a seguir que apresenta as vantagens e desvantagens de cada um: Quadro 10 Tipos de automação Paradigma Vantagens Desvantagens Baseado na Interface Gráfica Baseado na Lógica de Negócio Fonte: Caetano (2007) Não requer modificações na aplicação para criar os testes automatizados. Também não é necessário tornar a aplicação mais fácil de testar (testabilidade) porque os testes se baseiam na mesma interface utilizada pelos usuários. Foco na camada onde existe maior probabilidade de existir erros. Independência das mudanças da interface gráfica. Alto desempenho para testes automatizados que exigem centenas de milhares de repetições, testes de funcionalidades que realizam cálculos complexos, integração entre sistemas diferentes e assim por diante. Existe uma forte dependência da estabilidade da interface gráfica. Se a interface gráfica mudar, os testes falham. Baixo desempenho para testes automatizados que exigem centenas de milhares de repetições, testes de funcionalidades que realizam cálculos complexos, integração entre sistemas diferentes e assim por diante. Requer grandes modificações na aplicação para expor as funcionalidades ao mundo exterior. Exige profissionais especializados em programação para criar os testes automatizados. Existem poucas ferramentas/frameworks que suportam essa abordagem (normalmente é necessário criar soluções caseiras). Molinari (2003, p ) reconhece que não há uma unanimidade no mercado em relação aos tipos de ferramentas de teste existentes e que não existe uma classificação mínima, mas ele defende a existência de duas correntes. Uma comercial, que foca as funcionalidades, e outra acadêmica, que foca a forma básica de concepção (Anexo K).

56 54 Segundo Bartié (2002, p.181) a automação, que é desenvolvida em paralelo ao desenvolvimento da aplicação principal, pode ser classificada em dois tipos de componentes de testes fundamentais: controladores e simuladores. Os controladores de testes (Test-drivers) servem para testar uma unidade de software, disparando chamadas com os mais variados cenários existentes. Já os simuladores (Stubs) testam tanto software quanto hardware, criando artificialmente respostas simuladas que imitam conversas entre aplicativos, como, por exemplo, o teste de uma máquina que faz cálculos com base na velocidade do vento, ao invés de produzir o vento é melhor alimentar a máquina com as mais variadas velocidades do ar para concluir os testes mais rapidamente e de forma mais completa, pois poderemos simular todas as possibilidades. Bartié (2002, p ) separa componentes de ferramentas de testes (que ele também chama de CAST, Computer-Aided Software Testing), para ele as ferramentas de testes podem ser classificadas em cinco categorias, com suas respectivas características: Planejamento de testes o Análise de criticidade prioriza testes, estima tempo, custo e equipes; o Gerador de documentos gestão de versão, organiza work-flow de preparação, elaboração, inspeção e aceite de documentos. Revisões e inspeções o Análise de complexidade auxiliam na identificação de áreas complexas, a experiência diz que em 20% está 80% dos problemas; o Compreensão de código auxilia a inspeção de código-fonte; o Análise sintática e de semântica localiza erros de sintaxe que o compilador não detecta. Modelagem e automação o Modelagem de testes planeja e constrói os testes identificando os cenários de teste; o Gerador de massa de dados; o Automatizador de scripts. Execução e conferência

57 55 o Executor de scripts; o Análise de cobertura usado nos testes caixa branca para identificar áreas do código não cobertas pelos testes em execução; o Testadores de memória detecta problemas de uso e alocação de memória; o Simuladores e medidores de performance destinam-se aos testes de carga, volume e performance. Suporte aos testes o Gerenciamento de defeitos produz indicadores diversos de qualidade; o Gerenciamento de configurações controla mudanças em documentação, fontes e ambientes físicos. Carvalho e Filho (2005) fazem distinção entre ferramentas usadas em plataforma alta (mainframe) e plataforma baixa (Windows e Sun). Ambas são semelhantes na automação que executa as mesmas ações de um usuário on-line e na necessidade de programação. Quanto às diferenças, podemos citar que o teste automatizado na plataforma alta pode ser executado em batch, ou seja, não há necessidade de uma estação dedicada ao teste e os objetos a serem automatizados na plataforma alta obedecem a padrões rígidos, característicos dessa plataforma, enquanto que os da plataforma baixa estão em constante processo de evolução. Caetano (2007) também faz referência à filosofia apresentada pelo "Guide to the CSTE Common Body of Knowledge" do QAI que diz: apesar de não existir uma categorização amplamente difundida das ferramentas de teste, a experiência tem mostrado que elas são normalmente agrupadas em 8 áreas distintas: 1. Ferramentas de automação de testes de regressão; 2. Ferramentas para gestão de defeitos; 3. Ferramentas para testes de performance/stress; 4. Ferramentas manuais; 5. Ferramentas de rastreabilidade; 6. Ferramentas de cobertura de código; 7. Ferramentas para gestão de testes; 8. Ferramentas de apoio à execução dos testes.

58 56 Argollo (2008) defende ainda os testes baseados em modelos. Neste tipo os casos são derivados de um modelo que descreve as propriedades e características do sistema em teste. Este modelo fornece uma descrição do comportamento do sistema em avaliação. Conforme estimativa da Mark Utting, apresentada por Argollo, os testes baseados em modelos podem ser mais eficientes que as outras técnicas (gra.1) e no futuro ela pode se tornar uma das principais técnicas utilizadas pelo mercado. Caetano (2007) cita ainda os testes do tipo Interface de Linha de Comando (Command Line Interface - CLI) onde a interação ocorre através de um prompt ou shell do sistema operacional. A lógica de negócio da aplicação pode ser exercitada por meio da execução de um conjunto de comandos e parâmetros pré-determinados. Talvez você esteja pensando nos arquivos BAT do DOS, mas não é esse o caso. O objetivo da CLI é fornecer uma interface para o mundo exterior que não seja dependente da interface gráfica da aplicação, controlar a execução dos testes e apresentar os resultados Capture/Playback (Captura e executa) Quem já utilizou macros no Word ou Excel, tem uma boa idéia de como a técnica de Capture/Playback funciona. Ao acionar o recurso de gravação/captura (Record/Playback ou Capture/Playback) a ferramenta passa a fazer o registro de todos os passos do usuário, nesse momento devemos executar os casos de testes e interromper o processo de gravação quando desejarmos incluir verificações. Internamente a ferramenta terá criado um script com essas ações.

59 57 Da mesma forma que ocorre com as macros no Word e no Excel, podemos repetir todas as ações gravadas bastando executar o script criado. Podemos ver que a geração dos scripts é feita de forma rápida e fácil. Possibilitando que o automatizador não detenha conhecimento de programação e não onere a primeira execução dos testes trabalhando horas em scripts complexos (gra.3). Porém com o decorrer do tempo essa técnica não se mostra tão eficiente (gra.1). Quando optamos por um testador que não vai manipular os scripts ou até pelo fato da ferramenta não permitir essa manipulação, estamos condicionando a criação de novos scripts toda vez que precisarmos de novos testes ou quando algo for mudado na interface. Devido à falta de comandos de controle de fluxo e pela impossibilidade do uso de tabelas, um testador, que conhece programação, pode se deparar com uma quantidade muito grande de scripts para manipular. Segundo Correia (2004, p.6), a maioria das ferramentas que utilizam essa técnica interage com o standard Microsoft Foundation Class Library (MFC), ou seja, caso o sistema a ser testado esteja usando uma tecnologia diferente como, por exemplo, a Java Foundation Class Library, a ferramenta pode não funcionar. Por isso que algumas ferramentas também trabalham com o reconhecimento dos objetos através das coordenadas espaciais do ecrã. Correia também lembra que é possível usar essas ferramentas para testar stored procedures PL-SQL, a WebServices, aplicações servidoras ou um componente através de uma DLL, a solução passa pela criação de uma camada de interface gráfica standard simples, que possibilita a invocação dos serviços a serem testados. Através deste recurso, podemos dizer que essa técnica permite a execução e comparação automática de testes em todos os níveis: unidade, módulo, integração, sistema ou aceitação.

60 Scripts estruturados A técnica dos scripts estruturados permite a redução do código e sua reutilização, como também a possibilidade de organizar seu funcionamento em um framework que forneça funções básicas de automação. Necessita-se de um maior esforço do automatizador no início para a criação dos scripts, a compensação vem com a manutenção que é simples em caso de mudança na interface ou na adição de novos casos. O automatizador deve ter conhecimento de programação. Algumas ferramentas não possibilitam o uso de tabelas, ou seja, o conteúdo da ação do usuário deve estar no script (hard-coded) Data-Driven (Técnica orientada a dados) Nesta técnica os casos de teste são armazenados em tabelas (Anexo L). A ferramenta usa scripts para ler os dados dessas tabelas e processar os casos de teste de acordo com o cenário definido (Anexo F). A grande vantagem desta técnica está em usar o mesmo script, sem alteração, para executar novos casos de teste semelhantes. Dependendo de como o script é escrito, as alterações na interface não causam grandes problemas, pois as ferramentas costumam usar mapas de interface. Segundo Fantinato (2004, p.7) esse mapa é um arquivo que contém nomes fictícios dos componentes da interface gráfica (GUI) da aplicação e as propriedades que os identificam unicamente. Este mapa é utilizado para que todo componente da GUI seja referenciado nos scripts e nas planilhas de teste por um nome que independa de mudanças da aplicação, com o objetivo de que as alterações introduzidas na

61 59 interface gráfica da aplicação impliquem, apenas, em atualizações no mapa de interface, preservando e tornando o teste mais robusto. O esforço necessário para desenvolvimento dos scripts aumenta devido a maior complexidade dos mesmos Keyword-Driven (Técnica orientada a palavras-chave) Essa técnica usa tabelas para armazenar os casos de teste e os scripts para ler as informações da tabela e processar os casos de teste. Cada tabela também contém dados de diversos cenários de teste. O diferencial está no uso de palavras-chave para referenciar scripts específicos (tab.8), isso possibilita uma maior flexibilidade para a definição de novos cenários de teste. Os testes também são definidos em termos de processos de negócios. Exige-se do testador um pouco mais de conhecimento em desenvolvimento de software do que a técnica anterior, data-driven, pois os scripts desenvolvidos são mais complexos. Tabela 8 - Teste por palavras-chave Cadastro Silva José A ,00 Cadastro Moraes Carlos B 8.200,00 Transferência A B 500,00 VerificaSaldo A ,00 VerificaSaldo B 8.700,00 Fonte: Argollo (2008) Na tabela keyword-driven anterior, à primeira coluna possui as palavras que fazem referência aos procedimentos (scripts, também conhecidos como scripts de suporte) previamente construídos para executar determinada rotina de teste. As colunas seguintes possuem os parâmetros que serão usados pela rotina (script). Por exemplo, Transferência é uma rotina encarregada de passar dinheiro de uma conta para outra e, para realizar essa tarefa, ela recebe como parâmetro a conta de origem ( A), a conta de destino ( B) e o valor a ser transferido (500,00).

62 60 Figura 6 - Aplicação da técnica keyword-driven Fonte: Adaptada de Fewster e Grahm (apud Correia, 2004, p.6) Na técnica keyword-driven temos portanto três estruturas básicas que são: o script de controle, os ficheiros de teste e os scripts de suporte (fig.6). Dentre as técnicas para a construção de testes automáticos as mais evoluídas são as data-driven e keyword-driven, que permitem reutilização (inclusive em sistemas diferentes) e flexíbilidade. Como mencionamos no tópico scripts estruturados é possível, a partir dos scripts, elaborar frameworks. Fantinato apresentou em seu trabalho o AutoTest, que usa uma técnica mista de automação de teste, chamada de técnica keyword-data-driven, definida a partir de duas outras técnicas de automação conhecidas, dessa forma ele aproveita o que há de melhor em cada uma delas. Neste framework também foi necessário usar o IBM Rational Test Manager, que é uma ferramenta de gerenciamento de projeto de teste que possibilita a integração com as demais ferramentas da suite de desenvolvimento da IBM Rational. Seu uso

63 61 possibilitou um melhor gerenciamento dos resultados e a obtenção de relatórios mais específicos e detalhados. O framework AutoTest foi desenvolvido sobre a plataforma IBM Rational Functional Tester for Java and Web, uma ferramenta de automação de teste que oferece suporte somente à programação e a execução de scripts de teste. Apesar de dar suporte nativo à técnica record & playback de automação de testes, o Functional Tester usa Java como linguagem dos scripts de teste, permitindo a aplicação de técnicas mais avançadas de programação de scripts como a técnica keyword-data-driven. (FANTINATO, 2004, p.6) Teste de estresse Podemos dizer que atualmente é impensável realizar um teste de stress de forma manual. Mas como funciona? Como é possível imitar o comportamento de centenas ou até milhares de usuários? Tempo de resposta (segundos) Gargalo Número de usuários Gráfico 10 Tempo de resposta x nº de usuários (como descobrir gargalos) Fonte: Molinari (2003, p.188)

64 62 Molinari (2003, p.187) afirma que no teste automatizado de stress a ferramenta cria usuários virtuais (Vu ou Vusers Virtual User) e as situações de testes passam a ser cenários (Scenarios). Nos cenários de teste simula-se, por exemplo, uma carga de 10 usuários virtuais a cada 30 segundos até 1000 usuários e com o teste durando no máximo uma hora. Enquanto a avaliação ocorre a ferramenta registra diversas informações que podem indicar a presença de problemas durante a execução do teste, como por exemplo o aparecimento de gargalos (gra.10). Pode ser necessário um investimento adicional em hardware, dependendo da potência que se deseja atingir com o teste. Mas atenção para não confundir o desempenho do programa testado com o do servidor onde ele se encontra instalado. 3.3 FERRAMENTAS Neste tópico citaremos as ferramentas de teste e apresentaremos informações adicionais em alguns casos Suites JProbe Suite ( é um conjunto de três ferramentas, composto por: JProbe Profiler and Memory Debugger que ajuda a eliminar gargalos de execução causados por algoritmos ineficientes em códigos Java e aponta as causas de perdas de memória nessas aplicações, rastreando quais objetos seguram referências para outros; JProbe Threadalyzer, que monitora interações entre threads e avisa o testador quando essa interação representar perigo, bem como identifica potenciais perigos de concorrências e deadlocks; e JProbe Coverage, que localiza códigos não testados e mede quanto do código está sendo exercitado, permitindo ao testador estimar a confiança dos testes executados. Delamaro et al (2007, p.170). As principais suites são: SilkTest: pertence a Segue, mas a empresa é controlada pela Borland (qua.16);

65 63 Rational: IBM (qua.17); QADirector: Compuware; JProbe Suite: Quest Software; Software Comentaremos agora as ferramentas de automação. Algumas, além de automatizar testes em software também trabalham com sites web. Começaremos por uma que apresenta essa característica. A WinRunner é desenvolvida pela Mercury Interactive, mas a empresa é controlada pela HP (Hewlett-Packard). Essa ferramenta cria uma lista com as propriedades físicas juntamente com os respectivos valores de atribuição, usados para identificação de cada objeto gráfico, formando o que é chamado de descrição física do objeto. A relação entre a descrição física e o nome lógico é mantida em arquivos chamados de GuiMap (veja a razão para a criação desses mapas no item Data-Driven). A WinRunner utiliza a técnica Capture/Playback, mas as limitações referentes ao uso da MFC são resolvidas através de add-ins, isso é que possibilita o uso do WinRunner em aplicações Java, PowerBuilder, Visual Basic e aplicações Web. A ferramenta WinRunner também faz uso da técnica de script estruturado, ela possui uma linguagem estruturada, semelhante a C, chamada TSL (Test Script Language), Correia (2004, p.4). O HiperStation grava telas em seqüência num arquivo PDS que recebe um tratamento com uma linguagem de programação Rex. Ele é usado em plataforma alta e funciona com o EXTRA! Enterprise, da Attachmate Corporation. Os scripts criados no HiperStation são cadastrados no Control M.

66 64 O Control-M é responsável por iniciar e controlar todo o fluxo de jobs (processos) que serão executados dentro da periodicidade e dependências que foram cadastradas dentro dele. Carvalho (2005). A QA-Teste, desenvolvida pela empresa brasileira RSI Informática, é utilizada em plataforma baixa, para auxiliar os processos de planejamento, criação, documentação e manutenção de massa de testes. Essa ferramenta é focada no planejamento e arquitetura de teste. Ela se integra as ferramentas de automação, em particular a QA-Run, da Compuware. O uso em conjunto dessas ferramentas ocorre da seguinte forma: Geração de Massas de Dados e Scripts Padrões (QA-Teste); Filmagem e Automatização (QA-Run); Dois scripts são gerados pelo QA-Teste. No primeiro estão as definições das variáveis conforme definidas na massa de testes e o caminho do arquivo de massa de testes gerado pelo QA-Teste. Nesse arquivo também existe um loop para executar cada caso. No segundo estão às referências das variáveis definidas no primeiro. Esse é o script usado para filmagem, e posteriormente para a automatização. As ferramentas QA Wizard e e-test podem ser utilizadas exclusivamente com a técnica Record/Playback. Já as ferramentas Functional Tester, Robot, WinRunner, QuickTestPro, TestSmith 5, QA-Run e SilkTest, além da funcionalidade de gravação de scripts de teste, oferecem uma linguagem de programação permitindo que a técnica de programação de scripts seja utilizada. Nenhuma delas oferecem suporte nativo às técnicas de automação de teste data-driven e keyword-driven, não trabalham diretamente com o conceito de mapa de interface. Apesar disso, algumas dessas ferramentas oferecem certa facilidade, em diferentes níveis, no uso da técnica data-driven, Fantinato (2004, p.6). 5

67 65 Vale lembrar que Fantinato usou as técnicas data-driven e keyword-driven com a ferramenta IBM Rational Functional Tester for Java and Web através do framework AutoTest. TestMentor 6 e JFunc 7 (uma extensão funcional da ferramenta JUnit 8 usada para a automação do teste de unidade) são ferramentas de suporte a automação de teste, ambas oferecem suporte por meio da criação de classes de teste que devem interagir diretamente com as classes do sistema, sendo compiladas e ligadas juntas, Fantinato (2004, p.14). O Visual Studio Team System, da Microsoft, permite automatizar a gerência da qualidade e o SDLC (Software Development Life Cycle). Ele profissionaliza o processo de testes com um pacote de ferramentas integradas de testes unitários, cobertura de código, análise estática de código e carga, além dos recursos de gerenciamento, Microsoft (2008) Sites web O Watir tem se destacado entre as ferramentas para automação de testes em sites web. Existem vários fóruns na internet com milhares de participantes que interagem entre si tirando dúvidas e trocando dicas sobre a operação da ferramenta e da linguagem Ruby (linguagem de scripts utilizada pelo Watir). Esta popularização é um fator a mais para as empresas escolherem essa ferramenta, pois se torna mais fácil encontrar profissionais qualificados no mercado, dispensando assim o custo com treinamento. O Watir pode ser melhorado com o add-on Test-Report e a extensão WET, ambos servem para gerar relatórios dos testes. Diferente de frameworks Java, como o HttpUnit e o JWebUnit, o Watir realmente abre um browser Internet Explorer e vai JUnit Functional Testing Extension ( 8 Ferramenta para execução de testes unitários e integrados em JAVA

68 66 realizando ações, ele ainda não funciona com outros browsers. O Firefox, da Mozilla, possui uma extensão chamada Web Developer que ajuda a implementar os testes funcionais, Papo (2005). A ferramenta ReWeb é usada para obter e analisar as páginas da aplicação web, gerando a instância do metamodelo UML. O TestWeb gera e executa o conjunto de casos de teste, conforme a instância do metamodelo UML gerado pela ReWeb e o critério de teste que será empregado. Após a execução dos casos de teste, o testador avalia os resultados obtidos, isto é, verifica se a saída obtida está correta para determinada entrada. A ferramenta também fornece uma saída numérica especificando o nível de cobertura alcançado pelo conjunto de teste. A ferramenta denominada WAT (Web Application Testing), implementa as funções necessárias à geração de casos de teste, execução do conjunto gerado e avaliação dos resultados obtidos com o processamento. A WAT utiliza a análise estática de uma aplicação web resultante da execução da ferramenta WARE, que realiza engenharia reversa da aplicação. Delamaro et al (2007, p ). O Fitnesse liga uma página web de um wiki ao seu sistema sob teste, através de classes de negócio ou da interface do usuário. Esse modo de trabalho aumenta a colaboração entre clientes e os desenvolvedores do sistema. Um projeto que possui a filosofia data-driven e não a record/playback é o da ferramenta Canoo WebTest. Ela utiliza como fundamento o HtmlUnit e os testes são escritos através de arquivos XML, Papo (2005) Estrutural A aplicação de critérios de teste sem o apoio de ferramentas automatizadas tende a ser uma atividade propensa a erros e limitada a programas muito simples. (DELAMARO ET AL, 2007, p.65).

69 67 A RXVP80 e a TCAT, apóiam a aplicação de critérios estruturais baseados somente no Grafo de Fluxo de Controle. A ferramenta RXVP80, distribuída pela General Research Corporation, é um sistema que realiza basicamente a análise de cobertura do teste de arcos em programas escritos em Fortran. A ferramenta TCAT (Test-Coverage Analysis Tool), distribuída pela Software Research Corporation, realiza o teste de unidades segundo o critério Teste de Ramos Lógicos (arcos). A ferramenta SCORE apóia o teste de arcos de programas escritos em Pascal, tendo sido desenvolvida na Hitachi. A POKE-TOOL (Potential Uses Criteria Tool for Program Testing) apóia a aplicação de critérios no teste de unidade de programas escritos na linguagem C e encontrase disponível em ambiente UNIX. A versão mais recente está disponível na Incubadora Virtual da FAPESP ( Delamaro et al (2007, p.65-69) Mutação Para apoiar o teste de mutação em POO, Alexander et al (apud DELAMARO ET AL, 2007, p.172), propuseram a arquitetura de uma ferramenta, denominada Object Mutation Engine OME, que implementa um subconjunto dos operadores de mutação no teste de classes Java. A Mutation Testing System implementa parte do conjunto de operadores de mutação. A ferramenta utiliza o framework JUnit para documentar e executar de forma automática os casos de teste, determinando o número de mutantes mortos e o escore de mutação obtido, Delamaro et al (2007, p.173).

70 68 A ferramenta Mothra foi desenvolvida por pesquisadores da Purdue University e do Georgia Institute of Technology e é utilizada em programas Fortran 77, Delamaro et al (2007, p.97). A Proteum é similar à Mothra, porém destina-se a linguagem C e possui algumas facilidades para processamento bacth, Delamaro et al (2007, p.98-99) Orientados a objetos e de componentes A seguir será apresentada uma breve descrição, parcialmente extraída do trabalho de Domingues (apud DELAMARO, 2007, p ), é uma série de ferramentas comerciais e não comerciais que se encontram disponíveis para o teste de POO e algumas também destinadas ao teste de componentes, principalmente para o teste de programas escritos em C++ e Java. A ferramenta de teste PiSCES (Coverage Tracker for Java) é utilizada em teste de applets Java. PiSCES é uma ferramenta de medida de cobertura (comandos e decisões) que identifica quais partes do código-fonte já foram exercitadas durante a avaliação e quais ainda precisam ser. TCAT/Java e JCover servem para cobertura de comandos e decisões para applets Java. Parasoft C++ Test é utilizada em teste de unidade para códigos C/C++. Parasoft Insure++ trabalha na detecção de defeitos em tempo de execução para códigos C/C++ e acelera as tarefas de depuração. ProLint Advanced Graphical Lint verifica os módulos de uma aplicação com o objetivo de encontrar defeitos e inconsistências para mais de 600 tipos de problemas, proporcionando maior confiabilidade e portabilidade de códigos C/C++.

71 69 Rational PureCoverage faz análise de cobertura (comandos e decisões) para códigos C++ e Java. Rational Purify detecta defeitos em tempo de execução para códigos C/C++. Como a Rational PureCoverage, essa ferramenta permite ao testador escolher o nível de verificação por módulos. JaBUTi seu diferencial é a não-exigência da disponibilidade do código-fonte para a realização dos testes. A ferramenta trabalha diretamente com bytecode Java e apóia a aplicação dos critérios Todos-Nós, Todas-Arestas, Todos-Usos e Todos- Potenciais-Usos no teste intramétodos. Component Test Bench (CTB), pode ser utilizada no teste de componentes de software. A ferramenta fornece um padrão genérico que permite ao desenvolvedor do componente especificar o conjunto de teste utilizado na avaliação de um dado componente. O conjunto de teste é armazenado em um arquivo XML (extensible Markup Language) e executado por meio de uma ferramenta que compõe o CTB, denominada IRTB (Instrumented runtime system), ou eles podem ser executados invocando-se a execução de uma máquina virtual Java, ou ainda, compilando e executando programas em C ou C++. Parasoft JTest testa classes para códigos Java. A principal diferença entre JTest e CTB é que JTest utiliza o framework JUnit para armazenar e executar os casos de teste automaticamente, enquanto CTB armazena os casos em arquivos XML. Glass JAR Toolkit (GJTK) é uma ferramenta de teste de cobertura que opera diretamente no bytecode Java e não requer o código-fonte para aplicar critérios de fluxo de controle (cobertura de comandos e decisões) em bytecode Java. Nas ferramentas que permitem avaliação de cobertura de código por meio de critérios estruturais, todas apóiam somente o teste de fluxo de controle (cobertura de comandos e decisão) em POO. Nenhuma delas apóia a aplicação de algum critério de fluxo de dados, seja para o teste de unidade, integração ou sistema. Com exceção da ferramenta GlassJAR e as que apóiam o teste funcional, todas as

72 70 demais necessitam do código-fonte para a aplicação dos critérios, dificultando sua utilização no teste estrutural de componentes de software por parte dos clientes, que em geral, não têm acesso ao código-fonte Orientados a aspectos A ferramenta JaBUTi/AJ é uma extensão da ferramenta Java Bytecode Understanding and Testing (JaBUTi) proposta para o teste de POO escritos em Java. JaBUTi/AJ foi estendida para testar a estrutura das unidades de programas OA (orientados a aspectos) escritos em AspectJ, utilizando os modelos e critérios descritos na seção anterior, Delamaro et al (2007, p.198) Concorrentes Segundo Delamaro et al (2007, p ), a maioria das ferramentas existentes auxilia a análise, a visualização, o monitoramento e a depuração de um programa concorrente. Exemplos dessas ferramentas são: TDCAda que apóia a depuração de programas na linguagem ADA, utilizando execução determinística; ConAn (ConcurrencyAnalyser), que gera drivers para o teste de unidade de classes de programas concorrentes Java; e Xab, MDB e Paragraph para programas escritos em ambiente de passagem de mensagens. Xab e Paragraph objetivam o monitoramento de programas PVM e MPI, respectivamente. A ferramenta Della Pasta (Delaware Parallel Software Testing Aid) permite o teste de programas concorrentes com memória compartilhada. STEPS e Astral são ferramentas que apóiam a visualização e a depuração de programas PVM. Ambas geram caminhos para cobrir elementos requeridos por critérios estruturais baseados em fluxo de controle.

73 71 ValiPar permite que programas em diferentes ambientes de passagem de mensagens sejam testados. Atualmente, a ferramenta encontra-se configurada para PVM e MPI. Quadro 11 Ferramentas de teste/depuração para programas concorrentes Ferramenta Fluxo de dados Fluxo de controle Execução controlada Depuração TDC Ada a ConAn b Della Pasta c Xab d Visit d MDB d STEPS d Astral d XMPI e Umpire e ValiPar d, e a Ada, b Java, c Shmem, d PVM, e MPI Fonte: Delamaro et al (2007, p.249) O quadro 17 sintetiza as principais características das ferramentas existentes para apoiar a atividade de teste de programas concorrentes Open Source Nos tópicos anteriores também foram citadas ferramentas gratuitas para automação de testes. Citaremos mais algumas, adicionando comentários as já citadas. PMD é utilizada para auditoria de código fonte Java; Selenium é uma ferramenta GE para sites web; Fitnesse e o Watir, trabalham respectivamente com tabelas e palavras-chave; Jmeter faz avaliação de desempenho. JUnit é um framework de teste que vem sendo muito utilizado e viabiliza a documentação e a execução automática de casos de teste. Quando se analisa o Anexo O observa-se que o framework JUnit é uma das ferramentas que pode ser utilizada tanto para o programa quanto para o teste de componentes de software

74 72 desenvolvidos em Java, mas tal ferramenta apóia apenas a execução automática de casos de teste e realização de testes funcionais, sem apoio de nenhum critério de teste específico e não fornecendo informação sobre a cobertura de código obtida por determinado conjunto de teste. Outra ferramenta que também apóia somente o teste funcional é a CTB, Delamaro et al (2007, p.171 e 173) Faça você mesmo Não existindo a intenção de produzir um produto melhor para o mercado, não há motivo para reinventar a roda. Além dos custos com o desenvolvimento da aplicação outros gastos irão surgir, como por exemplo, os gastos com treinamento, pois não há conhecimento no mercado sobre a ferramenta e também não haverá fóruns na internet com dicas sobre o produto. Caso a empresa decida optar pelo desenvolvimento de uma nova ferramenta, ela pode começar pelo estudo da API (Application Programming Interface ou Interface de Programação de Aplicativos) que representa um conjunto de operações expostas por uma aplicação, a fim de permitir que outras aplicações possam acessar ou consumir as suas funcionalidades, esse recurso será útil na criação de ferramentas captura/executa. A técnica de automação OLE também pode ser usada, porém esse recurso necessita que o desenvolvedor especifique com qual aplicação a ferramenta deve estabelecer um vínculo. O objetivo de uma API é fornecer uma interface para o mundo exterior que não seja dependente da interface gráfica da aplicação. A automação de testes baseada na API faz uso dessa característica para orquestrar a execução dos testes. Uma das vantagens advindas do uso de uma API é que a aplicação externa que consome as operações expostas, não precisa conhecer em detalhes como essas operações são implementadas. (CAETANO, 2007). Caso a ferramenta seja desenvolvida para avaliar sites web é mais adequado analisar o resultado do conteúdo do arquivo e não o que é apresentado na tela. Por exemplo, um GIF pode ficar mudando sua aparência, mas uma instrução <IMG SCR= arquivo.gif > será sempre a mesma.

75 73 CONSIDERAÇÕES FINAIS Com o resultado dessa pesquisa passamos a conhecer os problemas da imprecisão e morosidade dos testes manuais em contra ponto ao aumento do tamanho e da complexidade dos programas. Conhecemos também os vários tipos de testes e examinamos as principais técnicas utilizadas na automação. Identificamos que a muito a se considerar em um processo de testes e que devemos planejá-los desde o início do projeto de desenvolvimento, como também a necessidade de uma prévia estruturação de todo o processo (técnicas, frameworks, ambientes, baselines, etc). Esperamos que essa pesquisa tenha contribuído para orientação daqueles que estão iniciando seu caminho em testes e que ela possa poupar seus esforços na busca pela informação. Fizemos um levantamento sobre ferramentas para todos os bolsos, mas esperamos tê-lo conscientizado de que nem sempre esse é o principal custo de toda a operação e a busca pelo equilíbrio entre os pilares custo, prazo e qualidade irá acompanhá-lo em seu dia-a-dia na área de testes. Vimos que a oferta das ferramentas, sob a estratégia caixa-branca, é determinada pela linguagem usada no desenvolvimento e que a estratégia caixa-preta pode oferecer soluções conjuntas para software e sites web. Também recomendamos a escolha de ferramentas que possam combinar as técnicas de capture/playback, data-driven, keyword-driven e scripts, seja com ou sem o uso de frameworks, além de chamar a atenção para o refinamento e reutilização dos scripts e dos casos de testes, como também para o futuro da técnica modelo de dados. Identificamos a importância das ferramentas para geração automática de casos e massa de teste e para os testes de stress. Por último, sugerimos uma visita ao BSTQB ( este órgão apresenta em seu site o material necessário à certificação de profissionais de teste, e leitura dos artigos sobre testes da Java Magazine e da recém lançada revista Testing Experience (

76 74 REFERÊNCIAS BIBLIOGRÁFICAS ARGOLLO, Miguel. Automação de testes: Características, vantagens e limitações. Trabalho apresentado durante o SBQS 2008 VII SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, Florianópolis, jun BARTIÉ, Alexandre. Garantia da qualidade de software: Adquirindo maturidade organizacional. Rio de Janeiro: Elsevier, BORLAND. Automação de testes de software. [S.l.]: Borland, Disponível em: < on.html>. Acesso em: 10 ago. 2008, 12:13:40.. Gerenciamento da qualidade do ciclo de vida. [S.l.]: Borland, Disponível em: < Acesso em: 31 ago. 2008, 11:50:45. BRITO, Rosane Deganeli de. Do ambiente de desenvolvimento ao ambiente de produção: Os testes de software como garantia da qualidade. Osasco: Universidade Cândido Mendes, CAETANO, Cristiano. Automação e gerenciamento de testes: Aumentando a produtividade com as principais soluções Open Source e gratuitas (2a edição). [S.l.]: Linha de Código, Disponível em: < x?id=1566>. Acesso em: 10 ago. 2008, 12:12:24.. Introdução à automação de testes funcionais. [S.l.]: TestExpert, Disponível em: < Acesso em: 10 ago. 2008, 12:02:26. CALLERI, Mário. Qualidade de software no desenvolvimento de sistemas corporativos. Rio de Janeiro: Centro Educacional de Realengo, CARVALHO, Cláudio et al. Apresentação EPD: Disciplina de teste. Rio de Janeiro: REDEA/RJ, 31 mar CARVALHO, Cláudio; FILHO, Francisco de J.R. Automação dos processos de testes. Rio de Janeiro: REDEA/RJ, 16 nov CORREIA, Simone; SILVA, Alberto. Técnicas para construção de testes funcionais automáticos. [S.l.]: Instituto Português de Qualidade, Disponível em: < Acesso em: 13 set. 2008, 14:58:32. DELAMARO, Márcio Eduardo; MALDONADO, José Carlos; JINO, Mario. Introdução ao teste de software. Rio de Janeiro: Elsevier, EUDESCOSTA. Automação de testes, uma tendência. [S.l.]: TestExpert, Disponível em: < Acesso em: 14 set. 2008, 21:52:12.

77 75 FANTINATO, Marcelo et al. AutoTest Um framework reutilizável para a automação de teste funcional de software. [S.l.]: SBC Sociedade Brasileira de Computação, Disponível em: < 55>. Acesso em: 10 ago. 2008, 12:03:26. HETZEL, William. Guia completo ao teste de software. Rio de Janeiro: Campus, IBM. Gerenciamento de qualidade de software. [S.l.]: IBM, Disponível em: < ry=j107030v33347x46>. Acesso em: 31 ago. 2008, 11:56:30. MENDES, Alvaro. Novo ASC [mensagem pessoal]. Mensagem recebida por <redearj114@mail.caixa> em 25 ago MICROSOFT. Test Edition. [S.l.]: Microsoft, Disponível em: < crosoft.com/pt-br/library/ms aspx>. Acesso em: 31 ago. 2008, 11:54:30.. Usando automação de interface do usuário para testes automatizados. [S.l.]: Microsoft, Disponível em: < /ptbr/library/aa aspx>. Acesso em: 16 ago. 2008, 19:57:40. MOLINARI, Leonardo. Testes de software: Produzindo sistemas melhores e mais confiáveis. São Paulo: Érica, OSHIRO, Ângela dos Santos. Gerência de projetos. Vila Velha: Escola Superior Aberta do Brasil, PAPO, José Paulo. Ferramentas para automação de testes. [S.l.]: José Papo Weblog, Disponível em: < tas-para-automao-de-testes.html>. Acesso em: 10 ago. 2008, 11:59:28. RSI Informática. Uso da ferramenta QA-Teste para controlar massas de teste. Rio de Janeiro: REDEA/RJ, dez UNGARELLI, Adriano. Teste de software como controle de qualidade. [S.l.]: Via6, Disponível em: < Acesso em: 31 ago. 2008, 12:00:20. WIKIPÉDIA. Código aberto. [S.l.]: Wikipédia, Disponível em: < Acesso em: 17 ago. 2008, 13:56:44.

78 76 GLOSSÁRIO Varias das definições a seguir foram extraídas do site Wikipédia ( Add-On ou Add-In é o nome que se dá a um recurso ou acessório que melhora ou aperfeiçoa a coisa à qual ele é acrescentado em utensílios eletrônicos. A expressão é usada para softwares e hardwares em geral, mas é bastante típica de jogos para computador (ou videogames) e consolas para videojogos. Análise estática a idéia é a mesma da auditoria de código, trata-se de uma verificação da estrutura do código e das nomenclaturas de variáveis, funções, objetos, entre outras atividades. Bug Defeito, falha no software ou site. Engenharia reversa elaborar a documentação de um sistema a partir dele próprio (da operação do programa concluído). Framework captura a funcionalidade comum a várias aplicações. Elas devem pertencer ao mesmo domínio de problema. Grafo de Fluxo de Controle é a representação usual para a relação de fluxo de controle de um programa. Essas relações de dependências determinam a seqüência necessária entre operações. Hands-On - usar o programa propriamente dito. Hard-Coded é a inserção de dados diretamente pelo usuário em um programa. Kaizen - significa de melhoria contínua, gradual, na vida em geral (pessoal, familiar, social e no trabalho).

79 77 NewsGroups são grupos de discussão on-line, o mesmo que fóruns, onde os internautas com interesses em comum se juntam para falar de tudo, desde software até política. Open Source Código Aberto. Software gratuito. O termo código aberto, ou open source em inglês, foi cunhado pela OSI (Open Source Initiative) e se refere ao mesmo software também chamado de software livre, ou seja, aquele que respeita as quatro liberdades definidas pela Free Software Foundation. Polimorfismo permite que métodos apresentem várias formas, de acordo com seu contexto. Por exemplo, quando podemos usar sorvete.cobertura(caldadechocolate) no lugar do comando sorvete.cobertura(caldadechocolate, granulados) e vice-versa. Post - essa palavra aparece no texto com o mesmo sentido de blog, Blog é uma página web atualizada freqüentemente, composta por pequenos parágrafos apresentados de forma cronológica. REDEA/RJ Uma das divisões da Caixa Econômica Federal responsável por desenvolver e manter as soluções tecnológicas da instituição financeira. Release pequena atualização do programa. Wiki são utilizados para identificar um tipo específico de coleção de documentos em hipertexto ou o software colaborativo usado para criá-lo.

80 78 ANEXO A ESTRATÉGIAS DE TESTE CAIXA-BRANCA CAIXA-PRETA Figura 7 Estratégias de testes caixa-branca e caixa-preta