Quality Assurance & Test Center
Experiência, Metodologia e Ferramentas
Março de 2008
Quality Assurance & Test Center
Índice
1.
Enquadramento
3
2.
Experiência e referências
2.1 Evolução e principais projectos
2.2 Certificações
3
3
4
3.
Metodologia de testes Link
4
3.1
3.2
3.3
3.4
3.5
4
5
5
6
7
Principais características
Tipos de teste
Iteração
Ciclo de vida
Coverage e métricas
4.
Estrutura de equipa
7
5.
Ferramentas e testware Link
8
5.1
5.2
Ferramentas
Testware Link
8
9
6.
Testes de aceitação
9
7.
Infraestrutura e logística
10
8.
Metodologia de testes SOA
10
16-06-2008
 Link, 2008
Pág. 2
Quality Assurance & Test Center
1. Enquadramento
O objectivo do presente documento é fornecer uma visão simplificada da oferta da Link na área de
Quality Assurance. Esta resulta da experiência da Link adquirida ao longo de vários anos, sobretudo no
Brasil, e pontualmente em Portugal.
Esta oferta assenta em 3 pilares base, que importa enumerar:
• Experiência – Adquirida nos vários projectos na área de testes e que permitiram obter um
conjunto valioso de best practices e um conjunto de recursos humanos experientes e com knowhow específico;
• Metodologia – A metodologia utilizada pela Link, além de seguir os padrões internacionais
existentes na área de testes, incorporou alguns pormenores significativos resultantes da
experiência adquirida;
• Ferramentas – Os projectos de testes apenas têm possibilidade de serem eficazes e eficientes
se utilizarem ferramentas adequadas que permitam automatizar todo o processo dos testes.
2. Experiência e referências
A Link possui uma vasta experiência em projectos de Quality Assurance e Serviços de Teste, que
remonta ao ano de 1999, aquando do início de vários projectos na Vivo (Brasil). Esta experiência tem
sido sucessivamente enriquecida ao longo do tempo, quer na dimensão dos projectos quer nas vertentes
de negócio e sistema que envolve.
2.1 Evolução e principais projectos
Ao longo dos anos a Link tem efectuado um conjunto de projectos relevantes que lhe permite assegurar
um know-how consistente e formar uma massa crítica de recursos na área de testes.
Enumeram-se sumariamente os principais projectos, sendo que o detalhe de cada um destes se
encontra em anexo.
Pós-Pago
P2K
1999
2000
Revenue
Assurance
SMP-Serviço
Móvel Pessoal
APOLO
GSM Vivo
2003
2004
2006
2002
Business
Simulat ion
2007
1999: Startup do Baby da Telesp Celular. Equipas de consultores até 2002
• 1999: Startup do Baby da Telesp Celular. Equipas de consultores até 2002;
• 2000: Implementação do sistema pós-pago P2K da Vivo;
• 2001: Criada a empresa Aitec do Brasil;
• 2002: Inicio de projectos com equipas mistas portuguesas e brasileiras;
• 2003: Regras SMP (Serviço Móvel Pessoal) – Vivo;
• 2004: Projecto APOLO: Migração/Unificação sistema pré-pago da Vivo;
• 2006: Implementação GSM na Vivo;
• 2007: Business Simulation.
16-06-2008
 Link, 2008
