fabrica de teste - tdc 2011
DESCRIPTION
Palestra de Otimario Cavalcanti da T&M Testes que teve sua apresentação dia 07/07/2011 no TDC 2011 - The Developer's Conference na Trilha de TesteTRANSCRIPT
+Fábrica de Serviços de Testes Atestando a qualidade do produto de software
Diretor de Projetos e Serviços
Otimário Cavalcanti Jr
+
4 serviços 3 ramos 3 focos 30 anos
Software Testing Core & Only
Business
Telecomm
Finance “Melhor Metodologia do
Mercado Financeiro”
Industry
Quality by Assurance Testes pró-ativos
Quality by Control Testes reativos
Quality by Design Testes preditivos
Consultoria em Testes de Software (STPI)
Fábrica de Testes (ISVV)
Treinamentos em Testes de Software
Automação de Testes
Atuação
Presença
T&M em um
flash
+O que é uma Fábrica de Testes
T&M Testes de Software
Sua atuacão não se limita apenas à execução
É uma estrutura formada por profissionais especializados e capacitados
Processos e Metodologias otimizados
Ferramentas e Técnicas
Engenharia de Requisitos
Deve ATESTAR a qualidade dos sistemas Construídos ou Modificados pelo Desenvolvimento
+
Valores de Uma Fábrica
A que se Propõe uma Fábrica de Testes
T&M Testes de Software
Testar mais RÁPIDO Uso de Processos ágeis, Paralelismo,
Testar MELHOR Maior Cobertura, Multiplas Visões do Testes, Foco na Qualidade,
Testar Mais BARATO Redução Re-trabalho, redução do caminho crítico do projeto, menor #ciclos de
testes
Você quer melhorar sua Qualidade e Produtividade?
40% da melhoria se obtém com melhores Testes de Sistema e de Aceite
60% da melhoria se obtém com melhor especificação, modelagem, construção e teste unitário
+
Homologação
Atuação da Fábrica
Codificação
Design
Planejamento &
Especificação
Testes de Sistemas
Testes de Unidade & Integração
Estudo de Viabilidade
& Proposta de
Entrega
Implantação
Testes de Especificações
Revisões Formais de Casos de Uso
Code Quality Assurance Automatizado
Teste de Desempenho
Automação de Testes Unitários
Automação de Testes de Sistemas
Testes de Disponibilidade, Resiliência e Estabilidade
Testes de Propagação de Impactos (Banco de Dados)
Code Security Audit
Testes de Usabilidade baseados em ISO/IEC 18529
Execução manual e automatizada de Testes de Aceite
ilustrado no V model
Geração de Massa e Ambiente de Testes
Preparação de Testes de Aceite Automatizados
Coleta de Indicadores, Análise Causal e Sugestões de Melhoria
Code Weakness & Exposure
+
Governança da Qualidade para estabelecimento de uma parceria de confiança e competência duradoura
Modelo de Fábrica de Serviços de Testes
Modelo de Atendimento que difere de demandas do tipo Projeto e modelo Time & Material
Estimativa algorítimica,
substanciada e rápida
Programação da produção
planejada e monitorada
Operação focada em demandas novas, evolutivas e
corretivas não emergenciais
Gestão de OS previsível e eficiente
Conhecimento documentado e
executável
SLA’s done right, on-time & on-budget
Comunicação em aperfeiçoamento
contínuo
alinhado com ITIL V.3
+Modelo de Governança
Governança da Qualidade
Responsabilidade Prestação de Contas Transparência
Implanta o modelo onde a fábrica é responsável pela qualidade acordada com o cliente e o solicitante é responsável pela qualidade informada dos artefatos de entrada
Estabelece um Sistema Corporativo de Metas de
Performance de Qualidade e Testes, aumentando a visibilidade da área de
sistemas
Exige justiça, recompensando a
qualidade e acabando com a impunidade
Divulga as metas de qualidade e testes; classifica artefatos,
recursos e equipes por critérios públicos e
transparentes
Eqüidade
• A qualidade final depende dos testes que depende da qualidade do código este por sua vez depende da qualidade do desenho técnico, da modelagem, da especificação.
• Os parceiros se comprometem a trabalhar dentro de resultados e metas previamente acordados
• SLA’s valem para os dois lados • Desempenho por resultados valorizado • Problemas de um parceiro são problemas do outro • Desempenho é recompensado com mais serviço
• Números abertos na mesa, • Modelo de Estimativa de Tamanho, Esforço, Prazo e Custo é aberto e algorítmico
+Modelo de Governança
Governança da Qualidade
Responsabilidade Prestação de Contas Transparência
Implanta o modelo onde a fábrica é responsável pela qualidade acordada com o
cliente e o solicitante é responsável pela
qualidade informada dos artefatos de entrada
Estabelece um Sistema Corporativo de Metas de
Performance de Qualidade e Testes, aumentando a visibilidade da área de
sistemas
Exige justiça, recompensando a
qualidade e acabando com a impunidade
Divulga as metas de qualidade e testes; classifica artefatos,
recursos e equipes por critérios públicos e
transparentes
Eqüidade
• Estabelecer uma parceria onde confiança prevaleça, além de tempo e perseveranças • Responsabilidade é de todos (qualidade será media para todos os artefatos e todas etapas do desenvolvimento • A qualidade final depende dos testes mas a qualidade dos testes depende da qualidade do código que por sua vez depende da qualidade do desenho técnico, da modelagem, da especificação.
• Os parceiros se comprometem a trabalhar dentro de resultados e metas previamente acordados • Os parceiros são responsabilizados financeiramente pelos seus resultados
• SLA’s valem para os dois lados • Desempenho por resultados valorizado • Problemas de um parceiro são problemas do outro • Desempenho é recompensado com mais serviço
• Números abertos na mesa, ganhos de produtividade são programados com investimentos sincronizados de ambos os lados. • Modelo de Estimativa de Tamanho, Esforço, Prazo e Custo é aberto e algorítmico • O modelo é aberto mas cada parceiro gerencia suas equipes, sem interferência dos outros.
Inatenção com os
Resultados
Evita-se Responsabilização
Ausência de Comprometimento
Receio de Conflitos
Ausência de Confiança
Focam em resultados coletivos
São responsáveis
uns pelos outros
Comprometem-se com decisões e planos de
ação
Discutem sobre idéias e resolvem conflitos maduramente
Confiam uns nos outros
+
Status da OS
Cancelada Aberta Pendente Rejeitada Agendada Aprovada Em Andamento Concluída
Atividades Solicitante
Atividades Fábrica
Fornece ao solicitante o prazo segundo os
indicadores obtidos de tamanho, qualidade,
produtividade.
Acorda novos indicadores com a
fábrica para a reabertura da OS
Avalia e valida a demanda segundo as
informações recepcionadas contra os
artefatos fornecidos (SLA de 24 horas úteis)
Solicita serviço via ferramenta Sistema
da fábrica (ou próprio) com
informações de tamanho, qualidade e
produtividade
Aguarda até que a OS seja finalizada
conforme planejado, acompanhando os
indicadores de progresso da OS
Acorda novos indicadores com o solicitante
Recebe estimativa inicial de prazo e
custo em função das informações
fornecidas e aguarda revisão da validação
da fábrica
Executa a OS conforme planejado, fornecendo
indicadores de progresso
Revisa e finaliza a OS, encaminha os artefatos de teste referentes ao serviço executado e
disponibiliza payment workflow
Aprova execução da OS com os prazos e custos fornecidos
Não acorda informações de prazo,
esforço e ou custo com fábrica
Solicitante
Fábrica
Modelo de Atendimento
Disponibiliza acesso para abertura de OS e acompanhamento dos status, fornecendo de
imediato um orçamento de esforço, prazo e
custo
Verifica agendamento da fábrica
Recepciona os artefatos e inicia
payment workflow
Agenda a execução da OS segundo a
programação da fábrica (factory workload)
Analisa os motivos de cancelamento para
melhorias no processo
Fluxo da OS
Conclusão da OS
S
N
Execução da OS
Aprovação de execução
da OS
Agendamento da OS
Cancela a OS
Check Ok?
Rejeita OS e aguarda
informações
Pendência de
Avaliação Técnica
Abertura da OS
+6 Grandezas Essenciais
Modelo de Estimativa de Tamanho, Qualidade, Produtividade, Esforço, Prazo e Custo é aberto e algorítmico
Info
rmaç
ões
para
Age
ndam
ento
da
SO
In
form
açõe
s O
btid
as
para
Apr
ovaç
ão d
a SO
Modelo de Estimativa
Tipo
OS
Programação da Fábrica
OS
PF IN
Tipo
Ativ
idad
e
Qualidade definida 1 2 3 Produtividade
estabelecida Tamanho estimado
4 Esforço conhecido
5 Prazo adequado
6 Custo derivado
Nova
Evolutiva
Corretiva não Emergencial*
Capacidade
Demandas
OUT Planejamento
Eft Df
Tecnologia Envolvida
Preparação
Execução
Evidenciação
*corretivas emergenciais devem ser tratadas de forma diferenciada, como força-tarefa, e não como OS de fábrica.
Gestão
Conhecimento e Reuso Disponíveis
+C
apac
idad
e d
e C
élu
las
da
Fáb
rica
at
ual
Formação, Capacitação, Certificação, Gestão & Relacionamento com Clientes
Flexibilidade Máxima de Células
Flex
ibili
dad
e d
as C
élu
las
-20
%
+ 2
0%
Capacidade Mínima Capacidade Máxima
Modelo de Capacidade e Flexibilidade N
omin
al
18 06
05
04
03
12
10
08
=
=
=
=
para manutenção do conhecimento
para atendimento
padrão
para atendimento de picos de demanda
células de trabalho
fábrica de serviços
recursos
+
N1
Modelo de Gestão do Conhecimento
Torna o conhecimento
executável
Documenta o conhecimento
Utiliza “gaps” de demanda
Promove Workshops
Aproveita o conhecimento formal já existente (reuso)
N2
N3
N4
N5
...para antecipar e ou complementar os casos de teste nas aplicações mais prováveis de serem testadas na seqüência pela programação da fábrica
Os casos de testes e massas de teste existentes serão a baseline deste conhecimento
Os casos de teste devem ser automatizados para se ganhar produtividade no tempo de execução e manutenção da atualização
Caso de Teste passa a ser um artefato compartilhado entre as partes podendo ser modelos comportamentais da aplicação. Todo o testware será armazenado em ferramentas fornecidas pelo cliente e dentro da sua metodologia
...para aquisição do conhecimento das aplicações
+Processos da
Operação Ponto Focal Solicitante Ponto Focal Fábrica
Recepcionar as demandas do ponto focal do Solicitante, fornecendo número de protocolo
Garantir que os critérios de entrada na fábrica de testes estejam sendo cumpridos rigorosamente
Fornecer orçamento para OS (ordem de serviço)
Direcionar OS para líder de projeto (segundo programação da fábrica)
Executar e Posicionar andamento da OS para o Solicitante
Efetuar Sign-off dos entregáveis enviados, verificando se os critérios de saída da fábrica de testes estão sendo cumpridos rigorosamente
Enviar para o ponto focal do Solicitante os entregáveis aplicáveis
Verificar issues do processo pré-estabelecido e aprimorar buscando um processo mais produtivo
Receber demandas das áreas de Desenvolvimento de Sistemas do Solicitante, e enviá-las para a fábrica.
Validar a especificação, estimativas e informações da demanda para garantir que estejam com condições mínimas para serem enviadas para a Fábrica.
Verificar adequações necessárias para efetuar estimativa
Verificar prazos e custos associados à OS e aprovar execução
Acompanhar andamento da OS
Receber da fábrica evidências dos testes e demais entregáveis aplicáveis
Dar aceite dos entregáveis enviados pela fábrica.
Propor melhorias nos processos [1;2;3;4;7] para evolução e perpetuação do relacionamento
Recepcionar 1
2 Verificar
Entradas/Saída
Estimar
Programar
Executar
Verificar Saídas/Entradas
Entregar
Aprimorar
6
7 8
3
4
5
Modelo de Comunicação
+ baseado
em riscos
Modelo de Operação MoSCoW
Priorities
III
I II
IV
Must Test
Should Test
Could Test
Won’t Test
Prob
abili
dade
(Ris
cos
Técn
icos
)
Impacto (Riscos para o Negócio)
req1
req2
req3
req4
req5
reqn
Focus of
System Test
Level
Focus of
Development Test
Level Seguimos padrões mundiais de teste (BS, IEEE)
Participamos e representamos a ABNT junto à ISO na
elaboração do
Padrão de Testes ISO 29.119
+EfT > 90% EfT > 95% SLA’s EfT > 85%
Modelo de SLA
[<=5]
[<=30% UCP]
[<=7d corridos; <=2d para show stoppers]
80%
[<=12%]
[<= 10% UCP]
# de ciclos de teste
Densidade de falhas encontradas
MTTR
Cobertura dos Casos de Teste
Reincidência de falhas
Volatilidade de requisitos
Distribuição da severidade das falhas
Qualidade e Produtividade é responsabilidade
de todos
[Show Stopper <8%;
High <35%]
[<=4]
[<=20% UCP]
[<=5d corridos; <=1d para show stoppers]
90%
[<=9%]
[<= 5% UCP]
[Show Stopper <6%;
High <25%]
[<=3]
[<=10% UCP]
[<=3d corridos; <=0,5d para show
stoppers]
100%
[<=6%]
[<= 1% UCP]
[Show Stopper <4%;
High <15%]
Entrega do SUT no prazo combinado [<5 dias de atraso] [<3 dias de atraso] [<2 dias de atraso]
Devem ser reavaliados a cada 3 meses
de projeto
para pelo menos 88% das OS´s
+Métricas e Indicadores
Indicadores preliminares “Densidade de Falhas -> Qualidade -> Confiabilidade” n 1 carro que anda 100.000km com apenas uma falha tem uma
Confiabilidade de 1/100.000 ou 99,9990% ou 4,3 Sigma
n Um carro com Confiabilidade 6 SIGMA teria que apresentar apenas 3,4 falhas rodando 1.000.000 de km!!!!
n Diz-se de uma especificação de 2.000 UCP (ou PF) com 200 falhas de especificação, que sua n Densidade de Falhas é de 10% (200/2.000) ou sua
n Densidade de Acerto é de 90% (1-200/2.000) ou que
n Sua qualidade é de 90% ou que
n Sua Confiabilidade Sigma é de 2,8 (escala de 1 a 6)
©2008 T&M Testes de Software (11) 4191.5456 - www.tmtestes.com.br - [email protected] - 17
Sigma Level: 2,43 2,50 2,59 2,84 3,08
82% 84% 87% 91% 93%
Maturidade Defeitos/KLOCem produção
Defeitos/PF5 defeitos por PF é a média
de injeção de falhas
Eficácia de Testes necesssária
para uma mesma quallidade de entrada
CMM I 7,5 0,8 85%CMM II 6,2 0,6 88%CMM III 4,7 0,5 91%CMM IV 2,3 0,2 95%CMM V 1,1 0,1 98%
+Highlights
n Responsabilidade=>Confiança n A base é PF recebida (por amostragem 5% confere-se)
n Testes seguem o modelo “Margarida” (<10% overlap)e não “Elipse” (100% overlap)
n Lista de Critérios de aceite derivados de RqN, RqU e RqS, única e compartilhada e atualizada por todos, nasce no início do projeto
n Evidência é a assinatura de que testou, não “print screen”
n Gestão de Testes PREDITIVA (espera-se X falhas por etapa, vamos localizá-los)
n Conceito de Esforço que muda dependendo do Qin e Qout
n Confiabilidade dos artefatos medidos em Sigma.
n Modelo de Estimativa público e transparente
T&M Testes de Software
+
São Paulo – Porto Alegre – Brasília
Fone/Fax: +55 11 2596-3350 e-mail: [email protected] – www.tmtestes.com.br
“Quality Testing does not happen by accident; It’s the Result of an Intelligent Effort”