VSTS – Visual Studio Team System para Testadores – Introdução

Antes de falar um pouco sobre o Visual Studio Tem System (VSTS), devemos entender um pouco sobre o papel do testador no ciclo de desenvolvimento de software. Resumidamente, podemos dizer que a função do testador é garantir a qualidade do produto e, para isso, o trabalho dele no ciclo de desenvolvimento de software é:

• Auxiliar os desenvolvedores na elaboração dos testes unitários automáticos;
• Montar e configurar o ambiente e infra-estrutura de teste;
• Escrever casos de teste;
• Executar testes;
• Automatizar casos e tarefas de teste;
• Evidenciar os resultados;
• Acompanhar os defeitos encontrados;
• Desenvolver novas habilidades;
• O Analista de Teste é “o cara que aprova”. Nada é considerado “pronto” sem que ele diga que está.

Bem, agora que você já sabe um pouco sobre o papel do testador no ciclo de desenvolvimento de software, é necessário saber quais os testes que podem ser aplicados ao projeto (qualquer projeto que está sendo desenvolvido e que o testador esteja participando) de teste. Abaixo temos alguns exemplos:

Unit e Component Tests: São os testes que focam na arquitetura. Esses testes são executados automaticamente e a responsabilidade é dos desenvolvedores. Os testadores devem auxiliar os desenvolvedores na elaboração desses testes.

Functional e Story Tests, Simulations, Prototypes: São os testes que focam no negócio. Esses testes são executados automaticamente/manualmente e a responsabilidade é dos testadores em conjunto com outros envolvidos (clientes, usuários, etc.) no projeto. Neste caso, esses tipos de teste ajudam no entendimento das funcionalidades.

Scenarios, Exploratory, Usability, User Acceptance Testing: São os testes que focam no negócio e encontrar defeitos. Esses testes são executados manualmente e a responsabilidade é dos testadores. Neste caso, esses tipos de teste ajudam a encontrar o maior número de defeitos possível.

Performance, Load e Security Testing: São os testes que focam na arquitetura e estrutura do software. Esses testes são executados por ferramentas capazes de simular cenários de testes, por exemplo: Ter 10.000 usuários registrados no sistema simultaneamente. A responsabilidade da execução desses testes é dos testadores. Neste caso, esses tipos de testes ajudam identificar se a aplicação/software que está sendo testado é robusto suficiente.

Neste momento, já sabemos o papel do testador no ciclo de desenvolvimento de software e também quais os testes que podem ser aplicados aos projetos. Agora chegou o momento de criar um Projeto de Teste e incluir todos os seus artefatos de teste. Para isso, basta acessar o menu File / New / Project. Após acessar este menu, a janela abaixo será aberta e basta você selecionar a opção Test Project / Test Documents no menu (árvore) da esquerda. Feito isso, selecione o template Test Project informando o nome do projeto no campo Name.

Feito isso chegou a hora de Conhecer a IDE de Testes no Visual Studio.

A IDE (Integrated Development Environment) possui um leque amplo de ferramentas para manipular testes e que auxiliam muito o testador no dia-a-dia de trabalho. Para acessar as funcionalidades relacionadas com testes do Visual Studio, basta acessar o menu Test / Window. Abaixo temos a lista das principais funcionalidades:

• Solution Explorer: essa janela apresenta uma listagem dos arquivos presentes em cada solution envolvendo projetos, arquivos de teste, etc;

 

• Test Manager: através dessa janela é possível executar os testes visualizando-os de diversas formas, adicionar novos testes, agrupar, ordenar e localizar testes na listagem;

• Test Result: com essa opção, podemos visualizar todos os resultados de testes executados no projeto. Essa janela demonstrará se o teste foi executado com sucesso ou se houve erros durante a execução. A partir dessa janela também é possível reexecutar o teste que acabou de ser rodado;

• Code Coverage Results: se essa opção estiver habilitada, é possível visualizar as coberturas de códigos em determinadas execuções de teste, observando o percentual de código executado para cada método;

• Test Runs: essa janela permite acompanhar uma fila de execução de testes, a fim de identificar testes que estão esperando para serem executados, testes em execução, já executados e diversas opções desse gênero;

• Test View: a janela Test View é a forma mais rápida de executar um teste. Através dela podemos executar inclusive em modo Debug, podendo acompanhar a execução passo a passo do método selecionado. Além disso, podemos configurar diversas propriedades de cada testes presente nessa janela.

Até+,

Quezada

 

Referências:

1. Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
2. Visual Studio Team System Rocks by Alércio Bressano, Alexandre Tarifa, Andrey Sanches, Clementino Mendonça, Emerson Facunte, Fábio Câmara, Fábio Hirota, Hélio Sá Moreira, Igor Abade V. Leite e Mauro Sant’Anna

Gerenciamento de Riscos - Introdução

Nos últimos dias estava discutindo com um amigo meu o tema “Gerenciamento de Risco”, então comecei a ler um artigo sobre esse tema e resolvi divulgar um pouco dessa informação com vocês. Mas você pode estar se perguntando “O que isso tem haver com teste e qualidade de software?”, bem, tem tudo haver, todo projeto que estamos executando precisamos gerenciar riscos. A nossa vida é gerenciar riscos! :-) Bem, vamos lá!

O fator prazo é crítico na identificação, quantificação e monitoramento de riscos em projetos nos quais o cumprimento de datas é mandatório. Para o gerenciamento de riscos, utiliza-se inicialmente a identificação e quantificação do fator ou evento de risco.
Complementando os modelos de gerenciamento de riscos do PMBOK (Project Management Body of Knowledge), iremos utilizar um método para aumentar a eficácia dos modelos de gerenciamento de riscos mais utilizados. “Trata-se de um método aprimorado de gerenciamento de riscos de não alcançar a meta de prazo do projeto. Quando não é possível planejar com mais folga, deve se pensar em planejamento e preparação de contingências. Isto freqüentemente envolve alocação de recursos adicionais para algo que pode não acontecer.” (Chris Felstead).

O método utilizado tem seis etapas que devemos usar para mitigar os riscos:

• Contextualizar: determinar a categoria da data meta e a conseqüência, caso esta não seja alcançada.
• Identificar: identificar os riscos que devem ser gerenciados e que requerem prazo de preparação anterior a implantação. Enfatizar que se o evento de risco ocorrer, fará com que o projeto ultrapasse a data meta.
• Analisar os riscos: identificar os responsáveis pelos planos de contingência e aqueles que podem custeá-los.
• Tratar os riscos: determinar a data na qual a preparação deve ser iniciada e se os planos de contingência são economicamente viáveis.
• Monitorar e revisar os riscos: para riscos que não tenham sido priorizados, determinar se e quando a preparação de contingências deve ser iniciada.
• Comunicar e discutir: obter a autorização do interessado para iniciar a preparação.

O Sr. Felstead caracteriza estas ações adicionais com um segundo passo para o gerenciamento de riscos. As atividades requeridas pelo modelo criam um método para identificar e gerenciar os riscos do projeto de forma simplificada. “Atualmente, em muitas empresas o gerenciamento de riscos não é agressivo o suficiente para viabilizar a alocação de recursos necessários ou realizar o planejamento de contingências de forma adequada”.

Se estivermos trabalhando em um projeto de desenvolvimento de software, todas as etapas acima devem ser negociadas e de conhecimento do time todo, incluindo desenvolvedores, testadores, etc.

Para ajudar ainda mais o entendimento de Gerenciamento de Riscos e as etapas usadas no método acima explicado, abaixo estão alguns conceitos usados no gerenciamento de riscos.