Pág. 3
Quality Assurance & Test Center
2.2 Certificações
A importância dada pela Link à qualidade na execução dos seus projectos, incluindo a área de testes, é
suportada pelas certificações que possui nesta área.
• ISTQB - International Software Testing Qualifications Board
Certificação internacional na área de Testes de Software.
• ISO 9001 - Sistema de Gestão da Qualidade, NP EN ISO 9001:2000, certificada pela EIC para
“desenvolver serviços integrados de sistemas, desenvolver soluções e consultoria”.
• NATO e UEO - Acreditação pela ANS (Agência Nacional de Segurança) para trabalhar com
material classificado do governo português, NATO e UEO até ao nível “Secreto”.
• Certificação para exercer actividades na indústria de armamento.
3. Metodologia de testes Link
3.1 Principais características
A metodologia de testes da Link, assenta num conjunto de princípios base que, além de seguirem as
best practices e conceitos dos modelos padronizados, incorpora a experiência adquirida pela Link ao
longo dos anos na área de testes.
Abordagem iterativa
A abordagem iterativa, baseia-se nas seguintes características:
• Em cada iteração são adicionados novos e refinados;
• Re-working dos testes (tal como o software…) em cada iteração;
• Não existem testes fechados.
Ferramentas de suporte
É um dos aspectos essenciais da metodologia, visto que o nível de exigência dos sistemas actuais, o
tempo de execução dos projectos, a natural instabilidade ao nível das correcções/alterações que são
necessárias, automatismos ao nível dos testes, entre outros aspectos, obriga a que todo o processo seja
suportado em ferramentas.
Foco muito grande nos testes de regressão
O conceito de iteração em conjunto com as capacidades das ferramentas, permite que os testes de
regressão desempenhem um aspecto central no processo.
Estes são essenciais na garantia de qualidade do software produzido, no sentido em que permitem
validar de forma quase-automática, o sistema como um todo, após cada iteração.
Automatização dos testes
A reutilização de testware produzido no âmbito dos vários projectos que a Link tem executado, além dos
produzidos no próprio projecto permite que grande parte dos testes sejam automáticos. Um dos
benefícios, consiste na rapidez de execução dos testes em cada nova iteração.
16-06-2008
 Link, 2008
Pág. 4
Quality Assurance & Test Center
3.2 Tipos de teste
Tipo
Objectivo
Dimensão
Qualidade
Integridade
Garantir que os procedimentos e métodos de acesso à base de dados
funcionam correctamente sem corrupção de dados.
Fiabilidade
Funcionais
Garantir que as funcionalidades do target estão correctas, incluindo a
navegação; entrada, processamento e obtenção de dados.
Funcionalidade
Assegurar que o target e processos background funcionam de acordo com
os modelos e processos de negócio definidos.
Assegurar que a UI fornece ao utilizador o acesso e navegação apropriada.
Adicionalmente, assegurar que os objectos na UI funcionam como
esperado e de acordo com os standards.
Verificar se os requisitos de performance foram atingidos. Consiste em
medir e avaliar: tempos de resposta, taxas de transacção e outros
requisitos “time sensitive”.
Verificar os comportamentos de performance para as transacções ou
funções de negócio designadas, em condições de workload variáveis.
System
Performance
Stress
Verificar que o target funciona adequadamente e sem erros nas seguintes
condições de stress.
System
Performance
Volume
Verificar que o target funciona adequadamente em cenários de grande
volume de dados.
System
Performance
Verificar as situações ao nível da segurança aplicacional (funcionalidades e
dados) e ao nível de sistema (acesso ao sistema e à aplicação).
Funcionalidade
Ciclo de Negócio
User Interface
Performance
Load
Segurança e
Acessos
Failover e
Recovery
Configuração
Verificar que os processos de recuperação (manuais ou automáticos)
recuperam correctamente a sgbd, aplicações e sistema, para um estado
desejado.
Verificar que as funcionalidades do target funcionam correctamente em
diferentes configurações de hardware e software.
Instalação
Verificar que o target é instalado correctamente em cada uma das
configurações de hardware definidas, em várias condições.
Funcionalidade
Fiabilidade
System
Performance
Fiabilidade
Fiabilidade
Fiabilidade
3.3 Iteração
Uma das características importantes da metodologia da Link, assenta no conceito de iteração. Esta
acontece quando se executa um ciclo de vida do processo de testes aplicado ao software target ou a um
conjunto de deliverables associados a este (ex: especificações). Consequentemente, está intimamente
ligado à fase em que o projecto de desenvolvimento se encontra.
Em cada iteração são adicionados novos testes e refinados outros, por forma a ir construindo uma base
sustentável de trabalho e ao mesmo tempo, responder às necessárias necessidades e adaptações do
projecto. Em cada iteração, é realizado um re-working dos casos de teste (tal como o software).
Um dos principais objectivos da avaliação é “medir a completude da iteração, através da verificação dos
requisitos que foram implementados”.
Regra das iterações
16-06-2008
 Link, 2008
