tag:blogger.com,1999:blog-43097641325160739352024-02-06T18:03:27.541-08:00MPT.BRMelhoria do Processo de Teste BrasileiroUeslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-4309764132516073935.post-64398862566474515732011-09-21T08:09:00.000-07:002011-09-21T08:09:16.905-07:00Resumo livro BCTS: Capítulo 11 - Estimativas<div style="text-align: justify;">Olá Amigos!!</div><div style="text-align: justify;">Peço desculpas pelo tempo de ausência e pela demora em publicar este artigo conforme prometido.</div><div style="text-align: justify;">Mas visando ajudar aqueles que farão a prova em novembro, segue ai o resumo sobre Estimativas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Espero que ajude a todos da mesma forma que me ajudou.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Bons estudos e boa prova a todos!</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="font-size: large;">Capítulo 11 - Estimativas</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>1. Análise de pontos de Teste – (APT)</strong></div><div style="text-align: justify;"></div><div style="text-align: justify;">Toda técnica de medição e estimativa precisa considerar o ambiente e o local onde está sendo usada.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">APT é uma medida de tamanho de teste que, com acertos e calibragens, gera previsões de esforço e estimativas de tempo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">APT toma como premissa básica o tamanho do sistema em pontos de função e também considera todas as suas funcionalidades como ponto de partida.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>1.1. Filosofia da medição de pontos de teste</strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Além das informações coletadas com o desenvolvimento, os testes também são afetados pelos seguintes fatores:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>• O grau de complexidade do processo de teste</strong> - Sistemas mais complexos, mais horas de testes serão consumidas.</div><div style="text-align: justify;">•<strong> O nível de qualidade que se pretende alcançar com os testes</strong> - Nível mais alto de qualidade demanda maior esforço que demanda maior custo.</div><div style="text-align: justify;"><strong>• Grau de envolvimento dos usuários com os testes</strong> - Quanto mais os usuários participarem melhor o resultado obtido e menor pode ser o esforço de testar.</div><div style="text-align: justify;"><strong>• As interfaces que as funções tem com os arquivos</strong> - quanto maior o número de arquivos envolvidos nos casos de teste, mais difícil será testar.</div><div style="text-align: justify;"><strong>• A qualidade do sistema testado (o ciclo de reincidência dos defeitos)</strong> - Defeitos de desenvolvimento ou de projeto, tornam o trabalho de testar muito mais oneroso.</div><div style="text-align: justify;"><strong>• O nível de cobertura esperado com os testes</strong> - Os requisitos do sistema normalmente vão estabelecer o nível de cobertura exigido pelos testes.</div><div style="text-align: justify;"><strong>• A experiência e a produtividade da equipe de teste (medidos através de indicadores históricos)</strong> </div><div style="text-align: justify;"><strong>• O grau de automação dos testes</strong> - Permite níveis maiores de produtividade e facilita a documentação dos testes.</div><div style="text-align: justify;"><strong>• A qualidade do ambiente de teste, até mesmo sai capacidade de simular o ambiente de produção</strong> - O ambiente de teste deve estar próximo ou ser igual ao ambiente de produção.</div><div style="text-align: justify;"><strong>• A qualidade da documentação do sistema e, em especial, dos requisitos.</strong> </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Abaixo, estão descritas as atividades para estimativa de <strong>Tamanho</strong>.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>1.2. Total de pontos de teste (PT)</strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O número total de pontos de teste (PT) é dado pela soma das seguintes medidas</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Pontos de teste dinâmicos (PTDf);</div><div style="text-align: justify;">• Pontos de teste estáticos (PTE).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Considerando-se o tamanho do sistema em pontos de função e uma constante igual a 500, que representa o tamanho mínimo do sistema em pontos de função.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><em>1.2.1. Pontos de teste dinâmico (PTDf)</em></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os pontos de teste dinâmicos são calculados com base nas funções do sistema.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As funções medidas em pontos de função e tratadas em pontos de teste são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Entradas Externas (EE);</div><div style="text-align: justify;">• Saídas Externas (SE) e</div><div style="text-align: justify;">• Consultas Externas (CE).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os pontos de teste dinâmicos tomam como base também os seguintes elementos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Funções dependentes (FDf);</div><div style="text-align: justify;">• Qualidades dos requisitos relacionados às características de qualidade a serem testadas dinamicamente (QRd).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"> <em>1.2.1.1. Fatores Funções dependentes - FDf</em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O cálculo de funções dependentes é realizar de funcionalidade por funcionalidade e considera os seguintes fatores:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• <strong>Importância do Usuário (Ue)</strong> - Grau de importância que o usuário dá à função a ser testada;</div><div style="text-align: justify;">• Int<strong>ensidade de Uso (Uy) -</strong> Nível de uso da função por intervalo de tempo;</div><div style="text-align: justify;">•<strong> Interface (I)</strong> - Nível de relacionamento entre data-sets (arquivos) e as funções que estão sendo medidas;</div><div style="text-align: justify;">• <strong>Complexidade (C)</strong> - Medido pela quantidade de comandos IF ou Cases existentes no algoritmo.</div><div style="text-align: justify;">• <strong>Uniformidade (U)</strong> - Mede o nível de re-utilização do material de teste.</div><div style="text-align: justify;">• Fu<strong>nções padronizadas -</strong> já possuem uma formula própria de contagem, como as:</div><div style="text-align: justify;">• F<strong>unções de mensagens de defeitos;</strong></div><div style="text-align: justify;">• <strong>Funções de ajuda</strong> e</div><div style="text-align: justify;">• <strong>Estrutura de menu</strong>.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><em>1.2.1.2. Características de qualidade dinâmica (QRd)</em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As características de qualidade dinâmica (QRd) medem como a qualidade dos requisitos pode, afetar a qualidade dos testes. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Para essa medição, são consideradas:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Medidas Explícitas e</div><div style="text-align: justify;">• Medidas Implícitas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><em>1.2.1.2.1. Características Explicitas (CE)</em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Temos as seguintes características explícitas:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Funcionalidade (F); [Peso = 0,75]</div><div style="text-align: justify;">• Performance (P); [Peso = 0,10]</div><div style="text-align: justify;">• Segurança (S) e [Peso = 0,05]</div><div style="text-align: justify;">• Aderência e Efetividade (A). [Peso = 0,10]</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Fatores de medição para as CE em relação à qualidade dos requisitos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">0 – não é importante;</div><div style="text-align: justify;">3 – não é importante, mas precisa ser considerada;</div><div style="text-align: justify;">4 – tem importância média;</div><div style="text-align: justify;">5 – muito importante e</div><div style="text-align: justify;">6 – extremamente importante.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: cyan; color: black;">F = [Fator Medição x Peso]/4</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Fórmula de cálculo para Características Explicitas:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: cyan;">CE = F + P + S + A</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As características de Aderência e Efetividade dizem respeito aos testes de alto nível (sistema e aceitação).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Testes de alto nível geralmente usam técnicas de caixa-preta em sua execução. Os testes de alto nível mais conhecidos são os testes de sistemas e de aceitação.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Teste funcional</strong> - é o grupo de testes que avalia se o que foi especificado pelo usuário foi realmente implementado.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Teste de usabilidade está diretamente ligado a Funcionalidade (F) da aplicação.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Teste de Usabilidade</strong> - Avalia a facilidade de uso do sistema pelos usuários.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><em>1.2.1.2.2. Características Implícitas (CI)</em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As características implícitas são utilizadas quando há coleta de dados e/ou indicadores para futuras medições quanto a qualidade dos testes. Sempre que houver indicadores que possam ser utilizados para avaliar uma das características explícitas (funcionalidade, performance, segurança e aderência), consideramos que pode existir uma característica implícita associada.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Fórmula de cálculo para Características Implicitas:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><span style="background-color: cyan;"><strong>CI = n x 0,02 (onde n varia entre 0 e 4)</strong></span></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Fórmula de cálculo para QRd:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: yellow;">QRd = CE + CI</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Fórmula de cálculo para Ponto de Teste Dinâmico:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: yellow;">PTDf = PFf x FDf x QRd</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><em>1.2.2. Ponto de Teste Estático (PTE)</em></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os pontos do teste estático levam em considerações o sistema como um todo, diferentimente dos pontos de testes dinâmico, que consideram cada característica isoladamente.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes estáticos só devem ser considerados quando a equipe de teste adotar processos de revisão de documentação e de códigos usando checklists; caso contrário, devem ser descartados e terão valor nulo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O cálculo dos PTE toma como base os critérios de qualidade para avaliação das características anteriormente citadas (funcionalidade, performance, segurança e aderência).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: cyan;">PTE = 16 x n</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Fórmula de cálculo do Total de Pontos de teste:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: lime;">PT = ∑PTDf + (PF x PTE)/500</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Abaixo, estão descritas as atividades para estimativa de <strong>Esforço</strong>.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>1.3. Estimativa de horas de teste primárias (HTP)</strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O cálculo da estimativa do número de horas de teste primárias depende dos seguintes elementos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Qualificação da equipe de teste e</div><div style="text-align: justify;">• Ambiente de teste.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><em><strong>1.3.1. Qualificação da Equipe de Teste (QET)</strong></em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Este valor é determinado por base histórica e deve variar entre 0,7 e 2,0 considerando-se a experiência e qualificação da equipe de teste. Estes fatores estão ligados diretamente com a produtividade da equipe de testes.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: cyan;">QET = 0,7 a 2,0</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Quanto melhor e mais qualificada a equipe, menor será o índice do QET.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><em><strong>1.3.2. Ambiente de Teste (AT)</strong></em></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O ambiente de teste é medido levando em conta alguns fatores ambientais, tais como:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• <strong>Ferramentas de teste</strong> - existência e aplicabilidade de uma ferramenta de automação nas fases do teste.</div><div style="text-align: justify;">• <strong>Teste de Precedência</strong> - Para cada etapa do processo de teste, a atividade imediatamente anterior deve produzir bons resultados para que a atividade seguinte seja bem executada.</div><div style="text-align: justify;">• <strong>Documentação de teste</strong> - Uso de documentos padronizados.</div><div style="text-align: justify;">• <strong>Ambiente de desenvolvimento</strong> - faz referência à linguagem de programação utilizada.</div><div style="text-align: justify;">• <strong>Ambiente de teste</strong> - utilização do ambiente de teste.</div><div style="text-align: justify;">•<strong> Testware</strong> - Existência de materiais de teste disponíveis.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: cyan;">AT = soma dos fatores/21</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: yellow;">HTP = PT x QET x AT</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>1.4. Número total de horas de teste (THT)</strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As horas primárias de teste devem ser corrigidas com a inclusão das atividades relacionadas ao Índice de Planejamento e Controle (IPC), cujo percentual é dado pelos seguintes fatores:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Tamanho da Equipe (TE);</div><div style="text-align: justify;">• Ferramentas de gerenciamento (FG).</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong><span style="background-color: yellow;">IPC = 1 + (TE + FG)</span></strong> onde: <strong><span style="background-color: yellow;">THT = HTP x IPC</span></strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>1.5. Estimativa baseada no tamanho e na complexidade do caso de uso</strong></div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Esta forma de estimativa utiliza como imputs os seguintes dados:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Contagem do número de fluxo de um determinado caso de uso;</div><div style="text-align: justify;">• Média de passos de cada fluxo;</div><div style="text-align: justify;">• Contagem do número de exceções;</div><div style="text-align: justify;">• Contagem das regras de negócio (classificação: simples, média, complexas).</div><div style="text-align: justify;"><br />
</div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com1tag:blogger.com,1999:blog-4309764132516073935.post-20667933449728775732010-08-23T14:39:00.000-07:002010-08-23T14:39:19.819-07:00Resumo livro BCTS: Capítulo 8 – Gestão de Defeitos<span style="font-size: large;"><strong>Capítulo 8 – Gestão de Defeitos</strong></span><br />
<br />
<br />
<div> </div><strong>Erro:</strong> resultado de uma falha humana.<br />
<strong>Defeito:</strong> resultado de um erro existente num código ou num documento.<br />
<br />
<div> </div><div style="text-align: justify;">O processo de gestão de defeitos se baseia nos seguintes princípios:</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• O objetivo primordial é evitar defeitos;</div><div style="text-align: justify;">• Um dos princípios básicos para evitar defeitos é minimizar riscos, não só do projeto de desenvolvimento, mas também do projeto de teste;</div><div style="text-align: justify;">• Integração entre desenvolvedores e testadores através de uma ferramenta de gestão de defeitos;</div><div style="text-align: justify;">• Automação da gestão de defeitos é um fator muito importante para o sucesso;</div><div style="text-align: justify;">• Melhoria contínua e</div><div style="text-align: justify;">• Utilizar práticas de modelos de processo (Ex: CMMI).</div><br />
<br />
<div> <strong>1.8. Conceito de defeito</strong> </div><div style="text-align: justify;">O Defeito ocorre em função de algum desvio em relação ao requisito:</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Defeitos decorrentes de falta de concordância com a especificação do produto</strong> As especificações dizem uma coisa e o software faz outra.</div><div style="text-align: justify;">• <strong>Defeitos decorrentes de situações inesperadas, mas não definidas nas especificações do produto</strong> O gestor ou usuário não definiu nada nas especificações, porém o software age de maneira inesperada em determinadas situações.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">No entanto, defeitos podem decorrer da falta de entendimento do requisito ou simplesmente da falta de definição do requisito.</div><br />
<div> </div><strong>1.8.1. Tipos de Defeito</strong><br />
<div style="text-align: justify;">• <strong>Defeito de interface com o usuário;</strong></div><ul><li><div style="text-align: justify;"><strong>Defeitos de funcionalidade</strong> quando o sistema não faz algo que o usuário espera que o faça</div></li>
<li><div style="text-align: justify;"><strong>Defeitos de usabilidade</strong> dificuldades de navegação</div></li>
<li><div style="text-align: justify;"><strong>Defeitos de desempenho</strong> não atende com rapidez necessária as solicitações do usuário</div></li>
<li><div style="text-align: justify;"><strong>Defeitos de saída</strong> o resultado apresentado pelo software não corresponde ao que foi definido pelo usuário nas especificações ou foram mal projetadas </div></li>
</ul><div style="text-align: justify;"> • <strong>Defeitos introduzidos no tratamento de defeitos;</strong></div><ul><li><div style="text-align: justify;"><strong>Prevenção dos defeitos</strong> o programa não se protege de entradas de dados imprevistas</div></li>
<li><div style="text-align: justify;"><strong>Detecção dos defeitos</strong> o programa não trata, ou trata inadequadamente, as indicações de defeitos esultantes de suas ações</div></li>
<li><div style="text-align: justify;"><strong>Recuperação dos defeitos</strong> mesmo detectando o defeito, o programa falha porque não trata adequadamente a situação</div></li>
</ul><div style="text-align: justify;">• <strong>Defeitos de limite</strong> não consegue tratar ou trata inadequadamente valores extremos</div><div style="text-align: justify;">• <strong>Defeitos de cálculo</strong> efetua cálculo e produz resultado errado</div><div style="text-align: justify;">• <strong>Defeitos de inicialização ou fechamento</strong> ausência de inicialização ou fechamento de rotinas, arquivos, etc.</div><div style="text-align: justify;">• <strong>Defeitos de controle de fluxo</strong> declaração de variável erroneamente</div><div style="text-align: justify;">• <strong>Defeitos de manuseio ou de interpretação de dados</strong> ocorre quando um programa tem que passar um grupo de dados para outro programa</div><div style="text-align: justify;">• <strong>Defeitos de condição de disputa</strong> ocorre quando o programa espera uma resposta dos eventos A e B, sendo presumido que A sempre termina primeiro, mas B terminou primeiro</div><div style="text-align: justify;">• <strong>Defeitos de carga</strong> o programa não suporta um pico de serviço num determinado momento (estresse) ou uma carga alta de serviço por um tempo muito prolongado</div><div style="text-align: justify;">• <strong>Defeito de hardware e software</strong> incompatibilidades entre o programa e o ambiente onde é processado</div><div style="text-align: justify;">• <strong>Defeitos de controle de versão</strong> falha no processo de gestão de configuração</div><br />
<div> </div><strong>1.9. Processo de Gestão de Defeitos</strong><br />
Os elementos-chave do processo de gestão de defeitos são:<br />
<br />
<div> </div>• Prevenção de defeitos;<br />
<ul><li>Identificar os riscos críticos; </li>
<li>Estimar os impactos esperados; </li>
<li>Minimizar os impactos;</li>
</ul><br />
<div> • Linha-de-base (baseline) a ser entregue; </div>• Identificação dos defeitos;<br />
<ul><li>Encontrar defeito; </li>
<li>Relatar defeito; </li>
<li>Reconhecer defeito;</li>
</ul> • Solução do defeito;<br />
<ul><li>Priorizar a correção; </li>
<li>Programar a correção; </li>
<li>Corrigir o defeito; </li>
<li>Relatar a solução;</li>
</ul>• Melhoria do processo;<br />
• Relatório de gestão.<br />
<br />
<div> </div><strong>1.9.1. Prevenção de Defeitos</strong><br />
<br />
<div> A maneira mais elementar de prevenir defeitos é detectá-los nos estágios iniciais do desenvolvimento do software.</div><br />
<div> </div>Passos para prevenção de defeitos:<br />
<br />
<div> </div>• Identificar os riscos críticos;<br />
• Estimar os impactos esperados;<br />
• Minimizar os impactos;<br />
<br />
<div> </div><br />
<div><strong><em> 1.9.1.1. Identificar os Riscos Críticos</em></strong></div><br />
<div style="text-align: justify;"> A melhor maneira de fazer isso é identificar os tipos de defeitos que representam as maiores ameaças, ou seja, defeitos que podem colocar em risco o sucesso da construção, entrega e/ou operação do software.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">A ênfase desse passo não é identificar todos os riscos, e sim identificar os riscos críticos que podem prejudicar o sucesso do projeto e que merecem atenção especial.</div><br />
<div> </div><strong><em>1.9.1.2. Estimar os impactos esperados</em></strong><br />
<br />
<div> Segundo Beizer, a importância do defeito está diretamente ligada à:</div><br />
<div> </div>• Freqüência com que o defeito ocorre;<br />
• Custo da correção do defeito;<br />
• Custo da instalação;<br />
• Conseqüência.<br />
<br />
<div> </div><br />
<div><strong><em> 1.9.1.3. Minimizar os impactos esperados</em></strong></div><br />
<div> Minimizar os impactos esperados envolve a combinação das seguintes estratégias:</div><br />
<div> </div>• Eliminar o risco; (às vezes não é possível)<br />
• Reduzir a probabilidade de o risco se tornar um problema; (Mitigar os riscos)<br />
• Reduzir o impacto se houver problema. (contigenciar o risco)<br />
<br />
Algumas técnicas podem se utilizadas para reduzir o impacto esperado. Entre essas técnicas temos:<br />
<br />
<div> </div>• <strong>Garantia da Qualidade</strong> área de GQA<br />
• <strong>Treinamento e educação</strong> voltado para desenvolvimento, teste e usuários<br />
• <strong>Metodologias e padrões</strong> processos bem definidos, metodologias adequadas e padrões consistentes<br />
• <strong>Desenho defensivo;</strong><br />
• <strong>Código defensivo.</strong><br />
<br />
<div> </div><br />
<div> <strong>1.9.2. Linha-de-base (Baseline) a ser entregue</strong></div><br />
<div> Um produto a ser entregue é considerado baseline quando alcança um marco pré-definido em seu desenvolvimento. </div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Depois de o produto se tornar baseline, recomenda-se que este seja colocado sob gerenciamento de configuração. Um defeito é caracterizado quando um componente de um produto baseline não satisfaz seu conjunto de requisitos.</div><br />
<div> </div><strong>1.9.3. Identificação do defeito</strong><br />
<br />
<div>O defeito é considerado identificado quando reconhecido formalmente pelos desenvolvedores como defeito válido.</div><br />
<div> </div>As etapas envolvidas na identificação dos defeitos são:<br />
<br />
<div> </div>• Encontrar defeito;<br />
• Relatar defeito;<br />
• Reconhecer defeito;<br />
<br />
<div> </div><br />
<div><strong><em> 1.9.3.1. Encontrar defeito</em></strong></div><br />
<div>Esta etapa utiliza de técnicas como:</div><br />
<div> </div>• <strong>Técnicas estáticas</strong> Revisões, walkthrough e inspeções<br />
• <strong>Técnicas dinâmicas</strong> realização de Testes<br />
• <strong>Técnicas operacionais</strong> defeito descoberto como resultado de uma falha na operação do sistema<br />
<br />
<div> </div><strong><em>1.9.3.2. Relatar defeito</em></strong><br />
<br />
<div>Ao relatar um defeito, devemos dar atenção aos seguintes detalhes:</div><br />
<div> </div>• Resumo;<br />
• Precisão;<br />
• Neutralidade;<br />
• Isolamento;<br />
• Generalização;<br />
• Reprodução;<br />
• Impacto;<br />
• Provas.<br />
<br />
<div> </div>Ao relatar um defeito, devemos indicar, entre outras coisas, o impacto que ele representa tato para o sistema quanto para os negócios.<br />
<br />
<div> </div><strong><em>1.9.3.3. Reconhecer defeito</em></strong><br />
<br />
<div>Depois de detectado o defeito, o desenvolvedor deve decidir se ele é válido ou não.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Quando um grupo achar que é defeito (os usuário, por exemplo) e outro grupo achar que não é, as abordagens mais eficazes são:</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div>• Arbitragem pelo usuário;<br />
• Arbitragem pelo gerente de desenvolvimento.<br />
<br />
<div> </div><strong>1.9.4. Solução do defeito</strong><br />
<br />
<div>Tendo defeitos validados pelos desenvolvedores, se dá início ao processo de correção. Para isso são realizados os seguintes passos:</div><br />
<div> </div>• Priorizar a correção;<br />
• Programar a correção;<br />
• Corrigir o defeito;<br />
• Relatar a solução;<br />
<br />
<div> </div><br />
<div> <strong><em>1.9.4.1. Priorizar a correção</em></strong></div><br />
<div>Um método sugerido para priorização é classificar o defeito conforme os critérios a seguir:</div><br />
<div> </div><div>• <strong>Crítico</strong> sério impacto no negócio </div>• <strong>Grave</strong> erro grave ou pára de funcionar<br />
• <strong>Menor</strong> algo errado, mas não afeta os usuários<br />
<br />
<div> </div><br />
<div><strong><em> 1.9.4.2. Programar a correção</em></strong></div><br />
<div>Refere-se ao processo de alocação de recursos para a correção do defeito.</div><br />
<div> </div><strong><em>1.9.4.3. Corrigir o defeito</em></strong><br />
<br />
<div>Envolve a verificação de um ou mais produtos necessários para a remoção do defeito (p.e.: programas, documentos) e a execução da correção.</div><br />
<div> </div><strong><em>1.9.4.4. Relatar a solução</em></strong><br />
<br />
<div>Notificar todos os envolvidos a correção, natureza da correção e como a correção será liberada.</div><br />
<div> </div><strong>1.9.5. Melhoria do processo</strong><br />
<br />
<div>A ocorrência de defeitos, independente de sua importância, pode oferecer a oportunidade de avaliar o processo que os originou, de estudar como melhorá-los e prevenir possíveis falhas.</div><br />
<div> </div>Essa atividade deve abranger:<br />
<br />
<div> </div>• Avaliação do processo que originou o defeito e a compreensão do que o causou;<br />
• Se pertinente, propostas de mudanças processuais capazes de minimizar ou eliminar a causa do defeito.<br />
<br />
<div> </div><br />
<div><strong> 1.9.6. Relatórios de gestão</strong></div><br />
<div>O propósito dessa atividade é criar um registro completo dos desvios identificados durante o processo de teste para que sirvam de base a várias utilizações no decorrer do projeto, o que inclui as medições de qualidade.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">O defeito pode ser definido por duas óticas:</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">• <strong>Pelo ponto de vista do produtor</strong> o defeito é causado por um desvio em relação às especificações; </div><div style="text-align: justify;">• <strong>Pela ótica do cliente</strong> defeito é qualquer coisa que cause insatisfação, constando ou não nos requisitos. É chamada de visão “ajustada para uso”.</div><br />
<div> </div><strong>1.9.7. Qualificação do defeito</strong><br />
<br />
<div>É importante que os defeitos sejam qualificados no início do processo de gestão de defeitos. </div><br />
<div> </div>É recomendada a seguinte estrutura de qualificação:<br />
<br />
<div> </div>• Definição do defeito;<br />
• Fase do ciclo de desenvolvimento ou atividade que o defeito ocorreu;<br />
• Categoria do defeito. (ausente, impreciso, incompleto inconsistente)<br />
<br />
<div> </div><div> </div><div><strong>Posts relacionados:</strong> <br />
<br />
<a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-2-processo.html">Resumo Livro BCTS: Capítulo 2 – Processo de teste</a><br />
<a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-4-analise-de.html">Resumo Livro BCTS: Capítulo 4 – Análise de Riscos</a><br />
<a href="http://mptbr.blogspot.com/2010/07/resumo-livro-bcts-capitulo-5.html">Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes</a><br />
<a href="http://mptbr.blogspot.com/2010/07/resumo-livro-bcts-capitulo-7-execucao.html">Resumo Livro BCTS: Capítulo 7 – Execução dos testes</a><br />
<br />
</div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com1tag:blogger.com,1999:blog-4309764132516073935.post-61321037264667175342010-07-28T06:13:00.000-07:002010-07-28T06:13:51.240-07:00Resumo livro BCTS: Capítulo 7 – Execução dos testes<strong><span style="font-size: large;">Capítulo 7 – Execução dos testes</span></strong><br />
<br />
<br />
<div> Segundo Cem Kaner:</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">No teste estático, o código é examinado.</div><div style="text-align: justify;">No teste dinâmico, o código é testado.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Conforme já definido, os testes devem ser executados em todas as etapas do ciclo de vida do processo de desenvolvimento de software, desde os requisitos até o teste de aceitação, na fase de homologar e liberar o software para a produção. O projeto de teste deve ser desenvolvido em paralelo e estar integrado ao projeto de desenvolvimento.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">A responsabilidade de cada um na execução dos testes devem ser documentadas no Plano de Teste. Por exemplo, os programadores ou desenvolvedores sãoresponsáveis pela execução dos testes unitários, ao passo que os testadores são os responsáveis pela execução dos testes de sistema.</div><br />
<div> </div><strong>Responsáveis pelos testes:</strong><br />
<br />
<div> </div>• Testes Unitários -- Programadores<br />
• Testes de Integração -- Analistas de Sistemas<br />
• Testes de Sistema -- Analistas de Testes<br />
• Testes de Aceitação -- Usuários com a ajuda dos Analistas de Testes.<br />
<br />
<div> </div><div style="text-align: justify;">O plano de teste deve incluir todos os elementos necessários para que os testes sejam executados corretamente. Como elementos podemos considerar os procedimentos a serem cumpridos, o ambiente necessário e as ferramentas.</div><br />
<div> </div><strong>1.1. Teste Unitário</strong><br />
<br />
<div> </div><div style="text-align: justify;">Os testes unitários devem ser feitos pelos programadores e garantir o funcionamento adequado do programa.</div><br />
<div> </div><strong>1.2. Teste de Integração</strong><br />
<br />
<div> </div><div style="text-align: justify;">O teste de integração deve ter início quando os componentes a ser integrados já tenham passado pelo teste unitário. Esse tipo de teste deve ser executado pelo Analista de Sistemas, restando ao Analista de Teste a responsabilidade de testar o sistema. </div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O teste de integração deve garantir que os componentes da aplicação, ou daquele módulo de aplicação, possam ser integrados com sucesso para executar determinada funcionalidade.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Considerando as aplicações cliente/servidor, o teste de integração deve levar em conta as seguintes camadas:</div><br />
<div> </div>• Camada de apresentação;<br />
• Camada de execução;<br />
• Camada de dados;<br />
• Camada de rede.<br />
<br />
<strong>1.3. Teste de Sistema</strong><br />
<br />
<div> </div><div style="text-align: justify;">O teste de sistema deverá ter início apenas quando o teste de integração for dado como encerrado, ou seja, executado com sucesso. Por outro lado, o teste de sistema será dado como terminado quando a equipe de teste perceber que a aplicação está apta a ser liberada para a produção.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Para o sucesso na execução dos testes de sistema, algumas atividades devem ser seguidas:</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• O ambiente de teste deve ser semelhando ao de produção;</div><div style="text-align: justify;">• Devem ser criados casos de teste, de preferência com uso de ferramentas;</div><div style="text-align: justify;">• Devem ser definidos os casos de testes que serão executados;</div><div style="text-align: justify;">• Preparar os scripts ou procedimentos a serem seguidos pelos testadores;</div><div style="text-align: justify;">• Avaliar os resultados e identificar problemas encontrados;</div><div style="text-align: justify;">• Registrar defeitos, de preferências em um sistema de gestão de defeitos;</div><div style="text-align: justify;">• Re-testar defeitos corrigidos. Fechar ou reabri o defeito, se não corrigido;</div><div style="text-align: justify;">• Garantir que os ciclos de testes foram cumpridos.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O teste de sistema precisa garantir que os requisitos do software foram cumpridos, e implementados corretamente. Posteriormente, a aplicação ainda passará pelo teste de aceitação, que será conduzido pelos próprios usuários com o apoio da equipe de teste.</div><br />
<div> </div><strong>1.4. Teste de Aceitação</strong><br />
<br />
<div> </div><div style="text-align: justify;">O teste de aceitação é realizado pelos usuários ou gestores do software para garantir que tudo que foi definido por eles nos requisitos tenha sido incluído no produto que lhes está sendo entregue. Muitas vezes recebem auxílio dos testadores.</div><br />
<div> </div><strong>1.5. Quando o teste termina?</strong><br />
<div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Algumas métricas podem auxiliar o gerente de teste a tomar a decisão de liberar ou não a aplicação para produção. Podemos destacar:</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• Tempo médio entre defeitos encontrados;</div><div style="text-align: justify;">• Porcentagem de cobertura alcançada na aplicação do teste;</div><div style="text-align: justify;">• Número de defeitos encontrados e ainda não corrigidos por grau de severidade;</div><div style="text-align: justify;">• Avaliar os riscos envolvidos com a liberação da aplicação para produção, comparando tias riscos com os riscos da não-liberação.</div><br />
<div> </div><strong>1.6. Considerações</strong><br />
<br />
<div> </div>Existem algumas considerações ou preocupações que os testadores devem sempre levar em conta durante a execução dos testes:<br />
<br />
<div> </div>• O software ainda não está em condições de ser testado adequadamente;<br />
• Os recursos ou o prazo são insuficientes;<br />
• Problemas importantes não serão revelados durante os testes;<br />
• Atenção com o que vai ser testado.<br />
<br />
<strong>1.7. Processo de execução de testes</strong><br />
<div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Para que seja bem sucedida, a etapa de execução dos testes, dentro do ciclo de vida dos testes, vai depender de tudo que foi feito anteriormente e que servirá de base para o cumprimento dessa etapa.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Um pré-requisito para o início desta etapa é o Plano de Teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>1.7.1. Teste segundo as características de qualidade de software</strong></div><br />
<div> </div>Tendo como base algumas características ou sub-características da norma ISO 9126-1, listamos alguns tipos de testes que se enquadram para atender as características listadas:<br />
<br />
<ul><li> <strong>Funcionalidade</strong></li>
<ul><li>Teste de Autorização;</li>
<li>Teste de Integridade dos arquivos;</li>
<li>Teste de Trilha de auditoria;</li>
<li>Teste de Conformidade com a metodologia;</li>
<li>Teste Negativo</li>
</ul><li> <strong>Continuidade</strong></li>
<ul><li>Teste de Recuperação;</li>
</ul><li><strong>Segurança</strong></li>
<ul><li>Teste de Segurança</li>
</ul><li><strong>Performance</strong></li>
<ul><li>Teste de Estresse;</li>
<li>Teste de Performance;</li>
</ul><li><strong>Usabilidade</strong></li>
<ul><li>Teste Manual;</li>
</ul><li><strong>Manutenibilidade</strong></li>
<ul><li>Inspeções</li>
</ul><li><strong>Portabilidade</strong></li>
<ul><li>Teste de Desastre;</li>
</ul><li><strong>Conectividade</strong></li>
<ul><li>Teste de Regressão;</li>
<li>Teste de Conexão;</li>
</ul><li><strong>Operacionalidade</strong></li>
<ul><li>Teste Operacional.</li>
</ul></ul><br />
<div> </div><div>Posts relacionados:</div><div> </div><div><a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-2-processo.html">Resumo livro BCTS: Capítulo 2 – Processo de teste</a></div><div><a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-4-analise-de.html">Resumo Livro BCTS: Capítulo 4 – Análise de Riscos</a></div><div><a href="http://mptbr.blogspot.com/2010/07/resumo-livro-bcts-capitulo-5.html">Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes</a></div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-7132909440094827012010-07-07T10:26:00.000-07:002010-07-07T10:26:56.251-07:00Resumo Livro BCTS: Capítulo 5 - Planejamento dos Testes<span style="font-size: large;"><strong>Capítulo 5 - Planejamento dos Testes</strong></span><br />
<br />
<br />
<div> </div><div style="text-align: justify;">Ambiente, técnicas, processo, análise de riscos – servirão de alicerce para o planejamento dos testes. </div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O documento básico do planejamento de testes é o PLANO DE TESTES.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">No Plano de Testes define-se o nível de cobertura dos testes e a abordagem dos testes.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Plano de Teste deve ter como base os requisitos da aplicação e os requisitos de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O Plano de Teste descreve como o teste deverá ser executado e traça uma linha mestra a ser seguida.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O Plano de Teste é um acordo formal entre testadores, desenvolvedores e usuários.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O teste de software é o processo que visa executar o software de maneira controlada, com o objetivo de avaliar seu comportamento de acordo com o que foi especificado. </div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">A execução dos testes é considerada um tipo de VALIDAÇÃO.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Os testes caixa-preta cobrem as funcionalidades, mas não todo código do programa, portanto, é impossível testar completamente todo sistema e afirmar que ele está livre de defeitos.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Segundo a estimativa de Beizer, a média do número de defeitos em programas liberados para testes e de 1 a 3 a cada 100 instruções executáveis.</div><br />
<div> </div><strong>CMMI nível 3</strong><br />
<br />
<div> </div>Validação; Executar Testes<br />
Verificação; Revisão, inspeção técnica<br />
Análise de Riscos;<br />
<br />
<div> </div><div style="text-align: justify;">Testes exaustivos só são justificados em sistemas críticos em que a taxa de defeitos deve ser próximo de zero, levando em conta que testar exaustivamente um software aumenta substancialmente e custo do projeto de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O planejamento estabelece o que vai ser testado, durante quanto tempo e quando os testes serão interrompidos.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">A metodologia TMAP (Matin Pol, Teunissem e Veernendaal) definem um docuemto chamado Estrutura de Teste, elaborado antes do Plano de Teste.</div><br />
<div> </div>TMAP = Estratégia de Testes<br />
QAI = Estrutura de Testes<br />
<br />
<div> </div><strong>1. Por que os Planos de Testes são importantes?</strong><br />
<br />
<div> </div><div style="text-align: justify;">A partir do momento que o teste passa a ser tratado como um projeto ou processo e não mais como uma etapa no processo de desenvolvimento, precisamos planejá-lo.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O Plano de Teste é uma maneira de documentar o projeto de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O Plano de Teste permite que os testes sejam repetidos e controlados e define o nível de cobertura segundo o qual os elementos mais críticos do software serão testados com prioridade e com cobertura mais ampla. Por elementos críticos, consideramos aqueles classificados pela análise de riscos ou caracterizado pelo cliente.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O Plano de Teste é elaborado nos moldes do padrão definido pelo IEEE 829. Mas, nem o IEEE, nem o QAI falam sobre estimativas e métricas de teste em seus modelos.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">O IEEE define a seguinte hierarquia entre os documentos de teste:</div><br />
<div> </div>• Plano de Teste;<br />
• Estrutura de Teste;<br />
• Casos de Teste e<br />
• Procedimentos de Teste.<br />
<br />
<strong>2. Desenvolvimento do Plano de Teste</strong><br />
<br />
<div> </div><div style="text-align: justify;"><strong>Escopo</strong>; O Escopo define exatamente a extensão do projeto de teste, até mesmo suas interfaces com outros softwares.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Custo</strong>; É preciso medir o tamanho do projeto de teste para saber quanto ele vai custar. Como métricas de teste temos: Análise de Pontos de Teste ou Pontos de Caso de Teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Tempo</strong>; A estimativa de tempo - , e, conseqüentemente, a elaboração do cronograma – está ligada diretamente ao tamanho do projeto, que por sua vez, servirá de base para o cálculo dos custos.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Qualidade</strong>; É acompanhada através de um programa de indicadores a ser implementado no decorrer do projeto.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Comunicação</strong>; A função dessa “atividade” é garantir a maneira como as partes envolvidas no projeto receberão as informações de que precisas para tomar decisões. Além disso, é necessário prever no projeto como e com que freqüência serão feitas as reuniões de controle. Relatórios de defeitos servirão de elemento de comunicação entre equipes de teste e de desenvolvimento.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Integração</strong>; Descrever a integração com os projetos de desenvolvimento e até mesmo com outros projetos de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Recursos</strong> <strong>Humanos</strong>; Definição de recursos humanos envolvidos em cada etapa do projeto. Definir funções e responsabilidades.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Riscos</strong>; O projeto de teste implica seus riscos específicos. Não misturar os riscos do projeto de teste com os riscos do negócio.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;"><strong>Suprimentos</strong>; Aquisição de software e ferramentas.</div><br />
<strong>3. Significado do Plano de Teste</strong><br />
<br />
<div> </div><div style="text-align: justify;">Segundo o QAI, o Plano de teste toma aproximadamente um terço do projeto de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">Problemas levantados pelo QAI que podem afetar um projeto de testes/plano de teste:</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Falta de treinamento</strong>; a equipe independente de testes de vê conhecer o processo de teste, seu ciclo de vida, metodologia usada e também técnicas específicas de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Desenvolvedores versus testadores</strong>; Os desenvolvedores não gostam que outras pessoas apontem seus erros, e os testadores tendem a apontar esses erros de maneira sarcástica. Brigas internas são ruins para o sucesso do projeto.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Falta de ferramenta de teste</strong>; realizar testes de regressão manualmente.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Falta de apoio da gerência</strong>; Além do suporte financeiro, algumas decisões não podem ser tomadas por técnicos.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Falta de envolvimento dos usuários e dos clientes</strong>; Os usuários e clientes precisam estar envolvidos no projeto de teste, inclusive na elaboração do Plano de Teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Falta de tempo para testar</strong>; Os desenvolvedores esgotam o prazo e transferem a pressão para a equipe de teste.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Quem testa é a equipe de testa</strong>; por existir uma equipe de teste independente, os desenvolvedores não se preocupam em realizar os testes unitários e de integração ou o fazem de maneira incipiente.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Alterações rápidas</strong>; O uso de ferramentas RAD que geram alterações rápidas e que nem sempre é possível testar com a mesma agilidade. Fazer uso de ferramentas.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">•<strong> Os testadores são sempre os culpados</strong>; Quando os testadores acham muitos defeitos os desenvolvedores reclamam se deixam passar defeitos sérios também há reclamações.</div><div style="text-align: justify;"></div><div> </div><div style="text-align: justify;">• <strong>Os testadores precisam aprender a dizer não</strong>; </div><br />
<strong>4. Tarefas para construir um Plano de Teste</strong><br />
<br />
<div> </div>A lista de tarefas e sub-tarefas para se construir um plano de teste é proposta pelo QAI <br />
<br />
<ul><li> Montar a equipe de teste;</li>
<ul><li>Testar usando a equipe de desenvolvimento como equipe de teste</li>
<li>Testar usando equipes independentes de teste e</li>
<li>Testar usando equipes de não-especialistas em TI.</li>
</ul><li>Entender os riscos do Projeto; </li>
<ul><li>Procure entender o que significam os objetivos do projeto</li>
<li>Entenda as áreas-chave e os processos-chave do negócio</li>
<li>Identifique o grau de severidade das potenciais falhas</li>
<li>Identifique os componentes do sistema</li>
<li>Identifique, priorize e estime com precisão os recursos necessários para a execução do projeto</li>
<li>Fases de teste</li>
<li>Defina os requisitos de seu ambiente de teste</li>
<li>Identifique as ferramentas necessárias</li>
<li>Avalie os planos de contingência do plano do projeto</li>
<li>Avalie outras vulnerabilidades fora da área de TI</li>
</ul><li>Construir o Plano de Teste;</li>
<ul><li>Estabelecer os objetivos do teste</li>
<li>Desenvolver os roteiros de teste</li>
<li>Definir a administração do teste e</li>
<li>Escrever o plano de teste.</li>
<ul><li>Informações gerais</li>
<li>Plano,</li>
<li>Especificações e avaliação</li>
<li>Descrição dos testes.</li>
</ul></ul></ul><br />
<div> <strong>5. Atividades pós-plano</strong></div><br />
<div> </div><div style="text-align: justify;">Quando se trata de teste, é muito importante que: todos os artefatos gerados durante projeto de teste sejam supervisionados por um gerenciamento de configuração.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Entre os artefatos de teste que devem estar sob os cuidados do gerenciamento de configuração, listamos:</div><br />
<div> </div>• Casos de teste;<br />
• Plano de teste;<br />
• Requisitos de teste;<br />
• Script de teste e <br />
• Outros artefatos usados nos testes.<br />
<br />
<div> </div><strong>6. Estratégia de Teste</strong><br />
<br />
<div> </div><div style="text-align: justify;">O objetivo maior dos testes é reduzir a probabilidade de ocorrência de defeitos quando o sistema ou software estiver em produção.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">A Estratégia de Teste, quando empregada, deve ser escrita antes do Plano de Teste.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">A Estratégia de Teste é composta por Fatores de Teste e Fases de teste.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;"><strong>Fatores de teste</strong>; São os riscos que precisam ser tratados através da Estratégia de teste. Em resumo, podemos dizer que os riscos associados aos testes são chamados Fatores de Teste. Mas nem todos os fatores de teste são transformados necessariamente em risco.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;"><strong>Fases de teste</strong>; São as fases do desenvolvimento do software nas quais o teste será executado. </div><br />
<div> </div><strong>7. Criação da Estratégia de Teste baseada em riscos</strong><br />
<br />
<div> </div><div style="text-align: justify;">Como podemos ver, o que foi chamado anteriormente de fatores de teste poderia guardar semelhança com as características de qualidade, embora não façam parte da norma ISO 9126-1.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Características de qualidade segundo a norma ISO 9126-1</div><br />
<div> </div>1. Funcionalidade;<br />
2. Confiabilidade;<br />
3. Usabilidade;<br />
4. Eficiência;<br />
5. Manutenibilidade e <br />
6. Portabilidade.<br />
<br />
<div> </div><div style="text-align: justify;">Um método de montar a estratégia de teste é associar o risco a uma característica ou sub-característica de qualidade da norma ISO 9126.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">O importante dos riscos é definir a probabilidade de sua ocorrência e sua severidade em relação ao negócio.</div><br />
<div> </div><strong>8. Criação da Estratégia de Teste baseada nos tipos, nas técnicas e nos estágios de teste</strong><br />
<br />
<div> </div><div style="text-align: justify;">Na formulação da estratégia de testes devem ser levados em consideração diversos fatores, tais como o porte e importância do software, os seu requisitos, os prazos estabelecidos, riscos do negócio e os custos envolvidos.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Uma estratégia de teste deve, portanto incluir:</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">• Estágios ou níveis de teste a serem abordados (unitário, integração, sistema e aceitação); </div><div style="text-align: justify;">• Fase do desenvolvimento em que se aplica o referido teste; </div><div style="text-align: justify;">• Os tipos de teste que devem ser executados (funcional, desempenho, carga, estresse etc.) </div><div style="text-align: justify;">• As técnicas e ferramentas a serem empregadas no teste (funcionais ou estruturais) e </div><div style="text-align: justify;">• Os critérios de conclusão com êxito do teste que serão aplicados.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Exemplo: Critérios podem permitir que o software evolua para o teste de aceitação quando 95% dos casos de teste estiverem sido executados com êxito.</div><br />
<div> </div><strong>Dimensões do teste</strong><br />
<br />
<div> </div>1. Estágios ou níveis de teste. (quando testar?) – Teste unitário, Teste de integração, Teste de Sistema ou Teste de Aceitação.<br />
2. Tipos de Teste. (o que testar?) – Teste de performance, Teste de carga ...<br />
3. Técnica de Teste. (como testar?) – Estrutural ou Funcional.<br />
<br />
<div> </div><strong>Técnicas de teste</strong><br />
<br />
<div> </div><div style="text-align: justify;">É o processo que assegura o funcionamento correto de alguns aspectos ou de uma unidade do software. Segundo a norma IEEE 610.12-1990, as técnicas são procedimentos técnicos e gerenciais que ajudam a avaliação e melhoria do processo.</div><br />
<div> </div>As técnicas podem ser <strong>Funcionais</strong> ou <strong>Estruturais</strong><br />
<br />
<div> </div><div style="text-align: justify;">A técnica de teste Funcional garante que os requisitos especificados foram devidamente cumpridos pelo sistema. Valida se o que foi especificado foi implementado de modo correto. A preocupação funcional não é COMO o processo ocorre, e sim QUAIS SÃO os resultados do processo.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">O teste funcional é realizado para assegurar que as especificações e os requisitos do software foram atendidos.</div><br />
<div> </div><strong>Técnicas de teste funcional</strong><br />
<br />
<div> </div>• Teste de requisitos;<br />
• Teste de regressão;<br />
• Teste de erro de manuseio (usabilidade);<br />
• Teste de suporte manual;<br />
• Teste de integração;<br />
• Teste de controle e <br />
• Teste paralelo.<br />
<br />
<div> </div><div style="text-align: justify;">A técnica de teste Estrutural garante que a implementação de uma funcionalidade foram devidamente testada em sua totalidade. O objetivo do teste estrutural é acessar a implementação, de modo a gerar uma massa de teste que force a cobertura de toda a estrutura presente na implementação da aplicação, garantindo que a estrutura do produto desenvolvido funcione corretamente.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Os testes estruturais foram criados para verificar se o sistema desenvolvido e os programas funcionam. A técnica não determina o funcionamento correto da aplicação, e sim da estrutura.</div><br />
<div> </div><strong>Técnicas de teste estrutural</strong><br />
<br />
<div> </div>• Teste de estresse;<br />
• Teste de execução;<br />
• Teste de contingência ou recuperação;<br />
• Teste de operação;<br />
• Teste de conformidade; (processo)<br />
• Teste de segurança.<br />
<br />
<div> </div><div style="text-align: justify;">Os testes estrutural e funcional, podem ser realizados com o emprego de um conjunto pré-determinado de técnicas. Selecionada a técnica, é preciso determinar um método de teste para implementá-la, que pode ser dinâmico ou estático. As técnicas dinâmicas determinam se o sistema funciona corretamente quando está rodando, e o teste estático “olha” para o sistema quando este não é executado.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">A <strong>análise dinâmica</strong> requer que o programa seja executado.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">A <strong>análise estática</strong>, por outro lado, não envolve a execução do programa. Entre as técnicas comuns de análise estática temos as tarefas que verificam a sintaxe.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">Uma ferramenta é um veículo para executar um processo de teste, é um recurso para o testador, mas sozinha, é insuficiente para a condução de um teste.</div><br />
<div> </div><strong>Estágio ou nível de teste</strong><br />
<br />
<div> </div><div style="text-align: justify;">É uma das dimensões do teste que representa o “quando”, ou melhor, a que fase do desenvolvimento se aplica determinado teste.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;"><strong>Teste de unidade</strong>; Costuma ser feito pelo programador e testa as unidades individuais: funções, objetos e componentes.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;"><strong>Teste de iteração ou integração</strong>; Em geral, é realizado pelo analista de sistemas para um módulo ou conjunto de programas.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;"><strong>Teste de Sistema</strong>; Costuma se feito pelo analista de teste (caso de teste) em ambiente de teste.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;"><strong>Teste de aceitação</strong>; Sua execução é de responsabilidade do cliente. Em geral é feito pelo usuário em ambiente de homologação.</div><br />
<div> </div>Leia também: <br />
<br />
<a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-2-processo.html">Resumo Livro BCTS: Capítulo 2 – Processo de teste</a> <br />
<a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-4-analise-de.html">Resumo Livro BCTS: Capítulo 4 – Análise de Riscos</a>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com2tag:blogger.com,1999:blog-4309764132516073935.post-68651704879996347102010-06-14T14:28:00.000-07:002010-06-14T14:33:53.606-07:00Resumo Livro BCTS: Capítulo 4 – Análise de Riscos<strong><span style="font-size: large;">Capítulo 4 – Análise de Riscos</span></strong><br />
<br />
<br />
<strong>1.1. Definição de risco</strong><br />
<br />
<div style="text-align: justify;">Ao avaliar os riscos de um projeto, estamos buscando aqueles fatos cujas ocorrências poderão acarretar perdas para empresa. Nem sempre é possível aliar um risco a uma perda – um risco presente nem sempre vai gerar uma perda. Em resumo, podemos dizer que o risco é a possibilidade de ocorrência de uma perda para empresa.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Segundo o dicionário Houaiss, Risco é a “probabilidade de insucesso, de malogro de determinada coisa, em função de acontecimento eventual, incerto, cuja ocorrência não depende exclusivamente da vontade dos interessados.”</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O que leva um risco a potencialmente se tornar uma perda é a ameaça de sua ocorrência.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As ameaças podem ser reduzidas através de mecanismos de controle. Controlar as ameaças é uma das maneiras de evitar sua ocorrência.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Quando os meios de controle são insuficientes ou inadequados para administrar a ocorrência de um risco, surgem então as vulnerabilidades.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Análise de riscos é o processo de avaliar os riscos, ameaças , controles e vulnerabilidades.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Conceito usados em gerenciamento de riscos</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Risco O risco é uma perda em potencial para organização.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Análise de Riscos É uma avaliação dos recursos de informação de uma organização, seus controles e suas vulnerabilidades.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Ameaça Capacidade de alguém explorar a vulnerabilidade de um sistema de computador ou aplicação</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Vulnerabilidade É uma falha no desenho, implementação ou operação que permite a concretização de uma ameaça.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Controle É uma maneira de tentar reduzir as causas dos riscos, evitando desse modo sua ocorrência ou, pelo menos reduzindo sua freqüência de ocorrência.</div><br />
<br />
<strong>1.2. Riscos decorrentes da tecnologia da informação</strong><br />
<div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O risco é, portanto, a materialização de uma ameaça. A análise de risco tenta identificar os riscos e medir seu nível de severidade. Desse modo, uma ameaça é a possível ocorrência de um evento que causa danos.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os riscos presentes na área de tecnologia da informação podem ser gerados por ameaças físicas ou decorrentes da ação de pessoas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O trabalho do audito de sistemas é procurar e identificar esses riscos, estimar sua severidade e montar processos de teste de auditoria para mapear os possíveis riscos derivados de sua ocorrência.</div><br />
<strong>1.3. Riscos relativos ao teste de software</strong><br />
<br />
<div style="text-align: justify;">Em geral, os testadores tentam cobrir as partes mais importantes do software, aquelas nas quais se concentrarão os maiores riscos para o negócio. No Plano de Testes, esses riscos receberão os maiores níveis de prioridade.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Ao fazer a análise de riscos, devemos levar em conta o seguinte:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• A probabilidade de ocorrência do risco.</div><div style="text-align: justify;">• O impacto e a perda associada a esse risco.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Esses dois pontos deverão ser levados em conta para definição da cobertura dos testes.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Podemos afirmar que o total de testes a ser executado está diretamente ligado ao total de riscos envolvidos.</div><br />
<strong>1.4. Riscos do Processo de teste</strong><br />
<br />
Dentre os possíveis riscos para o processo de teste, a ser identificados pelo gerente de teste, destacamos:<br />
<br />
• <strong>Orçamento;</strong> insuficiente para execução dos serviços de teste;<br />
• <strong>Qualificação da equipe de teste;</strong> equipe sem treinamentos;<br />
• <strong>Ambiente de teste;</strong> ambiente de teste mais próximo do ambiente de produção;<br />
• <strong>Ferramentas;</strong> faltas de ferramentas necessárias para sucesso de um tipo de teste;<br />
• <strong>Metodologias;</strong> falta de metodologia adequada e condizente com o desenvolvimento;<br />
• <strong>Cronograma de recebimento de programas para teste e cronograma para devolução;</strong> Caso os prazos sejam exíguos. Negociar.<br />
• <strong>Testware;</strong> ter metodologia para guardar a documentação de teste para uso futuro;<br />
• <strong>Novas Tecnologias;</strong> uso de tecnologias não dominadas pela equipe de teste.<br />
<br />
<strong>1.5. Determinação da magnitude dos riscos</strong><br />
<br />
<div style="text-align: justify;">O problema muitas vezes, consiste em determinar como classificar o risco e qual o custo de criação de um controle que evite a ocorrência desse risco. O controle de risco custa dinheiro, é necessário fazer uma análise de custo versus benefício para determinar se vale a pena investir em algum tipo de controle de risco.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Em resumo, quando se fala em risco, existe uma relação entre o custo da ocorrência do risco e o custo dos mecanismos de controle para evitar que o risco ocorra.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O QAI estabelece que um risco pode ser determinado por quatro maneiras, descritas a seguir:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Intuição ou discernimento Um técnico experiente da área de testes usa sua intuição, aliada a sua experiência para dizer que a ocorrência de um dado risco pode custar mais caro que os controles necessários para evitá-lo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• <strong>Consenso;</strong> Trata-se de um consenso entre a equipe de que aquele risco te um nível elevado de severidade.</div><div style="text-align: justify;">• <strong>Fórmula de risco;</strong> Existe dados financeiros que permitem medir o custo da perda pela ocorrência do risco.</div><div style="text-align: justify;">• <strong>Estimativas de perdas anuais;</strong> Este caso é uma combinação do consenso com a fórmula de risco.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Outras definições de riscos e avaliação de riscos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Avaliar Riscos:</strong> Avaliar os danos para o sucesso do negócio causados pelos defeitos não detectados antes da operação do software e que poderão ocorrer quando o software estiver sendo usado.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Risco:</strong> possibilidade de falha X prejuízo causado pela falha</div><br />
<strong>1.6. Riscos baseados nas características de qualidade</strong><br />
<br />
O risco de ocorrência de defeitos é maior num software mal testado.<br />
<br />
Considerando as características de qualidade da norma ISO 9126-1, podemos relacionar os seguintes testes.<br />
<br />
• <strong><em>Funcionalidade;</em></strong> Teste de Funcionalidade;<br />
• <strong><em>Confiabilidade;</em></strong> Teste de Estresse;<br />
• <strong><em>Usabilidade;</em></strong> Teste de Usabilidade;<br />
• <strong><em>Eficiência;</em></strong> Teste de Desempenho;<br />
• <strong><em>Manutenibilidade;</em></strong> Teste Caixa-Branca, etc.<br />
• <strong><em>Portabilidade;</em></strong> Teste de Produção, Alfa, etc.<br />
<br />
<strong>1.6.1. Outros riscos do projeto de testes</strong><br />
<br />
• Ausência do cronograma detalhado do projeto de desenvolvimento;<br />
• Datas finais dependentes da execução dos testes;<br />
• Bases de testes não disponíveis nas datas programadas;<br />
• Baixa qualidade da base de testes;<br />
• Falta de métrica adequada para medir o sistema e o processo de teste;<br />
• Disponibilidade de pessoal para testes;<br />
• Crescimento do sistema;<br />
• Disponibilidade do ambiente de teste.<br />
Uma das maneiras de reduzir os riscos do software é testá-lo adequadamente.<br />
<br />
<strong>1.7. Controle dos riscos</strong><br />
<div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A melhor maneira de controlar um risco é tentar identificá-lo na análise de requisitos de negócio, no momento em que os requisitos de teste são criados, pois assim haverá tempo hábil para que algumas ações possam ser planejadas enquanto o projeto segue seu curso normal.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Duas abordagens que podemos usar são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Se aumentarmos o esforço de teste, a tendência será minimizar os riscos de ocorrência de defeitos.</div><div style="text-align: justify;">• Tomar como base o Princípio de Pareto de que 20% do software é responsável por 80% de suas funcionalidades.</div><br />
<strong>1.8. Gerenciamento dos riscos dos projetos – Conforme PMBOK</strong><br />
<br />
<div style="text-align: justify;">Segundo o PMI, o gerenciamento de risco é um processo sistemático de identificar e analisar os riscos do projeto, bem como responder a eles.</div><div style="text-align: justify;"><br />
</div><div style="text-align: center;">Fluxo de atividades do gerenciamento de riscos.</div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvKE7W-Hve4xq4Jfd9jMeO7gV1hdH8cJZMjS3-yVyYyvsEqKlbznNRhPowA-5maA_RCgPYAJKa5V4AAwk49is2rAL0-YAEDENcUjZkCyGSscV8OWit3NvMMCtsnRoPLicd-XCQGm5FyFAd/s1600/Test+Risk+Manager.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="288" qu="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvKE7W-Hve4xq4Jfd9jMeO7gV1hdH8cJZMjS3-yVyYyvsEqKlbznNRhPowA-5maA_RCgPYAJKa5V4AAwk49is2rAL0-YAEDENcUjZkCyGSscV8OWit3NvMMCtsnRoPLicd-XCQGm5FyFAd/s320/Test+Risk+Manager.jpg" width="320" /></a></div><br />
<br />
O modelo PMI divide o gerenciamento de Riscos nos seguintes processos:<br />
<br />
• Planejamento do Gerenciamento de Riscos;<br />
• Identificação dos Riscos;<br />
• Análise Qualitativa dos Riscos;<br />
• Análise Quantitativa dos Riscos;<br />
• Planejamento de Resposta a Riscos;<br />
• Controle e Monitoração de Riscos.<br />
<br />
<div style="text-align: justify;">O PMI acrescenta uma terminologia que não havíamos abordado anteriormente, pois, segundo o instituto, os riscos podem ser tanto ameaças ao sucesso do projeto quanto oportunidades de implementar melhorias.</div><br />
<strong>1.8.1. Identificação dos riscos</strong><br />
<br />
Consiste em listar todos os riscos do projeto de teste. Pode ser:<br />
<br />
• Através de reuniões com os técnicos envolvidos no projeto;<br />
• Listas de riscos publicadas;<br />
• Base de informações de projetos anteriores.<br />
<br />
<strong>1.8.2. Análise de riscos</strong><br />
<div style="text-align: justify;"><br />
</div><div style="text-align: justify;">De acordo com o PMI os riscos devem ser analisados qualitativa e quantitativamente.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A análise qualitativa dos riscos é feita com base na definição da probabilidade de ocorrência do risco e de sua severidade.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Muitas vezes a análise quantitativa PE realizada em conjunto com análise qualitativa. O objetivo da análise qualitativa é analisar numericamente a probabilidade de cada risco, de modo que seja possível, depois definir seu tratamento. Essa análise é feita dentro do contexto global do projeto.</div><br />
<strong>1.8.3. Planejamento dos riscos</strong><br />
<br />
<div style="text-align: justify;">O planejamento dos riscos envolve a escolha dos planos para responder aos riscos. É realizado de acordo com o caminho de melhor custo-benefício.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os seguintes planos devem ser elaborados:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Plano de Mitigação;</div><div style="text-align: justify;">• Plano de Contingência.</div><br />
<strong>1.8.4. Controle e monitoração dos riscos</strong><br />
<br />
<div style="text-align: justify;">Controlar e monitorar riscos é acompanhar a evolução dos riscos no desenvolvimento dos projetos, o que envolve a avaliação permanente dos riscos e, caso algum já tenha ocorrido, como funcionou a resposta atribuída a sua ocorrência.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Veja também:</div><ul><li><a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-2-processo.html">Resumo livro BCTS: Capítulo 2 – Processo de teste;</a></li>
</ul><div style="text-align: justify;">Abraços e até o próximo post, onde estaremos falando de Planejamento.</div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com2tag:blogger.com,1999:blog-4309764132516073935.post-65922366535658731962010-06-09T09:53:00.000-07:002010-06-09T09:57:22.146-07:00Resumo livro BCTS: Capítulo 2 – Processo de teste<strong><span style="font-size: large;">Capítulo 2 – Processo de teste</span></strong><br />
<br />
<br />
<strong>1.1. Ciclo de vida de desenvolvimento de software (CVDS)</strong><br />
<br />
<div style="text-align: justify;">O CVDS é formado pelas seguintes fases:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>•</strong> <strong>Estudo preliminar;</strong></div><div style="text-align: justify;"><strong>• Análise de requisitos;</strong> Também nesta fase são levantadas as primeiras informações necessárias para a realização dos testes, tais como as regras para testar os requisitos e os pré-requisitos que permitem tal realização. Inclui-se ainda o Plano de Teste, que contempla o planejamento das principais atividades de teste, bem como recursos e os prazos para realizá-los.</div><div style="text-align: justify;"><strong>• Desenho do sistema;</strong></div><div style="text-align: justify;"><strong>• Construção;</strong> Nos programas preparados, devem ser aplicados os testes unitários conforme os planos de teste e os casos de teste preparados.</div><div style="text-align: justify;"><strong>• Implantação;</strong> Nesta fase são efetuados os testes de integração e sistema. Finalmente o sistema deve ser aceito pelo usuário ou cliente.</div><div style="text-align: justify;"><strong>• Operação.</strong></div><br />
<strong>1.2. Conceito “V” de teste</strong><br />
<br />
<div style="text-align: justify;">O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o processo de desenvolvimento.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os ciclos de vida de testes e de desenvolvimento são totalmente interdependentes, mas o ciclo de teste é dependente da conclusão dos produtos das atividades de desenvolvimento.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As atividades do ciclo de vida de teste devem ser realizadas por um grupo formalmente definido para tal. Esse grupo pode ser :</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>• Interno;</strong> formado por profissionais pertencentes ao projeto ou por uma área especial para as atividades de teste.</div><div style="text-align: justify;"><strong>• Externo;</strong> Formado por profissionais especializados em teste de uma empresa externa.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">No conceito de ciclo de vida de testes, os processos de desenvolvimento e teste têm início simultaneamente: a equipe que desenvolve o sistema inicia o processo de desenvolvimento do sistema, e a equipe que está conduzindo os testes começa o planejamento do processo de teste.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A equipe de teste usa os mesmos requisitos com o propósito de testar o sistema. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">No conceito “V” de teste, os processos de FAZER e CONFERIR convergem do início até fim do projeto. O grupo que FAZ trabalha com o objetivo de implementar o sistema, e a equipe que CONFERE, simultaneamente, executa procedimentos de teste visando minimizar ou eliminar riscos.</div><br />
<strong>1.3. Processo de teste de software</strong><br />
<br />
<div style="text-align: justify;">Baseado no conceito “V” de teste, o processo de teste de software tem como atividades de testes, onze passos a serem realizados paralelamente às atividades do desenvolvimento. Os primeiros cinco passos usam técnicas de verificação como principal meio de avaliar a correção dos produtos do desenvolvimento de software. Os outros passos usam técnicas de validação para testar o software durante as atividades que vão desde construção até a implantação. A verificação e validação devem ser usadas para o desenvolvimento e a manutenção de software.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os passos do processo de teste são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>• Acesso ao Plano de Desenvolvimento;</strong> Pré-requisito para a construção do Plano de Teste.</div><div style="text-align: justify;"><strong>• Desenvolvimento do Plano de Teste;</strong> A preparação do Plano de Teste deve seguir os mesmos padrões da preparação do plano de desenvolvimento.</div><div style="text-align: justify;"><strong>• Inspeção ou teste dos requisitos do software;</strong> Avaliação dos requisitos do software por meio do uso de técnicas de verificação.</div><div style="text-align: justify;"><strong>• Inspeção ou teste de desenho do software;</strong> Avaliação do desenho – interno ou externo – do software através do uso de técnicas de verificação.</div><div style="text-align: justify;"><strong>• Inspeção ou teste da construção do software;</strong></div><div style="text-align: justify;"><strong>• Execução dos testes;</strong> Envolve testar o código em estado dinâmico.</div><div style="text-align: justify;"><strong>• Teste de aceitação;</strong> Avaliação da aplicabilidade e usabilidade do software pelos usuários.</div><div style="text-align: justify;"><strong>• Informação dos resultados dos testes;</strong> informação dos defeitos, etc.</div><div style="text-align: justify;"><strong>• Teste de instalação do software;</strong> Visa verificar a interoperabilidade com o sistema operacional, etc.</div><div style="text-align: justify;"><strong>• Teste de mudança no software;</strong> Cobre mudanças que ocorrem em todo processo de desenvolvimento e as que vão ocorrer após a implantação do software.</div><div style="text-align: justify;"><strong>• Avaliação da eficácia dos testes;</strong> Responsável pelas melhorias no processo de teste.</div><br />
<strong>1.4. Ciclo de vida do processo de teste</strong><br />
<br />
O ciclo de vida do processo de teste abordado é composto por diversas etapas ou fases, sendo quatro delas seqüenciais ou em cascata e duas paralelas. Este modelo é baseado na metodologia TMap. Este modelo é conhecido como Modelo 3PX3E.<br />
<br />
• Procedimentos Iniciais;<br />
• Planejamento;<br />
• Preparação;<br />
• Especificação;<br />
• Execução e<br />
• Entrega.<br />
<br />
<em>1.4.1. Procedimentos iniciais</em><br />
<br />
Nesta etapa deverá ser aprofundado um estudo dos requisitos do negócio que dará origem ao sistema de informação a ser testado, de modo a garantir que o mesmo esteja completo e sem nenhuma ambigüidade. No final desta etapa é elaborado o GOT – Guia Operacional de Teste.<br />
<br />
<em>1.4.2. Planejamento</em><br />
<br />
<div style="text-align: justify;">Consiste em elaborar a Estratégia de Teste e o Plano de Teste a ser utilizados de modo a minimizar os principais riscos do negócio e fornecer os caminhos para as próximas etapas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A atividade de planejamento deve permanecer até a conclusão do projeto.</div><br />
<em>1.4.3. Preparação</em><br />
<br />
<div style="text-align: justify;">Nesta etapa, o objetivo básico é preparar o ambiente de teste (equipamentos, pessoal, ferramentas de automação, hardware e software), para que os testes sejam executados corretamente.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A atividade de preparação deve permanecer até a conclusão do projeto.</div><br />
<em>1.4.4. Especificação</em><br />
<br />
<div style="text-align: justify;">Os objetivos básicos desta etapa são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Elaborar/revisar casos de teste;</div><div style="text-align: justify;">• Elaborar/revisar roteiros de test.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os casos de teste e os roteiros de teste devem ser elaborados dinamicamente durante o decorrer do projeto de teste.</div><br />
<em>1.4.5. Execução</em><br />
<div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes deverão ser executados de acordo com os casos de teste e os roteiros de teste.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Devem ser usados scripts de teste, caso seja empregada alguma ferramenta de automação de testes.</div><br />
<em>1.4.6. Entrega</em><br />
<br />
Nesta etapa o projeto de teste é finalizado.<br />
<br />
<strong>1.5. Técnicas de teste</strong><br />
<br />
<strong>1.5.1. Teste Estrutural versus Teste funcional</strong><br />
<br />
<div style="text-align: justify;"><strong>Teste Funcional;</strong> Os testes funcionais do sistema são desenhados para garantir que os requisitos e as especificações do sistema tenham sido atendidos.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;"><strong>Teste Estrutural;</strong> Garante que os softwares e os programas sejam estruturalmente sólidos e que funcionem no contexto técnico onde serão instalados. Isto implica (1) testar a robustez e o funcionamento da estrutura do programa; (2) testar o funcionamento de todos os aspectos da estrutura em toda a sua extensão.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As técnicas para esse tipo de teste são desenhadas não para garantir que o sistema seja funcionalmente correto, e sim para que ele seja estruturalmente robusto.</div><br />
<strong>Técnicas de Teste Funcional </strong><br />
<br />
Testes de Requisitos;<br />
Testes de Regressão;<br />
Testes de Tratamento de Erros;<br />
Testes de Suporte Manual;<br />
Testes de interconexão com outros softwares;<br />
Testes de Controle;<br />
Testes Paralelos;<br />
<br />
<strong>Técnicas de Teste Estrutural</strong><br />
<br />
Testes de Estresse;<br />
Testes de Execução;<br />
Testes de Recuperação (contingência);<br />
Testes de Operação;<br />
Testes de Conformidade;<br />
Testes de Segurança;<br />
<br />
<strong>1.5.1.1. Técnicas de Teste Estrutural</strong><br />
<br />
<em><strong>Teste de Estresse</strong></em><br />
<br />
<div style="text-align: justify;">O objetivo desse teste é avaliar o comportamento do software sob condições críticas, tais como restrições significativas de memória, de área de disco e de CPU. Os testes de estresse visam também identificar o comportamento do software quando submetido a variados volumes de dados e acima das médias esperadas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Nos testes de estresse, o sistema deve ser executado como seria de fato executado no ambiente de produção.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de estresse são empregados quando existe incerteza quanto à quantidade ou ao volume de trabalho que a aplicação pode tratar sem falhas.</div><br />
<strong><em>Testes de Execução</em></strong><br />
<br />
<div style="text-align: justify;">Os testes de execução são desenhados para avaliar o comportamento do sistema no ambiente de produção e verificar se são atendidas as premissas de desempenho estabelecidas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O teste de execução é empregado para determinar se o sistema pode atingir os critérios de desempenho específicos.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Determinar o desempenho da estrutura do sistema;</div><div style="text-align: justify;">• Verificar o nível de utilização do hardware e software;</div><div style="text-align: justify;">• Determinar o tempo de resposta das transações on-line;</div><div style="text-align: justify;">• Determinar o tempo de processamento das transações.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de execução devem ser empregados no início do processo de desemvolvimento.</div><br />
<strong><em>Testes de Recuperação (Contingência)</em></strong><br />
<br />
<div style="text-align: justify;">A recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O teste de recuperação não só verifica o processo de recuperação como também a eficácia das partes componentes do processo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Manter backup dos dados;</div><div style="text-align: justify;">• Armazenar os dados do backup em local seguro;</div><div style="text-align: justify;">• Documentar os procedimentos de recuperação;</div><div style="text-align: justify;">• Etc.</div><br />
<strong><em>Testes de Operação</em></strong><br />
<br />
<div style="text-align: justify;">Os testes de operação são desenhados principalmente para estabelecer se o sistema é executável durante a operação normal. Os objetivos são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Determinar se a documentação da operação está completa;</div><div style="text-align: justify;">• Avaliar se o treinamento dos operadores está completo;</div><div style="text-align: justify;">• Garantir que mecanismos de suporte foram preparados e funcionam de modo adequado. Ex: Scheduling.</div><div style="text-align: justify;">• Etc.</div><br />
<strong><em>Testes de Conformidade</em></strong><br />
<br />
<div style="text-align: justify;">Os testes de conformidade verificam se a aplicação foi desenvolvida de acordo com os padrões, procedimentos e guias de TI. Pode ser mais importante executar testes de conformidade durante a fase de requisitos.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de conformidade são realizados para garantir a conformidade com as metodologias e encorajar e auxiliar os profissionais de TI a adotá-las. Os objetivos são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Verificar se as metodologias de desenvolvimento de software e de manutenção são seguidas;</div><div style="text-align: justify;">• Garantir a conformidade aos padrões, procedimentos e guias de TI;</div><div style="text-align: justify;">• Avaliar se a documentação do sistema de aplicação é racional e está completa.</div><br />
<strong><em>Teste de Segurança</em></strong><br />
<br />
<div style="text-align: justify;">São um processo necessário para garantir a confidencialidade das informações e a proteção dos dados contra acesso indevido de terceiros. </div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de segurança são desenhados com o intuído de avaliar a adequação dos procedimentos de proteção e contramedidas projetadas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de segurança visam descobrir defeitos muito difíceis de identificar.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Entre os objetivos temos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Determinar se foi dada atenção adequada á identificação de riscos de segurança;</div><div style="text-align: justify;">• Determinar se foi preparada uma definição de regras de acesso e se estas foram implementadas de acordo com as regras;</div><div style="text-align: justify;">• Etc.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de segurança podem ser divididos em segurança física e lógica. A física trata da invasão por pessoas não autorizadas, ao passo que a lógica trata do uso dos recursos computacionais e de comunicações para acessar indevidamente as informações.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de segurança devem ser empregados quando a informação e/ou o ativo protegido pelo sistema de aplicação são de valor significativo para a organização e realizados antes e depois de o sistema ser passado para a produção.</div><br />
<strong>1.5.1.2. Técnicas de Testes Funcionais</strong><br />
<br />
<strong><em>Testes de Requisitos</em></strong><br />
<br />
<div style="text-align: justify;">Os testes de requisitos visam verificar se o sistema executa corretamente as funcionalidades e se é capaz de sustentar essa correção após sua utilização por um período de tempo contínuo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os objetivos dos testes consistem em verificar se:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Os requisitos dos usuários estão implementados;</div><div style="text-align: justify;">• A correção é mantida por períodos prolongados de tempo;</div><div style="text-align: justify;">• O processamento da aplicação está em conformidade com as políticas e os procedimentos da organização.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de requisitos são realizados basicamente através da criação de condições de testes e checklists de funcionalidades. Recomenda-se que as condições de teste sejam derivadas diretamente dos requisitos.</div><br />
<strong><em>Teste de Regressão</em></strong><br />
<br />
<div style="text-align: justify;">Os testes de regressão voltam a testar segmentos já testados após a implementação de uma mudança em outra parte do software.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Sempre que mudanças são efetuadas num segmento de código, problemas podem ocorrer em outros segmentos já testados. Desse modo, entre os objetivos dos testes de regressão temos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Determinar se a documentação do sistema permanece atual;</div><div style="text-align: justify;">• Determinar se os dados e as condições de teste permanecem atuais;</div><div style="text-align: justify;">• Determinar se as funções previamente testadas continuam funcionando corretamente após a introdução de mudanças no sistema.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O teste de regressão deve ser executado sempre que o software sofre uma alteração.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de regressão são empregados quando é muito alto os riscos de novas mudanças afetarem áreas não alteradas da aplicação.</div><br />
<strong><em>Teste de Tratamento de Erros</em></strong><br />
<div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes de tratamento de erros determinam a capacidade do sistema de tratar apropriadamente transações incorretas.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os objetivos específicos são:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Determinar se todas as condições de erro esperadas são reconhecidas pelo sistema;</div><div style="text-align: justify;">• Determinar se foi atribuída responsabilidade para processar os erros identificados;</div><div style="text-align: justify;">• Determinar se é mantido um controle sobre os erros durante o processo de correção.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Um ótimo método para desenvolver testes de tratamento de erros é realizar um brainstorm com pessoas de Ti, da área usuária e de auditoria, procurando identificar o que pode dar errado no sistema.</div><br />
<strong><em>Teste de Suporte Manual</em></strong><br />
<br />
<div style="text-align: justify;">• Verificar se os procedimentos de suporte manual estão documentados e completos;</div><div style="text-align: justify;">• Determinar se as responsabilidades pelo suporte manual foram estabelecidas;</div><div style="text-align: justify;">• Determinar se o suporte manual e o segmento automatizado estão interligados apropriadamente;</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os testes manuais envolvem a avaliação da adequação do processo e, sua execução que pode ser feita juntamente com o teste normal do sistema.</div><br />
<strong><em>Testes de Interconexão</em></strong><br />
<br />
<div style="text-align: justify;">Estes testes são desenhados para garantir que a interconexão entre software de aplicação funcione corretamente. Entre os objetivos temos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Determinar se os parâmetros e dados são transferidos corretamente entre os softwares;</div><div style="text-align: justify;">• Garantir o momento certo de execução e a existência de coordenação das funções entre os softwares;</div><div style="text-align: justify;">• Determinar se a documentação pertinente é correta e completa.</div><br />
<strong><em>Testes de Controle</em></strong><br />
<br />
<div style="text-align: justify;">Os testes de controle é a ferramenta de gestão necessária para assegurar que o processamento seja realizado conforme sua intenção. Os objetivos são garantir que:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Os dados estejam completos e corretos;</div><div style="text-align: justify;">• As transações sejam autorizadas;</div><div style="text-align: justify;">• A manutenção das informações de trilha de auditoria seja realizada;</div><div style="text-align: justify;">• Os processamentos sejam eficientes, eficazes e econômicos;</div><div style="text-align: justify;">• O processamento atenda às necessidades dos usuários.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">O teste de controle pode ser considerado um sistema dentro do outro.</div><br />
<strong><em>Testes Paralelos</em></strong><br />
<br />
<div style="text-align: justify;">O teste paralelo serve para determinar se os resultados de um novo software de aplicação são consistentes com o processamento do antigo sistema ou da antiga versão do sistema.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Objetivos:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Assegurar que a nova versão do software de aplicação execute corretamente;</div><div style="text-align: justify;">• Demonstrar consistências e inconsistências entre duas versões do mesmo software de aplicação.</div><br />
<strong>1.5.2. Atributos de qualidade</strong><br />
<br />
Os atributos de qualidade a serem atendidos devem também fazer parte do Plano de Teste.<br />
<br />
<strong>1.5.2.1. Procedimentos para identificar a importância dos fatores de qualidade</strong><br />
<br />
<div style="text-align: justify;">Existem diversas técnicas para identificar os fatores de qualidade do software. Sugerimos que sejam seguidos os passos adiante:</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• Considerar as características básicas da aplicação;</div><div style="text-align: justify;">• Considerar as implicações no ciclo de vida;</div><div style="text-align: justify;">• Realizar uma avaliação de custo versus benefício da lista de fatores de qualidade;</div><div style="text-align: justify;">• Identificar os fatores de qualidade mais importantes;</div><div style="text-align: justify;">• Fornecer explicações para as escolhas.</div><br />
<strong>Fatores de qualidade:</strong><br />
<br />
<div style="text-align: justify;">• <strong>Correção;</strong> satisfaz as especificações e atende aos objetivos do usuário;</div><div style="text-align: justify;">• <strong>Confiabilidade;</strong> executa as funções programadas com a precisão requerida;</div><div style="text-align: justify;">• <strong>Eficiência;</strong> A quantidade de recursos computacionais e de dados para executar uma função.</div><div style="text-align: justify;">• <strong>Integridade;</strong> o acesso ao software ou aos dados por pessoa autorizada pode ser controlada;</div><div style="text-align: justify;">• <strong>Usabilidade;</strong> esforço requerido para aprender e operar o sistema;</div><div style="text-align: justify;">• <strong>Manutenibilidade;</strong> esforço requerido para localizar e corrigir um erro;</div><div style="text-align: justify;">• <strong>Testabilidade;</strong> esforço requerido para testar um programa;</div><div style="text-align: justify;">• <strong>Flexibilidade;</strong> esforço requerido para modificar um programa;</div><div style="text-align: justify;">• <strong>Reusabilidade;</strong> um programa pode ser usado em outra aplicação;</div><div style="text-align: justify;">• <strong>Interoperabilidade;</strong> esforço requerido para juntar um sistema com outro; </div><div style="text-align: justify;">• <strong>Portabilidade;</strong> facilidade do software operar em vários ambientes.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Os fatores de qualidade não devem ser confundidos com as características ou subcaracterísticas de qualidade da norma ISO 9126-1. Aqui trata-se apenas de uma abordagem didática.</div><br />
<strong>1.5.3. Garantia da qualidade versus Controle da qualidade</strong><br />
<br />
<div style="text-align: justify;">Métodos de qualidade podem ser segmentados em duas categorias: métodos preventivos e métodos de detecção. Essa distinção é o mecanismo usado para diferenciar atividades de garantia da qualidade das atividades de controle da qualidade.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• <strong>Garantia da qualidade;</strong> A garantia da qualidade é um conjunto sistemático e planejado de atividades, necessárias para proporcionar a confiança adequada de que produtos e serviços estarão em conformidade com requisitos especificados e atenderão às necessidades do usuário.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">• <strong>Controle de qualidade;</strong> O controle de qualidade é um processo pelo qual a qualidade do produto é comparada com os padrões aplicáveis; quando uma não-conformidade é detectada, são tomadas as devidas providências.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Tanto a garantia da qualidade quanto o controle da qualidade se distinguem da função de auditoria interna. A auditoria interna é uma atividade independente dentro da organização, tem o propósito de revisar as operações e é uma tarefa de gerenciamento.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A qualidade tem duas definições de trabalho:</div><br />
<div style="text-align: justify;">• Do ponto de vista do produtor, a qualidade é o comprimento de requisitos.</div><div style="text-align: justify;">• Do ponto de vista do consumidos, é o atendimento às necessidades do cliente.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">Na visão do CMMI, o propósito da Garantia da Qualidade de Software (GQS) é fornecer ao gerenciamento a visibilidade da eficácia, no sentido de produzir um software de qualidade. A GQS envolve rever e auditar partes do produto, de maneira a verificar se estão de acordo com os padrões definidos e fornecer os resultados dessas revisões para os implicados no processo.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">A garantia da qualidade é uma atividade que estabelece e avalia o processo que gera os produtos. Caso não exista processo, não há razão para a garantia da qualidade.</div><div style="text-align: justify;"><br />
</div><div style="text-align: justify;">As atividades de controle da qualidade se concentram na identificação de defeitos em produtos. Essas atividades começam no início do processo de desenvolvimento do software, com revisão dos requisitos, e continuam até que o teste do aplicativo esteja completo e o sistema esteja implementado.</div><br />
• <strong>O controle da qualidade</strong><br />
<br />
o Está relacionado a um produto ou serviço específico;<br />
o Verifica se um produto ou serviço específico tem um atributo específico;<br />
o Identifica defeitos com o propósito principal de corrigi-los;<br />
o É responsabilidade da equipe/do funcionário.<br />
<br />
<strong>• A garantia da qualidade</strong><br />
<br />
o Ajuda a estabelecer processos;<br />
o Determina programas de medida para avaliar processos;<br />
o Identifica fraquezas em processos e os aperfeiçoa;<br />
o É uma responsabilidade de gerenciamento;<br />
o Está relacionada com todos os produtos que serão gerados por um processo;<br />
o Avalia se o controle da qualidade está funcionando.<br />
<br />
<br />
<strong><span style="font-size: large;">FURPS</span></strong><br />
<br />
Uma metodologia muito usada no mercado é a FURPS. Uma metodologia que faz parte do RUP.<br />
<br />
• Funcionalidade (Functionality);<br />
• Usabilidade (Usability);<br />
• Confiabilidade (Reability);<br />
• Desempenho (Performance);<br />
• Suportabilidade (Suportability).<br />
<br />
<strong>Funcionalidade</strong><br />
<br />
Para atender a categoria da funcionalidade, o software em teste tem de estar de acordo com a especificação funcional.<br />
<br />
Testes que podem ser aplicados:<br />
<br />
• Teste funcional;<br />
• Teste de regressão (smoke test);<br />
• Teste de volume;<br />
• Teste de segurança.<br />
<br />
<strong>Usabilidade</strong><br />
<br />
Representa a facilidade de uso do sistema pelos usuários.<br />
<br />
Testes que podem ser aplicados:<br />
<br />
• Teste de interface;<br />
• Teste de usabilidade.<br />
<br />
<strong>Confiabilidade</strong><br />
<br />
Garante a confiabilidade do sistema, a permanência de operação, a integridade dos dados, a confiabilidade da estrutura de dados e também da aplicação.<br />
<br />
Testes que podem ser aplicados:<br />
<br />
• Teste de integridade;<br />
• Teste de estrutura;<br />
• Teste de estresse;<br />
• Smoke teste.<br />
<br />
<strong>Desempenho</strong><br />
<br />
Garante a velocidade de processamento da informação.<br />
<br />
Testes que podem ser aplicados:<br />
<br />
• Teste de avaliação de desempenho ou benchmark;<br />
• Teste de contenção;<br />
• Teste de carga;<br />
• Perfil de desempenho.<br />
<br />
<strong>Suportabilidade</strong><br />
<br />
Representa a capacidade do programa de funcionar em diversos ambientes diferentes. <br />
<br />
Testes que podem ser aplicados:<br />
<br />
• Teste de configuração;<br />
• Teste de instalação.<br />
<br />
<br />
Mesmo que não pareça... hehehe este foi o resumo para o capítulo 2.<br />
Até o próximo post.!!!Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com12tag:blogger.com,1999:blog-4309764132516073935.post-32776627292940136622010-06-09T09:30:00.000-07:002010-08-23T14:41:15.834-07:00Resumo de Capítulos do livro: Base de Conhecimento em Teste de SoftwareOlá Pessoal!<br />
<br />
Todos sabemos que a principal referência para prova de certificação da ALATS - CBTS - é o livro Base de Conhecimento em Teste de Software, escrito por Emerson Rios, Ricardo Cristalli, Aderson Bastos e T. Moreira .<br />
<br />
Para me auxiliar nos estudos e preparação para prova, resumi alguns capítulos que julguei interessante.<br />
<br />
Gostaria de deixar claro que, antes mesmo de resumir tais capítulos, eu já havia lido todo o livro algumas vezes e os resumos foram feitos com o objetivo a dar foco em pontos que julguei importantes sobre os capítulos escolhidos. No entanto, não aconselho à aqueles que pretendem fazer a prova em novembro se basearem simplesmente nos resumos. Aconselho leituras de todo o livro para que se tenha conhecimentos gerais do assunto tratado em cada capítulo.<br />
<br />
Os resumos a serem publicados serão dos seguintes capítulos:<br />
<br />
<a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-2-processo.html">Capítulo 2 – Processo de teste;</a><br />
<a href="http://mptbr.blogspot.com/2010/06/resumo-livro-bcts-capitulo-4-analise-de.html">Capítulo 4 – Análise de Riscos;</a><br />
<a href="http://mptbr.blogspot.com/2010/07/resumo-livro-bcts-capitulo-5.html">Capítulo 5 – Planejamento dos Testes</a>;<br />
<a href="http://mptbr.blogspot.com/2010/07/resumo-livro-bcts-capitulo-7-execucao.html">Capítulo 7 – Execução dos testes;</a><br />
<a href="http://mptbr.blogspot.com/2010/08/resumo-livro-bcts-capitulo-8-gestao-de.html">Capítulo 8 – Gestão de Defeitos</a>;<br />
Capítulo 11 – Estimativas.<br />
<br />
Abraços e até o próximo post.Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com3tag:blogger.com,1999:blog-4309764132516073935.post-50638798123490620242010-05-04T11:37:00.000-07:002010-05-04T11:44:44.683-07:00Preparado para novas tecnologias? cont...<span style="font-family: Verdana, sans-serif;">Rebatendo a bola levantada por nossa amiga Sarah Peimentel ( </span><a href="http://ensaiosdeqa.blogspot.com/2010/04/preparado-para-as-novas-tecnologias.html"><span style="font-family: Verdana, sans-serif;">http://ensaiosdeqa.blogspot.com/2010/04/preparado-para-as-novas-tecnologias.html</span></a><span style="font-family: Verdana, sans-serif;"> ), aproveito para apresentar mais uma nova solução High Tech. </span><br />
<br />
<span style="font-family: Verdana, sans-serif;">Entro no jogo não com espírito competitivo, mas com intenção de expor soluções High Tech.</span><br />
<br />
<span style="font-family: Verdana, sans-serif;">Creio que muitos já conhecem ou até mesmo ja viram antes, mas vale a pena colocar o post para aqueles que ainda não viram.</span><br />
<br />
<span style="font-family: Verdana;">E, pensando nas mesmas perguntas levantadas por Sarah, qual seria o melhor caminho para testar aplicações neste nível de interatividade com o usuário final?</span><br />
<br />
<object height="200" width="400"><param name="movie" value="http://www.youtube.com/v/S1t9CYrWPC8&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/S1t9CYrWPC8&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">O vídeo apresenta o xBox 360 com o componete Project Natal. Componente desenvolvido pela Microsoft para permitir total interatividade do usuário final com o xBox.</span><br />
<br />
<span style="font-family: Courier New;">Acreditem, não sou fã dos games mas esta solução é impecável.</span>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-13411236597217142352010-04-30T09:26:00.000-07:002010-04-30T09:26:49.582-07:00Está disponível o Nível 3 do MPTEm março de 2010, foi disponibilizado o Nível 3 do MPT no site da <a href="http://www.alats.org.br/">ALATS</a>.<br />
<br />
Levando em consideração a nova estrutura do modelo, o Nível 3 vem com o propósito de atender as seguintes àreas de Processo: Gerência de Configuração (GCO), Garantia da Qualidade (GQA) e Medição (MED).<br />
<br />
<strong><span style="color: #660000;">Gerência de Configuração - GCO</span></strong><br />
A àrea de processo GCO tem por objetivo, estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos. Em outras palavras, visa controlar a integridade e o rastreamento da configuração dos sistemas durante todo seu ciclo de desenvolvimento, garantindo, através do controle das versões e das alterações, que os itens relevantes do sistema estejam consistentes entre si, de forma a atender corretamente ao conjunto de requisitos pertinentes.<br />
<br />
A Gerência de configuração deve ser aplicado ao projeto como um todo, incluindo desenvolvimento e teste, sem para isso criar duas bases de GCO desconectadas.<br />
<br />
A não consideração da Gerência de Configuração no projeto de teste pode conduzir a diversos problemas decorrentes da falta de sincronização das versões em teste e a que está sendo modificada pela área de desenvolvimento, criando as condições para, potencialmente, passar a versão errada para as etapas seguintes do ciclo de desenvolvimento.<br />
<br />
<strong><span style="color: #660000;">Garantia da Qualidade - GQT</span></strong><br />
O objetivo do processo Garantia da Qualidade no processo de teste é garantir que a execução dos processos de teste (e em conseqüência, os produtos resultantes) estão em conformidade com as políticas, metodologias, padrões, planos e recursos definidos.<br />
<br />
A Garantia da Qualidade é orientada para a “prevenção”, ou seja monitorar e melhorar o processo, garantindo que os procedimentos e padrões sejam seguidos e os desvios identificados e corrigidos.<br />
<br />
<strong><span style="color: #660000;">Medição - MED</span></strong><br />
O objetivo primário de realizarmos medições no tocante a teste de software é o de obter níveis cada vez maiores de qualidade da atividade, considerando o projeto, o processo e os produtos, visando à satisfação dos clientes ou usuários, a um custo economicamente compatível.<br />
<br />
No caso do MPT, o processo Medição coleta, analisa e relata os dados relativos aos produtos do processo de teste (“testeware”) e do próprio processo em si, visando medir os resultados das atividades e criar as métricas da situação atual da atividade de teste, as tendências futuras, os efeitos das ações de correção e o nível em que estas atingem os objetivos de melhorias setoriais estabelecidos. Também tem um papel fundamental para gerar os dados requeridos para o processo de estimativas de teste. Qualquer que seja o processo adotado, sempre algumas métricas resultante das atividades será necessária, principalmente a métrica de produtividade da equipe de testes.<br />
<br />
<br />
Deve ser entendido que as métricas são meios para se atingir objetivos e não um objetivo em si. <br />
<br />
É isso ai pessoal... <br />
<br />
Para informações mais detalhadas sobre essas àreas de processo referentes ao nível 3 do MPT, confira diretamente do guia de implementação do nível 3 <a href="http://www.alats.org.br/Default.aspx?tabid=257">baixando-o aqui</a>.Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-11109535532185195932010-03-15T16:28:00.000-07:002010-04-30T08:18:06.106-07:00BRATESTE - Aviso importante<span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, Verdana, tahoma; font-size: 11px;"></span><br />
<span style="font-family: Verdana;"><span style="color: black;"><span class="Apple-style-span">Informamos que, para atender à mudanças solicitadas por importantes palestrantes, e, para não comprometer a qualidade do evento, estamos transferindo as datas do BRATESTE para os dias </span><span style="background-color: orange;"><span class="Apple-style-span">16, 17 e 18 de junho de 2010</span></span><span class="Apple-style-span">. Esclarecemos, outrossim, que as inscrições já feitas serão mantidas, mas caso algum inscrito queira cancelar a sua participação, o reembolso será feito pela ALATS, e, para tanto, o interessado deverá manter contato pelo telefone (21) 3231-9027 ou pelo e-mail </span></span></span><a href="mailto:contato@alats.org.br" style="font-family: arial, Verdana, tahoma; font-weight: bold; text-decoration: none;"><span style="font-family: Verdana;"><span class="Apple-style-span" style="color: black;">contato@alats.org.br</span></span></a><span style="font-family: Verdana;"><span class="Apple-style-span" style="color: black;">.</span></span><br />
<span style="font-family: Verdana;"><span class="Apple-style-span"><br />
<span style="color: black;"></span></span></span><br />
<span style="color: black;"><span style="font-family: Verdana;"><span class="Apple-style-span">No mais, informamos que as inscrições para este evento continuarão em aberto até a nova dat</span></span><span style="font-family: Verdana;"><span class="Apple-style-span">a.</span></span></span>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-90483953317205384632010-02-04T09:49:00.000-08:002010-02-04T09:49:24.945-08:00ALATS e RIOSOFT divilgam nova estrutura base dos Níveis de Maturidade do MPT<div style="text-align: justify;">Com o objetivo de tornar o MPT mais flexível e acessível às empresas, a ALATS (Associação Latino Americana de Teste de Software ) em conjunto com a RIOSOFT (Sociedade Núcleo de Apoio à Produção e a Exportação de Software), idealizadoras do MPT, realizaram algumas avaliações no modelo e decidiu-se realizar algumas alterações em sua estrutura base.</div><div style="text-align: justify;"></div><div style="text-align: justify;"> </div><div style="text-align: justify;">A estrutura do MPT, que antes contava com 7 Níveis de Maturidade, agora tem uma nova versão com apenas 5 níveis de Maturidade à saber:</div><br />
<div> </div>Níveis de Maturidade<br />
<ol><li>Nível 1 </li>
<ul><li> Gerência do Projeto de Teste - GPT</li>
</ul><li>Nível 2 </li>
<ul><li> Gerência de Requisitos de Teste – GRT</li>
</ul><li>Nível 3 </li>
<ul><li> Aquisição – AQU (Opcional)</li>
<li> Gerência de Configuração – GCO</li>
<li> Garantia da Qualidade – GQA</li>
<li> Medição – MED</li>
</ul><li>Nível 4 </li>
<ul><li> Gerência de Recursos Humanos – GRH</li>
<li> Gerência de Reutilização – GRU (Opcional)</li>
<li>Gerência de Riscos – GRI</li>
</ul><li>Nível 5 </li>
<ul><li>Verificação –VER</li>
<li>Validação – VAL (Opcional)</li>
</ul></ol>No Site da ALATS jão estão disponíveis para download os documentos referentes aos níveis 1, 2 e 3.<br />
<br />
<div> </div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-81219149826016832152010-01-23T14:04:00.000-08:002010-01-23T14:19:11.856-08:00BRATESTE 2010Ao interessados em participar do BRATESTE 2010, segue informações sobre o evendo divulgadas pela ALATS.<br /><br />Dados do Evento<br /><br />BRATESTE São Paulo 2010<br />Agregando valor ao negócio<br />Dias 24, 25 e 26 de março de 2010<br /><br />Dia 24 - Tutoriais (02 Manhã e 02 Tarde) e<br />dias 25 e 26 - Seminário com Palestras.<br /><br />Local: Renaissance São Paulo Hotel<br />Alameda Santos, 2233<br />São Paulo, Brasil<br />Tel: 55 11 3069-2233 55 11 3069-2233<br />Fax: 55 11 3064-3344<br />http://www.hoteis.marriott.com.br/renaissance-sao-paulo<br /><br />Investimento:<br />Brateste Tutoriais - R$ 800,00 (direito a 02 tutoriais - 01 manhã e 01 tarde) - Vagas Limitadas!<br />Seminário Brateste - R$ 500,00 (02 dias de Palestras)<br />Brateste Completo (Tutoriais + Seminário) - R$ 1.100,00<br />Pagamentos até 31/01 - desconto de 10%<br />Pagamento no dia do evento - acréscimo de 10%<br /><br />Associados Alats têm 20% de desconto.<br /><br />Empresas tem descontos para pagamentos de mais de 05 inscrições.<br /><br /><table width="100%" cellpadding="0" cellspacing="0"> <tr> <td><!-- #BeginLibraryItem "/Library/container_titulos.lbi" --> <table border="0" cellpadding="0" cellspacing="0"> <tr> <td height="25" align="left" valign="middle"></td> <td align="left" valign="middle"></td> <td valign="middle" class="@@(_document['title'])@@"><span id="_ctl0__ctl0_dnnTITLE_lblTitle" class="Head">Grade de Palestrantes - Provisória</span></td> </tr> </table> <!-- #EndLibraryItem --></td> </tr> <tr> <td id="_ctl0__ctl0_ContentPane" align="left"><!-- Start_Module_1285 --><div id="_ctl0__ctl0_ModuleContent"> <table cellspacing="0" cellpadding="0" width="100%" border="0" summary="Design Table"> <tr valign="top"> <td id="_ctl0__ctl0__ctl0_HtmlHolder" class="Normal"><p><span style="color:#000080;">As Palestras em inglês terão tradução simultânea.</span></p><table style="BACKGROUND-POSITION: 0% 50%; BACKGROUND-ATTACHMENT: scroll; BACKGROUND-REPEAT: repeat; BORDER-COLLAPSE: collapse; BACKGROUND-COLOR: white; mso-padding-alt: 0cm 0cm 0cm 0cm" cellspacing="0" cellpadding="0" width="360" bgcolor="#ffffff" border="0"><tbody><tr style="HEIGHT: 14.25pt"><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 14.25pt; BACKGROUND-COLOR: #d9d9d9" valign="center" width="356" colspan="3"><p class="ecxmsonormal" style="TEXT-ALIGN: center" align="center"><span style="COLOR: #1f497d"> Dia: 24/03/2010 – Sala 1</span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><b><span style="COLOR: #1f497d">Horários</span></b><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><b><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB">Tutoriais</span></b></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><b><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB">Palestrante</span></b><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 29.25pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB">09:00-13:00</span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><a href="/Portals/0/Bra_Test%20Improvement%20on%20a%20shoestring.htm" target="_blanc"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB"><span style="color:#0099ff;">Test Improvement on a shoestring</span></span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></a></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal" style="MARGIN-LEFT: -5.15pt"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB"><a href="/Portals/0/Bra_biography_of_martin_pol.htm" target="_blanc">Martin Pol</a>, Emerson Rios</span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB">13:00-14:00</span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB">Almoço</span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB">14:00-18:00</span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><a href="/Portals/0/Bra_Test%20Outsourcing.htm" target="_blanc"><span style="color:#0099ff;"><span lang="EN-GB" style="COLOR: #1f497d; mso-ansi-language: EN-GB"><span style="color:#3399ff;">Test Outsourcing</span></span><span lang="EN-GB" style="mso-ansi-language: EN-GB"><o:p> </o:p></span></span></a></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="99"><p class="ecxmsonormal"><span style="COLOR: #1f497d">Martin Pol</span><o:p> </o:p></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #d9d9d9; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;"> <o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #d9d9d9; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Dia 24/03/2010 – Sala 2<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #d9d9d9; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="99"><p class="ecxmsonormal"><span style="color:#003366;"> <o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 24.75pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 24.75pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">09:00-13:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 24.75pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;"><a href="/Portals/0/Bra_Test_Design.htm" target="_blanc">Best practices in Test Design<o:p> </o:p></a></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 24.75pt; BACKGROUND-COLOR: #ffffff; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="99"><p class="ecxmsonormal" style="TEXT-ALIGN: justify"><span style="color:#003366;"><a href="/Portals/0/Bra_biography_of_ruud_teunissen.htm" target="_blanc">Ruud Teunissen<o:p> </o:p></a></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">13:00-14:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Almoço <o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">14:00-18:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;"><a href="/Portals/0/Bra_Test%20Estimation.htm" target="_blanc">Test Estimation<o:p> </o:p></a></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="99"><p class="ecxmsonormal"><span style="color:#003366;">Ruud Teunissen<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 29.25pt"><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 29.25pt; BACKGROUND-COLOR: #d9d9d9; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="356" colspan="3"><p class="ecxmsonormal" style="TEXT-ALIGN: center" align="center"><span style="color:#003366;"> Dia: 25/03/2010 – Auditório Central </span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">Horários<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Palestra<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Palestrante<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">09:00-09:15<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Abertura<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Emerson Rios<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">09:15-10:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Keynote speaker<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Martin Pol<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">10:30-11:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Coffee break e visita aos stands<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 57.75pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 57.75pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">11:00-12:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 57.75pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Uma proposta de ROI para projetos de Automação e Alta Automação de Testes<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 57.75pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Marco Bassi<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">12:00-13:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Almoço e visita aos stands <o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 86.25pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 86.25pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">13:00-14:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 86.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Metodologia aplicada em projetos de teste OffShore - Case BTR (Cliente na Bélgica, Desenvolvimento na Índia e Teste no Brasil)<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 86.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Ricardo Cristalli<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 57.75pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 57.75pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">14:00- 15:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 57.75pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Controle de Qualidade na Implantação dos novos Servidores de Exibição no Jornalismo da TV Globo<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 57.75pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Andréa Cruz<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 16.9pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 16.9pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">15:00-15:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 16.9pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Coffee break e visita aos stands<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 43.5pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 43.5pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">15:30-16:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 43.5pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Testes ágeis: Prazo menor, custo menor e ótimos resultados<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 43.5pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Aderson Bastos<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 29.25pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">16:30-17:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Palestra 5 (escolhido entre os trabalhos apresentados)<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;"> <o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 17.25pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 17.25pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">17:30-18:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 17.25pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Sorteios<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 17.5pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 17.5pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">18:00-19:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 17.5pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Coquetel de confraternização<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 29.25pt"><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 29.25pt; BACKGROUND-COLOR: #d9d9d9; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="356" colspan="3"><p class="ecxmsonormal" style="TEXT-ALIGN: center" align="center"><span style="color:#003366;"> Dia: 26/03/2010 – Auditório Central </span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;"> <o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Palestra<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f2f2f2; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Palestrante<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">09:00-10:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Keynote speaker<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 15pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Ruud Teunissen<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">10:30-11:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Coffee break e visita aos stands<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 29.25pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">11:00-12:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Automação de Testes Funcionais<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 29.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Elias Nogueira<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 15pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">12:00-13:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 15pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Almoço e visita aos stands<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 43.5pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 43.5pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">13:00-14:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 43.5pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Processo de Teste de Software: O caso da Datasus<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 43.5pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Marcia Cristina da Silva<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 86.25pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 86.25pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">14:00-15:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 86.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Estimativas de tamanho e esforço usando Análise de Pontos de Teste – Apresentação de casos reais no uso da técnica.<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 86.25pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;">Rodrigo Fagundes Moreira<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 22.3pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 22.3pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">15:00-15:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; BACKGROUND-REPEAT: repeat; HEIGHT: 22.3pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Coffee break e visita aos stands<o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 21pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 21pt; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">15:30-16:30<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 21pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="160"><p class="ecxmsonormal"><span style="color:#003366;">Palestra 9<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ccccff 0.5pt solid; HEIGHT: 21pt; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="85"><p class="ecxmsonormal"><span style="color:#003366;"> <o:p> </o:p></span></p></td></tr><tr style="HEIGHT: 26.3pt"><td style="BORDER-RIGHT: #ccccff 0.5pt solid; PADDING-RIGHT: 0cm; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 0cm; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none; BACKGROUND-REPEAT: repeat; HEIGHT: 26.3pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt" valign="center" width="83"><p class="ecxmsonormal"><span style="color:#003366;">16:30-17:00<o:p> </o:p></span></p></td><td style="BORDER-RIGHT: medium none; PADDING-RIGHT: 5.4pt; BACKGROUND-POSITION: 0% 50%; BORDER-TOP: medium none; PADDING-LEFT: 5.4pt; BACKGROUND-ATTACHMENT: scroll; PADDING-BOTTOM: 0cm; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none; BACKGROUND-REPEAT: repeat; HEIGHT: 26.3pt; BACKGROUND-COLOR: #f3f3f3; mso-border-top-alt: solid #CCCCFF .5pt; mso-border-left-alt: solid #CCCCFF .5pt" valign="center" width="259" colspan="2"><p class="ecxmsonormal"><span style="color:#003366;">Encerramento<o:p> </o:p></span></p></td></tr></tbody></table> </td> </tr></table><!-- End_Module_1285 --><br /></div></td><br /><br /> </tr><br /> </table></td><br /> </tr><br /><br /><br /></td>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-47516001253411387212009-12-07T03:02:00.000-08:002010-04-30T08:19:45.889-07:00Mesa Redonda DFTestes<div align="justify"><span style="font-family: courier new;">A quinta Mesa Redonda DFTestes foi sobre MPT – Melhoria do Processo de Testes. A discussão teve 13 respostas e 8 participantes: Fabrício Ferrari, Ueslei Aquino, Shmuel Gershon, Felipe Silva, Edwagney Luz, Robson Agapito, Wesley Baldan e o Wagner Duarte.<br />
Na sequência, segue um resumo da discussão, quem quiser conferir a discussão na íntegra, pode acessá-la no DFTestes. </span></div><div align="justify"><br />
<span style="font-family: courier new;"><strong><span style="background-color: white; color: blue;">O MPT.BR</span></strong> </span></div><div align="justify"><br />
<span style="font-family: courier new;">O Ueslei Aquino explanou sobre o que é o MPT.BR: </span></div><span style="font-family: courier new;"></span><br />
<div align="justify"><br />
O MPT é um modelo que está em desenvolvimento, com o objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais. </div><div align="justify"><br />
Este Modelo está sendo elaborado com base em algumas áreas de processo do MPS.Br e também com referências ao CMMI e PMBOK (para termos de projeto). </div><div align="justify"><br />
O modelo foi projetado inicialmente com 7 níveis de maturidade, mas possivelmente será alterado para 5 tornando-o assim mais leve que previsto anteriormente (está em fase de aprovação). Mas esta mudança aconteceria do Nível 4 em diante, ou seja os níveis até agora definidos serão mantidos (Nível 1 e 2). O Nível 3 está em fase terminal de desenvolvimento e o Nível 4 em Desenvolvimento.<br />
No meu Blog tem um pequeno post sobre o modelo com sua estrutura inicial, com 7 níveis. </div><div align="justify"><br />
A estrutura com 5 níveis deve ficar da seguinte forma: </div><div align="justify"><br />
• Nivel 1:<br />
o GPT – Gerência do Projeto de Teste;</div><div align="justify"><br />
• Nivel 2:<br />
o GRT – Gerência de Requisitos de Teste;</div><div align="justify"><br />
</div><div align="justify">• Nivel 3:<br />
o AQU – Aquisição (opcional);<br />
o GCO – Gerência de Configuração;<br />
o GQA – Garantia da Qualidade;<br />
o MED – Medição; </div><div align="justify"><br />
• Nível 4:<br />
o GRH – Gerência de Recursos Humanos;<br />
o GRU – Gerência de Reutilização;<br />
o GRI – Gerência de Riscos;</div><div align="justify"><br />
• Nível 5:<br />
o VER – Verificação;<br />
o VAL – Validação. </div><div align="justify"><br />
Atualmente 4 empresas encontram-se com processo de implementação do MPT nível 1 (GPT – Gerência de Projeto de Teste). Empresas como DataSus e iTeste (que provavelmente se certifica até o início de 2010), além de outras. </div><div align="justify"><br />
<strong><span style="color: blue;">Ser certificado MPT vale a pena?</span> </strong></div><div align="justify"><strong><br />
</strong>Segundo o Ueslei Aquino:</div><div align="justify">O modelo está em “gestação”, mas aqueles que gostam da área de processo e/ou pretendem investir nessa área, acho que é uma boa sim. </div><div align="justify"><br />
<strong><span style="color: blue;">Por que os “selos” de qualidade e melhoria, são tão criticados hoje em dia, principalmente pelos agilistas?</span></strong> </div><div align="justify"><br />
O Ueslei Aquino acredita que:</div><div align="justify"><br />
Pelo fato de muitas empresas buscarem o selo apenas para serem melhor colocados em licitações mas depois que o avaliado vira as costas engavetam toda documentação e volta a vida normal. Implantar processo seguir práticas é um tanto quanto burocrático, se na organização não tiver o apoio da alta gerência para q tudo seja seguido nada funciona. Acredito que MPS resolveu essa situação colocando validade de 3 anos para a certificação, se uma empresa não se re-certificar sai da lista dos certificados em determinado nível. </div><div align="justify"><br />
Segundo o Shmuel Gershon: </div><div align="justify"><br />
Os agilistas não inventaram as críticas aos selos de qualidade… As reclamações são antigas, é só olhar para as críticas ao ISO9000 e ao Six Sigma.</div><div align="justify">Uma das limitações de todos os processos uniformizados, é, bem, a uniformidade do processo . Como ele é estático e uniforme, quem tem que se adaptar é a empresa e os empregados. Empresas não são uniformes, e elas são compostas por interações não uniformes entre pessoas não uniformes. </div><div align="justify"><br />
Empresas são diferentes, e programam software diferentes. O processo para tratar de qualidade é o mesmo em um produto web-based e embedded? Um controlador de equipamento médico e um administrador de conteúdo? Uma empresa com 700 empregados e uma com 7? </div><div align="justify"><br />
O comentário do Ueslei aparece como uma boa surpresa, pois o foco em “áreas de teste de software de tamanho reduzido” implica na fé de que existem contextos diferentes e o tamanho é um dos parâmetros – uma boa novidade na área de estandardização de processos, que tende a ver tudo como ‘tamanho único’.</div><div align="justify">Por outro lado: </div><div align="justify"><br />
a) O tamanho da empresa é um parâmetro fraco sobre seu contexto;<br />
b) Comumente empresas com tamanho reduzido sentem menos a falta de processos do que grandes;<br />
c) O comentário implica que tamanho reduzido resulta em níveis menores de maturidade </div><div align="justify"><br />
Sobre a limitação citada pelo Shmuel, acredito que é uma verdade, e o pior é como alguns profissionais encaram esses selos. Infelizmente, muitos ganham os seus uniformes (adorei essa analogia rs) e percebem que ficam bonitinhos com ele, daí então, a sua maior preocupação é deixar o uniforme bem limpinho. </div><div align="justify"><br />
Mas… e o cliente? ahh… ele terá uma primeira impressão muito boa da empresa uniformizada, e como dizem a primeira impressão é a que fica (ou não) </div><div align="justify"><br />
No entanto após um tempo, o cliente vai perceber que as aparências enganam. </div><div align="justify"><br />
O mais importante para qualquer fornecedor é atender bem o cliente, isso é tão “lógico”. Selos, certificações profissionais, etc são plus, primeiro você tem que comer o feijão com arroz, pra depois comer a sobremesa! </div><div align="justify"><br />
O Edwagney também fez um comentário sobre as colocações feitas pelo Shmuel, a respeito da padronização dos processos:<br />
Excelente exemplo Shmuel, </div><div align="justify"><br />
Isso vem ao encontro de um texto que escrevi em meu blog sobre padronização com o título: “Padrão, todos nós deveríamos ter um.” (<a href="https://itqualityview.wordpress.com/">https://itqualityview.wordpress.com/</a>) </div><div align="justify"><br />
Minha visão é exatamente essa. O ponto crucial de alguns processos de qualidade, e processos em geral, não darem certo em algumas organizações é que elas não lançam mão da sua cultura, da sua política, não usam o que tem de melhor. Não adaptam um determinado padrão aos padrões já existentes na empresa.nas empresas nas quais trabalhei, vi acontecer muito isso. A questão era: “Vamos implantar isso de qualquer forma.” Conhece o ditado: “Top-guela-down”? é mais ou menos por aí… </div><div align="justify"><br />
Usar padrões e processos faz parte da inovação e da melhoria da qualidade, porém, arrisco dizer que 80% do sucesso de um projeto nesse sentido, se ganha usando o lado bom do conhecimento e cultura da empresa. </div><div align="justify"><br />
<strong><span style="color: #33ff33;"><span style="color: blue;">Qual a posição do mercado em relação as empresas certificadas?</span> </span></strong></div><div align="justify"><span style="color: black;">O Shmuel Gershon acredita que:</span> </div><div align="justify"><br />
Em um primeiro momento, pareceria uma questão de oferta e demanda. É igual ISO9001… se a empresa vai perder mercado por falta de certificação, enão certamente vale a pena. Se a empresa consegue manter diferenciação comercial sem o certificado, então não vale a pena. Certo? </div><div align="justify"><br />
O único problema na situação descrita é que no caso de uma certificação sobre testes, quem cria a demanda são as próprias empresas certificadas. </div><div align="justify"><br />
Assim como nas certificações de indivíduos, existe tanta confusão ao redor do que testes e testadores fazem, que é fácil apresentar uma certificação e dizer “Aqui oh, não se preocupe, nos somos certificados, por isso somos melhores que a concorrência”. Ao criar a demanda, criamos um circulo vicioso aonde quem não se certifica fica pra traz. </div><div align="justify"><br />
No fim das contas, se uma empresa acredita que deve passar pelo processo de certificação, tudo bem, mas com cuidado e delicadeza…<br />
É muito importante que o processo seja guiado por alguém (interno ou externo) que está atento as interações e os métodos implícitos no dia-a-dia, para que o processo não estraguem alguma área que já anda bem – ou para que o processo não esconda a realidade sobre uma área aonde existe incompetência. </div><div align="justify"><br />
No cenários em que a certificação representa um diferencial competitivo para a empresa, mas irá “atrapalhar” os processos internos da empresa, costuma haver uma grande resistência interna, um exemplo bem básico: </div><div align="justify"><br />
Se você é o Gerente de Teste e acaba de ser informado que a sua empresa irá tentar se certificar em um selo X, e sabe que isso irá trazer um grande impacto para o processo atual de Teste de Software, talvez você possa ser resistente a essa decisão, pois está olhando só para o seu nível.</div><div align="justify">Agora se você for analisar num nível macro a decisão, você poderá perceber que o selo X irá trazer grandes benefícios a nível de negócio para a empresa, podendo resultar em contratos importantes, que ir. </div><div align="justify"><br />
Moral da história: Precisamos sempre buscar ter uma visão ampla do nosso mundo. Para alcançar o sucesso, é necessário sacrifícios. (“O importante é termos a capacidade de sacrificar aquilo que somos para ser aquilo que podemos ser.” – Charles Dubois) </div><div align="justify"><br />
<strong><span style="color: blue;">Para uma empresa cujo core business não é o Teste de Software, é interessante a certificação?</span></strong> </div><div align="justify"><br />
Para o Ueslei Silva: </div><div align="justify"><br />
Bom, se esta empresa usa SW e possui profissionais que testam o SW, acredito que sim. Trabalhei em uma empresa que mantém no mercado um grande ERP. A empresa possui uma fábrica de desenvolvimento de aproximadamente 70 desenvolvedores e um departamento de teste com 8 testadores, para o mercado seria interessante mostrar para os clientes que a qualidade do SW é assegurada por processos estabelecidos, maduros, etc. (eu era o gestor da área de testes, mas a empresa não estava preparada culturalmente para implantar um processo assim). </div><div align="justify"><br />
Para o Shmuel Gershon depende:</div><div align="justify">Uma possibilidade: <strong><span style="color: blue;">Sim!</span></strong> – pelo menos vai ter um processo mais estruturado.<br />
Outra: <strong><span style="color: blue;">Não!</span></strong> Aonde existia incompetência caótica, agora existirá uma incompetência organizada e rigorosa. O problema desta última, é que agora ninguém mais percebe que tem que melhorar.<br />
Ou ainda: <strong><span style="color: blue;">Depende!</span></strong> Pode ser que o dono da empresa se sente inseguro e a certificação vai deixá-lo mais cordato para guiar a empresa. Ou pode ser que a equipe é madura o suficiente para não deixar a certificação ou o rigor do processo atrapalhar a operação. Pode ser que o gerente de testes não quer a certificação de jeito nenhum, e certifica-se vai criar rixas desnecessárias. Pode ser que a equipe é tão madura e com ótima performance que inserir as mudanças da certificação vai atrapalhar. Tudo pode ser.</div><div align="justify">A melhor resposta depende de cada empresa, gerente, líder e equipe. A equipe deve se conhecer o suficiente para escolher.</div><div align="justify">A respeito do caos citado pelo Shmuel, nessa semana ouvi uma história interessante, de um amigo meu, sobre uma grande empresa que estava se preparando para o CMMI: </div><div align="justify"><br />
Ele trabalhava na empresa XPTO, e essa empresa estava se preparando para o CMMI, daí o cliente X, pediu uma nova funcionalidade no sistema dele, esse cliente estava acostumado com o processo antes o CMMI, sabe aquele processo padaria? (me ver um pãozinho aí = me ver uma funcionalidade X), porém o Gerente do Projeto, não podia mais seguir o processo padaria, e para explicar isso para o cliente? rsrs (para não chorar) </div><div align="justify"><br />
<strong><span style="color: blue;">Alguém já participou de uma avaliação, avaliando ou sendo avaliado? E poderia relatar a experiência.</span></strong> </div><div align="justify"><br />
O Ueslei Aquino compartilhou um pouco da sua experiência com o MPT:<br />
Eu mesmo conduzi as reuniões de implantação das práticas do nível 1 na iTeste, num projeto em que o Cliente encontra-se na Bélgica, o Desenvolvimento na Índia e os Testes são feitos aqui no Brasil (RJ). Detalhes:(1) O desenvolvimento utiliza scrum e ja estava com 1 ano iniciado sem muitas documentações. Foi necessário mapear casos de uso para que os casos de testes fossem realizados; (2) A fábrica de Teste não Fala com o Desenvolvimento, a comunicação é direta com o cliente e este passa os bugs para o Desenvolvimento. Apesar de todo este cenário, o Projeto está andando muito bem e seguindo as práticas do MPT nível 1. </div><div align="justify"><br />
O Shmuel Gershon compartilhou a sua experiência com o TPI: </div><div align="justify"><br />
Eu participei de processos TPI (Test Process Improvements), e no meu departamento tiramos nossas próprias conclusões sobre o que ajuda e o que deveríamos ignorar. Também faço parte de um grupo para a discussão de metodologias, mas não seguimos nenhum processo público. Judy Bamberger foi uma das autoras do CMM, e ela escreve que “acredito que ele (o CMM) não foi concebido para ser usado de maneira em que determinada empresa tem que alcançar o nível X em determinado tempo, ou que a empresa precisar “ser” um certo nível antes que outros negociem com ela” (tradução minha). Ou seja, as documentações normalizadas de processos são apenas auxiliares, mas não devem dominar o procedimento. </div><div align="justify"><br />
</div><div align="justify"><strong><span style="color: blue;">A CQA</span></strong> </div><div align="justify"><br />
Para o Felipe Silva: </div><div align="justify"><br />
“A hora” de certificar-se é quando o ambiente está pronto. Fazendo uma analogia, a empresa é um quarto, pode estar bagunçado e cheirando mal ou arrumado e cheiroso, a certificação seria uma placa que você colocaria do lado de fora da porta “Quarto organizado”, dai já dá pra tirar as conclusões de quando tentar colocar a placa ou não e os impactos de tentar colocar a placa no momento errado, já pararam pra pensar se o cliente resolve abrir a porta e ver como está realmente este quarto por dentro e vê algo assustador? </div><div align="justify"><br />
O fato é, se o quarto está arrumado, por que não sinalizar isso ao mercado? Sim, vale a pena para a empresa estes selos.<br />
A respeito do ponto de vista do Felipe Silva, o Shmuel Gershon fez o seguinte comentário: </div><div align="justify"><br />
Seu exemplo é muito bom, mas eu gostaria de adicionar que ele falha em perceber a limitação das certificações de processos. Por exemplo: Meu jeito de arrumar o quarto e o de minha esposa são diferentes, os métodos de trabalho e os critérios de qualidade de nos dois difere também. Porém, ela performa com rapidez e segurança no seu modo – e consegue encontrar qualquer coisa em um piscar de olhos. </div><div align="justify"><br />
Se eu criar a CQA (certificacao de quarto arrumado), ela terá que mudar seu modo de trabalho – o quarto vai ficar do jeitinho que eu quero (e defini na documentação)… Mas será que ela vai estar executando a tarefa com a mesma satisfação? Será que ela vai encontrar as coisas com a mesma agilidade agora que as roupas estão guardadas por ordem alfabética? </div><div align="justify"><br />
E, mais importante: Será que a imposição de um método não natural a sua personalidade não vai afetar uma serie de outras áreas que a CQA não mede? Ou que eu não percebi serem cruciais para o bom funcionamento da família? </div><div align="justify"><br />
Enquanto o método de melhoria de processo de testes estiver aí para ensinar e guiar e deixar cada empresa criar seu próprio caminho para a excelência, maravilha. Mas ao tratar o conteúdo como uma ‘certificação’, o material acaba se tornando mandatório e standardizado – e o que pode ser bom para uma empresa pode ser perigoso para outra. </div><div align="justify"><br />
A resposta ao “vale a pena?” é “depende” – cada empresa e equipe deve analisar sua situação e necessidades. </div><div align="justify"><br />
<strong><span style="color: blue;">Experiências com o MPS-BR</span></strong> </div><div align="justify"><br />
O Robson Agapito compartilhou a sua experiência com o MPS-BR: </div><div align="justify"><br />
Vou contar uma história verídica que aconteceu conosco na Mega em relação ao MPS-Br… estávamos procurando melhorar a qualidade de nosso produto, e buscamos o conhecimento oferecido pela Softex chegando então a certificação do Nível G… mas desde o início lutamos não pela certificação, e sim pela melhor qualidade e melhor controle de tudo que entrava (solicitações) pelos clientes e tudo que saia (melhorias e correções) do desenvolvimento/testes. E tínhamos em mente que a certificação seria uma conseqüência da melhoria de nosso processo. </div><div align="justify"><br />
Com certeza no inicio “travou” um pouco, mas com o andamento dos projetos e adaptações ao modelo proposto, melhorias foram identificadas durante o andamento do trabalho, e esta melhoria foi identificada por todos, inclusive pelos clientes que hoje sentem um produto final mais maduro e com uma melhor qualidade. </div><div align="justify"><br />
Então digo, o importante não é a certificação (claro que ajuda muito em uma venda), mas sim o conhecimento e a bagagem na melhoria da qualidade que conquistamos na implantação de processos para garantir a maturidade de nossos processos… a certificação foi conseqüência. Mas a cada dia batalhamos pela melhoria do processo, pois sempre podemos melhorar e jamais se acomodar. </div><div align="justify"><br />
Creio que o MPT vem para se tornar um apoio à todos da área de testes, ajudando a criar e melhorar processos de testes pelo Brasil, e futuramente pela América Latina. </div><div align="justify"><br />
O Wesley Baldan também compartilhou uma experiência com o MPS-BR:<br />
Onde eu trabalho, foi um pouco diferente. Para obtermos o nível F (se eu não estou enganado, enfim, é o 2º nível) do MPS-Br a principal preocupação era com a aprovação, mas por conseqüência houve uma grande melhora… Claro, se está se preparando para obter um nível de qualidade as mudanças tem que ocorrer e por conseqüência há melhoras no produto final. </div><div align="justify"><br />
No começo foi muito difícil, porque antes era organizado, mas não tanto, então travava muito no começo o processo, mas depois de um tempo todos perceberam a melhora que aconteceu… É aquela coisa de quebrar a rotina, quando há uma mudança muitas pessoas não gostam.<br />
Depois de obtido o nível, a empresa foi adquirida por outra e um dos pontos positivos da área de Desenvolvimento era a atenção com a qualidade. </div><div align="justify"><br />
Para encerrar o “resumo”, segue abaixo o comentário do Wagner Duarte, que levantou um ponto muito importante a atitude das pessoas, principalmente, dos que estão liderando a implementação:<br />
Essa questão (mudança cultural) é e sempre foi um obstáculo na implementação de quaisquer melhorias e/ou mudanças em qualquer tipo de grupo. </div><div align="justify"><br />
Creio eu, que o problema não está apenas em quebrar paradigmas, mas principalmente no perfil daquele que propõem as mudanças.<br />
Vejo hoje, que têm muitos “líderes” que não têm perfil ou apenas que não aprenderam algumas das boas práticas de um “bom líder”, para exercer tal atividade. </div><div align="justify"><br />
• A forma em que a solução/mudança é proposta pode causar discordância e desmotivação dos membros da equipe;<br />
• Um “bom líder” tem que ter visão – para analisar um “Modelo” proposto e verificar o que se adéqua melhor à sua empresa/instituição;<br />
• Os membros que participam da implantação das mudanças/melhorias devem ter qualidade nas veias, para proporem ainda mais melhorias e não, contaminarem e desestimularem o restante do grupo, por não gostarem de mudanças e serem comodistas. </div><span style="font-family: courier new;"></span><a href="http://qualidadebr.wordpress.com/2009/12/06/mpt-melhoria-do-processo-de-testes/">http://qualidadebr.wordpress.com/2009/12/06/mpt-melhoria-do-processo-de-testes/</a> <br />
<div align="justify"><br />
O ponto levantado, faz-se bastante pertinente ao dizer que <strong><span style="color: blue;">“o MPT diz o que deve ser feito e não como”</span></strong>, ou seja, isso o torna um modelo proposto que, para se alcançar um determinado nível faz-se necessária a implementação/modificação de uma metodologia. Porém, como a empresa fará para se atingir o nível esperado, depende muito do “líder” que conduzirá o movimento.</div><div align="justify"></div><div align="justify"></div><div align="justify"></div><div align="justify"></div><div align="justify"></div><div align="justify"><br />
<br />
Post Original da Mesa Redonda no Blog do Fabrício Ferrari:</div><div align="justify"></div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-70183784452048196582009-10-06T16:46:00.000-07:002010-04-30T08:43:15.088-07:00Entendendo a Estrutura do MPT<strong><span style="color: #660000; font-family: "Courier New", Courier, monospace;">Introdução ao modelo</span></strong><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;">O MPT.BR é um modelo para Melhoria de Processo de Teste de Software Brasileiro, que está sendo desenvolvido com o princípio básico de ser compatível com o modelo MPS.BR criado pela Softex e é baseado também em alguns critérios usados pelo CMMI. O MPT é voltado para a melhoria das áreas de teste de software de empresas de qualquer porte. O modelo é leve e passível de ser adotado por áreas de teste de software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados. O objetivo principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais. </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: #660000; font-family: "Courier New", Courier, monospace;">Organizações envolvidas</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">As seguintes organizações:• ALATS – Associação Latino Americana de Teste de Software• RIOSOFT – Sociedade Núcleo de Apoio à Produção e a Exportação de Software</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">criaram este modelo com o objetivo de manter a compatibilidade com o MPS.BR e com o CMMI e permitir que empresas que implementaram o MPS e o CMMI na sua área de desenvolvimento, possam, com um pequeno esforço adicional, aumentar o nível de maturidade da sua área de teste de software. Entende-se que a melhoria da área de desenvolvimento, por si só, é insuficiente para que os resultados melhorem substancialmente. Necessário se faz uma melhoria de maturidade da área de teste de software.</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">À medida que o modelo for evoluindo serão liberados documentos de suporte para nortear os implementadores e avaliadores, assim como outros documentos relacionados ao modelo. Para obtê-los, bastará acessar o site da ALATS ou da Riosoft na área reservada ao MPT. </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: #660000; font-family: "Courier New", Courier, monospace;">Forma de organização do modelo</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Para garantir a aderência a esta área de processo devem ser implementadas as práticas específicas e as práticas genéricas, que se aplicam a todas as áreas de processo, correspondentes ao nível de maturidade visado. A avaliação de que a unidade de teste alcançou um determinado nível será feita através da comprovação objetiva dos resultados alcançados e do exame das evidências (diretas, indiretas e afirmações) de que a empresa implantou cada uma das práticas específicas e genéricas para aquela área de processo e grau de maturidade visado.</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Desta forma temos a seguinte organização:</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><strong><span style="color: blue;">Área de processo</span></strong> </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Práticas específicas </span><br />
<span style="font-family: "Courier New", Courier, monospace;">Objetivos genéricos </span><br />
<span style="font-family: "Courier New", Courier, monospace;">Práticas genéricas</span><br />
<br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: #660000; font-family: "Courier New", Courier, monospace;">Áreas de processo</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<span style="font-family: "Courier New", Courier, monospace;">O Guia de implementação do MPT.BR está subdividido em níveis de maturidade, a exemplo do CMMI e do MPS.BR. O nível 1 (um) contempla apenas a área de processo de Gerência de Projetos. O objetivo é atender áreas de teste de todos os tamanhos, mesmo aquelas com número reduzido de profissionais. </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="background-color: white; color: blue; font-family: "Courier New", Courier, monospace;">Nivel 1</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Gerência de Projetos de Teste - GPT</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: blue; font-family: "Courier New", Courier, monospace;">Nível 2</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Gerência de Requisitos de Teste - GRT </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: blue; font-family: "Courier New", Courier, monospace;">Nivel 3</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Aquisição – AQU (opcional)</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Gerência de Configuração – GCO</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Garantia da Qualidade - GQA</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Medição - MED </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: blue; font-family: "Courier New", Courier, monospace;">Nível 4</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Gerência de Recursos Humanos - GRH</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: blue; font-family: "Courier New", Courier, monospace;">Nível 5</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Desenvolvimento de Requisitos - DRE</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Integração do Produto - ITP</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Validação - VAL (opcional)</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Verificação - VER </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: blue; font-family: "Courier New", Courier, monospace;">Nível 6</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Análise de Decisão e Resolução - ADR</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Desenvolvimento para Reutilização - DRU(opcional)</span><br />
<span style="font-family: "Courier New", Courier, monospace;">Gerência de Riscos - GRI </span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br />
</span><br />
<strong><span style="color: blue; font-family: "Courier New", Courier, monospace;">Nível 7</span></strong><br />
<span style="font-family: "Courier New", Courier, monospace;">Análise de Causas e Resolução de Problemas- ACP</span> <br />
<br />
<br />
Fonte: http://www.alats.org.br/Default.aspx?tabid=252Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0tag:blogger.com,1999:blog-4309764132516073935.post-86023289800725702862009-09-20T09:27:00.000-07:002010-04-30T08:22:00.969-07:00A Origem do MPT.BR<div align="justify"><span style="font-family: courier new;"><strong><span style="color: #660000;">Introdução</span></strong><br />
<br />
Na década de 60 os softwares eram desenvolvidos com baixo nível tecnológico, os testes ficavam a cargo dos Analistas e programadores. O foco nesse momento era apenas <strong><span style="color: #660000;">demonstrar</span></strong> que o software estava funcional. À medida que a tecnologia evoluía, softwares mais sofisticados eram desenvolvidos, impactando diretamente na realização dos testes que desta vez se focaliza na <strong><span style="color: #660000;">detecção</span></strong> dos defeitos, erros e deficiências existentes no software, definição das capacidades e limitações e o fornecimento de informações sobre a qualidade dos componentes, sistemas e outros produtos. Mas, o grande problema neste momento estava em quem realizava tais processos, pois eram realizados pelos próprios usuários e testadores sem experiência. Embora desde a década de 70 já existir trabalhos mostrando que o teste precisava ser re-estruturado (Em 1979 Glenford Myers publicou aquele que atualmente ainda é considerado um dos melhores livros de teste de software existentes no mercado, sob o título de “The Art of Software Testing” (publicado por John Wiley and Sons Inc. em edição revisada em 2004)) foi a partir da década de 90 que o teste de software, enfim, recebe um novo olhar. Os holofotes agora estão sob a perspectiva da <strong><span style="color: #660000;">prevenção</span></strong>. Assim como comprovado por Myers, quanto mais cedo encontrar e corrigir um defeito, mas barato se torna para empresa. Desta forma inspeções são realizadas nos artefatos do software, possibilitando a detecção e redução de defeitos logo nas fases iniciais do desenvolvimento.<br />
<br />
Com a sofisticação dos softwares, processos de maturidade no desenvolvimento de software foram criados para se garantir cada vez mais a qualidade do produto. Em conseqüência, Processos de Teste surgiram para atribuir uma melhoria contínua aos serviços de teste. Atualmente vários são os processos destinados a Teste de Software. Citando alguns deles temos :<br />
<br />
• Testability Suport Model (TSM);<br />
• Testing Maturity Model (TMM);<br />
• Test Process Improviment (TPI) entre outros.<br />
<br />
Alguns desses modelos tiveram origem a partir de um modelo de processo de software, como por exemplo o TMM, cuja base original é o CMM. </span></div><div align="justify"><span style="font-family: courier new;"><br />
Aplicar algum desses modelos de teste no mercado brasileiro é um tanto quanto trabalhoso e caro, pois não existem entidades responsáveis pela manutenção no Brasil, não são fáceis e nem baratos de se implementar.<br />
<br />
<strong><span style="color: #660000;">Uma nova perspectiva de Processo de teste no Brasil</span></strong><br />
<br />
Tendo como fundamento toda história em torno de “Teste de Software” e a realidade do mercado brasileiro de desenvolvimento de software, em novembro de 2007, após avaliações, análises e comparações Emerson Rios chega à conclusão de que mais do que criar um modelo de maturidade independente para o processo de teste de software temos, a primeira vista, o privilégio de implementar o que por ele foi chamado de <span style="color: #660000;">processo compartilhado</span>, ou seja, o MPS.BR (modelo criado com base no CMMI, normas ISO 12207 e 15504, para melhoria do processo de software brasileiro – seu foco é tornar possível a implementação do modelo nas empresas de pequeno e médio porte) é flexível ao ponto de se enquadrar completamente a realidade de uma fábrica de teste, a partir do momento em que o teste é tratado como projeto como relata o autor: </span></div><div align="justify"><span style="font-family: courier new;"><br />
</span><br />
<div align="justify"><span style="font-family: courier new;">“Os métodos usados para testar software evoluíram à medida que os sistemas tornaram-se maiores, mais complexos e destinados a variados ambientes. Os testes passaram a ser executados por equipes especializadas e as empresas criaram áreas dentro de sua estrutura organizacional para cumprir esse papel. Passamos a ter projetos e processos de teste, que como tal são passíveis de melhorias. Há diversos modelos de maturidade de teste, entretanto o autor os considera desnecessários, propondo que seja utilizado o MPS.BR como modelo de maturidade...” (Rios, Emerson) </span></div><div align="justify"><span style="font-family: courier new;"><br />
<br />
Algumas adaptações seriam necessárias e estas seriam em função da diferença entre os documentos adotados para o projeto de software e de teste.<br />
<br />
Não tendo esta proposta aceita pelo MPS.Br. A ALATS em parceria com a RioSoft dão início ao desenvolvimento de um modelo de maturidade de processo de teste baseado no MPS.Br. Este modelo, que atualmente consta com os níveis 1 e 2 desenvolvidos e em implementação com projetos piloto, é chamado de <strong><span style="color: #660000;">MPT.BR (Melhoria do Processo de Teste Brasileiro).</span></strong></span></div></div>Ueslei Silvahttp://www.blogger.com/profile/00371911091979980191noreply@blogger.com0