• Riscos: O risco é uma perda em potencial para a organização. Um exemplo é o risco resultante do mau uso do computador. O risco pode ser medido através da análise de risco.
• Análise de risco: A análise de risco é uma avaliação dos recursos de informação de uma organização, seus controles e suas vulnerabilidades. Ela combina a possibilidade de perda de cada recurso com sua taxa estimada de ocorrência para estabelecer o grau de prejuízos financeiros, ou de outra ordem, que essa perda poderá ocasionar. Na verdade, a análise de riscos combina a probabilidade de ocorrência com a gravidade dos danos causados por sua ocorrência.
• Ameaça: Existe um risco de um meteoro cair na cidade onde você mora. Isso é uma ameaça a sua vida? Não, pois a probabilidade dessa ocorrência é quase zero. Podemos dizer que a ameaça é a capacidade de alguém explorar a vulnerabilidade de um sistema de computador ou aplicação.
• Vulnerabilidade: A vulnerabilidade é uma falha de desenho, implementação ou operação que permite a concretização de uma ameaça. Um site na internet, por uma falha de desenho e de implementação, pode permitir que hackers invadam o ambiente interno da empresa, portanto uma falha tornou o site vulnerável. Um risco só se torna uma ameaça quando existe uma vulnerabilidade.
• Controle: O controle é uma maneira de tentar reduzir as causas dos riscos, evitando, desse modo, sua ocorrência ou, pelo menos, reduzindo a freqüência de ocorrência.

Este texto é baseado no artigo “O desafio de projetos com data meta – novas estratégias de gerenciamento de riscos”, apresentado por Chris Felstead, PMP, no Congresso PMI 2005 – Ásia. Fonte: PM Network, edição Setembro/2005, página 76

Muitas vezes você pode utilizar uma simples planilha para gerenciar riscos. Abaixo estão algumas informações que podem ter nessa sua planilha:

• ID do Risco: Número que identifica o Risco
• Projeto: Nome do projeto que o risco está relacionado
• Item de Risco: Risco que foi identificado
• Status: Status do risco (Aberto, Parado, Em andamento, Fechado, etc.)
• Impacto: Nível de impacto do risco no projeto (Alto(5), Médio(3), Baixo(1))
• Plano de Mitigação e Contingência: Plano de Mitigação e Contingência elaborado para minimizar ou remover o risco encontrado.
• Pessoa Responsável: Pessoa responsável por executar o Plano de Mitigação e Contingência
  Acompanhamento / Comentários: Informações de acompanhamento das atividades executados para mitigar o risco
• Data de Abertura: Data de abertura do risco
• Data de Fechamento: Data de fechamento do risco
• Duração (dias): Tempo que o risco ficou aberto

Boa leitura!

Até+,
Quezada

XXXVII Encontro do SPIN-Campinas - Participação do "Time de Teste" em Projetos Scrum

Olá Pessoal,

Gostaria de agradecer a participação de TODAS as pessoas que participaram do XXXVII Encontro do SPIN-Campinas que aconteceu no dia 24/Setembro/09 na Motorola em Jaguariúna, principalmente a Coordenação do SPIN-Campinas.
Realmente foi muito legal, conseguimos trocar experiências, tivemos várias discussões excelentes. A participação de vocês foi essencial para fazer o evento acontecer!!!

Gostaria de dar os Parabéns para a Gabriela, ela ganhou um vale presente da FNAC pois acertou o nome dos Macacos!! Hehehehehe !!! Gabriela, se você comprar um DVD de filme, depois me empresta, ok? :-)

Bem, para finalizar, segue abaixo a apresentação:

XXXVII Encontro do SPIN-Campinas - Participação do Time de Teste em Projetos Scrum

Veja mais apresentações de Gustavo Quezada.

Muito obrigado!!

Até+,
Quezada

Palestra - Papel do Time de Teste em Projetos SCRUM

Olá Pessoal,

Chegou o momento da gente bater um papo sobre Teste de Software! Desta vez estarei falando um pouco sobre as experiências em Projetos SCRUM. :-) ANOTEM NA AGENDA DE VOCÊS!!!

Estão abertas as inscrições para o XXXVII evento do SPIN-Campinas, que será realizado no dia 24 de setembro de 2009, a partir das 13:00h, na Motorola. No evento serão realizadas três apresentações sobre Testes e eu serei um dos palestrantes. São elas:

Título: Papel do Time de Teste em Projetos SCRUM

Resumo: Os projetos de desenvolvimento de software que utilizam o SCRUM para auxiliar no gerenciamento de projetos vêm crescendo a cada dia. A empresa que decide utilizar o SCRUM nos projetos tem um grande desafio para implementá-lo e desenvolver essa nova “cultura” internamente na empresa e o desafio é maior ainda quando o time de teste participa desses projetos. A apresentação abordará alguns pontos onde o time de teste colabora e participa, e o mais importante, quais tipos de atividades o time de teste executa no projeto.

Palestrante: Gustavo Quezada (ASGA)

Título: Análise da causa de defeitos em aplicações web

Resumo: Atualmente, é crescente a dependência humana para com computadores e software. Uma vez que sistemas baseados na web são cada vez mais utilizados, avaliar sua confiabilidade é vital para que estes sejam robustos e tenham qualidade, refletida na redução no número de defeitos. Esta palestra apresenta de maneira geral um dos processos utilizados pela empresa na implantação de um mecanismo para análise da causa dos defeitos em um conjunto de aplicações web. Além disso, dados coletados em um estudo de caso serão apresentados ao público, assim como benefícios obtidos e lições aprendidas.

Palestrante: Bruno Teixeira de Abreu (SOFIST)

Título: Case – Automação de testes de interface do usuário em ambientes virtualizados

Resumo: Os testes de regressão geralmente são executados após a correção de algum defeito ou após a adição de uma nova funcionalidade. Normalmente, este tipo de teste é realizado através de ferramentas de automação de teste, devido à falta de tempo para executar novamente casos de teste já executados. E se o sistema precisa ser testado em mais de um ambiente? Não é por acaso que os testes de regressão ficam para segundo plano. Portanto, o uso de ferramenta para a automação de testes e a virtualização dos ambientes são indispensáveis para garantir os prazos e a qualidade do sistema. Alguns benefícios da automação e virtualização de ambientes de teste:

• Métricas de retrabalho e esforço de teste
• Aumento da qualidade do produto final
• Diminuição do esforço e tempo do ciclo de desenvolvimento

Palestrante: Joselito Viana Soares (Synchro Solução Fiscal)

O evento é gratuito!!!

Para se inscrever, envie um e-mail para Fernanda Azevedo Oshiro (wfa019@motorola.com), informando o nome completo, RG, empresa e e-mail e placa do carro dos inscritos, até dia 22 de setembro de 2009. O endereço da Motorola é Rodovia SP 340, Km 128,7 – Tanquinho – Jaguariuna-SP.

Para maiores detalhes acessem - http://www.cpqd.com.br/spin-cps/index.php

Até+,
Quezada

Execução e Relatório de Teste

Para continuar com o assunto “Relatório de Execução de Teste”, hoje vamos mostrar um pouco mais sobre Execução de Teste. A idéia deste post é auxiliar você com as atividades de planejamento, execução e relatórios de teste.

Execução dos casos de teste

Após a fase de Análise e Design de Teste ser concluída, chega à hora de entrar na fase de Execução de Teste. A primeira coisa que deve ser feita antes de começar a execução efetivamente é planejar e/ou rever o planejamento dessa fase. Para ajudar nesse planejamento uma boa prática é utilizar um Gráfico para mostrar o planejado versus o atual e, neste caso, nada melhor do que o Gráfico Curva-S. Abaixo temos a Tabela 1 – Gráfico Curva-S, a qual é utilizada para fazer o planejamento da execução dos casos de teste.

Tabela 1 – Gráfico Curva-S

Para facilitar o entendimento da tabela acima, segue abaixo a descrição de cada coluna:

• Data: data de execução planejada;
• Total Planejado: número total de casos de teste planejado para execução;
• Total Planejado Acumulativo: número total de casos de teste planejado acumulativo;
• Total Passado Planejado: número total de casos de teste passados no dia;
• Total Passado: número total de casos de teste passados acumulados;
• Total Falhado Planejado: número total de casos de teste falhados no dia;
• Total Falhado: número total de casos de teste falhados acumulados;
• Total Bloqueado Planejado: número total de casos de teste bloqueados no dia;
• Total Bloqueado: número total de casos de teste bloqueados acumulados;
• Total Atingido: número total de casos de teste executados até o momento somando, total passado, total falhado, total bloqueado;
• Comentário Execução: comentários gerais do planejamento.

