This document summarizes a project to create a testing cell for a company from 2012-2014. The project aimed to improve software quality by focusing testing efforts, defining metrics, and continuously measuring applications. Over four testing cycles, issues discovered decreased from 400 initially to zero as development and documentation improved. The results were higher sales, better delivery processes, and more efficient development and quality control.

1. Projeto Célula de Testes
2012 - 2014
Patrocinador:
Gerente do Projeto:
Responsável pelo Negócio:
Gerente do Produto:
Responsável pela Operação:
Fase de Encerramento
Maio/2014

2. Agenda
 Introdução
 Contexto
 Proposta do Projeto
 Metas do Projeto
 Premissas e Restrições
 Estratégia
 Cronograma/Custo
 Resultados
 Conclusão

3. Introdução
Este material tem como objetivo apresentar uma visão geral,
pós-projeto, da criação da Célula de Testes da Empresa para
as partes interessadas em todos os níveis da hierarquia.
Desta forma, serão abordados, resumidamente, pontos de
importância, que remontam desde a fase de início do projeto
até a fase encerramento em fevereiro de 2014.

4. Contexto
Problema: Grande número de erros encontrados nos “sites” da empresa.
Consequências:
- Em torno de 50% de Vendas iniciadas e não efetivadas nos “sites”;
- Reclamações dos clientes quanto a problemas nas atividades de entrega dos itens
comprados;
- Área de negócios da empresa tem a percepção da inexistência ou deficiência do
processo de testes de software.
Necessidades:
- Retirar o foco dos testes de software dos desenvolvedores;
- Criar o processo de testes de software;
- Buscar elementos especializados em testes de software;
Solução: Contratar empresa especializada em Projeto de Testes de Software;

5. Proposta do Projeto
Realizar ORQUESTRAÇÃO DA QUALIDADE
com foco em Testes Funcionais de Aplicações a
serem executados em ambiente de testes,
homologação e/ou produção, identificando
problemas e propondo soluções.
Visando a criação do processo particularizado e sua
melhoria continuada.
Proposta básica:
1. Célula de Testes recebia as aplicações e artefatos de desenvolvimento;
2. Célula de Testes identificava as não-conformidades e os defeitos;
3. Célula de Testes detalhava os problemas encontrados e encaminhava às equipes de desenvolvimento
para tratamento.

6. Metas do Projeto
 Planejar estratégias para entrega de teste capazes de garantir que as funcionalidades do
sistemas estejam de acordo com os requisitos do negócio;
 Definir métricas e validar as características de qualidade dos testes;
 Executar testes das funcionalidades mapeadas na entrega de acordo com o Plano de
estratégia de testes definido;
 Realizar o processo de auditoria das exigências de qualidade e de avaliação dos resultados
de controle de qualidade identificando problemas e indicando soluções para garantir
padrões de qualidade apropriados (Garantia de Qualidade);
 Medir constantemente a qualidade das aplicações visando melhoria continuada do processo
de teste;
 Produzir documentação de testes e indicadores técnicos e gerenciais.

7. Premissas e Restrições
Premissas:
 Equipe de negócio e/ou desenvolvimento do cliente, localizada no Rio de Janeiro, estava disponível
para sanar dúvidas ou explanações mais detalhadas;
 Facilidade de comunicação com a Equipe de testes;
 As funcionalidades da aplicação possuem documentação adequada;
 Problemas nas funcionalidades já implementadas nos “sites” deveriam ser tratados primeiro;
 A comunicação dos resultados do projeto deveria ser homogênea, de forma a atingir entendimento
idêntico à todas as partes interessadas;
 Erros deveriam ser zerados;
Restrições:
 Equipe do cliente possuía apenas 1 hora diária para atendimento à equipe de testes;
 Equipe de Testes remota, localizada em São Paulo;
 Algumas partes da aplicação ainda estavam sendo levantadas;
 Prazo máximo de 22 meses para implementação do Projeto, com saneamento de todos os problemas
