BR102012008593A2 - Projeto de script modular para sistema de teste de próxima geração - Google Patents

Abstract

PROJETISTA DE SCRIPT MODULAR PARA SISTEMA DE TESTE DE PRÓXIMA GERAÇÃO. Um método para projeto de script modular inclui receber, em um componente projetista de script modular, informação de script de um usuário, gerar uma lista de módulos sugeridos com base na informação de script, e receber, no componente projetista de script modular, uma seleção de um próximo módulo do usuário. A seleção do próximo módulo inclui uma seleção do próximo módulo dentre a lista dos módulos sugeridos ou uma solicitação para um novo módulo. Se a seleção do próximo módulo incluir a solicitação para o novo módulo, o método inclui adicionalmente gerar o novo módulo

Description

Relatório Descritivo da Patente de Invenção para "PROJETISTA DE SCRIPT MODULAR PARA SISTEMA DE TESTE DE PRÓXIMA GERA- ÇÃO".

Reivindicação de Prioridade Este pedido reivindica o benefício do Pedido de Patente Provisó-

rio U.S. No. Serial 61/475.057 depositado em 13 de abril de 2011, o qual está incorporado na sua totalidade neste documento pela referência. Antecedentes da Invenção

1. Campo Técnico.

Esta revelação diz respeito a teste de software, e em particular

esta revelação diz respeito a uma plataforma integrada para desenvolver, depurar e executar testes para garantir a integridade e funcionalidade de sistemas de software.

2. Antecedentes.

O desenvolvimento de software de computador envolve um rigo-

roso processo de teste para garantir que o software funciona como pretendi- do. Durante o processo de teste, testadores gravam vários scripts de teste ou módulos de teste de software para executar tipos diferentes de testes necessários para assegurar que o software de computador está funcionando 20 tal como projetado. Os testadores também configuram e executam os scripts de teste enquanto rastreando os resultados, e reportam o resultado de teste para o pessoal apropriado. Este processo é ineficiente e demorado, e exige significativo envolvimento de testador.

Adicionalmente, como os negócios continuam a contar com 25 softwares de computador e pacotes de softwares complexos, um número crescente de softwares de computador altamente complexos tem sido de- senvolvido para satisfazer demandas de negócio. Por causa da complexida- de e escala aumentadas, tais softwares exigem um processo de teste de grande escala envolvendo muito mais testadores e scripts de teste do que 30 eram exigidos anteriormente. Tais aumentos estão relacionados com organi- zações centralizando seus testes e mudando para um modelo de teste ter- ceirizado. Tradicionalmente teste era 'embutido' no ciclo de vida de desen- T 2/32

volvimento de software para cada projeto, mas agora funções de teste 'dis- tintas' centrais existem dentro de organizações, as quais testam através de múltiplos projetos e liberações.

Ferramentas de testes têm sido desenvolvidas para ajudar os 5 testadores a executar as várias etapas do processo de teste. Entretanto, fer- ramentas de testes existentes não são capazes de fornecer a funcionalidade e eficiência exigidas para superar os desafios propostos pelo processo de teste de grande escala.

Teste de vários produtos e/ou de produtos de software tem au- 10 mentado em complexidade e escopo. No passado, grupos relativamente pe- quenos de projetistas e desenvolvedores, talvez 10 a 30 em número, desen- volviam vários testes para testar e verificar a função de módulos de software ou segmentos de código. Tais pequenos grupos de indivíduos eram gerenci- áveis. Entretanto, à medida que o número de indivíduos contribuindo para o 15 projeto se torna grande, redundância e complexidade aumentam, o que con- tribui para custo aumentado e um aumento no número de erros. Portanto, existe uma necessidade de abordar o exposto acima.

Sumário

Um método para projeto de script modular inclui receber, em um 20 componente projetista de script modular, informação de script para um script modular de um usuário, gerar uma lista de módulos sugeridos com base na informação de script, e receber, no componente projetista de script modular, uma seleção de um próximo módulo do usuário. A seleção do próximo mó- dulo inclui uma seleção do próximo módulo dentre a lista dos módulos suge-

ridos ou uma solicitação para um novo módulo. Se a seleção do próximo módulo incluir a solicitação para o novo módulo, o método inclui adicional- mente gerar o novo módulo.

Outras modalidades de sistemas, métodos, recursos e suas van- tagens correspondentes estarão, ou se tornarão, aparentes para os versa- dos na técnica mediante exame das figuras seguintes e da descrição deta- lhada. É considerado que todos os tais sistemas, métodos, recursos e van- tagens adicionais estão incluídos nesta descrição, estão dentro do escopo da invenção e estão protegidos pelas reivindicações a seguir.

Breve Descrição dos Desenhos

O sistema pode ser mais bem entendido com referência aos de- senhos e à descrição a seguir, além das folhas de apresentação incluídas no 5 apêndice, o que está incorporado neste documento na sua totalidade. Os componentes nas figuras não estão necessariamente em escala, ênfase em vez disto sendo dada para ilustrar os princípios da invenção. Além disso, nas figuras, números de referência iguais designam partes correspondentes por todas as diferentes vistas.

A figura 1 mostra um sistema de teste de próxima geração

("NGT").

A figura 2 é um diagrama mostrando o processo de teste global usando o sistema NTG.

A figura 3 mostra um diagrama de componentes chaves do sis-

tema NTG.

A figura 4 é um diagrama de blocos de hardware de alto nível de uma modalidade do sistema NTG.

A figura 5 mostra um diagrama lógico de uma modalidade de um projetista de script modular ("MSD").

As figuras 6-9 mostram diagramas lógicos de uma interface de

usuário de uma modalidade do MSD.

A figura 10 mostra um diagrama lógico de uma interface de usu- ário de uma modalidade do projetista de script modular.

As figuras 11-13 mostram diagramas de vários recursos de uma

modalidade do MSD.

A figura 14 mostra um diagrama conceituai de uma modalidade do sistema NTG.

A figura 15 mostra um diagrama lógico de uma modalidade do sistema NTG.

A figura 16 é um diagrama de blocos de hardware de alto nível

de uma outra modalidade do sistema NTG. Descrição Detalhada das Modalidades Preferidas

Tal como mostrado na figura 1, um sistema 100 para teste de próxima geração ("sistema NTG") usando controlador de automação fornece uma plataforma permitindo eficiência e funcionalidade aumentadas para tes- 5 tar software de computador. O sistema 100 pode ser incorporado como um sistema cooperando com componentes de hardware de computador e/ou como um método implementado por computador.

O sistema NTG 100 pode incluir uma área de trabalho unificada 102 que inclui uma ferramenta de planejamento de teste 104, um projetista de script modular 106, uma barra de ferramentas de execução 108 e um componente de gerenciamento de defeitos 110. O sistema NTG 100 também pode incluir um gerenciador de priorização e designação 112, um controla- dor de automação 114, um controlador de cadeia de fornecimento de dados 116, uma camada de integração 118 e um portal de reportação 120. A ca- mada de integração pode se ligar a uma ferramenta de teste existente 130, tal como a HP Quality Center™ da Hewlett Packard, uma ferramenta de ge- renciamento de teste e gerenciamento de qualidade existente 140, tal como a IBM Rational Quality Manager, e uma base de dados ou servidor 150, tal como um Microsoft SQL Server com Serviços de Integração SQL e Serviços de Análise SQL. O NGT também pode incluir as máquinas virtuais 160 que se conectam por meio de interface ao controlador de automação 114. As máquinas virtuais 160 podem executar uma ferramenta de automação de teste funcional, tal como o software de teste funcional e de regressão 162, tal como o HP QuickTest Professional (QTP) da Hewlett Packard. Outros tipos de ferramentas de testes também podem ser usados.

O sistema NTG 100 fornece um conjunto de programas de fer- ramentas "adaptadoras" para um processo de teste. O sistema NTG 100 po- de consistir de um conjunto de ferramentas que se integram com ferramen- tas de teste existentes e que estendem suas funcionalidades. O sistema 30 NTG 100 permite teste funcional em uma escala ampliada ao entregar fer- ramentas para reduzir o esforço de teste e aumentar a qualidade de teste. O sistema NTG 100 pode reduzir esforço de teste por mais que 20% quando comparado às ferramentas de testes existentes 130, tal como a HP Quality Center™. Adicionalmente o sistema NTG 100 pode ser extensível para uso por múltiplos clientes. O sistema NTG 100 pode ser construído como um conjunto interno de recursos para uso por clientes e pode ser projetado para 5 permitir funcionalidade específica de cliente para ser manuseada por meio de configuração e extensão.

A figura 2 é um diagrama mostrando um processo de teste glo- bal usando o sistema NTG 100. O processo de teste pode incluir um estágio de planejamento de teste 202, o estágio de preparação de teste 204 e o es- 10 tágio de execução de teste 206. O sistema NTG 100 pode fornecer eficiência e funcionalidade aumentadas através de todas as áreas de teste. Fazer transição do estágio de planejamento de teste 202 para o estágio de prepa- ração de teste 204, e do estágio de preparação de teste 204 para o estágio de execução de teste 206 pode envolver a designação de trabalho 208. O 15 estágio de planejamento de teste 202 pode incluir o escopo 210, as estimati- vas 212 e os recursos 214. O estágio de preparação de teste 204 pode inclu- ir projetar novos scripts em 222, otimizar pacote de regressão em 224, pre- parar dados de teste em 226 e desenvolver testes automatizados em 228. O estágio de execução de teste 206 pode incluir alocar dados de teste em 232, 20 executar testes manuais em 234, executar testes automatizados em 236 e o gerenciamento de defeitos em 238. O sistema de teste de próxima geração 100 também pode incluir a capacidade de reportação 240 por todos os está- gios do processo de teste.