Após a criação da tabela acima, basta gerar gráfico incluindo os campos Data, Total Planejado Acumulativo, Total Passado, Total Falhado, Total Bloqueado, Total Atingido, como mostrado abaixo na Figura 1 – Gráfico Curva-S.

Figura 1 – Gráfico Curva-S

Após a criação do Gráfico Curva-s, obtém-se o número total de casos de teste que foram planejados para execução incluindo os novos casos de teste, porcentagem de casos passados, falhados e bloqueados e casos de teste de regressão. Com isso é possível verificar se o planejamento feito anteriormente está de acordo com o atual, caso seja necessário, um novo re-planejamento deve ser feito e as partes interessadas informadas. Vale lembrar que a criação dos ciclos de teste deve ser planejada de acordo com o progresso da execução, estabilidade do software e critério de saída. Quando o planejamento está concluído, chega a hora da execução dos testes.
Os casos de teste são executados usando os procedimentos documentados e/ou automáticos do script de teste. Para que a fase de execução de teste seja executada com sucesso deve-se:

• Executar os casos de teste usando o documento de procedimentos de teste e/ou scripts de teste;
• Registrar o resultado atual;
• Comparar o resultado atual com o resultado esperado;
• Se necessário, repetir a execução de um caso de teste quando um incidente é encontrado, ou seja, devemos fazer o teste de confirmação;
• Executar testes de regressão como planejado.

Devido ao alto risco de mudança do código entre a execução de um ciclo e outro, deve-se ter uma política de re-teste bem definida.
Em alguns casos, testes podem ser executados “informalmente” sem usar procedimentos de teste detalhado, como por exemplo: teste exploratório.

Relatórios de Teste
Sempre que é encontrado um incidente de teste na fase de execução é necessário relatar esse incidente. Para isso, deve-se definir os relatórios necessários para acompanhar o progresso do(s) projeto(s) de teste segundo a norma IEEE 829-1998. Os relatórios de teste que a IEEE sugere são os seguintes:

• Relatório de Log de Teste;
• Relatório de incidentes de Teste;
• Relatório de Sumário de Teste.

Para ajudar no entendimento de como chegamos aos relatórios acima, segue abaixo a Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829.

Figura 2 – Relação de documentos de teste para o processo de teste - IEEE 829 -1998

Relatório de Log de Teste
Tudo o que for relevante durante a fase de execução de teste deve ser reportada no relatório de log de teste.
Segundo a norma IEEE 829 o relatório de log de teste deve ter as seguintes informações:

• Identificador: identificador único e específico para o relatório, por exemplo, o nome do sistema com número do release mais data e hora do teste;
• Descrição: identificar o que foi testado e o ambiente em que o teste foi executado incluindo hardware, quantidade de memória utilizada, etc;
• Atividades e eventos: para cada evento, identificar data/hora, tempo utilizado e responsável;
• Descrição da execução: descrever o que foi feito e identificar os responsáveis pela atividade incluindo testadores, observadores e operadores;
• Resultados dos procedimentos: para cada execução, descrever os resultados encontrados podendo ser sucesso ou não;
• Informações sobre ambiente de teste: informar qualquer condição específica do ambiente de teste, caso seja necessário;
• Eventos imprevistos: descrever detalhadamente o que aconteceu antes e depois de uma atividade ou evento inesperado.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

Relatório de Incidentes de Teste
Toda e qualquer discrepância entre o resultado esperado e o encontrado na execução dos casos de teste devem ser reportados para o time de desenvolvimento com o máximo de detalhes possíveis. Nesse caso, é utilizado o relatório de incidentes de teste o qual é registrado todos os defeitos encontrados durante a fase de execução de teste.
Segundo a norma IEEE 829 o relatório de incidente de teste deve ter as seguintes informações:

• Identificador do relatório: identificador único e específico para o relatório, por exemplo, release testado mais o identificador de um caso de teste ;
• Sumário da ocorrência: uma breve descrição do incidente; identificar os itens de teste envolvidos indicando sua versão, caso seja necessário; adicionar referência para a especificação do caso de teste, assim o desenvolvedor que for corrigir o defeito terá uma base de documento de teste além do documento de requisitos e adicionar também o relatório de log de teste, se necessário;
• Descrição do incidente: prover uma descrição do incidente incluindo os seguintes itens:
• ==>Entradas;
• ==>Resultados esperados;
• ==>Resultados encontrados;
• ==>Problemas;
• ==>Data e hora do incidente;
• ==>Procedimentos para reproduzir o problema;
• ==>Ambiente;
• ==>Tentativas para repetir o problema;
• ==>Testadores;
• ==>Observadores.
  

Vale lembrar que outras informações podem ser incluídas sempre que necessário e nem sempre todos os campos acima serão necessários.

• Impacto: indicar qual o impacto que o incidente terá no plano de teste de execução podendo falhar, bloquear o(s) testes(s) ou até mesmo uma possível mudança no caso de teste ou requisitos. Se possível, informar a prioridade e severidade do incidente.
  Os incidentes de teste devem ser armazenados em um repositório e, caso necessário, revisar o relatório de incidentes de teste com as partes interessadas.

Relatório de Sumário de Teste
Fornecer um sumário das atividades de teste incluindo os resultados, como o próprio nome do relatório já diz, relatório de sumário de teste. A idéia é resumir as atividades realizadas na execução dos testes.
Segundo a norma IEEE 829 o relatório de sumário de teste deve ter as seguintes informações:

• Identificador: identificador único e específico para o relatório, por exemplo, release e/ou projeto testado;
• Sumário: sumarizar a evolução das atividades de teste identificando os itens testados e o ambiente utilizado para execução dos testes;
• Variações: informar qualquer procedimento diferente do que estava especificado no plano de teste e procedimentos de teste; especificar o motivo da utilização do procedimento alternativo;
• Avaliações do processo: avaliação resumida do processo adotado contra o especificado no plano de teste; identificar as funcionalidades ou combinações de teste que não foram exercitadas explicando a razão; qualquer ocorrência que possa impactar na qualidade do software/produto deve ser considerada;
• Sumário dos resultados: sumarizar os resultados de teste identificando o número de casos de teste executados, número de defeitos encontrados, número de defeitos fechados e abertos, etc;
• Avaliação do(s) teste(s): proporcionar uma avaliação global de cada item, incluindo suas limitações. Essa avaliação deve ser baseada nos resultados dos casos de teste e nos critérios de aprovação/reprovação;
• Sumário de atividades: resumir os recursos envolvidos no projeto de teste, número total de horas utilizadas no projeto, tempo total utilizado para cada atividade principal, etc;
• Aprovações: listar o nome e títulos das pessoas responsáveis pela aprovação do projeto de teste incluindo os relatórios.

Vale lembrar que outras informações podem ser incluídas sempre que necessário.

No post Relatório Parcial de Execução de Teste você pode encontrar informações adicionais sobre relatório de teste.

Até+,
Quezada

Relatório Parcial de Execução de Teste

Quando estamos participando de uma execução de teste não basta executar, executar, executar, encontrar defeitos, encontrar mais defeitos e mais. Precisamos saber repassar/compartilhar para os Stakeholders (Partes interessadas no projeto) todo o trabalho que foi feito em forma de números e riscos. A idéia deste post é compartilhar com vocês um exemplo simples e fácil de reportar o status de uma execução de teste.

Um Analista de Teste precisa reportar os defeitos encontrados na execução de testes, juntamente com informações úteis para as partes interessadas no projeto. Na maioria das vezes, esses relatórios não usam nenhum padrão ou modelo nem são comuns para a organização e, o que é pior, não é possível saber se a execução está atrasada ou quais defeitos o time de desenvolvimento deverá dar prioridade.

O relatório parcial de execução deve ser resumido e objetivo, basicamente com as informações abaixo:

• Informação do Plano Master;
• Gráfico Curva-S Esforço;
• Distribuição Gráfica de Defeitos;
• Lista de Requisição de Mudanças;
• Riscos;
• Contatos;