Pág. 5
Quality Assurance & Test Center
Um dos aspectos que usualmente tem impacto nos projectos de teste, refere-se às condições em que
cada iteração é executada, nomeadamente na fase final do projecto (fase de Transição tradicional). Isto
porque as iterações finais influenciam directamente a entrada em produção do software target.
É usual existirem mal-entendido entre os vários stakeholders envolvidos, que resultam muitas vezes de
indefinição das condições de execução da iteração.
Neste enquadramento, devem ser definidas entre as partes (cliente, equipa de desenvolvimento e equipa
de testes) as regras e condições associadas a cada iteração, considerando os seguintes aspectos:
• As regras devem ser definidas para cada tipo de iteração considerada;
• Devem ser definidos os prazos de disponibilização dos deliverables alvo de teste;
• Condições de entrega dos deliverables alvo de teste;
• Condições de rejeição e interrupção de iteração;
• Critérios de avaliação e completude do software target.
3.4 Ciclo de vida
Uma das principais características da metodologia da Link, assenta no conceito de ciclo de vida dos
testes. Tal como a figura abaixo ilustra, este consiste nos seguintes passos:
1. Planeamento dos testes;
2. Design dos testes;
3. Implementação dos testes;
4. Execução dos testes (de integração e de sistema);
5. Avaliação dos testes.
Planear
testes
Design dos
testes
Implementação
dos testes
Execuç ão dos
Execuç
testes na fase
de Integraç
Integra ção
[Refazer testes]
Avaliar
testes
Execuçção dos
Execu
testes na fase de
Testes Sistema
[Refazer testes]
Este modelo tradicional não pode no entanto ser aplicado de forma independente do “projecto de
desenvolvimento” a que está associado. Ambos os projectos devem evoluir em paralelo, tendo em conta
16-06-2008
 Link, 2008
Pág. 6
Quality Assurance & Test Center
as várias iterações que o projecto possui.
Em resumo, em cada iteração, deve ser considerado um ciclo de vida, à semelhança do que acontece
com o “projecto de desenvolvimento”.
3.5 Coverage e métricas
Uma das principais questões associadas aos testes refere-se ao conceito de completude dos testes. Isto
é, saber até que ponto é que os testes conseguem aferir a qualidade do software target.
Test-Coverage
As métricas de test-coverage usadas pela Link respondem à questão “Quão completos estão os
testes?”.
As métricas mais usadas são as seguintes:
• Requirements-based : verificação de Use Cases;
• Code-based : execução de todas as linhas de código.
A escolha da métrica depende em grande parte da estratégia de testes adoptada. Devem ser usadas as
seguintes regras:
• Se os requisitos estiverem completamente catalogados
o Adoptar uma estratégia de coverage requirements-based, como medida quantificáve
para a completude dos testes;
• Se a estratégia de teste for formulada em termos de “qual a quantidade do source code foi
executada por testes” (usual em sistemas críticos)
o Adoptar uma estratégia de coverage code-based.
4. Estrutura de equipa
A equipa de testes tem uma estrutura própria que, apesar do esforço poder variar ao longo do ciclo de
vida, é mantida ao longo do mesmo.
Esta estrutura, juntamente com a metodologia aplicada, facilita a implementação de um dos factores
críticos de sucesso de um projecto de testes: entrosamento entre a equipa de testes, de
desenvolvimento e os key users do cliente.
A estrutura típica adoptada está representada na figura abaixo. Esta pode variar conforme as
características específicas do projecto, organização do cliente, estrutura da equipa de desenvolvimento,
etc.
16-06-2008
 Link, 2008