A figura 3 mostra um diagrama de componentes chaves do sis- 25 tema NTG 100. Os componentes chaves podem incluir uma ferramenta de planejamento de teste 104, um projetista de script modular 106, um gerenci- ador de priorização e designação 112, uma barra de ferramentas de execu- ção de teste 108, um controlador de automação 114, uma cadeia de forne- cimento de dados de teste 116, um portal de reportação 120 e a ferramenta 30 de gerenciamento de defeitos 110.

A figura 4 é um diagrama de blocos de hardware de alto nível de uma modalidade do sistema NTG 100. O sistema NTG 100 pode incluir um sistema de computador 402, o qual pode ser um computador pessoal e pode incluir vários componentes de hardware, tais como a RAM 414, a ROM 416, o armazenamento de disco rígido 418, a memória cache 420, o armazena- mento de base de dados 422 e outros mais (também referidos como "o sub- sistema de memória 426"). O computador 402 pode incluir qualquer disposi- tivo de processamento adequado 428, tal como um computador, micropro- cessador, processador RISC (computador de conjunto de instruções reduzi- das), processador CISC (computador de conjunto de instruções complexas), computador de grande porte, estação de trabalho, computador de um único chip, processador distribuído, servidor, controlador, microcontrolador, com- putador de lógica distinta e outros mais, tal como é conhecido na técnica. Por exemplo, o dispositivo de processamento 428 pode ser um microproces- sador Intel Core i7®, microprocessador compatível x86, ou dispositivo equi- valente, e pode ser incorporado em um servidor, um computador pessoal ou em qualquer plataforma de computação adequada.

O subsistema de memória 426 pode incluir quaisquer compo- nentes de armazenamento adequados, tais como RAM, EPROM (ROM pro- gramável eletricamente), memória flash, memória dinâmica, memória estáti- ca, memória FIFO (primeiro a entrar, primeiro a sair), memória LIFO (último 20 a entrar, primeiro a sair), memória circular, memória semicondutora, memó- ria de bolha, memória de armazenamento temporário, memória de disco, memória ótica, memória cache e outras mais. Qualquer forma adequada de memória pode ser usada, se armazenamento fixo em uma mídia magnética, armazenamento em um dispositivo semicondutor, ou armazenamento remo- 25 to acessível por meio de um enlace de comunicação. Uma interface de usuá- rio ou de sistema 430 pode ser acoplada ao computador 402 e pode incluir vários dispositivos de entrada 436, tais como comutadores selecionáveis pelo gerenciador de sistema e/ou um teclado. A interface de usuário também pode incluir os dispositivos de saída adequados 440, tais como um mostra- 30 dor LCD, um CRT, vários indicadores LED, uma impressora e/ou um disposi- tivo de saída de fala, tal como é conhecido na técnica.

Para promover comunicação entre o computador 402 e fontes externas, uma interface de comunicação 442 pode ser acoplada operacio- nalmente ao sistema de computador. A interface de comunicação 442 pode ser, por exemplo, uma rede de área local, tal como uma rede Ethernet, intra- net, Internet ou outra rede adequada 444. A interface de comunicação 442 5 também pode ser conectada a uma rede telefônica pública comutada (PSTN) 446 ou POTS (sistema telefônico tradicional), o que pode promover comunicação por meio da Internet 444. Qualquer dispositivo ou rede de co- municação disponível comercialmente adequado pode ser usado.

A descrição do projetista de script modular ("MSD") 106 se se- gue. O MSD 106 combina uma interface simples para desenvolver scripts, ou facilitar criação de script, usando uma abordagem modular juntamente com uma estrutura de aprovações. Modularização é o processo de agrupar etapas de teste em pequenos módulos que descrevem uma parte da funcio- nalidade. Estes módulos combinam conjuntamente para formar scripts ou casos de teste. O MSD 106 fornece sugestões de módulo inteligente para desenvolver scripts de teste. Scripts de teste podem incluir um ou mais mó- dulos. Quando um módulo é acrescentado a um script, uma lista de prová- veis 'próximos módulos' é exibida para o usuário. Portanto, o MSD 106 pode melhorar gerenciamento de conhecimento e diminuir esforços duplicados ao criar módulos. Usuários também podem procurar por módulos com uma fun- ção de pesquisa em linha.

O MSD 106 também permite identificar e indicar parâmetros nos módulos. Metadados são acrescentados aos módulos de maneira que o sis- tema possa entender como e onde o módulo é usado. Parâmetros de entra- 25 da e de saída são especificados para capacitar reutilização de módulos e abordagens de dados acionados. O MSD 106 também permite a especifica- ção de conhecimentos profissionais e de pré-requisitos associados com um módulo. Conhecimentos profissionais são designados para os testes de ma- neira que o sistema conhece quem será capaz ou qualificado para executar 30 o script. Pré-requisitos (incluindo dados) são especificados para rastrear a disponibilidade de um teste para execução. O MSD 106 também fornece fluxo de trabalho de aprovações automatizadas. Um sistema de fluxo de tra- t 8/32

balho centralizado é usado para capacitar módulos para serem aprovados ou rejeitados. Após um módulo ser criado ou modificado, o aprovador é noti- ficado. O aprovador pode aprovar o módulo para ser usado em todos os s- cripts, para um subconjunto de scripts, ou para um único script.

A descrição da barra de ferramentas de execução de teste 108

se segue. A barra de ferramentas de execução de teste 108 pode ser uma barra de ferramentas unificada incorporando todas as ferramentas que um testador exige. A barra de ferramentas de execução de teste 108 pode for- necer execução de teste em linha. Scripts de teste podem ser abertos dire- 10 tamente dentro da barra de ferramentas, o que economiza espaço em uma área de trabalho do testador e evita certos toques de tecla, tais como ALT- Tab, entre telas. Descoberta de defeito e captura de tela podem ser parte do processo. A barra de ferramentas de execução de texto 108 também pode fornecer uma lista de aprovações embutida. Todas as aprovações de módu- 15 lo/script podem ser mostradas na barra de ferramentas, e um aprovador po- de abrir rapidamente o script/módulo pertinente para aprovação. A barra de ferramentas de execução de teste 108 também permite acesso rápido a to- das as ferramentas NGT. Uma barra de lançamento rápido pode ser forneci- da para capacitar o testador para acessar rapidamente todas as ferramentas 20 NGT. A barra de ferramentas também pode manusear gerenciamento de entrada no sistema para NGT. Uma seção de perfil de usuário está disponí- vel para mudança de informação de usuário. A barra de ferramentas de exe- cução de teste 108 também é atracável a uma função de auto-ocultação. A barra de ferramentas de execução de teste 108 pode ser atracada no lado 25 esquerdo da tela, e ela pode ser selecionada para ficar visível ou com auto- ocultação. Uma estrutura extensível permite que painéis extras sejam acres- centados à barra de ferramentas.

A descrição do gerenciador de priorização e designação ("PAM") 112 se segue. O PAM 112 fornece uma priorização automatizada centraliza- da de scripts de teste com lógica de designação em tempo real. O PAM 112 fornece fatores de priorização configuráveis. Scripts de teste são priorizados com base em um conjunto centralizado de fatores, e os fatores podem ser «r 9/32

configurados centralmente para influenciar a operação de teste total (por exemplo, para melhorar desempenho junto a indicadores chaves de desem- penho ("KPIs") contratuais). O PAM 112 fornece adicionalmente uma desig- nação baseada em conhecimento profissional - ele fornece uma abordagem de puxar em vez de empurrar. Testadores podem clicar em Obter o Próximo' por meio de uma interface de usuário para terem designado o próximo script a executar. O melhor script é escolhido em tempo real com base em fatores de designação ponderados. Gerenciadores podem controlar os conhecimen- tos profissionais quando comparados aos conhecimentos profissionais de seus elementos de equipe. O PAM 112 também pode fornecer anulações de gerenciador. Gerenciadores são providos com uma visualização dos scripts planejados para execução por sua equipe. Eles são capazes de mudar os fatores de scripts específicos (por exemplo, prioridade de negócio) para prio- rizar novamente a fila e forçar scripts para serem designados para indivíduos específicos. O PAM 112 também pode fornecer uma estrutura plugável para novos fatores. Novos fatores de decisão podem ser adicionados ao definir uma nova classe de fatores. O fator pode ser apresentado por meio da inter- face de usuário e pode ser ponderado na lógica de decisão. Isto pode ser usado para capacitar modelos de decisão avançados de 'Estatística Aplica- da'.

A descrição do controlador de automação 114 se segue. O con- trolador de automação 114 pode ser uma estrutura de automação para au- tomação fora de linha resiliente em um parque virtual, tal como uma máquina de computação em um "ambiente de nuvem". O controlador de automação 25 114 fornece execução remota de scripts de teste. Um agente controlador de automação pode executar em máquinas virtuais ("VMs") para gerenciar a execução de scripts de teste. Uma estrutura de entrada em sessão é usada para suportar a execução. O controlador de automação 114 também pode se comunicar com o PAM 112 para obter o próximo script. Isto permite que os 30 fatores centralizados se apliquem para execução tanto manual quanto auto- matizada.

O controlador de automação 114 também fornece seleção inteli- r 10/32

gente de módulos para maximizar o "retorno de investimento" ou "ROI" as- sociado com cada script de teste que é executado automaticamente. O con- trolador de automação 150 seleciona para automação os scripts de teste que forneçam o maior ROI coletivamente. A escolha para definir se automatiza 5 um script de teste particular usando o controlador de automação 150 pode ser baseada no ROI associado com o script de teste. Por exemplo, um script de teste particular pode ser um script de teste que manuseia entrada no sis- tema inicial por um usuário. Por causa de um script de teste que manuseia entrada no sistema inicial por usuário poder ser usado por centenas de dife- 10 rentes scripts de teste sem variação, este script de teste fornece um alto ROI, e como tal pode ser um bom candidato para automação. O ROI é es- sencialmente uma medida de eficiência aumentada alcançada por meio de automação do script de teste. Um fluxo de trabalho de priorização ajuda a equipe de automação a avaliar o próximo módulo a ser automatizado. A in- 15 terface de usuário permite que a equipe de automação 'verifique' e 'atualize' módulos automatizados.