1. Informação do Plano Master
A seção informação do plano master deve conter a quantidade de testes planejados, executados, passados, falhados e bloqueados até o momento. Ao verificar essa seção, o usuário deve ser capaz de obter as seguintes informações que são divididas em três partes:

Informações Gerais

• Plano Master: nome do plano master;
• # de Ciclos: número de ciclos executados até o momento;
• Data de Início: data de início da execução;
• Data de Término: data de término da execução;
• Release Atual: versão do release usado na execução;

Dados de execução do(s) ciclo(s)

• Ciclo: número do ciclo;
• Total Planejado: número total de testes planejados;
• Total Executado: número total de testes executados;
• Total Passado: número total de testes passados;
• Total Falhado: número total de testes falhados;
• Total Bloqueado: número total de testes bloqueados;

Dados de execução do plano master

• Total Planejado: número total de testes planejados;
• Total Executado: número total de testes executados;
• Total Passado: número total de testes passados;
• Total Falhado: número total de testes falhados;
• Total Bloqueado: número total de testes bloqueados;

Como um plano master pode conter vários ciclos, ou seja, um caso de teste pode ser executado em mais de um ciclo e o resultado da execução desse teste pode ser diferente em todos os ciclos, o valor reportado no plano master deve ser o resultado mais novo/atual reportado. Abaixo segue um exemplo para ilustrar as informações acima:

Informações Gerais

• Plano Master: Portal Web de Notícias
• # de Ciclos: 02
• Data de Início: 01/08/2009
• Data de Término: 12/08/2009
• Release Atual: 01.00.01

Dados de execução do(s) ciclo(s)

• Ciclo: 01 (data 05/08/2009)
• Total Planejado: 100
• Total Executado: 100 100%
• Total Passado: 90 90%
• Total Falhado: 05 05%
• Total Bloqueado: 05 05%
  

• Ciclo: 02 (data 12/08/2008)
• Total Planejado: 10 (5 casos de teste falhados e 5 bloqueados)
• Total Executado: 10 100%
• Total Passado: 09 09%
• Total Falhado: 01 01%
• Total Bloqueado: 00 00%

Dados de execução do plano master

• Total Planejado: 100;
• Total Executado: 100 100%
• Total Passado: 99 99%
• Total Falhado: 01 01%
• Total Bloqueado: 00 00%

2. Gráfico Curva-S Esforço
A seção gráfico curva-s esforço deve informar a quantidade de testes planejados, executados, passados, falhados e bloqueados até o momento, só que de forma gráfica, onde o usuário poderá comparar o esforço planejado X atual. Para gerar esse gráfico, o Analista de Teste deve ter uma tabela onde os valores são atualizados diariamente de acordo com o progresso. Segue abaixo um exemplo:

Tabela 1 – Tabela Gráfico Curva-S Esforço



Figura 1 – Gráfico Curva-S Esforço

3. Distribuição Gráfica de Defeitos
A seção distribuição gráfica de defeitos deve conter a quantidade de defeitos encontrados de forma gráfica. Ao verificar essa seção, o usuário deve ser capaz de saber quais são os defeitos que impactam um número maior de casos de teste e, dessa maneira, o Gerente de Projeto ou o próprio time de desenvolvimento poderá dar prioridade para os defeitos que mais impactam o resultado final da execução. Vale lembrar que nem sempre devemos olhar somente para o número de casos de teste que o defeito impacta, mas também analisar a severidade e prioridade do mesmo. Segue abaixo um exemplo:

Figura 2 – Gráfico de Defeitos Encontrados

4. Lista de Requisição de Mudanças
A seção lista de requisição de mudanças deve conter os defeitos encontrados com o ID do defeito, descrição, status, severidade, data de abertura, data de fechamento e duração (em dias).

• ID do Defeito: identificador do defeito;
• Descrição: descrição do defeito (deve ser uma descrição resumida);
• Status: status do defeito (pode ser aberto, fechado, análise, assinalado, etc.);
• Severidade: severidade do defeito;
• Data de Abertura: data da abertura do defeito;
• Data de Fechamento: data do fechamento do defeito;
• Duração: quantidade de dias que o defeito levou para chegar ao status fechado;

Ao verificar essa seção, o usuário deve ser capaz de identificar quais são os defeitos que ainda continuam abertos e qual a sua gravidade, pois dessa maneira, o Gerente de Projeto ou o próprio time de desenvolvimento poderá dar prioridade para os defeitos que tem maior severidade e impactam no resultado final da execução. Segue abaixo um exemplo:

Tabela 2 – Defeitos Encontrados

5. Riscos
A seção Riscos deve conter os riscos identificados na fase de execução ou até mesmo os que estão em fases anteriores e, que de alguma forma, impactam o progresso de execução. Ao verificar essa seção, o usuário deve ser capaz de encontrar os riscos levantados até o momento de forma resumida, com uma descrição do risco e seu possível impacto não sendo necessário listar todos os dados dos riscos encontrados na fase de identificação dos riscos do produto. Segue abaixo um exemplo completo de como reportar um risco e, neste caso, fica a critério de cada Projeto e Equipe de Teste reportar os campos necessários:

Como faço para documentar os riscos?
Para documentar e fazer o acompanhamento dos riscos é necessário ter uma Matriz de Análise de Riscos. Nessa matriz temos alguns campos, por exemplo:

• ID do Risco: campo utilizado para identificar o risco;
• ID do Requisito: campo utilizado para identificar qual requisito está associado com o risco, se aplicável;
• Projeto: campo utilizado para identificar o projeto associado ao risco;
• Item de Risco: campo utilizado para documentar qual é o item de risco;
• Status: campo utilizado para saber qual é o status do risco, por exemplo, aberto, fechado ou parado;
• Impacto: campo utilizado para saber qual é o impacto do risco, por exemplo, alto, médio ou baixo;
• Plano de Mitigação e Contingência: campo utilizado para documentar o plano de mitigação e contingência;
• Pessoa Responsável: campo utilizado para identificar a pessoa responsável para ajudar, acompanhar ou resolver o risco;
• Acompanhamento / Comentários: campo utilizado para documentar o acompanhamento e comentários em geral;
• Data de Abertura: campo utilizado para indicar a data de abertura do risco;
• Data de Fechamento: campo utilizado para indicar a data de fechamento do risco;
• Duração (dias): campo utilizado para indicar a quantidade de dias que o risco ficou aberto.

6. Contatos
A seção Contatos deve conter informações dos participantes do projeto de teste, principalmente na fase de execução. Será por meio desta seção que o usuário deverá ser capaz de encontrar as pessoas em caso de dúvidas com os resultados reportados ou ter acesso a qualquer outra informação. Segue abaixo um exemplo:

Líder de Teste:

• Email:
• Telefone:

Analista de Teste:

• Email:
• Telefone:

Testador:

• Email:
• Telefone:

Para finalizar, segue o modelo do relatório:

Relatório Parcial de Execução de Teste - Exemplo

Veja mais apresentações de Gustavo Quezada.

Agora, se na sua empresa não tem um modelo de relatório parcial de execução de teste, você poderá conversar com o seu gerente imediato e propor o exemplo mostrado neste post ;-).

Caso ele não goste da idéia, não vai falar que viu isso no meu blog, hein?!?!?! :-D

Para obter mais detalhes sobre execução e relatório de teste, basta acessar o post Relatório e Execução de Teste.

Até+,
Quezada

CheckList de Transição de Fases – Análise, Design e Execução de Teste

Uma boa prática que ajuda a minimizar os problemas de rotatividade das equipes e transição de atividades é a utilização de um Check List para cada fase. O objetivo deste post é compartilhar um checklist que ajude a garantir que todos os trabalhos realizados na fase de análise, design e execução de teste foram concluídos e passar o conhecimento adquirido nessas fases para os Engenheiros, Analistas de Teste que serão envolvidos na próxima fase de teste.

1. Transição da fase de análise para design

Projeto: Nome do Projeto e/ou Componente
Data: Data quando a reunião de transição aconteceu
Participantes da Reunião de Transição:
Incluir o nome dos participantes da reunião de transição – Nome 1
Incluir o nome dos participantes da reunião de transição – Nome 2