Pág. 7
Quality Assurance & Test Center
Cliente
Testes
Gestor Projecto
Testes
Gestor Projecto
Cliente
Pontos
Situação
Períodicos
Desenvolvimento
Gestor Projecto
Desenv.
Pontos
Situação
Períodicos
Key User 1
Test Designer
Key User n
Admin.
Redes/DBA
Responsável
Técnico
Responsável
Técnico
Progress
Reports
Tester 1
Tester n
Prog. 1
Prog. n
5. Ferramentas e testware Link
5.1 Ferramentas
A Link possui uma experiência considerável em 2 suites de referência do mercado:
• Quality Center da HP/Mercury Interactive;
• CARS da Compuware.
Além destas ainda usamos pontualmente ferramentas de outros fornecedores (ex: IBM/Rational).
Vertente
Gestão global de testes
Tracking defeitos
Testes funcionais
Testes performance
Descrição
Ferramenta
Gestão do planeamento, design,
implementação, execução, avaliação das
actividades dos testes e artefactos.
• Quality Center (HP/Mercury)
Reporte de defeitos, tracking da resolução,
etc.
• Quality Center
Verificação dos requisitos funcionais e de
usabilidade
• Quality Center: Win Runner, QuickTest,etc.
Análise e validação da performance
• Performance Center: Load Runner
(HP/Mercury)
• QA Center (Compuware)
• GO-GestorOcorrências (Link)
• CARS (Compuware)
• Vantage (Compuware)
Test coverage monitor
Análise de Cobertura dos testes
• Quality Center
Dynamic Measurement
Análise de execução do código, para
detectar os erros de memória, performance,
etc
• Performance Center (HP/Mercury)
Gestão de Projecto
Gestão de projecto de testes
• MSProject
População de SGBD
Data Acquisition, manipulação de dados,etc.
• Quest Data Factory
• Rational Suite (Purify)
• FileAID (Compuware)
Ferramentas SGBD
16-06-2008
Gestão das bases de dados de teste.
 Link, 2008
• SQL Server, Navigator
Pág. 8
Quality Assurance & Test Center
5.2 Testware Link
Ao longo do tempo e na sequência dos vários projectos que têm vindo a ser efectuados, a Link
desenvolveu testware específico que, pela sua flexibilidade, têm sido adaptados e reutilizados com
sucesso. Estes tanto abrangem aplicações com alguma complexidade, como scripts SQL.
Enumeramos na tabela abaixo, alguns exemplos do testware Link, sendo a lista detalhada se encontra
no anexo correspondente.
Vertente
Nome
Descrição
Gestão global de
testes
Gestão do planeamento, design,
implementação, execução,
avaliação das actividades dos
testes e respectivos artefactos.
• Link Test Manager
Tracking defeitos
Report de defeitos, tracking da
resolução, etc.
• GO-Gestor Ocorrências
Ferramenta construída em MS Access com forms interactivos
para registo, gestão da execução dos testes e relatórios de status.
Ferramenta adaptada pela Link para utilização não só nos
projectos de teste, como também nos de desenvolvimento.
Construção Casos
de Testes produtividade
Template para criação de casos
de testes
• QCTemplate.xls
Gerador de massa
de testes
Geração de bilhetes de
chamadas de telefone móvel
para processamento e geração
de factura POS-PAGO
• Genbir
Simulador
processamento
Processamento de chamadas de
telefone móvel em lote para
verificar o motor tarifário online
• processa_chamadas.sh
Ficheiro excel contendo templates pré-definidos para criação de
casos de testes. Após a criação e validação dos casos de testes na
spreadsheet, efectua-se a importação directa para a ferramenta
HP-QualityCenter através de um Plug-in disponível para o efeito.
Interface WEB intuitiva que permite a parametrizacão de vários
cenários de chamadas para geração de bilhetes em massa para
processamento e geração de factura de pagamento.
Script SHELL para simulação de chamadas PRE-PAGO em lote
– processa arquivo contendo chamadas de diversos cenários
6. Testes de aceitação
A metodologia da Link considera a execução da fase de testes de aceitação, que pelas suas
características, devem ser acordadas e planeadas com o cliente.
Existem 2 estratégias principais para a implementação destes testes:
• Aceitação formal;
• Aceitação informal ou testes Alfa;
Aceitação formal
São uma extensão dos testes de sistema, sendo planeados e executados com o mesmo cuidado e
detalhe destes. As suas principais características:
• Os casos de teste são um sub-conjunto dos testes de sistema;
• Podem ser totalmente automatizados;
• As actividades e artefactos são os mesmos que os dos testes de sistema.
16-06-2008
 Link, 2008