O controlador de automação 114 fornece adicionalmente projeto modular e automação parcial. Scripts de automação podem ser desenvolvi- dos como módulos, e cada módulo de automação pode ter um ou mais mó- 20 dulos manuais mapeados junto a ele. Automação parcial capacita execução rápida de partes automatizadas de scripts. Essencialmente, o controle de automação 150 é usado onde aplicável para automatizar a execução de s- cripts de teste.

A descrição do portal de reportação 120 se segue. O portal de 25 reportação 120 fornece uma capacidade de reportação automatizada aces- sível por meio de um portal online central. O portal de reportação 120 pode incluir um conjunto de programas total Microsoft™ Business Intelligence ("BI"). A solução faz uso de Serviços de Integração de Servidor SQL, Servi- ços de Análise de Servidor SQL e Serviços de Reportação de Servidor SQL, 30 os quais são disponíveis pela Microsoft Corporation. Um componente perso- nalizado de Serviços de Integração de Servidor SQL (SSIS) se comunica diretamente com as ferramentas de testes externas 130 tais como uma HP r 11/32

Quality Center™, a qual está disponível pela Hewlett-Packard Corporation.

O portal de reportação 120 também inclui um depósito de dados fora de linha para evitar degradação de ferramenta de teste. Um depósito de dados fora de linha pode ser mantido para evitar consultas diretamente na ferramenta de teste externa. Um modelo de dados baseado em dimensão é usado para reportação simplificada. Adicionalmente, dados são pré- agregados em uma base de dados de processamento analítico online multi- dimensional ("MOLAP") para fornecer análise rápida. O portal de reportação 120 fornece adicionalmente métricas baseadas em cubo e KPIs (indicadores chaves de processo). Usando Serviços de Análise SS1 medidas e alvos po- dem ter sido predefinidos, os quais podem ser incluídos em reportações. PowerPivot, uma planilha de inclusão disponível pela Microsoft Corporation, permite que dados sejam rapidamente analisados em programas de plani- lhas, tais como Microsoft Excel™ para estas reportações. Adicionalmente, o portal de reportação 120 fornece integração com soluções tais como o Mi- crosoft SharePoint™. Onde dados de sistemas a não ser o HP Quality Cen- ter™ são exigidos (por exemplo, dados financeiros/de produção), a solução pode receber dados de soluções tais como o Microsoft SharePoint™. O componente SSIS permite que a solução seja facilmente estendida para fon- tes de dados diretas, onde exigido.

A descrição da ferramenta de gerenciamento de defeitos 110 se segue. A ferramenta de gerenciamento de defeitos 110 pode simplificar o processo para descobrir, rastrear e atualizar defeitos. A ferramenta de ge- renciamento de defeitos 110 pode fornecer uma lista de guarda de defeitos. 25 Uma lista de defeitos baseada em barra de ferramentas com indicadores de status Vermelho, Âmbar ou Verde (RAG) em tempo real pode ser fornecida. Status Vermelho indica alto risco ou questões de projeto sérias, status âm- bar indica risco médio, e status verde indica baixo risco. A ferramenta de gerenciamento de defeitos 110 pode permitir acesso rápido à informação 30 total dos defeitos para ver o status mais recente. A ferramenta de gerencia- mento de defeitos 110 também pode fornecer descoberta de defeito em linha com histórico de teste. Enquanto executando um teste por meio da barra de t 12/32

ferramentas, capturas de tela e etapas de teste podem ser obtidas. Quando um defeito é descoberto, esta informação é pré-povoada no defeito. Captu- ras de tela e outras anexações podem ser transferidas diretamente. A ferra- menta de gerenciamento de defeitos 110, também reduz operações de "alt- 5 tab". Ao incluir gerenciamento de defeitos de núcleo na barra de ferramen- tas, a ferramenta de gerenciamento de defeitos 110 é capaz de reduzir a necessidade de "alt-tab" para um sistema de teste externo 130, tal como o HP Quality Center™. A ferramenta de gerenciamento de defeitos 110 tam- bém capacita desbloqueio automatizado de scripts para evitar adicionalmen- 10 te tempo gasto no sistema de teste externo. A ferramenta de gerenciamento de defeitos 110 fornece adicionalmente visualizações baseadas em equipe. Gerenciadores têm uma Visualização de equipe' para capacitá-los para ver os defeitos impactando atualmente sua equipe com o tamanho e status per- tinentes.

A descrição da ferramenta de planejamento de teste 104 se se-

gue. A ferramenta de planejamento de teste 104 fornece uma interface inte- ligente para estimar, planejar, selecionar regressão e designar trabalho de preparação. A ferramenta de planejamento de teste 104 fornece estimativas auxiliadas. Um processo de três estágios é usado para fornecer estimativas 20 em níveis crescentes de precisão. Informação é usada de liberações de tes- te anteriores para melhorar estimativas. Arquitetura plugável para cálculos específicos de cliente pode ser usada. A ferramenta de planejamento de tes- te 104 também fornece desconstrução de exigências para testes. A ferra- menta de planejamento de teste 104 ajuda o usuário a reduzir exigências 25 para um número gerenciável de testes. Capacidades de trabalho colaborati- vo permitem uma abordagem de 'dividir e superar'. A ferramenta de plane- jamento de teste 104 fornece adicionalmente previsão de recurso por meio de conhecimento profissional. Previsão antecipada de conhecimentos profis- sionais exigidos para suportar as atividades de teste torna-se possível, e 30 exibição gráfica de disponibilidade versus demanda pode ser apresentada na interface de usuário. A ferramenta de planejamento de teste 104 ajuda adicionalmente a modelar a organização de teste ao promover cruzamento r 13/32

de conhecimentos. A ferramenta de planejamento de teste 104 também for- nece sugestões de pacote de regressão. Usando uma abordagem impulsio- nada por metadados, o sistema irá sugerir um pacote de regressão apropri- ado. Pontuações de testes baseadas em risco podem ser usadas para di- 5 mensionar o pacote desta maneira.

A descrição da cadeia de fornecimento de dados de teste 116 se segue. A cadeia de fornecimento de dados de teste 116 automatiza o geren- ciamento de demanda e fornecimento de dados de teste. A cadeia de forne- cimento de dados de teste 116 pode fornecer um catálogo de dados. Tipos 10 de dados são modelados e armazenados em uma base de dados. A equipe de dados de teste pode verificar dados no catálogo e fora dele. Também, regras podem ser especificadas para capacitar exploração de dados bási- cos. A cadeia de fornecimento de dados de teste 116 também fornece dados de mapeamento para scripts de teste. Durante preparação, o tipo de dados 15 exigido é selecionado junto ao script. Também, usando o projetista de script modular 106, parâmetros de dados podem ser mapeados diretamente para parâmetros de script para permitir designação automatizada em tempo de execução. A cadeia de fornecimento de dados de teste 116 fornece adicio- nalmente monitoramento de 'níveis de estoque' e reordenação. A cadeia de 20 fornecimento de dados de teste 116 pode monitorar demanda versus capa- cidade para todos os tipos de dados, e à medida que obtém dados 'usados' por scripts de teste os níveis são atualizados. A cadeia de fornecimento de dados de teste 116 pode ordenar dados adicionais a partir da equipe de da- dos ou por meio de uma provisão automatizada. A cadeia de fornecimento 25 de dados de teste 116 também pode ser integrada ao PAM 112. Os níveis de estoque podem ser usados durante priorização para evitar executar s- cripts que não tenham dados de teste disponíveis ou onde níveis de estoque estejam baixos.

Por exemplo, se cinqüenta scripts de teste específicos exigirem dados de entrada tipo "A" e vinte e sete scripts de teste específicos exigirem dados de entrada tipo "B", a cadeia de fornecimento de dados de teste 116 organiza os tipos de dados exigidos para cada script e fornece os dados pa- ra o script de teste em um modo de "no tempo certo" para evitar redundância e reduzir complexidade. Adicionalmente, tais dados de teste podem mudar por todo o ciclo de vida do processo de teste com base nos resultados de um teste particular. Desta maneira, a cadeia de fornecimento de dados de 5 teste 116 rastreia as mudanças exigidas e atualiza os conjuntos de dados exigidos para os scripts de teste correspondentes de maneira que, à medida que os scripts de teste estão sendo executados, dados de teste atualizados estão disponíveis para o script de teste.

O MSD 106 pode fornecer as seguintes funcionalidades: Definir Novo Script: O usuário é capaz de criar um novo script de teste e introduzir informação de chave a respeito desse script; Editar Script Existente: O usuá- rio é capaz de carregar, ou transferir, um script existente e editar a informa- ção/módulos nesse script; Selecionar Dados de Teste: O usuário é capaz de selecionar tipos de dados de teste do catálogo de dados para associar ao script; Procurar por Módulos: O usuário é capaz de procurar por módulos existentes; 10 Próximos Módulos Superiores: O MSD 106 pode sugerir os muitos prováveis próximos módulos, os quais podem ser dez módulos ou qualquer outro número de módulos, para o testador com base nos scripts existentes dentro do repositório; e Criar Novo Módulo: O usuário é capaz de projetar um novo módulo quando exigido.