2. Transição da fase de design para execução
Projeto: Nome do Projeto e/ou Componente
Data: Data quando a reunião de transição aconteceu
Participantes da Reunião de Transição:
Incluir o nome dos participantes da reunião de transição – Nome 1
Incluir o nome dos participantes da reunião de transição – Nome 2

Como vocês podem ver, é uma maneira fácil e rápida de garantir que todos os trabalhos realizados na fase de análise, design e execução de teste foram concluídos e que o conhecimento adquirido nessas fases foi compartilhado com as partes interessadas na próxima fase de teste.

Até+,
Quezada

Dança das Cadeiras ou Samba do Crioulo Doido? Será que isso acontece na sua empresa ou projeto(s)?

Você deve estar fazendo a seguinte questão “O que ele quer dizer com Dança das Cadeiras ou Samba do Crioulo Doido?”. Confesso que fiquei pensando nisso alguns dias, e como não consegui identificar se a rotatividade das pessoas nas empresas e projetos é a Dança das Cadeiras, ou se é o Samba do Crioulo Doido, acabei colocando essa questão para você decidir. Bem, como esse assunto é muito amplo e poderíamos ficar aqui horas e horas discutindo e expondo as nossas idéias, vou tentar focar em projetos de teste de software.

A rotatividade das pessoas em projetos de teste de software é um fato. Essa nova era em que vivemos, "Era do Conhecimento", umas das características do profissional, é a mobilidade em busca de melhores oportunidades.
Segundo estudos do DIEESE – Departamento Intersindical de Estatística e Estudos Socioeconômicos (publicados em 2007), no ano de 2006 a taxa mensal de rotatividade no Brasil era de 3,5% ao mês, que representa um índice anual de 42%. Em 2002, este índice era de 35% ao ano, ou seja, em cinco anos a rotatividade aumentou 20%, o que significa que em aproximadamente 2,5 anos, as empresas trocam seus quadros de funcionários.

Muitas vezes as pessoas perguntam “Como resolver esse problema?”. O que eu sempre tento mostrar é que não se consegue resolver 100% do problema, mas é possível minimizá-lo fazendo um bom planejamento e gerenciamento de riscos. Vamos lá, quem aqui nunca teve esse tipo de problema em projetos que teve participação? Se você falar que isso não acontece na sua empresa me avisa que vou mandar o meu CV pra você :-). Pensando bem, acho que não vou fazer isso não, afinal, resolver os problemas dos projetos que é o legal e se fosse fácil, qualquer um faria !!!
No momento em que estamos planejando os projetos é necessário levar em consideração o perfil dos profissionais que poderão contribuir para que o projeto seja executado com sucesso. Se você fizer um planejamento sem considerar esse item, provavelmente terá problema com a rotatividade de pessoas, pois precisará fazer a “dança das cadeiras” entre os projetos para atender o perfil que já devia ter sido pensado na hora do planejamento, isso sem considerar as pessoas que acabam saindo da empresa ou mudando de área. Sabemos também que em alguns casos não temos um profissional na empresa que tenha o perfil que o projeto está demandando, então, neste caso, temos o risco identificado e é necessário criar um plano de ação para mitigar o risco.

Vale lembrar que mesmo com todo o planejamento feito, as técnicas selecionadas, o recurso e pessoas alocadas, os riscos identificados e, as partes interessadas comprometidas, sempre terão possíveis riscos de projeto com rotatividade da equipe. Neste caso, tudo o que você puder fazer para documentar o que está sendo feito no projeto de teste, faça. Só tome cuidado para não burocratizar o seu dia-a-dia.

Vou tentar mostrar um exemplo clássico que acontece em projetos de testes:
Vamos supor que temos um Gerente de Teste ou Projeto, um Líder/Arquiteto de Teste, um Analista de Teste e vários Testadores.

Fase de Planejamento
Gerente de Teste: Ah, vamos alocar o Líder/Arquiteto X, o Analista Y e os Testadores A, B e C nesse projeto que vai dar tudo certo.

Líder/Arquiteto de Teste X: Olha seu Gerente, para esse projeto precisamos de alguém que tenha conhecimento em testes de aplicação web e o Analista Y e os Testadores A, B e C não tem esse conhecimento, teríamos que treiná-los.

Gerente de Teste: Não temos como fazer isso, os outros Analistas e Testadores que tem esse conhecimento não poderão participar do projeto e tenho certeza que você conseguirá resolver possíveis problemas técnicos que poderemos ter.

Nesse momento o Líder/Arquiteto de Teste pensa “Vai dar M@#$%ERDA” isso ai... :-(

Fase de Análise de Teste
Analista de Teste Y identifica todos os casos de teste que devem ser feitos de acordo com os requisitos do sistema e executa todas as outras tarefas que pertencem a essa fase.

Pausa para o café, reunião!
Na reunião de acompanhamento do projeto o Gerente de Teste comunica para sua equipe que aconteceu um problema no Projeto W e o Analista de Teste Y terá que mudar de projeto, e o Analista Z irá substituí-lo.
Agora acontece o problema de transição e compartilhamento do conhecimento do Analista Y para o Analista Z, afinal, quem sabe e entende do sistema é o Analista Y.

Fase de Design de Teste
Analista Z faz todo o design dos casos de testes identificados na fase de Análise e executa todas as outras tarefas que pertencem a essa fase. Bem, tudo pronto para começar a execução dos testes.

Fase de Execução de Teste
Testadores A, B e C começam a execução sem ter uma visão geral de como funciona o sistema, e ai as dúvidas começam a surgir. Um problema atrás do outro, teste executado incorretamente, etc.

Bem, esse é um exemplo resumido e simplista de como as coisas acabam acontecendo quando fazemos um planejamento sem considerar o perfil do profissional.

Uma boa prática que ajuda a minimizar os problemas de rotatividade das equipes e transição de atividades é utilizar um Check List para cada fase. A idéia desse check list é passar o conhecimento adquirido em cada fase para os profissionais envolvidos no projeto.

No post CheckList de Transição de Fases – Análise, Design e Execução de Teste coloquei um exemplo de check list para a transição entre as fases de Análise, Design e Execução de Teste.

Agora me diz, na sua empresa acontece a dança das cadeiras ou samba do crioulo doido? Ou melhor, será que a dança das cadeiras acaba criando o samba do crioulo doido?

Até+,
Quezada

Papéis e Responsabilidades do Time de Teste

Muitos já estão “carecas” de saber quais são os papéis e responsabilidades do time de teste, mas vale a pena relembrar, afinal, pode ser que no projeto que você esteja trabalhando as coisas estejam um pouco confusas! :-)

Gerente de Teste

Pessoa responsável pelo êxito do esforço de teste. Seu papel envolve a defesa da qualidade e dos testes, planejamento e gerenciamento de recursos, pessoas e resolução de problemas que representam um obstáculo para o esforço de teste. Isso inclui:

• Gerenciamento funcional e operacional da equipe de testes;
• Planejamento e alocação de recursos e pessoas para novos projetos e produtos;
• Definição da política de testes de software e acompanhamento a sua execução;
• Participação em reuniões de projeto e acompanhamento;
• Defender o nível apropriado de qualidade mediante a correção de defeitos importantes;
• Avaliação do andamento e a eficácia do esforço de teste;
• Acompanhamento de falhas em campo para refinar os processos de testes;
• Geração de indicadores de desempenho de teste.

Líder de Testes

Pessoa responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção.

Arquiteto de Teste
É o técnico responsável pelo levantamento de necessidades relacionadas à montagem da infra-estrutura de teste, incluindo-se o ambiente de teste, a arquitetura de solução, as restrições tecnológicas, as ferramentas de teste. Também responsável pela liderança técnica do trabalho de teste e pela comunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).

Analista de Teste
É o técnico responsável pela operacionalização do processo de teste. Deve seguir as orientações do gerente de teste e/ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de teste necessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada.

Analista de Ambiente de Teste
É o técnico responsável pela configuração do ambiente de teste e pela aplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução, nos sistemas operacionais e softwares de infra-estrutura que regem o ambiente. Ele será responsável por tornar disponível o ambiente de teste.