observados;
 Custo máximo de R$ 2.000.000,00

8. Estratégia
Levantamento Inicial de Funcionalidades
Em junho de 2012 a Equipe de Testes recebeu toda documentação de desenvolvimento necessária para avaliação e definição
dos trabalhos de testes das funcionalidades da aplicação.
Foram levantadas as seguintes demandas de teste para a aplicação:
 Funcionalidades implementadas – 500;
 Funcionalidades documentadas – 600;
 Funcionalidades à documentar – 500;
 Funcionalidades à levantar – 400.
Definição do Plano Estratégico de Testes
De acordo com as necessidades, com o levantamento inicial, com as premissas e restrições foi decidido que:
Comunicação com a Equipe de Testes seria diária, via telefone ou videoconferência Web e que o fluxo das
atividades seria controlado por ferramenta de gestão de fluxo via WEB;
 Comunicação com o Cliente diariamente para sanar dúvidas, devolução de erros nos testes para acerto seria
realizada pelo Gerente e/ou Equipe de Testes;
 Comunicação com o Cliente para apresentação de relatórios de indicadores seria realiada apenas pelo Gerente do
Projeto;
 Tipos de Testes automatizados, principalmente, de unidade, de integração, de interface e de estresse;
 Métricas de Qualidade – Indicadores de Resultado, Indicadores de Recursos, Indicadores Técnicos, indicadores de
Desempenho, Indicadores de Gestão, dentre outros ao longo do Projeto;
 Atuaríamos em 4 ciclos de testes levando em consideração a situação da preparação da documentação de
desenvolvimento da funcionalidade.

9. Estratégia
Definição dos Ciclos de Entrega de Testes
Como era premissa do projeto atendermos de imediato as funcionalidades já implementadas da aplicação, pois a empresa havia
detectado diversas incorreções que afetavam diretamente o negócio, foi decidido que o primeiro ciclo seria de teste das 500
funcionalidades implementadas e outros ciclos seriam escolhidos conforme a ordem de elaboração de documentação de
desenvolvimento.
Portanto,
 Ciclo de Testes 1 – Funcionalidades implementadas
 Recursos Estimados – 5 unidades
 Prazo Estimado - 5 meses;
 Custo Estimado – R$ 500.000,00
Ciclo de Testes 2 – Funcionalidades documentadas
 Recursos Estimados – 5 unidades
 Prazo Estimado - 6 meses;
 Custo Estimado – R$ 600.000,00
 Ciclo de Testes 3 – Funcionalidades à documentar
 Recursos Estimados – 5 unidades
 Prazo Estimado - 5 meses;
 Custo Estimado – R$ 500.000,00
 Ciclo de Testes 4 – Funcionalidades à levantar
 Recursos Estimados – 5 unidades
 Prazo Estimado - 4 meses;
 Custo Estimado – R$ 400.000,00

10. Estratégia
Encerramento do Projeto
Encerrar o projeto, identificar e registrar as liç ões aprendidas que servirão como base para planejamento de futuros
projetos.
Definição dos Ciclos de Entrega de Testes (continuação)
Em cada ciclo deveria ser apresentados semanalmente a documentação e os indicadores preliminares definidos pelo acordo e a
cada Marco deveria ser apresentados os relatórios de indicadores Técnicos e Gerenciais completos do período, conforme
abaixo:
Documentação - Plano de Testes Estruturado; Modelagem dos Cenários de Teste; Casos de Testes; Scripts de Automatização
dos Testes
Relatório de Indicadores Preliminares – Indicadores Técnicos para os Testes e Indicadores Gerenciais;
Relatório de Indicadores do Período - Indicadores Técnicos para os Testes e Indicadores Gerenciais;