A funcionalidade Criar Novo Módulo pode incluir as seguintes subfuncionalidades: Definir Etapas de Teste: Etapas de teste podem ser capturadas junto ao módulo; Definir Resultados Esperados: Resultados Es- perados podem ser capturados junto às etapas de teste; Definir Variáveis de 25 Entrada: O testador pode ser capaz de definir as variáveis de entrada para o módulo e as incluir tal como exigido nas etapas/resultados de teste; Definir Variáveis de Saída: O testador pode ser capaz de definir as variáveis de saí- da para o módulo e as incluir tal como exigido nas etapas/resultados de tes- te.

O MSD 106 pode fornecer adicionalmente as seguintes funcio-

nalidades: Mapear Variáveis de Entrada de Módulo: A entrada dos módulos é mapeada para a saída de módulos anteriores, introduzidos pelo testador r 15/32

em tempo de execução ou mapeados para um campo de dados de teste; Metadados de Módulo: O MSD 106 permite que metadados configuráveis adicionais sejam especificados junto a cada módulo; Captura de Conheci- mento Profissional: O testador é capaz de introduzir os conhecimentos pro- 5 fissionais exigidos para executar o teste; Captura de Pré-Requisitos: O MSD 106 permite ao testador introduzir quaisquer pré-requisitos exigidos junto ao script; Captura de Prioridade e Risco: O usuário é capaz de introduzir a prio- ridade de negócio, probabilidade de falha e impacto de falha junto ao script de teste.

O MSD 106 pode fornecer funcionalidades adicionais, tais como

permitir aos usuários: clonar scripts de teste, salvar scripts como esboços, visualizar etapas legadas, reordenar facilmente módulos no script, marcar módulos como favoritos, visualizar módulos favoritos, submeter módulos aos aprovadores de módulo, salvar módulos como esboços, definir fonte de vari- 15 ável de entrada e de saída como um valor fixo, marcar scripts como não exi- gindo revisão, anexar documentos ou imagens a scripts e cancelar criação de um script. O MSD 106 também pode assegurar que módulos não são cri- ados com o mesmo nome. O MSD 106 pode fornecer menos, mais ou outras funcionalidades.

A figura 5 mostra um diagrama lógico de uma modalidade do

MSD 106. Usando o MSD 106, um testador 501 pode abrir ou acessar s- cripts em 510 que já tenham sido criados. O MSD 106 também permite ao testador 501 clonar ou duplicar scripts existentes em 520, ao permitir ao tes- tador 501 pesquisar para um script usando IDs de scripts ou por meio de 25 navegação em uma base de dados de planos de testes ou em uma base de dados de laboratório de testes, as quais são bases de dados nas quais os scripts de teste são armazenados. O MSD 106 pode permitir adicionalmente ao testador 501 ver etapas legadas em 511, após o testador 501 abrir um script em 510. O testador 501 pode converter, usando o MSD 106, um script 30 legado para um script de teste de próxima geração ao adicionar detalhes e módulos ao script legado. Um script legado é um script que não tenha sido modularizado. O testador 501 também pode visualizar etapas legadas usan- do o MSD 106 e converter as etapas legadas em módulos, se tais módulos já não estiverem presentes no script legado.

O MSD 106 pode permitir adicionalmente que o testador 501 crie novos scripts em 530. Para criar um novo script em 530 no MSD 106, o tes- 5 tador 501 pode introduzir detalhes de script em 531, incluindo um nome de script exclusivo, uma descrição resumida de capacidades de script e deta- lhes de conhecimento profissional. Detalhes de conhecimento profissional podem incluir os conhecimentos profissionais exigidos para executar o script de modo bem sucedido. Em 532, o testador 501 pode especificar, no MSD 10 106, variáveis de entrada e de saída para o script, e revisar todos os dados que o testador 501 introduziu para o script, selecionar um aprovador para o script e anexar quaisquer dados que o script possa exigir. O testador 501 pode submeter o script a uma ferramenta de teste em 533, tal como a HP Quality Center™.

O MSD 106 também permite ao testador 501 introduzir módulos

no script de teste. O MSD 106 pode sugerir para o testador 501 módulos a ser acrescentados ao script. Em 534, o testador 501 também pode usar o MSD 106 para pesquisar outros módulos para aumentar o script, criar um novo módulo, editar módulos existentes ou clonar módulos existentes. O 20 MSD 106 também pode armazenar os módulos favoritos do testador 501. O MSD 106 pode permitir ao testador 501 adicionar ao script módulos selecio- nados, recém-criados, editados ou clonados. O testador 501 opcionalmente pode submeter um módulo em 535 a um aprovador 504, o qual pode ser um revisor par, tal como um condutor de teste. O aprovador 504 pode fornecer 25 comentários para o script e pode aprovar o módulo em 536 ou rejeitar o mó- dulo em 537. Se o aprovador 504 rejeitar o módulo em 537, o aprovador 504 pode distribuir o módulo de volta para o testador para edição em 538, e o módulo somente pode ser editado a partir do ponto onde o módulo foi sub- metido em 535. Um módulo rejeitado fica inativo, o que significa que o módu- 30 Io não pode ser procurado e não pode ser usado. O testador 501 pode editar o script em 538 com base nos comentários do aprovador 504. Se o aprova- dor 504 aceitar o módulo em 536, o módulo é marcado como pronto para teste, o que significa que o módulo está pronto para execução e para ser acrescentado ao script.

Em uma modalidade específica, o MSD 106 pode fornecer o processo de aprovação seguinte para aprovar um módulo recém-criado.

Quando o testador 501 submete um módulo para aprovação, o MSD 106 pode estabelecer um indicador de status do módulo para aprovação penden- te e alertar um aprovador 504 para rever o módulo. O testador 501 pode de- signar um indivíduo para ser o aprovador 504, ou o MSD 106 pode selecio- nar um aprovador 504 com base em uma função do aprovador e conheci- 10 mentos profissionais exigidos para o módulo. Quando o aprovador 504 apro- va o módulo, o MSD 106 pode mudar o indicador de status do módulo para aprovado para uso e o módulo está então disponível para uso em outros s- cripts e está investigável por usuários do MSD 106. O aprovador também pode fazer emendas no módulo antes de aprovar o módulo. Quando o apro- 15 vador 504 rejeita um módulo, o MSD 106 pode orientar o aprovador para introduzir um motivo para a rejeição e muda o indicador de status do módulo para rejeitado, e alerta o testador de que o aprovador rejeitou o módulo. O testador 501 pode editar ou atualizar o módulo rejeitado no MSD 106. O tes- tador 501 pode editar ou atualizar o módulo rejeitado e submeter o módulo 20 para revisão de novo, ou o testador 501 pode remover o módulo rejeitado do script, em cujo caso o MSD 106 muda o indicador de status do módulo rejei- tado para inativo ou deleta o módulo rejeitado.

As figuras 6, 7, 8 e 9 mostram um diagrama lógico de uma mo- dalidade do MSD 106. Tal como mostrado na figura 6, o MSD 106 pode ori- 25 entar o usuário para entrada no sistema em 601 e abrir o projetista de script modular em 602. Então, o MSD 106 pode orientar o usuário para escolher entre criar um novo script em 610, abrir um script existente em 620, clonar um script existente em 630, ou visualizar etapas legadas em 640. Se o usuá- rio escolher criar um script, o MSD pode orientar o usuário para introduzir 30 detalhes e pré-requisitos de script em 604 e adicionar módulos em 605. Se o usuário escolher abrir um script existente em 620, o MSD 106 pode orientar o usuário para procurar um script por meio de detalhes de script em 622 ou pesquisar em uma base de dados de laboratório de testes ou em base de dados de planos de testes em 623 e exibir scripts disponíveis para o usuário. Então, o usuário pode selecionar um script em 624 no MSD 106, e o MSD 106 pode dar ao usuário opções tais como o que fazer com o script em 625, 5 incluindo as opções para abrir o script em 626, exportar o script para um programa externo em 627 (tal como o Microsoft Excel, ou um outro programa para visualizar o script), ou cancelar a operação em 606. Se o usuário abrir o script em 626, o MSD 106 continua com o processo de criação de script 700, tal como mostrado na figura 7. Se o usuário escolher clonar um script em 10 630, o MSD 106 pode orientar o usuário para introduzir detalhes de script em 604 e adicionar módulos ao script em 605. A ferramenta de automação de teste funcional 162 pode armazenar scripts que não tenham etapas ou mó- dulos, por exemplo, alguns scripts legados ou scripts que incluam somente informação de script, mas nenhum módulo. Assim, se o usuário escolher ver 15 etapas legadas em 640, o MSD 106 pode determinar se os scripts legados têm quaisquer etapas em 641 e permitir ao usuário ver etapas legadas dis- poníveis em 642, adicionar etapas legadas selecionadas por usuário ao s- cript em 643 ou cancelar a operação em 606. Se o usuário adicionar etapas ao script em 643, o MSD 106 pode orientar o usuário para introduzir detalhes 20 e pré-requisitos de script em 604 e adicionar módulos em 605. Após o usuá- rio adicionar módulos em 605, o MSD 106 guia o usuário através das próxi- mas etapas no processo de criação de script 800 (figura 8).

A figura 7 mostra um diagrama lógico de uma modalidade do MSD 106 em continuação à figura 6. Após o usuário abrir o script em 626 na 25 figura 6, o MSD 106 continua o processo de criação de script 700 e dá ao usuário a opção para editar o script em 710. Se o usuário escolher editar o script, o MSD 106 pode determinar se o usuário tem direitos de edição em 720. Se o usuário tiver direitos de edição, o MSD 106 pode permitir ao usuá- rio editar o script em 721, e continuar a completar o processo de criação de 30 script 900. Se o usuário não tiver direitos de edição, o MSD 106 permite ao usuário cancelar a operação em 722.