Testador
É o técnico responsável pela execução de teste. Ele deve observar as condições e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuções de teste mal-sucedidas, esse profissional pode também registrar ocorrências (na maioria das vezes, defeitos), em canais através dos quais os desenvolvedores tomarão conhecimento e providências de correção ou esclarecimentos das mesmas.

Automatizador de Teste
É o técnico responsável pela automação de situações de teste em ferramentas. Ele deve observar as condições de teste e respectivos passos documentados pelo analista de teste e automatizar a execução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitem a execução de ciclos de teste sempre que julgar necessário, desde que é claro, sejam garantidas as mesmas condições iniciais do ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc.).

Papéis e Pessoas
Uma pessoa pode acumular mais de um dos papéis citados acima, de acordo com características e restrições de projetos de desenvolvimento de software, nas quais estejam inseridas.

Vale lembrar que os papéis e responsabilidades citados acima não é uma regra! :-)

Até+,
Quezada

Perguntas e Respostas - Parte 3

E para “finalizar” a primeira série de Perguntas e Respostas, vamos tentar esclarecer a pergunta 3 e 4.

3) Ter um especialista em Qualidade de Software significa que o desenvolvedor não precisa desenvolver um projeto com tanta atenção ou cuidado?

Ter um time de teste de software trabalhando em conjunto com o time de desenvolvimento, não significa que os desenvolvedores não precisam ter atenção ou cuidado na hora de desenvolver o produto ou software, muito pelo contrário, o desenvolvedor deve ter sempre muita atenção no seu trabalho, afinal, o sucesso do projeto depende muito da sua contribuição. O desenvolvedor tem de pensar que existe um time de teste que está focado para garantir a qualidade do produto, e não desenvolver um produto com qualidade. A maior responsabilidade de construir um produto com qualidade é do time de desenvolvimento.

Bem, falar para o desenvolvedor ter atenção e cuidado é fácil, difícil é fazer. Já fui desenvolvedor um dia e sei como isso funciona. O mais importante é o desenvolvedor ter em mente o seguinte: quanto mais cuidado e atenção ele tiver na hora que estiver desenvolvendo um produto, menos defeito será introduzido, e com isso, menos retrabalho ele terá.

4) Em um projeto relativamente pequeno, é necessário o teste?

Se você deseja garantir a qualidade do seu projeto, seja ele, pequeno, médio ou grande, não terá alternativa a não ser TESTÁ-LO!!!

Se você não quer ter a imagem da sua empresa prejudicada junto ao cliente, então garanta a qualidade do produto que está sendo entregue, mesmo sendo um projeto pequeno e simples.

Vale lembrar que a quantidade e tipos de teste irão variar de acordo com o tamanho, complexidade e características do seu projeto.

Espero que tenham gostado! :-D

Até+,
Quezada

Perguntas e Respostas - Parte 2

Como prometido, vamos tentar esclarecer a pergunta 2.

2) Quando o teste de software é aplicado? Existe um momento exato ou acontece durante todo o processo de desenvolvimento? Como funcionam os testes de software? Quais são as etapas?

A experiência tem mostrado que bons resultados não são alcançados quando o próprio desenvolvedor realiza os testes, uma vez que é muito difícil fazer com que esses profissionais atuem ao mesmo tempo como desenvolvedores e testadores.

No conceito “V” de teste, os procedimentos de fazer e conferir convergem do início até o fim do projeto. O time de desenvolvimento trabalha com o objetivo de implementar o sistema, já o time de teste executa procedimentos de teste visando minimizar e eliminar riscos e defeitos do sistema. Com isso, o alto nível de riscos que caracteriza os projetos de desenvolvimento de software irá decrescer a um patamar aceitável que permita a conclusão bem-sucedida.
Os benefícios advindos da adoção do modelo em “V” são claros: detecção precoce de defeitos, maior envolvimento do time de testes no início do projeto e aumento da qualidade do software.

O ciclo de vida do teste faz parte do ciclo de vida do software e eles devem ser iniciados ao mesmo tempo. O processo de design e desenvolvimento de testes pode ser tão complexo quanto o processo de desenvolvimento do software em si. Se os testes não forem iniciados juntamente com os primeiros releases executáveis do software, o esforço de teste retardará a descoberta de muitos problemas no ciclo de desenvolvimento. Em geral, isso resulta em um longo período de correção de erros após a programação de desenvolvimento, acabando com as metas e as vantagens do desenvolvimento iterativo.

Além da possibilidade de retrabalho já mencionada, a equipe de teste precisa ter cuidado para manter seu papel como consultora de qualidade imparcial e não se desviar das atividades de design e dos requisitos iniciais, atuando como "guardiã da qualidade".
Os problemas localizados durante uma iteração podem ser solucionados ou adiados para a próxima — uma decisão que fica, em última instância, a critério do Gerente de Teste. Uma das principais tarefas da equipe de teste e dos gerentes de projeto consiste em medir a abrangência da iteração, verificando se os objetivos de cada iteração foram alcançados. A "detecção de requisitos" é realizada continuamente a cada iteração, e você precisa estar atento e preparado para gerenciá-la.

Após cada iteração ou fase é necessário re-planejar as atividades seguintes, caso necessário. Em alguns casos, os projetos podem ter somente a fase de execução de teste após a fase de planejamento de teste.

Para todas as fases de testes temos critérios de entrada e saída e muitas vezes, os critérios de saída de uma fase, são os critérios de entrada da fase seguinte.

• Estimativa de Teste
• ==> Estimativa de teste inicial;
• ==> Confirmação da nova funcionalidade no cronograma de teste;
• Análise de Teste
• Design de Teste
• Execução de Teste

Para entender um pouco como funcionam os critérios de entrada e saída das fases, segue um exemplo abaixo:

Fase de Estimativa de Teste:

• Critérios de Entrada:
• ==> Email do time de desenvolvimento requisitando uma nova estimativa de teste;
• ==> Documentos de requisitos disponíveis.
• Critérios de Saída:
• ==> Documento de estimativa criado e atualizado com os valores estimados;
• ==> Cronograma de Teste atualizado.

Fase de Análise de Teste:

• Critérios de Entrada:
• ==> Documento de estimativa criado e atualizado com os valores estimados;
• ==> Email de alocação de análise e design de teste;
• ==> Documentos de requisitos disponíveis.
• Critérios de Saída:
• ==> Documento com o cabeçalho dos casos de teste que serão criados;
• ==> Plano de Teste atualizado;
• ==> Cronograma de Teste atualizado (se aplicável);
• ==> Matriz de Rastreabilidade de Requisitos (opcional).

Fase de Design de Teste:

• Critérios de Entrada:
• ==> Documento com o cabeçalho dos casos de teste que serão criados;
• ==> Email de alocação de análise e design de teste;
• ==> Documentos de requisitos disponíveis;
• ==> Plano de Teste atualizado;
• ==> Cronograma de teste atualizado (se aplicável);
• ==> Matriz de Rastreabilidade de Requisitos (opcional).
• Critérios de Saída:
• ==> Casos de Teste criados, revisados e atualizados;
• ==> Email para o Gerente de Testes requisitando o fechamento da atividade;
• ==> Plano de Teste atualizado;
• ==> Cronograma de teste atualizado (se aplicável);
• ==> Matriz de Rastreabilidade de Requisitos (opcional).

Fase de Execução de Teste:

• Critérios de Entrada:
• ==> Email do time de teste requisitando uma nova execução de teste;
• ==> Plano de Teste atualizado;
• ==> Ciclo de execução de teste criado;
• ==> Email de notificação do novo release para teste;
• ==> Documento de requisitos disponíveis;
• ==> Gráfico Curva-S com o planejamento da execução (planejado x executado).
• Critérios de Saída:
• ==> Ciclo atualizado;
• ==> Gráfico Curva-S com o planejamento da execução (planejado x executado);
• ==> Relatório de execução de teste parcial (se aplicável);
• ==> Relatório de execução de teste final (se aplicável);
• ==> Plano de teste atualizado.

