ANÁLISE DO PROCESSO DE TESTE DE SOFTWARE NA … · do sistema ERP R/3 da SAP, ... A Seção 2...

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 )

[email protected]

Chana Michelli Brum Guillen (UFRGS )

[email protected]

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 dia-

a-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

XXXIV ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO Engenharia de Produção, Infraestrutura e Desenvolvimento Sustentável: a Agenda Brasil+10

Curitiba, PR, Brasil, 07 a 10 de outubro de 2014.



2

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.



3

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.



4

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



5

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).

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).



6

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).

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



7

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.

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-



8

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

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



9

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.

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.



10

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

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



11

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.

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



12

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

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



13

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).

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.

http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=2861

http://help.sap.com/saphelp_nw04/helpdata/en/1b/e81c3b84e65e7be10000000a11402f/frameset.htm

http://help.sap.com/saphelp_aif20/helpdata/pt/88/d667d8546d443ebe0f328240830669/content.htm

ANÁLISE DO PROCESSO DE TESTE DE SOFTWARE NA … · do sistema ERP R/3 da SAP, ... A Seção 2...

Documents

Transcript of ANÁLISE DO PROCESSO DE TESTE DE SOFTWARE NA … · do sistema ERP R/3 da SAP, ... A Seção 2...