A figura 8 mostra um diagrama lógico de uma modalidade do r » 19/32

MSD 106 em continuação à figura 6. Após o usuário adicionar módulos ao script em 605 na figura 6, o MSD 106 pode guiar o usuário através das pró- ximas etapas no processo de criação de script 800. O MSD 106 pode permi- tir ao usuário usar um módulo sugerido em 801, Se o usuário puder usar um 5 módulo sugerido em 801, o usuário pode selecionar um módulo em 802 de módulos existentes sugeridos, e o MSD 106 dá ao usuário a opção para edi- tar o módulo em 803. Se o usuário editar o módulo em 804, o MSD 106 ori- enta o usuário para salvar mudanças em 805 e submeter o módulo em 806. O MSD 106 também pode permitir que o usuário cancele mudanças em 808. 10 Se o usuário não editar o módulo em 803, o MSD 106 orienta o usuário para determinar se clona o módulo em 810. Se o usuário clonar o módulo em 810, o MSD 106 orienta o usuário para introduzir um nome de módulo em 811. Se o usuário escolher não clonar o módulo em 810, então o MSD 106 orienta o usuário para adicionar o módulo ao script em 812. Após o módulo ser acres- 15 centado ao script em 813, o MSD 106 dá ao usuário a opção para adicionar um outro módulo em 814. Se o usuário não adicionar quaisquer outros mó- dulos, o MSD 106 orienta o usuário para introduzir informação de entra- da/saída de script e continuar a completar o processo de criação de script 900.

O MSD 106 pode permitir ao usuário pesquisar para um módulo

em 820 ao orientar o usuário para introduzir detalhes de pesquisa em 821, executar a pesquisa em 822 e exibir os resultados de pesquisa para o usuá- rio. Então, o MSD 106 pode permitir ao usuário selecionar um módulo em 802 de módulos existentes nos resultados de pesquisa, e pode dar ao usuá- rio a opção para editar o módulo em 803.

O MSD 106 também pode permitir que um usuário use um mó- dulo favorito em 830. O MSD 106 permite ao usuário selecionar um módulo em 802 de módulos existentes e dá ao usuário a opção para editar o módulo em 803. Se o usuário não puder usar quaisquer módulos existentes (por e- 30 xemplo, um módulo sugerido em 801, um módulo de resultados de pesquisa em 820, ou um módulo favorito em 830), o usuário pode usar o MSD 106 para criar um novo módulo em 831. Após o usuário criar um novo módulo em 831, o MSD 106 pode orientar o usuário para adicionar o módulo aos favoritos em 832. O usuário pode verificar uma caixa em 833 para adicionar o módulo aos favoritos e então submeter o módulo em 806. Alternativamen- te, o usuário pode submeter o módulo em 806 sem adicionar o módulo aos 5 favoritos. Após o módulo ser submetido em 806, o MSD 106 pode orientar o usuário para cancelar em 808 ou adicionar o módulo ao script em 812, adi- cionar outros módulos em 814, introduzir informação de entrada/saída de script em 815, e completar o processo de criação de script 900.

A figura 9 mostra um diagrama lógico de uma modalidade do MSD 106 em continuação às figuras 7 e 8. Após um usuário editar o script em 721 ou terminar de adicionar módulos ao script em 814 e introduzir in- formação de entrada/saída script em 815, o MSD 106 pode orientar o usuá- rio para indicar se o script necessita revisão em 901. Se o usuário indicar que o script não necessita revisão, o MSD 106 orienta o usuário para intro- duzir um motivo para nenhuma revisão em 902, antes de permitir que o usu- ário prossiga. Se o usuário indicar que o script necessita revisão, o MSD 106 orienta o usuário para introduzir o nome do aprovador em 903. Após o usuá- rio introduzir informação de revisão de script, o MSD 106 orienta o usuário para anexações exigidas em 904, e permite ao usuário adicionar anexações em 905 ou prosseguir sem adicionar anexações. As anexações podem inclu- ir uma captura de tela, um arquivo, ou um documento para mostrar os resul- tados do script. Então, o MSD 106 orienta o usuário para salvar o script em 906, e permite ao usuário completar etapas para salvar o script em 907. En- tão, o MSD 106 orienta o usuário para submeter o script em 908, e dá ao usuário a opção para completar etapas para submeter o script em 909 ou fechar o projetista de script modular em 910 sem submeter o script.

A figura 10 é um diagrama lógico de uma interface de usuário de uma modalidade específica do MSD 106. O MSD 106 pode permitir ao tes- tador projetar rapidamente novos scripts com base em um repositório exis- 30 tente de módulos. Onde um novo módulo é exigido, o testador pode ser ca- paz de criar esse módulo dentro do MSD 106. Usando o MSD 106, o testa- dor pode introduzir informação a respeito do teste e de conhecimentos pro- f I 21/32

fissionais exigidos para executar o teste em 1004. O testador pode selecio- nar o tipo de dados de teste de um catálogo de dados em 1006. O testador também é capaz de introduzir metadados a respeito do módulo corrente e estabelecer parâmetros de entrada para o módulo em 1008. O MSD 106 5 também pode mostram uma visão geral do script de teste corrente. A visão geral pode mostrar os módulos selecionados para o script de teste corrente em 1010. Novos módulos podem ser criados quando exigido em 1012 usan- do o MSD 106, e o testador é capaz de procurar por um módulo específico em 1014. O MSD 106 também pode mostrar automaticamente os cinco pró- 10 ximos módulos superiores que provavelmente serão os próximos que o tes- tador usará em 1016. Qualquer outro número de possíveis próximos módu- los pode ser exibido. Os prováveis próximos módulos são determinados com base em conhecimento dos testes existentes. O MSD 106 pode permitir a um testador arrastar e retirar módulos do script em 1018. O MSD 106 tam- 15 bém pode exibir informação de etapa de teste para uma referência para os testadores em 1020.

Afigura 11 mostra uma captura de tela 1100 de uma modalidade do MSD 106. A interface de usuário pode incluir uma pluralidade de telas, ou tabulações, incluindo uma tabulação de Detalhes 1102, uma tabulação de 20 Pré-Requisitos 1104, uma tabulação de Criação de Scripts 1106 mostrada com mais detalhes na figura 11, uma tabulação de Entrada/Saída 1108, e uma tabulação de Término 1110. A pluralidade de telas, ou tabulações, pode guiar o usuário através do processo de projeto de script ao exibir opções e informação para usuário e orientar o usuário para introduzir informação para 25 criar ou projetar um script. Por exemplo, o usuário pode iniciar na tabulação de Detalhes 1102 ao clicar em uma tecla Arquivo para acessar e escolher em uma lista suspensa de funções, incluindo Abrir Script, Novo Script, Visua- lizar Script, Clonar Script ou Salvar Esboços. O testador também pode intro- duzir, na tabulação de Detalhes 1102, informação de chave a respeito do 30 script. A informação de chave pode incluir o cabeçalho script 1114, um nome de script 1116, uma descrição do script 1118, os nomes e valores de atribu- tos de teste 1120, os conhecimentos profissionais exigidos para completar t * 22/32

execução de script 1122, e uma referência de exigência para o script. O u- suário pode selecionar os conhecimentos profissionais exigidos 1122 de uma lista de conhecimentos profissionais exibidos na tabulação de Projeto 1102. Os conhecimentos profissionais exigidos 1122 podem ser usados mais 5 tarde para designar os scripts para testadores e aprovadores pertinentes, ou qualificados. A tabulação de Detalhes 1102 pode incluir adicionalmente uma tecla Salvar Esboço 1124, na qual o usuário pode clicar para salvar a infor- mação de script introduzida. Na tabulação de Pré-Requisitos 1104, o MSD 106 pode exibir e permitir ao usuário modificar pré-requisitos para executar o 10 script, os quais podem incluir tipo de dados, comentários de dados e outros pré-requisitos. Outras modalidades podem incluir menos, mais ou telas ou tabulações alternativas, para exibir opções e informação script para o usuá- rio, e para aceitar entrada de usuário com relação a scripts.

Tal como mostrado na figura 12, a tabulação de Criação de S- 15 cripts 1106 pode exibir para o usuário todos os módulos que estejam no s- cript de teste, e permitir ao usuário adicionar um módulo ao script ao criar um novo módulo, editar um módulo existente, ou clonar um módulo existen- te. O usuário também pode introduzir dados com relação a um módulo, inclu- indo, por exemplo, um nome de módulo 1202, um status do módulo 1204, 20 uma versão do módulo 1206 e uma descrição de módulo 1208. A interface de usuário pode exibir adicionalmente para o usuário uma pluralidade de opções em painéis, incluindo os módulos sugeridos 1210 para incluir no s- cript e a opção para pesquisar módulos 1212.

O usuário pode selecionar um módulo dos módulos sugeridos 25 1210 ao clicar em um módulo de escolha e arrastá-lo para um campo de S- cript Corrente 1214. O usuário pode introduzir informação adicional com re- lação ao módulo, incluindo componentes aos quais o módulo esta ligado (ar- rastado de uma base de dados de gerenciamento de configuração (CMDB) e quaisquer outros metadados). A interface de usuário pode exibir para o usu- 30 ário outra informação com relação ao script, incluindo, por exemplo, as eta- pas de módulo 1216, as etapas de teste para cada etapa de módulo 1218, os resultados esperados para cada etapa de módulo 1220, as etapas de s- cript corrente 1214, os nomes de atributo 1222, os valores de atributo 1224 e os parâmetros 1226. O usuário pode clicar na tecla "Adicionar a Script" 1228 para adicionar um módulo ao script.

