ANÁLISE DO PROCESSO DE TESTE DE SOFTWARE NA IMPLANTAÇÃO DE ERP SAP COM E SEM O USO DA FERRAMENTA DE AUTOMAÇÃO DE TESTES ECATT

ANÁLISE DO PROCESSO DE TESTE DE SOFTWARE NA IMPLANTAÇÃO DE ERP SAP COM E SEM O USO DA FERRAMENTA DE AUTOMAÇÃO DE TESTES ECATT Aline Vieira Malanovicz (UFRGS ) malanovicz@gmail.com Chana Michelli Brum Guillen (UFRGS ) michelliguillen@gmail.com O objetivo desta pesquisa é analisar o processo de testes de software, no caso da implantação do sistema ERP R/3 da SAP, utilizando a ferramenta de automação de testes ecatt (Extended Computer Aided Test Tool), descrevendo seu uso com um exemplo e analisando suas vantagens e desvantagens, em comparação com o método de teste manual. Foi possível verificar detalhes da tentativa de adequação da prática à teoria e as dificuldades encontradas pelos testadores no diaa-dia dos testes na empresa pesquisada. Percebeu-se que a decisão quanto a automatizar ou não um projeto de testes deve analisar fatores além da simples redução de tempo e custo da execução dos testes, pois, embora significativa, a redução de tempo da Execução Automatizada versus Execução Manual não se refletiu no tempo total do processo de testes (exigiu muito mais tempo na fase de preparação dos ambientes, pacotes e demais objetos). Sua importância maior foi a de permitir executar todos os testes e evitar o problema de descartar alguns por falta de tempo ou prazo, e permitir reutilizar dados em caso de necessidade de novos testes. Foi possível concluir que todo o tempo e esforço investido na etapa de planejamento, organização, replanejamento e alterações, para maior cobertura dos casos de testes, refletiram-se em vantagens na abrangência dos casos de teste, na modularidade dos casos para posterior possibilidade de reuso dos casos em combinações; no número de erros detectados (e corrigidos e retestados), enfim, na melhor qualidade do sistema implantado. Conclui-se que a ferramenta ecatt analisada parece adequada para a execução das atividades de testes dos processos da empresa pesquisada, e a análise da aplicação da ferramenta para outros processos da mesma empresa, especialmente aqueles que necessitam de testes com repetições de valores variáveis, como, por exemplo, o processamento do cálculo de valores para pagamentos, configura uma possibilidade de pesquisa futura suscitada por este trabalho. Palavras-chaves: teste de software, automação de teste, ferramentas de automação de teste, ecatt

1. Introdução A qualidade de produtos é definida de maneira mundialmente padronizada pela Norma ISO/IEC 9126 como tendo as características de Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, e Portabilidade. No caso de produtos de software, uma decisão estratégica é a adoção do processo de garantia de qualidade e confiabilidade (Software Quality Assurance), que inclui um conjunto de atividades técnicas aplicadas durante todo o processo de desenvolvimento, para garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam os níveis de qualidade especificados (AMMANN; OFFUTT, 2008). Algumas falhas de software (bugs) levaram à ocorrência de desastres que viraram notícia, incluindo mortes na queda de aviões, lesões corporais por overdose de radiação, explosão de foguetes, danos em sondas espaciais, cancelamentos e atrasos em voos de companhias aéreas, cobranças incorretas realizadas por bancos. Considerando que as falhas são inerentes ao software, pode-se dizer que o Teste de Software ajuda a garantir que a detecção de erros seja efetiva, de modo que o software terá menos defeitos latentes, maior confiabilidade (resultando em maior satisfação do cliente), custo do ciclo de vida global reduzido, e custos de manutenção possivelmente reduzidos (PEZZE; YOUNG, 2008). Para a melhor eficiência da atividade de testes de software, a automação tem sido vista como a principal medida, comparativamente com a execução manual (VELOSO et al., 2009). Um exemplo de ferramenta de Automação de Testes é a ecatt (Extended Computer Aided Test Tool) (SAP, 2011). Existe consenso entre os especialistas quanto aos ganhos que podem ser alcançados com a adoção de uma estratégia de automação de teste de software. Entretanto, as empresas que usufruem desta tecnologia frequentemente enfrentam dificuldades em avaliar o real benefício que está sendo alcançado com o investimento realizado (FANTINATO et al., 2005; FEWSTER, 2001). Embora possam ser importantes para entregar soluções de tecnologia com alta qualidade, são poucos os trabalhos de pesquisa que relatam avaliações comparativas entre diferentes métodos de teste (VELOSO et al., 2009; DÓREA et al., 2008; CAETANO, 2007; NÓBREGA, 2006; FANTINATO et al., 2005; ROBINSON, 2001). Assim, pode-se dizer que a análise dos benefícios e dificuldades do uso de uma ferramenta de automação constitui um interesse acadêmico para pesquisa e um interesse prático para empresas. 2