Então, gostaram? Espero que tenha esclarecido algumas dúvidas que geralmente surgem nos projeto.

No próximo post irei responder as seguintes questões:

3) Ter um especialista em Qualidade de Software significa que o desenvolvedor não precisa desenvolver um projeto com tanta atenção ou cuidado?

4) Em um projeto relativamente pequeno, é necessário o teste?

Até+,
Quezada

Perguntas e Respostas - Parte 1

Você deve estar perguntando... “Perguntas e Respostas?”... Eu achei que esse Quezada era maluco, mas agora está comprovado... Tanto nome melhor para colocar no título do post e ele coloca Perguntas e Respostas... :-P

Vamos parar de besteira e falar, ou melhor, escrever o que interessa. Vou escrever 3 novos post’s no formato de perguntas e respostas e a idéia e tentar responder algumas perguntas que ficam no “ar”. Para este primeiro post vou falar um pouco sobre as minhas atividades, que com certeza irão ajudar outras pessoas, e sobre as vantagens do teste e qualidade de software para a empresa e para o cliente. Então, vamos lá...

1) Como é o seu trabalho como Gerente de Teste de Software na AsGa Sistemas? Quais as vantagens do teste de qualidade de software para a empresa e para o cliente?

Muitas pessoas acham que o trabalho de um Gerente de Teste de Software está relacionado somente com as tarefas de teste de um projeto. Será que isso é verdade nos dias de hoje? Isso realmente era verdade há alguns anos atrás. Hoje em dia, um Gerente de Teste de Software deve cuidar não somente das tarefas ou atividades de teste de um projeto, ele deve ser uma das pessoas responsáveis pelo sucesso de um projeto, colaborando em todas as fases do projeto focando na qualidade do mesmo.

As principais atividades que estão sob a minha responsabilidade são:

• Gerenciamento funcional e operacional da equipe de testes;
• Planejamento e alocação de recursos e pessoas para novos projetos e produtos;
• Elaboração de Proposta Técnica e Comercial para projetos de teste de software;
• Definição da política de testes de software e acompanhamento a sua execução;
• Participação em reuniões de projeto e acompanhamento;
• Criação e atualização das metodologias, modelos, framework e processos de teste;
• Avaliação do andamento e a eficácia do esforço de teste;
• Supervisão da criação dos planos e casos de testes;
• Responsável pela especificação da política e processo de teste em propostas técnicas para operadoras de Telecom (TIM, Oi, Claro, Vivo, Etc.), incluindo especificação de ambiente de teste;
• Acompanhamento da correção dos erros encontrados;
• Acompanhamento de falhas em campo para refinar os processos de testes;
• Geração de indicadores de desempenho de teste;
• Geração de indicadores de desempenho junto à área de operações.

Eu sempre digo que o dia-a-dia de trabalho das pessoas em uma empresa vai depender de como é o ambiente de trabalho desta empresa, podendo ser muito agradável e prazeroso, ou um tédio. Se o ambiente que você trabalha não é agradável, existe muita competição entre as áreas ou até mesmo dentro da sua própria área, conflito de interesses, etc., pode ter certeza que o seu desafio será muito maior. Trabalhar na AsGa Sistemas é muito prazeroso e agradável. Os profissionais que lá trabalham são extremamente comprometidos, estão sempre dispostos a ajudar com os desafios técnicos, propondo soluções simples, eficazes e eficientes, sempre pensando no que é melhor para o projeto e empresa. Os times de desenvolvimento e teste estão sempre se comunicando e focando nos objetivos e metas dos projetos.

A principal vantagem do teste de software para a empresa é a garantia da qualidade dos produtos, afinal, não basta ter um produto no mercado, é necessário ter um produto com qualidade, o que torna-o confiável e muito mais competitivo. Além disso, quando mais tarde o defeito for encontrado, mais caro ele será, o que resulta na famosa curva "Regra 10 Myers". Com isso, ambos (empresa e cliente) saem ganhando, pois o custo do projeto acaba sendo menor. A AsGa Sistemas está totalmente comprometida com a qualidade de seus produtos, e é por isso que temos um time de teste independente do time de desenvolvimento. Temos dois times principais em cada projeto, um focado no desenvolvimento dos produtos (time de desenvolvimento), e outro focado na qualidade (time de teste). Já a principal vantagem do teste de software para o cliente, é ter a garantia que o seu produto estará funcionando corretamente 24 horas x 7 dias. Além das vantagens citadas, vale a pena citar alguns produtos do processo de teste que agregam valor para a empresa:

• Qualidade do processo;
• Aumento da qualidade do produto;
• Diminuição do retrabalho;
• Maior produtividade;
• Redução do tempo para atender o mercado;
• Maior competitividade;
• Maior precisão nas estimativas;
• Acompanhamento da satisfação do cliente;
• Promover a melhoria contínua da qualidade de produtoFormalização dos processos de teste.

A formalização dos processos de testes apresenta maiores ganhos nas seguintes situações:

• Quanto mais inexperiente for a equipe;
• Quanto mais complexo for o ambiente;
• Quanto mais profissionais estejam envolvidos;
• Quanto mais projetos simultâneos ocorrerem;
• Quanto mais sua organização deseja crescer.

Essa primeira questão foi uma introdução para as próximas.

No próximo post irei responder a seguinte questão:

2) Quando o teste de software é aplicado? Existe um momento exato ou acontece durante todo o processo de desenvolvimento? Como funcionam os testes de software? Quais são as etapas?

Até+,
Quezada

O mundo pertence aqueles que pensam em novos caminhos

Há algumas semanas atrás, estávamos fazendo uma reunião de projeto e o Gerente do Projeto fez um comentário que 100% dos participantes (time de desenvolvimento e teste) ficaram sem entender nada no primeiro momento. Sabe qual foi o comentário? Foi o seguinte: “Bem, agora que o time de desenvolvimento concluiu o desenvolvimento e a execução dos testes unitários do release, e disponibilizarão o mesmo para o time de teste iniciar a execução dos testes, vou pegar a minha CADEIRA DE RODAS para andar pelo sistema!”. Nossa! Essa frase deixou um ponto de interrogação (?) na “testa” de cada pessoa que estava participando da reunião. Ninguém entendeu nada.

Creio que o pessoal que trabalha na área de teste e qualidade de software tenha entendido, não? Você entendeu? Está com dúvida? Vamos assistir ao vídeo abaixo para ter certeza que você entendeu.

E ai, entendeu? Não, vamos lá então...

Vamos utilizar a Arquitetura Inclusiva para “traduzir” este vídeo para a área de teste e qualidade de software.

A falta de acessibilidade é a principal barreira enfrentada por pessoas que convivem com algum tipo de deficiência nas grandes cidades brasileiras. E a inclusão desta importante parcela da população – 24,6 milhões de pessoas em todo o país, segundo o Instituto Brasileiro de Geografia e Estatística (IBGE), é um desafio cada vez maior para arquitetos, engenheiros e responsáveis pela definição e implantação de políticas públicas que permitam aos que têm mobilidade reduzida se locomoverem com autonomia e independência.

Essa falta de “acessibilidade” é totalmente aplicada a nossa área de teste e qualidade de software. Na maioria das vezes os desenvolvedores de software não pensam nas possíveis falhas que podem ocorrer nos sistemas que estão desenvolvendo. Quantas vezes você já fez a pergunta “E se eu fizer isso ou aquilo, o que vai acontecer?” e o time de desenvolvimento respondeu “Xiiiii, isso eu não sei o que vai acontecer não. Não tem requisito pra isso”. Ou aquela velha frase que já conhecemos quando reportamos uma falha quando não existe um requisito específico associado a ela “Isso não é uma falha, é Work as Design” :-P !

Tudo isso é para incentivar os desenvolvedores de software a passearem de “cadeira de rodas” pelo sistema antes de disponibilizar um release para o time de teste, afinal, muitas vezes existem falhas que basta você acessar a segunda tela do sistema que elas aparecem.

Só lembrando que não estou criticando os desenvolvedores de software, que fique bem claro isso! Eu já fui desenvolvedor de software e ainda hoje gosto de brincar de ser desenvolvedor.