O MSD 106 atualiza a lista de módulos sugeridos com base no último módulo no script. Se o script não tiver módulos, o MSD 106 pode for- necer uma lista dos módulos mais populares para serem usados como a primeira etapa no script. Por exemplo, o MSD 106 pode sugerir um primeiro módulo popular tal como "Registro para Aplicação". Se um ou mais módulos estiverem no script, o MSD 106 pode sugerir módulos populares que sigam o último módulo listado no script. O MSD 106 pode acrescentar o módulo sele- cionado por usuário da lista de módulos sugeridos ao script, e exibir os deta- lhes do módulo selecionado para o usuário para revisão e modificação. Os detalhes podem incluir, por exemplo, as etapas em um dado módulo, os atri- butos para esse módulo e os parâmetros do módulo. Atributos podem ficar ocultos para permitir mais espaço para rever as etapas. Após rever os deta- lhes, o testador pode acrescentar o módulo selecionado ao script de teste ao clicar em "Adicionar a Script". Os detalhes de cada etapa no script corrente podem ser mostrados em um painel, tal como um painel de Script Corrente 1202, para o testador ver o script total à medida que o testador progride. A- pós o testador adicionar o módulo selecionado ao script, o MSD 106 pode atualizar os painéis de módulo sugerido para mostrar as próximas etapas, ou módulos, mais prováveis no script. O MSD 106 pode determinar, com base na ordem de módulos em outros scripts existentes, quais módulos são co- mumente adicionados após o módulo selecionado. O MSD 106 permite ao testador desenvolver o script ao adicionar módulos ao script, mudar a ordem de módulos no painel de Script Corrente 1202, ou remover módulos do pai- nel de Script Corrente 1202.

Na tabulação de Entrada/Saída 1108, o MSD 106 pode exibir uma lista de todos os parâmetros de entrada/saída associados com o script de teste. O testador pode emendar a fonte para os parâmetros de entra- da/saída ao selecionar um parâmetro para mudança. Por exemplo, o testa- dor pode mudar um parâmetro de entrada para um valor fixo. Valores fixados são introduzidos diretamente no campo de "Valor" e são armazenados com o script. Alternativamente, o usuário pode mudar a fonte do parâmetro de entrada para "Definido por Usuário".

Na tabulação de Término 1110, o MSD 106 exibe para o testa- dor um resumo dos detalhes para o script de teste. O MSD 106 pode apre- sentar o novo módulo para o testador de maneira que o testador pode a- crescentar o novo módulo ao script corrente. O usuário pode selecionar um de seus pares para rever o script. Quando o script é submetido para revisão, o MSD 106 ativa um fluxo de trabalho de aprovação para assegurar que mó- dulos do script não são criados incorretamente. O usuário também pode pesquisar a ferramenta de teste para decidir onde armazenar o script que tenha sido desenvolvido. O MSD 106 permite ao testador adicionar anexa- ções ao script e submeter o script para revisão de par. O MSD 106 pode permitir ao testador introduzir um motivo para nenhuma revisão e prosseguir para submeter o script de teste.

A figura 13 mostra um diagrama de um Projetista de Módulo em uma modalidade do MSD 106. Quando o testador escolhe criar, editar ou criar um clone de um script, o MSD 106 pode exibir o Projetista de Módulo 1300. O Projetista de Módulo pode incluir uma pluralidade de telas, ou tabu- 20 lações, para guiar o usuário através da criação de um novo módulo. O Proje- tista de Módulo 1300 pode incluir uma tabulação de Detalhes 1114, uma ta- bulação de Projeto de Etapa 1320 e uma tabulação de Término 1330. A ta- bulação de Detalhes 1114 pode orientar o testador para introduzir um nome de módulo, nomes e valores para atributos de módulo, uma descrição do 25 módulo e conhecimentos profissionais exigidos para executar o script e a- provar o módulo. O Projetista de Módulo 1300 pode fornecer uma lista de conhecimentos profissionais dos quais o usuário pode selecionar os conhe- cimentos profissionais exigidos para testar o módulo.

A tabulação de Projeto de Etapa 1320 pode guiar o testador a- través da adição de etapas ao módulo. A tabulação de Projeto de Etapa 1320 pode orientar o testador para introduzir informação com relação a uma descrição, parâmetros e resultados esperados para cada etapa no módulo. Parâmetros podem ser embutidos nas etapas usando notações, tais como "»>lntroduzir«<" para entradas e "<«Saída»>" para parâmetros de saí- da. A lista de parâmetros pode ser atualizada à medida que cada etapa é introduzida. O usuário continua a introduzir o resultado esperado para a eta- 5 pa e especificar se evidência de teste deve ser capturada para essa etapa. Este processo é repetido para as etapas remanescentes no módulo. O tes- tador também pode inserir etapas e adicionar etapas usando a tabulação de Projeto de Etapa 1320. A tabulação de Término 1330 pode exibir para o u- suário uma página de resumo de módulo e permite ao testador submeter o 10 módulo, salvar um esboço do módulo, adicionar o módulo como um favorito, ou cancelar criação do módulo. Um módulo salvo como um esboço não pode ser acrescentado a quaisquer scripts.

Um módulo exemplar pode ser um módulo de "Visualizar Fatu- ramento" que permite a um usuário ver informação ou detalhes com relação 15 à conta do usuário. Uma etapa de teste para o módulo de "Visualizar Fatu- ramento" pode ser "Clicar na Tabulação de Conta'", para a qual o resultado esperado é "tabulação de Conta deve abrir". Uma outra etapa de teste pode ser "Clicar no vínculo 'Detalhes de Conta"', para a qual o resultado esperado é "Detalhes de conta resumidos devem ser mostrados". Uma outra etapa de 20 teste pode ser "Clicar em 'Mais visualização", para a qual o resultado espe- rado é "Todos os detalhes de conta devem ser exibidos".

Em uma outra modalidade do MSD 106, uma interface de usuá- rio pode incluir menus suspensos para permitir ao usuário introduzir outra informação a respeito do script. Por exemplo, o usuário pode descrever a 25 probabilidade de falha e impacto de falha para o script, e com base na des- crição do usuário o sistema pode calcular uma pontuação de teste baseada em risco para o script. Por exemplo, um usuário pode selecionar dentre as escolhas suspensas Baixo, Médio, Alto e Muito Alto em um menu suspenso para "probabilidade de falha" e dentre as escolhas suspensas Baixo, Médio, 30 Alto e Muito Alto em um menu suspenso para "impacto de falha". Uma lista de atributos configuráveis é então completada. Estes atributos podem ser ligados diretamente para uma ferramenta de teste subjacente (por exemplo, campos HP QC).

Também em uma outra modalidade, um testador pode pesquisar para o tipo de dados de teste que será exigido para o script. O usuário pode selecionar dados de teste que são exigidos para executar o teste, introduzir 5 uma descrição dos dados de teste exigidos e introduzir comentários adicio- nais a respeito do tipo de dados. O usuário pode introduzir comentários adi- cionais a respeito da configuração específica dos dados de teste exigidos. Por exemplo, o usuário pode especificar "Cliente deve ter uma ordem de a- bertura". O MSD 106 pode exigir adicionalmente que o testador introduza 10 certos dados para o script. Os dados exigidos podem incluir, por exemplo, tipo de cliente (por exemplo, negócio ou consumidor), tipo de endereço e produto (por exemplo, linha terrestre, banda larga, ou telefone móvel). O MSD 106 pode exigir que o testador introduza menos, mais ou outros dados para o script.

A figura 14 mostra um diagrama conceituai de uma modalidade

do sistema NTG 100. Tal como mostrado na figura 14, o sistema NTG 100 pode incluir uma camada de apresentação 1410, uma camada de compo- nente de negócio 1420, uma camada de integração 118 e uma camada de dados 1440. A camada de apresentação 1410 inclui os componentes de in- 20 terface de usuário (UI) 1412 que renderizam e formatam dados para exibição para os usuários 1402, incluindo gerenciadores de projetos, testadores e condutores de testes, e obtêm e validam dados que os usuários 1402 intro- duzem. A camada de apresentação 1410 também inclui os componentes de processo Ul 1414 que acionam o processo usando componentes de proces- 25 so de usuário separados para evitar codificar rigidamente o fluxo de proces- so e lógica de gerenciamento de estado nos elementos Ul propriamente di- tos. A camada de componentes de negócio 1420 implementa lógica de ne- gócio e fluxo de trabalho. A camada de componentes de negócio 1420 inclui os componentes de negócio 1422 que implementam a lógica de negócio da 30 aplicação. A camada de componentes de negócio 1420 também inclui as entidades de negócio 1424 e o fluxo de trabalho de negócio 1426. Entidades de negócio são objetos de transferência de dados na camada de componen- tes de negócio 1420. Estes são objetos comuns que podem ser usados atra- vés das camadas, incluindo a camada de apresentação 1410, para passar dados para todas as direções.

A camada de integração 118 fornece acesso agnóstico de lado servidor às camadas a montante (a camada de componentes de negócio 1420 e a camada de apresentação 1410), e fornece capacidade de se co- nectar por meio de uma interface comum a um ou mais sistemas de lado servidor tais como QC, Rational and Team Foundation Server. A camada de integração 118 implementa o seguinte projeto padrão: uma classe de base abstrata herda do ProvideBase (que é uma classe disponível com a estrutura .Net da Microsoft); cada implementador concreto por sua vez herda da clas- se abstrata indicada acima; Provedor apropriado (que pode ser um compo- nente NGT que se comunica com um sistema de lado servidor, tal como QC) é carregado com base na definição de tipo em um arquivo .config. A camada de integração 118 também inclui a fachada de integração. A fachada de in- tegração expõe uma interface simplificada para a camada de componentes de negócio 1420, e lê dados de uma combinação de objetos de transferência de dados em um ou mais repositórios ou caches de lado servidor (R2) e os intercala em um objeto de transferência de dados super comum para retor- nar para a camada de componentes de negócio 1420. A camada de integra- ção 118 também inclui os componentes NGT 1434 que se conectam por meio de interface entre a fachada de integração 1432 e a camada de dados 1440 e podem fornecer funcionalidade de mapeamento para a camada de integração 118, se exigido. A camada de integração 118 também inclui os componentes de armazenamento em cache 1436 e os componentes de fer- ramenta de teste 1438. Os componentes de ferramenta de teste 1438 são provedores servindo às solicitações para leitura/gravação de dados em uma ferramenta de teste 1404.