O objetivo desta pesquisa é analisar o processo de testes de software, no caso da implantação do sistema ERP R/3 da SAP, utilizando a ferramenta de automação de testes ecatt, descrevendo seu uso com um exemplo e analisando suas vantagens e desvantagens, em comparação com o método de teste manual. A Seção 2 deste trabalho apresenta os principais conceitos sobre Teste de Software utilizados nesta pesquisa, incluindo uma breve descrição da ferramenta ecatt. O método da pesquisa é descrito na Seção 3. A Seção 4 apresenta o Estudo de Caso realizado, descrevendo como é o processo de teste com a execução manual e com a execução automatizada. A Seção 5 demonstra a análise dos resultados do trabalho fazendo uma comparação entre os métodos e apontando prós e contras, benefícios e limitações. A Seção 6 resume as conclusões desta pesquisa e indica possíveis investigações adicionais suscitadas por este trabalho. 2. Teste de software Teste de Software consiste em definir um conjunto de entradas, executar um pedaço do software, e monitorar o estado, as saídas e propriedades do software e compará-los com o resultado esperado (AMMANN; OFFUTT, 2008; FEWSTER, 2001). Espera-se ter o conjunto de casos de teste possíveis com maior probabilidade de encontrar a maioria dos erros (MYERS, 2004). Um Caso de Teste é o conjunto de dados de entrada, condições de execução de uma ou mais operações, e resultados esperados ou dados de saída, para um objetivo particular. O projeto dos casos de teste e a preparação dos dados de teste são fundamentais no projeto de teste, pois todas as atividades de teste baseiam-se na escolha de bons casos de teste (AMMANN; OFFUTT, 2008). Quanto à forma de Execução, os testes podem ser Manuais ou Automáticos. Testes Manuais são aqueles que podem ser executados manualmente pelos testadores, sendo cada resultado armazenado manualmente, sem utilizar ferramentas de automação. Testes Automáticos são aqueles executados por ferramentas automatizadas, sendo cada resultado armazenado automaticamente pela ferramenta de teste, e podendo reutilizar os Casos de Teste em outros planos de testes (SAP, 2011). Assim, a Automação de Testes pode ser definida como o uso de software para controlar a execução do teste de software, a comparação dos resultados esperados com os resultados reais, a configuração das pré-condições de teste e outras funções de controle e relatório de teste. É adotada para reduzir custos e acelerar a execução dos testes. 3