O mundo pertence aqueles que pensam em novos caminhos!!! Fica ai a dica!

Até+,

Quezada

Estimativa de Teste utilizando uma Matriz de Teste por Tipo de Funcionalidade

Um assunto que está sendo muito discutido na nossa área de teste atualmente é Estimativa de Esforço de Teste. Essa fase do projeto de teste é muito importante e devemos dar atenção especial para ela, afinal, a estimativa deve ser a mais confiável possível. Devemos tomar muito cuidado com o que é, ou foi estimado, pois a maioria dos Gerentes de Projeto quer que você assine essa estimativa com “sangue” e com certeza irão lembrar-se de você caso o valor realizado seja totalmente diferente do estimado, ou seja, o valor planejado deve ser o mais próximo possível do valor realizado.

O que geralmente acontece é o seguinte: Um analista de teste precisa analisar e estimar os casos de testes que serão desenvolvidos para testar um software. Na maioria das vezes as estimativas não usam qualquer técnica, não são comuns em toda organização e, o que é pior, elas não garantem que a cobertura de testes está validando todos os requisitos.

O objetivo deste artigo é mostrar uma maneira fácil, simples e eficaz de estimar o esforço de teste utilizando uma Matriz de Teste por Tipo de Funcionalidade e o que é mais importante, documentar o “estimado”.

Para que a estimativa de esforço e custo de teste seja feita da maneira mais cuidadosa possível, deve-se levar em consideração algumas atividades para isso, como por exemplo:

• Determinar e manter as estimativas dos produtos de trabalho e tarefas de teste;
• Estudar os fatores que possam influenciar a estimativa;
• Selecionar modelos e/ou dados históricos que servirão para transformar os produtos de trabalho e tarefas de teste em estimativas de esforço e custo;
• Incluir as necessidades de infra-estrutura;
• Documentar os riscos resultantes da análise dos documentos;
• Documentar os dados da estimativa, incluindo as informações necessárias para a reutilização em novas estimativas.

Um “modelo” muito utilizado nas empresas para realizar as estimativas é a intuição e julgamento de um especialista baseados na experiência em planejar e testar sistemas semelhantes. Dessa forma, a precisão da estimativa depende da experiência, competência, objetividade e percepção de quem realiza a estimativa.

Os produtos de trabalhos gerados na fase de estimativa são os critérios de entrada para a fase de planejamento onde é verificado o esforço e custo do projeto incluindo a disponibilidade de recurso, infra-estrutura, negociação com o time de desenvolvimento, etc. Para facilitar essa interação entre a fase de estimativa e planejamento devemos documentar tudo o que foi analisado e estimado. Abaixo seguem alguns itens que podem ser documentados na estimativa de esforço:

• Documentos usados para estimar: Nome e versão dos documentos utilizados durante a estimativa;
• Data: Data quando a estimativa foi completada;
• Data da Requisição: Data quando a estimativa foi solicitada;
• Responsável: Pessoa que fez a estimativa, podendo haver mais de uma pessoa responsável;
• Esforço Atual da Estimativa: Esforço gasto na estimativa;
• Complexidade: Indica se a funcionalidade tem uma complexidade baixa, média ou alta para testar. Considerar quantidade de suporte de teste requerido, riscos e desafios;
• Razão para complexidade: indicar o porquê a funcionalidade foi marcada com a dada complexidade;
• Análise de Teste
• => Requisitos Funcionais: Número de requisitos funcionais aplicáveis;
• => Requisitos de Interface: Número de requisitos de interface aplicáveis;
• => Casos de Teste: Número de Casos de Teste estimado;
• => Premissas: Premissas identificadas para fase de design;
• => Esforço Calculado: Esforço de análise calculado baseado no número de casos de teste estimado;
• => Esforço Calculado para Revisão: Esforço da revisão dos casos de teste sugeridos na fase de análise.
• Design de Teste
• => Casos de Teste: Número de Novos Casos de Teste;
• => Casos de Teste Reutilizados: Número de Casos de Teste Reutilizados (nenhum esforço de design requerido);
• => Premissas: Premissas identificadas para fase de execução;
• => Esforço Calculado: Esforço de design calculado baseado no número de casos de teste a serem criados;
• => Esforço Calculado para Revisão: Esforço da revisão dos casos de teste criados na fase de design.
• Execução de Teste
• => Casos de Teste: Número de Casos de Teste que serão executados para a funcionalidade incluindo testes de regressão;
• => Total de Casos de Teste: Número Total de Casos de Teste que serão executados incluindo a porcentagem de casos de testes falhados e bloqueados para todos os ciclos de execução;
• => Premissas: Premissas identificadas para fase de execução. Podendo conter também indicações sobre casos de teste adicionais de regressão ou reuso, porcentagem de defeitos encontrados, porcentagem de re-execução de casos de teste passados;
• => Esforço Calculado: Esforço de execução calculado baseado no número de casos de teste a serem executados.
• Otimista: Valor otimista da estimativa gerada;
• Mais provável: Valor mais provável da estimativa gerada;
• Pessimista: Valor pessimista da estimativa gerada.

Para ajudar a calcular o valor otimista, mais provável e pessimista, pode-se usar a simulação de Monte Carlo. Uma boa prática para ajudar o trabalho de estimativa de teste é utilizar um mapa da mente, por exemplo, usar o software Free Mind.

Bem, agora que já vimos uma maneira fácil e simples de documentar tudo o que foi estimado, chegou o momento de verificar o que é essa tal Matriz de Teste por Tipo de Funcionalidade. Será que essa matriz é um bicho de 7 cabeças? Claro que não, é uma das coisas mais simples que já desenvolvi e que ajudam muito na hora de fazer uma estimativa de teste.

Quem aqui já precisou fazer uma estimativa para um novo projeto e teve aquela leve impressão de já ter feito uma estimativa anterior para uma mesma funcionalidade que está prevista para o novo projeto? Aquela funcionalidade de leitura de arquivo TXT ou XLS, validação de campos de formulários, realizar operações em Banco de Dados, etc.

Se você já passou por isso, com certeza chegou a hora de criar uma Matriz de Teste por Tipo de Funcionalidade para você nunca mais ficar perdendo tempo na hora de estimar e deixar de identificar casos de teste já identificados anteriormente em projetos anteriores. Essa matriz é uma base de conhecimento onde documentamos todos os testes/cenários necessários para testar um determinado tipo de funcionalidade. Neste momento, você deve estar pensando “Esse cara é maluco, é só isso mesmo?”. A resposta é mais simples ainda... quer dizer, me deixa pensar um pouco... continuo pensando... Ah, já sei... SIM, é só isso mesmo :-) . Segue abaixo um exemplo de uma Matriz de Teste por Tipo de Funcionalidade.

No nosso exemplo usaremos os seguintes campos na nossa Matriz:

• Telas / Funcionalidade
• Testes - Características
• Testes – Sub-características
• Categorias do TesteTipo de Teste

Para ajudar a analisar a matriz, é uma boa prática criar um gráfico, pois assim ficará fácil identificar a quantidade de testes para cada funcionalidade. Abaixo temos a consolidação dos dados (utilizei a Pivot Table do Microsoft Excel para gerar a tabela de dados) e o gráfico gerado para este exemplo.

Depois de ter a primeira versão da Matriz criada é só ir adicionando, modificando os testes/cenários por funcionalidade. Simples assim !!! ;-) Agora você sempre terá uma base de dados histórica de testes por funcionalidade e com certeza não se esquecerá de estimar um determinado teste que já foi desenvolvido em projetos anteriores.

Bem, então, caso o gerente do projeto de teste que você trabalha chegasse para você e pedisse uma nova estimativa de esforço de teste para um novo projeto, qual seria o seu primeiro passo? Pensando... pensando... pensando... cri... cri... cri... cri.. nossa quantos grilos... isso mesmo, analisar a Matriz de Teste por Tipo de Funcionalidade para saber se já existe uma funcionalidade que foi testada anteriormente em outro projeto e que será desenvolvida ou alterada no novo projeto!

Espero que tenham gostado!

Até+,

Quezada