11. Cronograma/Custo
Marcos Data Início
Estimado
Data Início
Real
Custo Situação
Início do Projeto
Levantamento, Planos e Definições
02/05/2012 R$ 100.000,00 Completo
Ciclo de Testes 1 – Funcionalidades
Implementadas
21/05/2012
Completo
Ciclo de Testes 2 – Funcionalidades
Documentadas
Completo
Ciclo de Testes 3 – Funcionalidades à
Documentar
Completo
Ciclo de Testes 4 – Funcionalidades à
Levantar
20/09/2013 Completo
Encerramento do Projeto
Registros do Projeto
Completo
R$ 600.000,00
R$ 550.000,00
R$ 400.000,00
R$ 300.000,00
R$ 50.000,00
22/10/2012
22/04/2013
22/01/2014
26/11/2012
06/05/2013

12. Resultados
 Ciclo de Testes 1 – Funcionalidades implementadas
 Documentação não conforme – 250
 Funcionalidades Testadas – 500
 Funcionalidades Retornadas com erro – 400
 Funcionalidades Re-testadas com erro – 100
 Funcionalidades Re-Testadas com erros distintos – 20
 Funcionalidades ainda c/problemas no final do Ciclo - 6
Ciclo de Testes 2 – Funcionalidades documentadas
 Documentação não conforme – 300
 Funcionalidades Testadas – 606
 Funcionalidades Retornadas com erro – 300
 Funcionalidades Re-testadas com erro – 90
 Funcionalidades Re-Testadas com erros distintos – 10
 Funcionalidades ainda c/problemas no final do Ciclo - 5
 Ciclo de Testes 3 – Funcionalidades à documentar
Documentação não conforme – 50
 Funcionalidades Testadas – 495
 Funcionalidades Retornadas com erro – 200
 Funcionalidades Re-testadas com erro – 50
 Funcionalidades Re-Testadas com erros distintos – 5
 Funcionalidades ainda c/problemas no final do Ciclo – 2
 Ciclo de Testes 4 – Funcionalidades à levantar
 Documentação não conforme – 20
 Funcionalidades Testadas – 382
 Funcionalidades Retornadas com erro – 100
 Funcionalidades Re-testadas com erro – 20
 Funcionalidades Re-Testadas com erros distintos – 2
 Funcionalidades ainda c/problemas no final do Ciclo - 0
Conforme o processo de testes foi sendo aprimorado foram verificadas diminuição dos índices de retorno
de funcionalidades testadas com erro, Vejamos:
Nota-se que o processo de desenvolvimento do Cliente foi sendo aprimorado dia-a-dia com a troca de
informações e de conhecimento do aplicativo entre as equipes.
No Ciclo de Testes 4, não só os testes estavam sendo desenvolvidos de forma mais rápida, mas também a
documentação estava conforme e o desenvolvimento com mais qualidade e menos erros.

13. Conclusão
 Processo de Testes definido e melhorado continuamente durante o ciclo de construção do software;
 Fluxo de Trabalho transparente e entendido por todos os envolvidos;
 Atribuições e competências, antes indefinidas e/ou parcialmente, estão descritas de maneira clara e objetiva;
 Obtenção de Documentação de testes apropriada;
 Os índices de erro de desenvolvimento do Cliente caíram à níveis desejáveis e próximos de zero;
 Os erros da aplicação em produção foram eliminados gerando aumento das vendas nos “sites” e melhoria do processo de
entrega das mercadorias compradas;
 Técnicos do Cliente ganharam agilidade no trabalho de desenvolvimento com descoberta rápida de erros;
 Técnicos do Cliente foram capacitados no entendimento da documentação de desenvolvimento e melhoraram seus índices de
incorreção no código;
 Controle de qualidade eficiente;
 Melhoria na Governança de TI do Cliente.

14. Obrigado
 Material Produzido para orientação na apresentação
de resultados das equipes de teste.
Responsável:
RMS – Serviços de Informática Ltda.
rmsil2@ig.com.br