Alats Seminario V03 3

Testes de Software & Vôo 3054 da TAM Leonardo Molinari Consultor Sênior de Qualidade de Software

Antes uma pequena história...

Agenda

Projeto de Software X Testes

Principais Problemas em Web App

Capacidade de um Sistema Web

Teste em Sistemas Embarcados

Aplicação Web (Imaginária) 3054

Heróis na Qualidade

Projeto de Software X Testes Sistema sob Testes Estado do Programa Entradas Intencionais Estado do Sistema Recursos do sistema E de Configuração Entrada de outros Processos, clientes e servidores Saídas Monitoradas Estado do Programa, incluindo saídas inesperadas Estado do Sistema Impacto na conexão dos devices / recursos de sistema Saída para outros Processos, clientes e servidores

Curva de Falhas

Projetos Distintos ao longo do tempo tempo “ desgaste” “ mortalidade infantil” índice de falhas

Detecção de Erros: O Custo dos Erros

Principais Problemas em Web App

Conexões com BD e Queries

Código do Application Server

Hardware do WebServer

Network em si

Capacidade de um Sistema Diagrama de Gargalos

Capacidade de um Sistema

Capacidade de Utilização

= [ saída atual ]/[ capacidade de projeto ]

Capacidade de Eficiência

= [ saída atual ]/[ capacidade efetiva ]

0 Capacidade De Projeto Capacidade Efetiva Saída Atual Period #5 Saída Atual Period #8 Gerencia de Foco : Perda na Capacidade de Produção

Visão de Demanda 6am 12pm 6pm 12am 6am 12pm 6pm 12am Day 1 Day 2 6am 12pm 6pm 12am 6am 12pm 6pm 12am Day 1 Day 2 Demand Surge Cyclical Random & Infrequent

Sistemas Embarcados (Embedded Systems) = Hardware + Software

Ex: Máquinas de Jogos, Painel Eletrô-Eletrônico, Aparelhos Médicos, Sistemas de Aviões, etc.

Testes em Sistemas Embarcados

Teste do Hardware (isolado)

Teste do Software (isolado)

Testes de Caixa-Branca

Testes Unitários

Teste do Software e Hardware Juntos

Teste de Aceitação do Usuário

Problemas:

Custo

Simulação e Dados de Testes

Deve-se fazer análise de Risco Forte

Visão Geral de Análise de Risco

Opções de Risco

Aplicação Web 3054

Fato: Acidente com Vôo 3054 da TAM, ocorrido em 17 de julho de 2007 às 18h50min.

Premissa: imagine que o Vôo 3054 TAM é uma aplicação Web.

Perguntas:

O que fazer evitar um desastre Web?

O que fazer para evitar um desastre Web:

As máquinas Web onde estão os servidores estão funcionando perfeitamente? Estão preparadas para receber o "pouso" do sistema Web?

Os servidores (o "aeroporto") estão sobrecarregados antes mesmo do sistema Web entrar no ar?

O firewall ("torre de controle") que protege os dados e outras partes do sistemas está devidamente configurado que evitar "intrusos"?

Os servidores possuem espaço em disco e em memória suficientes?

Os requisitos de instalação ("normas internacionais") do sistema web confere com o que foi disponibilizado (real) para instalação do sistema em produção?

O sistema Web foi testado (o mais próximo possível) em termos de performance (teste de desempenho) no ambiente que espelhasse a realidade?

Todos os requisitos funcionais e não funcionais foram testados antes do sistema entrar em produção? E os requisitos que se precisa testar e não foram especificados? Ambiente chuvoso pode ser um requisito não-funcional...

Ao entrar em produção o sistema Web foi testado de forma mínima para verificar se o mesmo consegue "entrar no ar"?

As contingências ("segurança") para o sistema foram definidas e testadas de modo a ter certeza que se algo falhar haverá socorro ("bombeiros e ambulância")?

A segurança das informações dos usuários ou do negócio envolvido, está garantido com o sistema no ar ou não? Tem backup?

Todos os funcionários, consultores, analistas envolvidos estão capacitados e cientes de tudo que existe e deve ser feito ?

O sistema recebe manutenções periódicas de modo a acompanhar seu desempenho (ser pró-ativo)?

O tempo para Teste foi adequado em todas as etapas? (teste é antes, durante e depois)

Um defeito quando encontrado foi devidamente reportado, com as devidas providências tomadas?

O risco de um defeito não resolvido pode inviabilizar o sistema a médio ou longo prazo? (efeito rachadura. Exs: peça com defeito não resolvido)

Até que ponto o “log” do sistema (caixa-preta) está funcionando corretamente sem inviabilizar a performance?

Conceito de Herói:

Herói : Alguém exemplar que reúne em si os atributos necessários para superar de forma gloriosa ou excepcional um determinado problema ou obstáculo ou meta.

Super-Herói : é a realização máxima, ou suprema, do mito do herói.

Anti-herói : é alguém realiza as mesmas atitudes do herói, porém por motivos egoístas ou que não tem vocação heróica.

Por que precisamos de heróis na Qualidade?

Para nos inspirarmos na ATITUDE correta.

Quem pode ser um herói?

VOCÊ e qualquer um que tenha atitude correta perante a qualidade.

Pode ser alguém simples que faz coisas extraordinárias.

Quais atitudes devemos ter para sermos um profissional-herói:

Faça parte de seu time;

Tenha comprometimento;

Seja visível para todos;

Faça bons relacionamentos;

Tenha sempre iniciativa. Não confundir com precipitação;

Seja respeitável e decente;

Respeite a diversidade;

Use estratégias ganhadoras sempre, e busque sempre novas;

Trate de sua saúde. Aparência não é saúde;

Não se acomode nunca. Busque melhorar sempre!

Reflexões

“ Na Qualidade,

não avançar é recuar!”

Reflexões

Teste

é coisa séria...

Mas pode e deve ser prazeroso...

Conhecendo o Palestrante

Engº de Sistemas-UERJ & Pós-Graduado em Gestão Pela Qualidade Total – Univ. Estácio de Sá

Consultor de Sênior de Qualidade de Software

Certificação/Experiência (metodologia, processos, ferramentas e ministrar treinamento) em Testes, Requisitos, Ger. de Configuração, Ger. Projetos, OpenSource