A camada de dados 1440 inclui os componentes de acesso a dados 1442 que centralizam a lógica necessária para acessar armazena- mento de dados NGT subjacente, expondo métodos para permitir acesso mais fácil e transparente à base de dados. Ela também inclui os ajudan- tes/utilitários de dados 1444 que são usados para centralizar funcionalidade genérica de acesso a dados, tal como gerenciar conexões de base de da- dos. A camada de dados 1440 também inclui os agentes de serviços 1436 que fornecem proxy de serviços Windows Communication Foundation para 5 falar com serviços de servidor de aplicação. A camada de dados 1440 pode ser um Bloco de Aplicação de Acesso a Dados de Biblioteca de Empresa ou uma camada de dados projetada personalizada. Alternativamente, ferramen- tas de mapeamento relacionai de objeto, tais como a Entity Spaces (disponí- vel pela EntitySpaces1 LLP), Genome (disponível pela TechTaIk, GmbH), 10 LINQ-to-SQL (disponível pela Microsoft Corporation), Entity Framework (também disponível pela Microsoft Corporation), ou LLBLGen Pro (disponível pela Solutions Design), podem ser usadas para gerar os componentes da camada de dados 1440.

As funções transversais 1405 no NGT 100 podem incluir, por 15 exemplo, segurança, manuseio de exceções, bloqueio e comunicação. O NGT 100 também pode incluir um cache local 1406. Saídas do NGT 100 po- dem incluir, por exemplo, a funcionalidade de correio eletrônico 1407 ou ou- tra funcionalidade de comunicação de informação. Mensagens de correio eletrônico podem incluir notificações para testadores com relação à rejeição 20 ou aprovação de script, notificações para aprovadores com relação a scripts que estejam prontos para revisão, e notificações com relação a questões de segurança, exceções de sistema e auditoria. O NGT 100 também pode co- municar informação para a ferramenta de teste 130 e para uma base de da- dos NGT 150.

A figura 15 mostra um diagrama lógico de uma modalidade do

sistema NTG 100. Na modalidade, a camada de apresentação 1410 pode incluir uma pluralidade dos componentes Ul 1412 e os processos Ul 1414, incluindo uma interface de administração 1511, uma barra de ferramentas de execução 1512, um projetista de módulo de script 1513, uma área de traba- 30 Iho unificada 102, uma interface de rastreamento de defeito 1514, as visuali- zações KPI 1515 e uma interface de revisão de aprovação 1516. A camada de componentes de negócio 1420 pode incluir uma pluralidade de compo- , *

nentes, incluindo um componente de perfil de usuário 1521, um componente de serviços de pesquisa 1522, um componente de serviços de fluxo de tra- balho 1523, um componente de regras de negócio 1524, um componente de manutenção de tempo 1525, um componente de autorização 1526 e um 5 componente de autenticação 1527. A camada de integração 118 pode incluir uma fachada de integração 1432, a qual pode incluir a agregação 1531, as APIs de integração 1532 e a decomposição 1533. A camada de integração 118 também pode incluir os provedores 1534, o armazenamento em cache 1535 e a transformação de dados 1535. A camada de dados 1440 pode for- 10 necer acesso a um provedor de dados 1541, aos ajudantes/utilitários dados 1542 e à API de serviços de dados 1543.

O MSD 106 pode ter um sistema de fluxo de trabalho centraliza- do para aprovar/rejeitar módulos e scripts. Quando um módulo é criado ou modificado, o MSD 106 notifica um aprovador para rever o módulo. O apro- vador pode escolher aprovar o módulo para ser usado em todos os scripts, para um subconjunto de scripts ou para um único script.

Quando o aprovador aprova uma mudança de módulo para to- dos os scripts, o MSD 106 muda o indicador de status do módulo para apro- vado para uso. A nova versão do módulo é atualizada junto a todos os s- 20 cripts contendo a versão anterior do módulo. Se o aprovador indicar que os scripts de teste exigirão revisão após a atualização, o MSD 106 muda o indi- cador de status do script para revisão pendente.

Quando o aprovador aprova uma mudança de módulo para um subconjunto de scripts, o MSD 106 orienta o usuário para introduzir um novo 25 nome para o módulo, e clona o módulo ao criar um novo identificador de módulo, ligando o novo módulo ao módulo existente, e mudando o indicador de status do novo módulo para aprovado para uso. O MSD 106 associa, ou adiciona, o novo módulo clonado ao subconjunto de scripts selecionado pelo aprovador. O aprovador pode escolher se os scripts exigem revisão seguinte 30 à adição do novo módulo ao subconjunto selecionado de scripts.

Quando o aprovador rejeita um módulo, o MSD 106 orienta o a- provador para introduzir um motivo para rejeição, marca o módulo como re- jeitado, e permite ao aprovador sugerir um módulo de substituição para os testadores. Então, o MSD 106 envia uma notificação, por exemplo, por cor- reio eletrônico, para o testador para notificar o testador de que o módulo está rejeitado. Então, o MSD 106 pode permitir ao testador atualizar e submeter 5 novamente o módulo, ou remover o módulo do script.

O MSD 106 também fornece um processo de aprovação de s- cript. Quando um novo script é criado, o MSD 106 estabelece o indicador de status do novo script para revisão pendente. O MSD 106 designa um revisor para rever o script. Quando o revisor aprova o script, o MSD 106 muda o 10 indicador de status do script para pronto para teste se todos os módulos no script estiverem aprovados para uso. Se alguns dos módulos no script esti- verem com aprovação pendente, o MSD 106 pode mudar o indicador de sta- tus do script para aprovação de módulo pendente.

Quando um script é atualizado, a pessoa atualizando o script pode indicar se o script exige revisão e o MSD 106 muda o indicador de sta- tus do script para revisão pendente. Então, o MSD 106 envia notificação pa- ra o revisor para rever o script. Se o revisor aprovar o script, o MSD 106 mu- da o indicador de status do script para pronto para teste se todos os módulos no script estiverem aprovados para uso. Se alguns dos módulos ainda esti- verem com aprovação pendente, o MSD 106 muda o indicador de status do script para aprovação de módulo pendente, até que todos os módulos no script estejam aprovados para uso. Se a pessoa atualizando o script indicar que o script não exige revisão, o MSD 106 muda o indicador de status do script para pronto para teste se todos os módulos no script estiverem apro- vados para uso. Se alguns dos módulos ainda estiverem com aprovação pendente, o MSD 106 muda o indicador de status do script para aprovação de módulo pendente, até que todos os módulos no script estejam aprovados para uso.

A figura 16 é um diagrama de blocos de hardware de alto nível de uma outra modalidade do sistema NTG. O sistema NTG 100 e seus com- ponentes chaves 104, 106, 108, 114, 116, 120 e 110 podem ser incorpora- dos como um sistema cooperando com componentes de hardware de com- putador, tal como um dispositivo de processamento 428, e/ou como métodos implementados por computador. O sistema NTG 100 pode incluir uma plura- lidade de componentes ou subsistemas de software. Os componentes ou subsistemas, tais como a ferramenta de planejamento de teste 104, o proje- 5 tista de script modular 106, o gerenciador de priorização e designação 112, a barra de ferramentas de execução de teste 108, o controlador de automação 114, a cadeia de fornecimento de dados de teste 116, o portal de reportação 120 e/ou a ferramenta de gerenciamento de defeitos 110, podem ser imple- mentados em hardware, software, firmware, ou qualquer combinação de 10 hardware, software e firmware, e podem ou não residir em um único espaço físico ou lógico. Por exemplo, os módulos ou subsistemas referidos neste documento e que podem ou não estar mostrados nos desenhos, podem es- tar localizados remotamente uns dos outros e podem ser acoplados por meio de uma rede de comunicação.

A lógica, conjunto de circuitos e processamento descritos anteri-

ormente podem ser codificados em uma mídia legível por computador, tal como uma CDROM, disco, memória flash, RAM ou ROM, um sinal eletro- magnético, ou outra mídia legível por máquina, como instruções para execu- ção por um processador. Alternativamente ou de forma adicional, a lógica 20 pode ser implementada como lógica analógica ou digital usando hardware, tal como um ou mais circuitos integrados, ou um ou mais processadores e- xecutando instruções; ou em software em uma interface de programação de aplicações (API) ou em uma Biblioteca de Vínculo Dinâmico (DLL), funções disponíveis em uma memória compartilhada ou definidas como chamadas 25 de procedimento local ou remoto; ou como uma combinação de hardware e software.