Pág. 9
Quality Assurance & Test Center
Aceitação informal ou Alfa
Os procedimentos de teste não são definidos de forma tão rigorosa como os da “aceitação formal”. As
funcionalidades e processos de negócio a testar estão identificadas e documentadas, mas não existem
casos de teste particulares a executar. Enumeram-se de seguida as suas principais características:
• O tester individual é que define o que fazer;
• É frequentemente feito pela organização do end-user;
7. Infraestrutura e logística
Um dos aspectos essenciais nos projectos de testes, refere-se às infra-estruturas e logística necessárias
à execução do projecto. É necessário garantir os seguintes aspectos:
• Réplica, o mais similar possível, do ambiente de produção, nomeadamente:
o Servidores aplicacionais e web (se for necessário);
o Servidores de base de dados;
o Comunicações (ex:rede com a mesma largura de banda);
• Réplica da base de dados de produção, caso o software-target necessite de acesso/reutilização
deste dados;
• Acesso às várias versões do software-target que forem sendo construídas, ou a partes deste, por
forma a conseguir efectuar os testes necessários e definidos no plano.
8. Metodologia de testes SOA
A estratégia que de testes SOA, baseia-se no ciclo de vida dos serviços em cada uma das camadas de
abstracção:
• Business Solutions Services,
• Business Services e
• Business Infra-structure Services.
Cada uma destas camadas é alvo de testes específicos com fins específicos.
Não obstante este facto, podemos sempre enquadrar a nossa aproximação na metodologia clássica de
testes de sistemas, apresentada na figura seguinte.
Start-Up Projecto
Business
Solution
Requisitos
Utilizador
Aceitação Sistema
1
Requisitos
Software
8
2
7
Testes
Aceitação
Testes
Sistema
Business
Services
Arquitectura
Business
Infrastructrure
16-06-2008
3
Código
 Link, 2008
6
4
5
Testes
Integração
Testes
Unitários
Pág. 10
Quality Assurance & Test Center
Testes de Aceitação
Estes testes traduzem a plena aceitação dos requisitos do utilizador e correspondem aos testes da
camada de Business Solutions, os quais têm como critérios fundamentais de qualidade os requisitos de
negócio.
Testes de Sistema e Integração
Estes testes traduzem a perspectiva dos requisitos/regras de negócio e a perspectiva de integração.
No universo SOA, os requisitos/regras de negócio correspondem à descrição das actividades expressas
em BPMN ou BPEL.
Relativamente aos testes de integração, em SOA, correspondem à invocação de Serviços,
nomeadamente à invocação dos Business Infra-structure Services.
Note-se que os testes sobre os Business Services, que no fundo consistem em verificar o fluxo de
chamadas aos Business Infra-structure Services, compreendem desde logo dois níveis de teste do
modelo clássico.
Testes Unitários
Finalmente, os testes unitários traduzem o correcto funcionamento de cada Business Infra-structure
Services. Estes serviços são testes individuais a cada serviço.
Estes testes são usualmente mais complexos que os testes “normais”, devido à reutilização e ao facto de
cada um dos níveis de serviços ter um ciclo de vida próprio e autónomo dos restantes, o que não
acontece na visão clássica do ciclo de vida de uma aplicação.
16-06-2008
 Link, 2008
Pág. 11