Uma Ferramenta de Automação de Testes é um software que executa Scripts de teste (Executable Test Script), que são casos de teste implementados de forma a serem executados automaticamente no sistema em teste e a gerar relatórios dos testes. Um exemplo de ferramenta de automação de testes é a ecatt (Extended Computer Aided Test Tool), da empresa SAP, utilizada para Execução de Testes de implantação dos módulos do sistema ERP-SAP-R/3 (SAP, 2011). 2.1. Processo de Testes no SAP A Ferramenta de Testes da SAP (SAP Test Workbench) suporta o processo de Organização dos Testes; criação dos Planos de Teste e Pacotes de Teste; amarração dos pacotes de teste aos usuários testadores; monitoração e a análise de status; administração de mensagens de problemas; administração e acompanhamento de erros. A Organização dos Testes Automáticos é gerenciada no ambiente da transação SECATT, que inclui editores de configuração, de script de teste, de dados de teste e de dados de sistema. A Execução dos Testes é feita pela transação STWB_WORK (SAP, 2011). Desse modo, o Processo de Testes é organizado nas seguintes fases (SAP, 2004) (Figura 1): Figura 1 Processo de Teste no SAP: Definição de Casos, Planos, Pacotes, Execução e Análise Fonte: SAP (2011) Definição do conjunto de Casos de Teste (Test-Cases) (estrutura de processos de projeto com as descrições dos dados de testes associados (manuais ou ecatt) e os scripts para 4

os testadores seguirem, ou seja, definição de o que se quer testar (STWB_2), e Preparação do sistema de testes e dos sistemas a serem testados (STWB_2); Seleção dos Planos de Teste (Test-Plans) (conjuntos de todos os Casos de Teste (manuais ou ecatt) e transações exigidos para uma fase de teste específica) (STWB_2); Criação dos Pacotes de Teste (Test-Packages) (conjuntos baseados em um Plano de Teste, com todos os Casos de Teste atribuídos para um ou mais testadores) (SPRO IMG), Sequenciamento e Amarração dos Pacotes de Teste aos Testadores (STWB_2 e SPRO IMG); Execução dos Testes (Manuais ou ecatt) (STWB_WORK e SECATT); Análise dos Testes (relatórios gráficos e/ou logs ecatt) (STWB_2 ou SOLAR_EVAL). 2.2. ecatt A ferramenta ecatt é utilizada para criar e executar testes funcionais automatizados de software de processos de negócio dos sistemas da empresa SAP (SAP, 2014). A ferramenta permite testar transações, relatórios e cenários, chamar módulos de funções, testar sistemas remotos, verificar autorizações dos perfis de usuários, atualizações de bancos de dados, aplicações e interfaces de usuário, verificar mensagens de sistema e testar o efeito de mudanças de configurações customizáveis (SAP, 2011). A ferramenta permite criar testes modulares ou unitários que podem ser combinados com outros módulos para representar processos inteiros de negócios, e permite criar testes de processos de negócio end-to-end para processos que abrangem múltiplos sistemas ou módulos internos do ERP SAP (SAP, 2004). Os testes podem ser iniciados manualmente ou programados para execução regular, e cada teste gera um log detalhado que documenta o processo de teste e resultados (SAP, 2014). As atividades de teste de cada configuração de teste executada são documentadas na forma de logs que registram permanentemente e detalhadamente todo o teste, de modo que o Histórico de cada teste é mantido. Relatórios de Teste para monitoração e acompanhamento oferecem uma visão detalhada do progresso dos testes e de seus resultados, com gráficos e relatórios para todos os Planos de Teste de um projeto, descrevendo cada Caso de Teste utilizado, quem o testou, o resultado, as evidências de teste, e eventuais chamados abertos, e podem ser exportados para outros formatos, para análise e auditoria (SAP, 2014). 5

A ecatt estrutura o teste (Figura 2) e exige que sejam criados em objetos separados: Dados de Sistema, Dados de Teste, Script de Teste, e Configuração de Teste (SAP, 2004). Figura 2 Estrutura de Teste com ecatt Fonte: SAP (2014) A Configuração de Teste (/AIF/TEST_ECATT_CONFIG_TMPL) combina o componente de aplicação (MM, ECC, etc.), o Script de teste (Test Script Editor), o Container dos Dados do teste (/AIF/TEST_ECATT_DATA_TMPL) e o Container dos Dados do sistema (SECATT) para cada execução e seleciona os Casos de Teste utilizados na execução. O Catálogo de Testes (STWB_1) une várias Configurações, que permitem agrupar Casos de Teste com diferentes sistemas de destino, e cada Plano de Teste (STWB_2) inclui pelo menos um Catálogo de testes e é incluído em um Pacote de testes, necessário para criar execuções de teste programadas. A criação de um Caso de Teste válido exige parâmetros como (SAP, 2014): Estrutura de Dados de Origem: deve ser preenchida com os dados de origem; Estrutura de Dados de Destino: preenchida com os dados de origem e depois alterada; Log de Exibição: exibe o log de resultados de aplicação da interface atual; Tabela de Valores Previstos: mostra o valor na estrutura de origem e o valor previsto; Tabela de Mensagens Previstas: permite uma mensagem para cada situação de teste. O módulo exibe no log os resultados do status do processamento e as tabelas de mensagens exibidas e de valores previstos: confirmados (verde) ou divergentes (vermelho) (SAP, 2014). 6

3. Método Esta pesquisa tem caráter exploratório e de natureza qualitativa, pois objetiva a descrição aprofundada de um exemplo real prático de aplicação de uma ferramenta de testes, com uma avaliação de prós e contras. Faz-se uma análise intensiva de uma situação particular, em que se coloca questão tipo como e o foco está em um processo inserido em um contexto da vida real, por isso a opção é pelo método de pesquisa denominado Estudo de Caso (YIN, 2005). O caso selecionado é o processo de teste de software realizado ao longo da implantação do sistema integrado de gestão SAP R/3 em uma empresa do ramo financeiro. Nos últimos cinco anos, a empresa conduz um projeto que objetiva migrar os sistemas para uma plataforma mais moderna, mudando o foco para os processos de trabalho, para obter ganhos de eficiência e de produtividade. Organizações com uso intensivo de tecnologia de informação, como é o caso das instituições financeiras, dependem intensamente (pode-se dizer estrategicamente) da exatidão e da eficiência de seus sistemas de informação. Por isso a elevada importância de reduzir o risco de erros de sistema, utilizando-se, entre outros métodos, os testes de software. A coleta de dados foi realizada por meio de técnicas como consulta documental ao material de treinamento da SAP, entrevistas com a equipe de testes, e análise de artefatos como resultados de testes, sistemas, telas, tutoriais, além da observação participante do dia-a-dia do processo (BAUER; GASKELL, 2002; YIN, 2005). A análise de dados foi realizada pela comparação entre a execução manual do teste de software com a execução automatizada via ferramenta ecatt do mesmo conjunto de casos de teste. 4. Estudo de Caso A implantação de novos módulos do sistema ERP SAP na empresa pesquisada foi uma situação que exigiu testes funcionais, tanto unitários (de uma única funcionalidade/transação), quanto integrados (envolvendo sequências de transações relacionadas a vários cenários de negócios). Uma empresa de consultoria especializada responsável por essa implantação, foi, no momento dos testes, responsável pela organização dos sistemas e ambientes. Funcionários da empresa pesquisada fizeram a elaboração de cenários de teste relevantes, e também atuaram como testadores de transações individuais (testes unitários) e dos testes integrados. 7

O Escopo dos Casos de Teste enfocou os processos de Aquisições&Contratos, Adiantamentos; Contas a Pagar; Gestão Contábil e Gestão Tributária. Com base nos testes unitários desses processos, os funcionários da empresa (testadores) realizaram a elaboração de cenários para execução dos testes integrados, buscando contemplar uma ampla cobertura de possibilidades, de acordo com os critérios e necessidades da empresa. Assim, por exemplo, o cenário TI-C2-046 (Figura 3) contempla transações dos processo de Aquisições& Contratos, Contas a Pagar e Gestão Contábil. Além disso, foram efetuados cadastros de fornecedores Pessoa Física e Pessoa Jurídica, cadastros de Materiais e Serviços, lançamento de Notas Fiscais de Serviços e de Materiais, buscando-se diversificar Notas Fiscais com e sem retenções de tributos e com diferentes alíquotas de impostos para verificar a integração entre todos os processos testados com os demais, por exemplo tributos com contas a pagar, e contas a pagar com contabilidade. Figura 3 Execução Manual de Testes no SAP-SolMan Fonte: coleta de dados Os consultores prepararam o sistema SAP no ambiente QAS (Quality Assurance System) para todas as funções de sistemas relevantes para os testes (SOLAR_PROJECT_ADMIN). A estrutura de processos do projeto (cenários de negócios, processos e etapas), definida no SAP SolMan, serviu como base para a criação dos Planos de Teste (SOLAR01 Business Blueprint). Foram criados scripts de teste (manuais, descritos no MSWord, e automatizados, em linguagem 8

ABAP para ecatt), para diferentes processos, com cenários variantes descritos em planilhas do MSExcel. Esses Casos e scripts de teste preparados foram configurados e associados aos cenários correspondentes no SolMan (SOLAR02 Configuração). Assim, os Casos de teste, transações, cenários, processos e etapas foram associados a cada item da estrutura de processos contemplada pelo Plano de testes (SolMan STWB_2). Os consultores também criaram Pacotes de testes, ligando as transações a cada Testador (funcionário da empresa) e definindo sequências adequadas para os testes, conforme os processos (SolMan STWB_2 e SPRO IMG). Os registros da Execução Manual dos Testes foram efetuados no SAP-SolMan pelos funcionários da empresa, incluindo Registros de Issue ou Mensagem de Erro e as Evidências dos Testes. Cada testador acessou sua lista de trabalho (STWB_WORK) com seus Pacotes, leu os Casos de Teste, executou o script manual das transações necessárias do sistema, conferiu os resultados dos testes, gravou uma Evidência de Teste para cada caso testado; e atualizou o status de cada caso de teste (Não testado, OK, OK com restrição, Incorreto: teste posterior necessário) conforme sua avaliação dos resultados dos testes. Os consultores puderam monitorar o andamento dos testes via relatórios de progresso e resultados também no SolMan. Um consultor ficou responsável pela Análise dos Relatórios de teste: acessar os cenários de teste, verificar o status atribuído pelo usuário e, no caso de haver status Incorreto ou OK com restrição, demandar o consultor responsável pelo desenvolvimento e correção do problema. Uma vez corrigido o problema apontado, modificava-se o status para Liberado para re-teste. Entretanto, houve problemas na determinação do status, pois o que foi considerado como Incorreto pelos testadores muitas vezes foi considerado OK com restrição pelos consultores, resultando em tratamento diferenciado pela consultoria, sendo considerado uma situação de melhoria e não de erro, e por isso não sendo resolvido de imediato. Outro problema encontrado foi a necessidade de repetir o cenário de testes inteiro para re-testar determinada transação. Por exemplo, se o registro foi gerado incorretamente no processo de Contabilidade, foi necessário a repetição das transações dos processos de Aquisições e Contratos, e de Contas a Pagar. A Execução Automatizada dos testes na ferramenta ecatt (Figura 4) seguiu o mesmo processo de teste na fase de organização. As mudanças ocorreram na fase de elaboração de scripts, que para o caso automatizado foram escritos em linguagem de script pelos consultores especializados. 9

A execução propriamente dita foi realizada por funcionários da área de informática da empresa, e a análise dos resultados foi feita em conjunto com funcionários-chave dos processos correspondentes. Para o teste automatizado, os consultores criaram Test Configurations (Configurações de Teste), juntando dados de teste, dados de sistema, e scripts de teste. Figura 4 Execução Automatizada de Testes no ecatt: (a)configuration (b)script (c)log (a) (b) (c) Fonte: coleta de dados Na transação SECATT, foram criados System Data Containers (objetos de dados de sistema) que configuraram como target systems os módulos MM e ECC (Administração de Materiais e módulo principal do sistema ERP SAP). Os Test Scripts (comandos de teste executáveis) foram elaborados com base no processo de gravação (recording) da sequência de transações do teste (criação de cenários TCD e Test Script Editor). As transações foram executadas do mesmo modo 10

como em um teste manual, porém uma única vez, e gravadas para serem reutilizadas na automação. Os Test Data Containers (objetos de dados de teste) foram criados com base na importação dos Casos de teste (cenários) elaborados pelos funcionários, de planilhas do MSExcel convertidas para arquivos.txt para tabelas internas. Estes cenários descreveram em múltiplos conjuntos de valores e atributos de tabelas da ecatt as diversas variações possíveis dos parâmetros de entrada das transações gravadas. Com todos esses elementos criados, as Test Configurations puderam ser testadas massivamente por meio de loops de leitura de tabelas no script. Os resultados da execução foram relatados automaticamente em logs bastante detalhados, contendo todos os dados da Configuração do teste e Mensagens de Resultado (/AIF/ECATT_TESTS_PROCESS) para análises. A tarefa de debug dos testes automatizados na ferramenta ecatt exigiu conhecimentos mais avançados da linguagem de script de testes, assim como a própria elaboração dos loops de leitura de tabelas de variantes de parâmetros, e teve que ser realizada com apoio da consultoria. A criação dos cenários teve que seguir rigorosamente a ordem dos campos definida na Configuração de teste, sob pena de gerar erro de leitura dos arquivos de cenários. 5. Resultados A contraposição entre o processo de Execução Manual de Testes e a Execução Automatizada de Testes com utilização da ferramenta ecatt evidenciou algumas vantagens e desvantagens, acertos e erros, prós e contras de ambas as abordagens de realização de testes. Foi possível perceber que ambas as abordagens exigem muita preparação da equipe de testes, o que foi constatado na necessidade de elaboração cuidadosa de casos de teste criteriosamente selecionados, no correto sequenciamento das atividades de teste, na correta atribuição de perfis de acesso aos testadores, na inclusão ou alteração de casos de teste para alcançar maior cobertura em cenários mais abrangentes, e na análise dos relatórios de resultados dos testes. Também em ambas as abordagens, todo o tempo e esforço investido na etapa de planejamento e organização, e replanejamento e alterações para maior cobertura dos casos e procedimentos de testes, refletiram-se em vantagens na abrangência dos casos de teste, na configuração dos casos para posterior possibilidade de reuso em combinações; nos erros detectados, corrigidos e retestados; e, enfim, na melhor qualidade do sistema implantado. 11

Os principais benefícios do uso da ferramenta ecatt identificados nesta pesquisa foram a maior produtividade e a maior qualidade do software implantado. A possibilidade de execução de vários casos de teste em um intervalo de tempo menor do que se fossem executados manualmente permitiu a execução (e eventual correção, e posterior reexecução) de um número maior de casos de teste. Foi possível perceber que a execução manual dos testes levou a uma situação de não execução de todos os casos, por questões de imposição de prazos, o que limitou os casos ao teste do funcionamento do fluxo básico de alguns processos, ou seja, apenas do comportamento esperado, o que limitou a detecção (e correção) de erros. Por outro lado, as principais limitações do uso da ferramenta ecatt identificadas nesta pesquisa foram a necessidade de aprendizado da linguagem de script da ferramenta; a necessidade de adequação dos casos e procedimentos de teste às exigências da ferramenta quanto às configurações de objetos previamente aos testes; e a necessidade de cuidados especiais no gerenciamento da replicação dos dados dos testes nos vários arquivos utilizados pelos scripts, pois a ferramenta não administra isso automaticamente. Comparativamente, a configuração do ambiente de testes para execução manual é mais simples, não muito exigente. 6. Conclusões Pode-se concluir que esta pesquisa atingiu o seu objetivo, pois foi analisado o processo de testes de software, no caso da implantação do sistema ERP R/3 da SAP, utilizando a ferramenta de automação de testes ecatt (Extended Computer Aided Test Tool), descrevendo seu uso com um exemplo e analisando suas vantagens e desvantagens, em comparação com o método de teste manual. Foi possível verificar detalhes da tentativa de adequação da prática à teoria e as dificuldades encontradas pelos testadores no dia-a-dia dos testes na empresa pesquisada. Os resultados confirmam apontamentos de outras pesquisas, principalmente que a decisão quanto a automatizar ou não um projeto de testes deve analisar fatores além da simples redução de tempo e custo da execução dos testes (NÓBREGA, 2006). Embora significativa, a redução de tempo da Execução Automatizada versus Execução Manual não se refletiu no tempo total do processo de testes, pois exigiu muito mais tempo na fase de preparação dos ambientes, pacotes e demais objetos. Sua importância maior foi a de permitir executar todos 12

os testes e evitar o problema de descartar alguns por falta de tempo ou prazo, e permitir reutilizar dados em caso de necessidade de novos testes (VELOSO et al., 2009). De maneira geral, conclui-se que a ferramenta ecatt analisada parece adequada para a execução das atividades de testes dos processos da empresa pesquisada. Assim, a análise da aplicação da ferramenta para outros processos da mesma empresa, especialmente aqueles que necessitam de testes com repetições de valores variáveis, como, por exemplo, o processamento do cálculo de valores para pagamentos, configura uma possibilidade de pesquisa futura suscitada por este trabalho. REFERÊNCIAS AMMANN, P.; OFFUTT, J. Introduction to Software Testing. Cambridge/UK: Cambridge University Press, 2008. BAUER, M.W.; GASKELL, G. (org.). Pesquisa qualitativa com texto, imagem e som. Petrópolis: Vozes, 2002. CAETANO, C. Automação e Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas. 2.ed. São Paulo: HP Invent, 2007. DÓREA, A.D.O.; CARVALHO, F. S.; SANTOS, M.T.; NETO, M.C.M.; MOISES, D. Avaliação de Ferramentas de Automação para Engenheiros de Testes. In: Anais. Simpósio Brasileiro de Sistemas de Informação, 4. Rio de Janeiro, 2008. p. 23-34. FANTINATO, M.; CUNHA, A.; DIAS, S.; MIZUNO, S. AutoTest: um framework reutilizável para automação de teste funcional de software. In: Anais. Simpósio Brasileiro de Qualidade de Software, 3., Brasília, 2005. FEWSTER, M. Common mistakes in test automation. In: Proceedings. Fall Test Automation Conference, 2001. KHAN, Rohit; BABU, Prasad. Working with ecatt: Tutorial and Step-by-Step Guide. 2011. Disponível em:.scn.sap.com/docs/doc-10439. Acesso em: 24 abr. 2014. MYERS, G.J. The Art of Software Testing. 2.ed. New Jersey: John Wiley & Sons, 2004. NÓBREGA, R.O. Framework para Automação de Testes Funcionais Utilizando o Rational Functional Tester (Trabalho de Graduação Ciência da Computação). Recife: UFPE, 2006. PEZZE, M.; YOUNG, M. Software Testing and Analysis. New Jersey: John Wiley & Sons, 2008. ROBINSON, R. Automation Test Tools Comparison. 2001. Disponível em: http://www.stickyminds.com/sitewide.asp?function=edetail&objecttype=col&objectid=2861 SAP. ecatt: extended Computer Aided Test Tool (BC-TWB-TST-ECA). 2004. Disponível em: http://help.sap.com/saphelp_nw04/helpdata/en/1b/e81c3b84e65e7be10000000a11402f/frameset.htm SAP, Help Portal Page. Automação do teste com CATT ampliado. 2014. Disponível em: http://help.sap.com/saphelp_aif20/helpdata/pt/88/d667d8546d443ebe0f328240830669/content.htm SAP Brasil. Workshop sobre SAP Solution Manager (SolMan): Planejamento de Testes (STWB_2) e Execução de Testes (STWB_WORK). São Paulo: SAP, 2011. (Instrutor Paulo Barata). 13

VELOSO, J.S.; SANTOS NETO, P.A.; SANTOS, I.S.; BRITO, R.S. Avaliação de Ferramentas de Apoio ao Teste de Sistemas de Informação. In: Anais. Encontro Regional de Computação (ERCEMAPI), 3. Parnaíba-PI, out.2009. YIN, Robert K. Estudo de Caso: Planejamento e Métodos. 3.ed. Porto Alegre: Bookman, 2005. 14