A lógica pode estar representada (por exemplo, armazenada) em uma mídia legível por computador, mídia legível por máquina, mídia de sinal propagado e/ou mídia portadora de sinal. A mídia pode compreender 30 qualquer dispositivo que contenha, armazene, comunique, propague ou transporte instruções executáveis para uso por um sistema, aparelho ou dis- positivo de instruções executáveis ou em conexão com ele. A mídia legível por máquina pode ser seletivamente, mas não está limitada a isto, um sinal eletrônico, magnético, ótico, eletromagnético ou infravermelho ou um siste- ma semicondutor, aparelho, dispositivo ou mídia de propagação. Uma lista não completa de exemplos de uma mídia legível por máquina inclui: um dis- 5 co magnético ou ótico, uma memória volátil tal como uma Memória de Aces- so Aleatório "RAM", uma Memória Somente de Leitura "ROM", uma Memória Somente de Leitura Programável e Apagável (isto é, EPROM) ou Memória flash, ou uma fibra ótica. Uma mídia legível por máquina também pode inclu- ir uma mídia tangível na qual instruções executáveis são impressas, já que a 10 lógica pode ser armazenada eletronicamente como uma imagem ou em um outro formato (por exemplo, por meio de uma varredura ótica) e então com- pilada e/ou interpretada ou processada de outro modo. A mídia processada pode então ser armazenada em um computador e/ou memória de máquina.

Os sistemas podem incluir lógica adicional ou diferente e podem ser implementados em muitos modos diferentes. Um controlador pode ser implementado como um microprocessador, microcontrolador, circuito inte- grado de aplicação específica (ASIC), lógica distinta, ou uma combinação de outros tipos de circuitos ou lógica. De forma similar, memórias podem ser DRAM, SRAM, Flash, ou outros tipos de memória. Parâmetros (por exemplo, condições e limiares) e outras estruturas de dados podem ser armazenados e gerenciados separadamente, podem ser incorporados em uma única me- mória ou base de dados, ou podem ser organizados logicamente e fisica- mente em muitos modos diferentes. Programas e conjuntos de instruções podem ser partes de um único programa, programas separados, ou distribu- idos através de diversas memórias e processadores.

Embora várias modalidades da invenção tenham sido descritas, estará aparente para as pessoas de conhecimento comum na técnica que muitas outras modalidades e implementações são possíveis dentro do esco- po da invenção. Desta maneira, a invenção não é para ser restringida exceto considerando as reivindicações anexas e suas equivalências.

Claims (20)

1. Método para projeto de script modular, compreendendo: receber, em um componente projetista de script modular, infor- mação de script para um script modular, onde a informação de script com- preende informação de script submetida por usuário e informação de módulo existente; gerar uma lista de módulos sugeridos com base na informação de módulo existente; receber, no componente projetista de script modular, uma sele- ção de um próximo módulo de um usuário, a seleção do próximo módulo compreendendo: selecionar o próximo módulo dentre a lista dos módulos sugeri- dos, ou uma solicitação para criar um novo módulo; e gerar o novo módulo se a seleção do próximo módulo compre- ender a solicitação para criar o novo módulo.

2. Método de acordo com a reivindicação 1, em que gerar a lista de módulos sugeridos com base na informação de módulo existente com- preende: analisar uma base de dados incluindo uma pluralidade de módu- los e scripts para determinar a lista de módulos sugeridos com base na in- formação de módulo existente.

3. Método de acordo com a reivindicação 2, compreendendo a- dicionalmente: receber, do usuário, uma modificação para o novo módulo; obter aprovação da modificação de um aprovador, onde a apro- vação obtida da modificação é para um subconjunto da pluralidade de s- cripts; atualizar o subconjunto da pluralidade de scripts para incluir a modificação aprovada.

4. Método de acordo com a reivindicação 2, em que gerar o novo módulo compreende: receber informação de novo módulo do usuário, e gerar o novo módulo com base na informação de novo módulo; e o método compreende adicionalmente: obter aprovação do novo módulo de um aprovador, e atualizar, quando aprovação é obtida do aprovador, a base de dados para incluir o novo módulo.

5. Método de acordo com a reivindicação 1, em que a informa- ção de script submetida por usuário compreende adicionalmente informação de etapa de teste, informação de resultado esperado, informação de conhe- cimento profissional exigido de testador e informação de tipo de dados exigi- dos.

6. Método de acordo com a reivindicação 2, em que gerar o novo módulo compreende: receber uma seleção de um módulo armazenado do usuário, gerar o novo módulo ao clonar o módulo armazenado seleciona- do e editar o módulo armazenado selecionado clonado; e o método compreende adicionalmente: obter aprovação do novo módulo de um aprovador, e atualizar, quando aprovação é obtida do aprovador, a base de dados para incluir o novo módulo.

7. Método de acordo com a reivindicação 3, em que a informa- ção de novo módulo compreende: informação de conhecimento profissional exigido de testador, e o aprovador é selecionado com base em conhecimentos profis- sionais do aprovador e na informação de conhecimento profissional exigido de testador.

8. Método de acordo com a reivindicação 1, compreendendo a- dicionalmente: adicionar o próximo módulo ao script modular, e atualizar a lista de módulos sugeridos com base no próximo mó- dulo.

9. Método para projeto de script modular, compreendendo: receber, em um componente projetista de script modular, infor- mação de script para um script modular de um usuário, onde a informação de script compreende informação de script submetida por usuário e informa- ção de módulo existente; analisar uma base de dados incluindo uma pluralidade de módu- los e scripts para determinar uma lista de módulos sugeridos com base na informação de script, e exibir a lista de módulos sugeridos para o usuário; receber, no componente projetista de script modular, uma sele- ção de um primeiro módulo do usuário, onde o primeiro módulo é seleciona- do dentre a lista dos módulos sugeridos; adicionar o primeiro módulo ao script modular; atualizar a lista de módulos sugeridos com base no próximo mó- dulo, e exibir a lista atualizada de módulos sugeridos para o usuário; e receber, no componente projetista de script modular, uma sele- ção de um segundo módulo do usuário, a seleção do segundo módulo com- preendendo: selecionar o próximo módulo dentre a lista atualizada dos módu- los sugeridos, ou uma solicitação para criar um novo módulo; e gerar o novo módulo se a seleção do próximo módulo incluir a solicitação para criar o novo módulo.

10. Método de acordo com a reivindicação 9, em que a informa- ção de script submetida por usuário compreende informação de etapa de teste, informação de resultado esperado, informação de conhecimento pro- fissional exigido de testador e informação de tipo de dados exigidos.

11. Método de acordo com a reivindicação 9, em que gerar o novo módulo compreende: receber informação de novo módulo do usuário, e gerar o novo módulo com base na informação de novo módulo; e o método compreende adicionalmente: obter aprovação do novo módulo de um aprovador, o aprovador sendo selecionado com base em conhecimentos profissionais do aprovador e na informação de conhecimento profissional exigido de testador, e atualizar, quando aprovação é obtida do aprovador, a base de dados para incluir o novo módulo.

12. Método de acordo com a reivindicação 9, em que gerar o novo módulo compreende: receber uma seleção de um módulo armazenado do usuário, e gerar o novo módulo ao clonar o módulo armazenado seleciona- do e editar o módulo armazenado selecionado clonado; e o método compreende adicionalmente: obter aprovação do novo módulo de um aprovador, e atualizar, quando aprovação é obtida do aprovador, a base de dados para incluir o novo módulo.

13. Sistema para projeto de script modular, compreendendo: um processador de computador; e uma memória em comunicação com o processador de computa- dor, a memória compreendendo lógica para um componente projetista de script modular, onde a lógica quando executada pelo processador de compu- tador induz o processador de computador para: receber, no componente projetista de script modular, informação de script para um script modular de um usuário, onde a informação de script compreende informação de script submetida por usuário e informação de módulo existente; gerar uma lista de módulos sugeridos com base na informação de módulo existente; receber, no componente projetista de script modular, uma sele- ção de um próximo módulo do usuário, a seleção do próximo módulo com- preendendo: selecionar o próximo módulo dentre a lista de módulos sugeri- dos, ou requerer solicitação para criar um novo módulo; e gerar o novo módulo se a seleção do próximo módulo compre- ender a solicitação para criar o novo módulo.

14. Sistema de acordo com a reivindicação 13, em que gerar a lista de módulos sugeridos com base na informação de módulo existente compreende: analisar uma base de dados incluindo uma pluralidade de módu- Ios e scripts para determinar a lista de módulos sugeridos com base na in- formação de módulo existente.

15. Método de acordo com a reivindicação 14, compreendendo adicionalmente: receber, do usuário, uma modificação para o novo módulo; obter aprovação da modificação de um aprovador, onde a apro- vação obtida da modificação é para um subconjunto da pluralidade de s- cripts; atualizar o subconjunto da pluralidade de scripts para incluir a modificação aprovada.

16. Sistema de acordo com a reivindicação 14, em que gerar o novo módulo compreende: receber informação de novo módulo do usuário, e gerar o novo módulo com base na informação de novo módulo; e o método compreende adicionalmente: obter aprovação do novo módulo de um aprovador, e atualizar, quando aprovação é obtida do aprovador, a base de dados para incluir o novo módulo.

17. Sistema de acordo com a reivindicação 13, em que a infor- mação de script submetida por usuário compreende informação de etapa de teste, informação de resultado esperado, informação de conhecimento pro- fissional exigido de testador e informação de tipo de dados exigidos.

18. Sistema de acordo com a reivindicação 14, em que gerar o novo módulo compreende: receber uma seleção de um módulo armazenado do usuário, e gerar o novo módulo ao clonar o módulo armazenado seleciona- do e editar o módulo armazenado selecionado clonado; e o método compreende adicionalmente: obter aprovação do novo módulo de um aprovador, e atualizar, quando aprovação é obtida do aprovador, a base de dados para incluir o novo módulo.

19. Sistema de acordo com a reivindicação 16, em que a infor- mação de novo módulo compreende: informação de conhecimento profissional exigido de testador, e o aprovador é selecionado com base em conhecimentos profis- sionais do aprovador e na informação de conhecimento profissional exigido de testador.

20. Sistema de acordo com a reivindicação 13, compreendendo adicionalmente: adicionar o próximo módulo ao script modular, e atualizar a lista de módulos sugeridos com base no próximo mó- dulo.