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

Usando Rede Bayesiana e Critério de Adequação para Obter uma Melhor Cobertura de Teste de Requisitos – 2º. BRATESTE - ALATS

Em teste de software, quando um engenheiro de testes precisa estimar o número de casos de testes para um desenvolvimento de software, geralmente os documentos utilizados como entradas para essa fase de testes são os requisitos de clientes, requisitos de software seja funcional ou de interface visual, casos de uso, diagramas UML quando disponíveis ou qualquer outro documento no qual tenha informações necessárias sobre o software que será desenvolvido. Após analisar todos os documentos citados, o engenheiro de testes estima o número de casos de testes que serão desenvolvidos juntamente com o cabeçalho de cada teste. Feito isso, algumas perguntas começam a ser feitas para o engenheiro que fez a estimativa: “A estimativa está cobrindo todos os requisitos?”, “Qual é a confiabilidade dessa estimativa?”, “Não está faltando nenhum requisito que não foi criado?”. Usando uma rede Bayesiana, o engenheiro de testes conseguirá modelar a arquitetura de testes que será desenvolvido, podendo fazer uma ponderação estatística de cenários e riscos. Agregando valor a rede Bayesiana, o critério de adequação é usado para aumentar a cobertura de testes e requisitos. Cada requisito de software é analisado e é verificado se ele se aplica aos critérios pré-definidos. Com o uso da rede Bayesiana e critério de adequação, conseguimos ter uma representação gráfica dos requisitos, podendo fazer simulações dos cenários de casos de testes seguindo uma sequência lôgica, inclusive, teremos uma matriz de requisitos versus casos de testes, que contém todos os cenários de casos de testes obtidos na rede Bayesiana aplicando o critério de adequação.

A apresentação abaixo neste post irá mostrar como essa técnica pode facilmente ser introduzida nas atividades diárias de um engenheiro de testes, identificando novos requisitos de software ou cenários que não foram considerados na fase de requisitos inicial, minimizando assim o problema de falta de requisitos ou requisitos dúbios e garantindo que sua estimativa é a mais confiável possível.

Essa técnica foi apresentada no 2º. BRATESTE – ALATS, São Paulo no dia 12/Março/2009 - http://www.alats.org.br/default.aspx?tabid=209

Usando Rede Bayesiana e Critério de Adequação para Obter uma Melhor Cobertura de Teste de Requisitos

Veja mais apresentações de Gustavo Quezada.

Espero que gostem!

Até+,
Quezada

O Incentivo para começar o Blog

Sempre pensei em compartilhar o conhecimento adquirido com outras pessoas e agora chegou a hora :-)!!!

Depois de muito acompanhar alguns blogs que falam sobre Teste e Qualidade de Software, resolvi criar este blog para poder compartilhar as experiências profissionais nesta área também. Confesso que as principais pessoas que acabaram me incentivando a criar este blog foram:

• Sem Bugs - Teste e Qualidade de Software – Elias Nogueira
• José Papo Weblog – José Papo
• Diário da Qualidade – Leonardo Molinari
• QualidadeBR – Fabrício Ferrari de Campos
• TESTAVO – Luiz Gustavo S. Vieira
• TextExpert – Cristiano Caetano

Então, fica aqui o meu MUITO OBIGADO por este incentivo, mesmo sem vocês saberem ;-)

É, Pessoal, agora vocês terão mais um integrante para ajudar no “compartilhamento” de informações para a nossa área de Teste e Qualidade de Software!!!

Até+,

Quezada