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