Em junho do ano passado eu postei um texto sobre o Teste no ciclo de vida de software. Quando a gente começa a estudar testes e procura amadurecer um pouco a idéia, esse é o primeiro questionamento que vem: Onde se encaixam os testes? Parece meio intuitivo que testar só ao final do projeto demanda muito esforço e gera muitos problemas.
Recebi um email da STP com um artigo do Rich Hand,um dos diretores da STP, sobre o mesmo assunto. Examining the software development lifecycle. Recomendo a leitura e a reflexão proposta no fim. "Onde o teste se encaixa no ciclo de desenvolvimento de software na sua empresa?"
quarta-feira, 3 de fevereiro de 2010
segunda-feira, 1 de fevereiro de 2010
CInTEQ 2010
Nos dias 22 e 23 de Março / 2010 vai acontecer o CInTEQ, um congresso internacional sobre Teste e Qualidade de Software, no Caesar Business Faria Lima, em SP.
O evento vai contar com a participação de grandes nomes como Rex Black, Erik Van Veenendaal, Alessandro Collino e Dorothy Graham.
Fora as palestras, também haverão mini cursos de TMMi, Test Automation, CTAL, Agile Testing e IREB.
Mais informações: http://www.cinteq.org.br/
O evento vai contar com a participação de grandes nomes como Rex Black, Erik Van Veenendaal, Alessandro Collino e Dorothy Graham.
Fora as palestras, também haverão mini cursos de TMMi, Test Automation, CTAL, Agile Testing e IREB.
Mais informações: http://www.cinteq.org.br/
segunda-feira, 25 de janeiro de 2010
Mesa Redonda do DFTestes
Serviço de utilidade pública (ao menos para os profissionais de teste :) )
Se você ainda não assina a lista de discussão do grupo DFTestes, não sabe o que anda perdendo.
No dia 02 de novembro, por inciativa do Fabrício Campos, teve início no DFTestes uma série de discussões muito proveitosas sobre teste de software.
Durante uma semana inteira os participantes discutem os temas selecionados por eles mesmos em uma votação prévia. Ao final, o Fabrício faz um apanhado de tudo o que foi comentado e gera um post no blog dele com um resumo da mesa redonda.
Nas discussões tivemos o prazer de ver bons nomes que estavam com pouca participação no grupo reaparecerem e contribuirem muito com o conteúdo discutido no grupo, como José Correia, Jorge Diz e Anderson Bastos. Essa iniciativa esquentou mesmo o grupo e vale muito a pena conferir, não só quem está aprendendo, iniciando na área de testes, mas também quem já tem uma boa bagagem.
Seguem alguns resumos feitos pelo Fabrício do que rolou até agora e o link para inscrição no DFTestes. Se você tem dúvidas ou gostaria que algum assunto em especial, sugira um tema para discussão.
Post inicial: Primeira Mesa Redonda DFTestes
Mesas:
Inscreva-se no grupo através do site do Yahoo ou mandando uma mensagem em branco para DFTestes-subscribe@yahoogrupos.com.br. E seja bem vindo ;)
Se você ainda não assina a lista de discussão do grupo DFTestes, não sabe o que anda perdendo.
No dia 02 de novembro, por inciativa do Fabrício Campos, teve início no DFTestes uma série de discussões muito proveitosas sobre teste de software.
Durante uma semana inteira os participantes discutem os temas selecionados por eles mesmos em uma votação prévia. Ao final, o Fabrício faz um apanhado de tudo o que foi comentado e gera um post no blog dele com um resumo da mesa redonda.
Nas discussões tivemos o prazer de ver bons nomes que estavam com pouca participação no grupo reaparecerem e contribuirem muito com o conteúdo discutido no grupo, como José Correia, Jorge Diz e Anderson Bastos. Essa iniciativa esquentou mesmo o grupo e vale muito a pena conferir, não só quem está aprendendo, iniciando na área de testes, mas também quem já tem uma boa bagagem.
Seguem alguns resumos feitos pelo Fabrício do que rolou até agora e o link para inscrição no DFTestes. Se você tem dúvidas ou gostaria que algum assunto em especial, sugira um tema para discussão.
Post inicial: Primeira Mesa Redonda DFTestes
Mesas:
- Testar é tão fácil, que até a minha mãe testaria!
- Teste Ágil, como implementar?
- Estimativa de Testes (APT)
- Certificações, valem a pena?
- MPT: Melhoria do Processo de Testes
- Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)
- Quando documentar não é preciso?
- O Testador também necessita saber programar?
- Testar sem documentação é possível?
Inscreva-se no grupo através do site do Yahoo ou mandando uma mensagem em branco para DFTestes-subscribe@yahoogrupos.com.br. E seja bem vindo ;)
domingo, 20 de dezembro de 2009
Overview tipos de técnicas de testes
A figura abaixo mostra a taxonomia utilizada para estudo da CTAL.
A primeira distinção é entre teste estático e teste dinâmico. Testes estáticos compreendem os testes que não envolvem a execução de testes (rodar) e os testes dinâmicos são aqueles relacionados à execução dos testes.
Testes estáticos são as revisões e a análise estática. As revisões são realizadas por pessoas e análise estática é realizada através de ferramentas.
Testes dinâmicos são 5:
Caixa preta: é o teste baseado em especificações (ou comportamentos). O teste é realizado em cima da idéia de como o sistema deveria se comportar. Esses testes são divididos ainda em funcionais e não funcionais, seguindo a norma ISO 9126. Uma maneira de distingui-los é que os testes funcionais dizem o que o sistema deve fazer e os não funcionais dizem como.
Caixa branca: também chamados de testes estruturais. São realizados emcima de como o programa foi construido.
Baseado em experiência: baseado nas habilidades, intuições e experiências anteriores do testador.
Análise dinâmica: análise da aplicação enquanto ela está rodando através de ferramentas.
Baseado em defeitos: utilização do entendimento de defeitos como base para o projeto de testes.
Ao contrário do que pode sugerir a figura, esses testes não são exclusivos. É possível (e comum) utilizar mais de uma dessas técnicas. É necessário selecionar que tipos de teste se aplicam na sua estratégia e em que nível eles serão aplicados.
Os ATA e ATTA que aparecem nessa figura referem-se à especilidade do ISTQB em que a técnica é coberta. Os ATA são cobertos na prova de analista e os ATTA na prova de analista tecnico. Essa abordagem não necessariamente é a aplicada na sua empresa, é apenas uma divisão para estudos.
Nos próximos posts cobrirei algumas das técnicas desses tipos de teste.
Fonte: Advanced Software Testing Vol 1. - Rex Black
Ver também:
Partição por Equivalência
Análise por Valor Limite
A primeira distinção é entre teste estático e teste dinâmico. Testes estáticos compreendem os testes que não envolvem a execução de testes (rodar) e os testes dinâmicos são aqueles relacionados à execução dos testes.
Testes estáticos são as revisões e a análise estática. As revisões são realizadas por pessoas e análise estática é realizada através de ferramentas.
Testes dinâmicos são 5:
Caixa preta: é o teste baseado em especificações (ou comportamentos). O teste é realizado em cima da idéia de como o sistema deveria se comportar. Esses testes são divididos ainda em funcionais e não funcionais, seguindo a norma ISO 9126. Uma maneira de distingui-los é que os testes funcionais dizem o que o sistema deve fazer e os não funcionais dizem como.
Caixa branca: também chamados de testes estruturais. São realizados emcima de como o programa foi construido.
Baseado em experiência: baseado nas habilidades, intuições e experiências anteriores do testador.
Análise dinâmica: análise da aplicação enquanto ela está rodando através de ferramentas.
Baseado em defeitos: utilização do entendimento de defeitos como base para o projeto de testes.
Ao contrário do que pode sugerir a figura, esses testes não são exclusivos. É possível (e comum) utilizar mais de uma dessas técnicas. É necessário selecionar que tipos de teste se aplicam na sua estratégia e em que nível eles serão aplicados.
Os ATA e ATTA que aparecem nessa figura referem-se à especilidade do ISTQB em que a técnica é coberta. Os ATA são cobertos na prova de analista e os ATTA na prova de analista tecnico. Essa abordagem não necessariamente é a aplicada na sua empresa, é apenas uma divisão para estudos.
Nos próximos posts cobrirei algumas das técnicas desses tipos de teste.
Fonte: Advanced Software Testing Vol 1. - Rex Black
Ver também:
Partição por Equivalência
Análise por Valor Limite
A profissionalização do teste
(Artigo escrito para o GUTS-RS, publicado pela SUCESU-RS)
Quando o teste de software despontou, era apenas uma parte da Engenharia de Software. Após o UP (Unified Process), a disciplina começou a ter mais força e alcançar um lugar próprio na TI. Ainda hoje o conhecimento sólido dessa disciplina é restrito a poucos profissionais, e muitas vezes é tida como uma disciplina que não requer muito conhecimento técnico, ou que qualquer profissional sem um bom respaldo acadêmico e/ou treinamento adequado pode executar com maestria.
Poucas faculdades incluem no seu currículo uma disciplina dedicada a Teste de Software. Normalmente, quando é abordada, não compreende mais do que algumas aulas da disciplina de Engenharia de Software.
Esse cenário aos poucos vem mudando. Com a crescente demanda do mercado por profissionais que desejam seguir essa carreira, algumas faculdades têm incluído a disciplina no seu currículo e também têm surgido cursos de pós graduação na área. Essas iniciativas dão a base acadêmica que o profissional deveria ter para descobrir, ganhar interesse e ingressar na área. Até então, esse papel estava sendo desempenhado apenas por cursos de extensão/capacitação.
Antes mesmo dessas iniciativas acadêmicas, assim como em outras áreas de TI, surgiu a necessidade de criar uma maneira de atestar o conhecimento do profissional em Teste de Software. Começaram a surgir então as certificações. Todas elas com o objetivo de criar uma linguagem única e um guia de boas práticas a ser seguido pelos profissionais.
Algumas das instituições internacionais mais conhecidas que aplicam certificações em Teste de Software são ISTQB (2002) / BSTQB (2006), ISEB (~1980), QAI (1980), IIST (1966).
No Brasil, essa iniciativa veio por parte da ALATS (2002) que criou a CBTS (Certificação Brasileira de Teste de Software) após analisar as certificações internacionais e criar o seu próprio padrão.
Cada instituição possui a sua própria base de conhecimento para a aplicação desses exames. Em relação a processos, são bastante similares, mas podem gerar dúvidas quanto a algumas terminologias que nem sempre representam a mesma coisa.
Além das certificações, iniciativas de grupos de profissionais estão se tornando cada vez mais populares no Brasil. Há vários grandes grupos de discussão na web e grupos que promovem encontros com palestras.
Com o apoio da SUCESU-RS foi criado o Grupo de Usuários de Teste de Software do Rio Grande do Sul, integrando o time de GUs da instituição. Hoje o grupo conta com 213 usuários e encontros constantes que promovem o networking na área e a disseminação de conhecimento.
Esse tipo de iniciativa agrega bastante, ajundando a difundir a área e aprimorando o conhecimento dos profissionais de Teste de Software e de outras áreas que interagem com eles.
Há várias empresas no Brasil que valorizam o profissional de Teste de Software e entendem o seu papel no ciclo de desenvolvimento, mas ainda é muito pouco. A grande maioria ainda não entende o papel do profissional de teste, não tem um processo de contratação adequado para esses profissionais e até mesmo se negam a contratar um profissional especializado devido ao seu valor, para contratar pessoas sem experiência, sem treinamento, sem preparo algum.
Teste de Software é uma área que vem crescendo mediante essas iniciativas acadêmicas e profissionais, entretanto ainda é uma área que sofre preconceito, muitas vezes é tida como uma área que não demanda conhecimento técnico e que inclusive empresas que buscam profissionais de Teste de Software, não sabem exatamente o que estão buscando. O profissional de teste, na verdade, é um agente de mudanças, trabalhando na prevenção de defeitos e colaborando para a melhoria contínua das equipes e processos.
Essa é uma realidade que vem sendo transformada aos poucos e que conta com a sede de conhecimento de cada um para crescer ainda mais e firmar o seu lugar no ciclo de desenvolvimento de software.
Fontes:
Associação Latino-Americana de Testes
Brazilian Software Testing Qualification Board
International Software Testing Qualifications Board
Quality Assurance Institute Brasil
Information Systems Examination Board
International Institute for Software Testing
Quando o teste de software despontou, era apenas uma parte da Engenharia de Software. Após o UP (Unified Process), a disciplina começou a ter mais força e alcançar um lugar próprio na TI. Ainda hoje o conhecimento sólido dessa disciplina é restrito a poucos profissionais, e muitas vezes é tida como uma disciplina que não requer muito conhecimento técnico, ou que qualquer profissional sem um bom respaldo acadêmico e/ou treinamento adequado pode executar com maestria.
Poucas faculdades incluem no seu currículo uma disciplina dedicada a Teste de Software. Normalmente, quando é abordada, não compreende mais do que algumas aulas da disciplina de Engenharia de Software.
Esse cenário aos poucos vem mudando. Com a crescente demanda do mercado por profissionais que desejam seguir essa carreira, algumas faculdades têm incluído a disciplina no seu currículo e também têm surgido cursos de pós graduação na área. Essas iniciativas dão a base acadêmica que o profissional deveria ter para descobrir, ganhar interesse e ingressar na área. Até então, esse papel estava sendo desempenhado apenas por cursos de extensão/capacitação.
Antes mesmo dessas iniciativas acadêmicas, assim como em outras áreas de TI, surgiu a necessidade de criar uma maneira de atestar o conhecimento do profissional em Teste de Software. Começaram a surgir então as certificações. Todas elas com o objetivo de criar uma linguagem única e um guia de boas práticas a ser seguido pelos profissionais.
Algumas das instituições internacionais mais conhecidas que aplicam certificações em Teste de Software são ISTQB (2002) / BSTQB (2006), ISEB (~1980), QAI (1980), IIST (1966).
No Brasil, essa iniciativa veio por parte da ALATS (2002) que criou a CBTS (Certificação Brasileira de Teste de Software) após analisar as certificações internacionais e criar o seu próprio padrão.
Cada instituição possui a sua própria base de conhecimento para a aplicação desses exames. Em relação a processos, são bastante similares, mas podem gerar dúvidas quanto a algumas terminologias que nem sempre representam a mesma coisa.
Além das certificações, iniciativas de grupos de profissionais estão se tornando cada vez mais populares no Brasil. Há vários grandes grupos de discussão na web e grupos que promovem encontros com palestras.
Com o apoio da SUCESU-RS foi criado o Grupo de Usuários de Teste de Software do Rio Grande do Sul, integrando o time de GUs da instituição. Hoje o grupo conta com 213 usuários e encontros constantes que promovem o networking na área e a disseminação de conhecimento.
Esse tipo de iniciativa agrega bastante, ajundando a difundir a área e aprimorando o conhecimento dos profissionais de Teste de Software e de outras áreas que interagem com eles.
Há várias empresas no Brasil que valorizam o profissional de Teste de Software e entendem o seu papel no ciclo de desenvolvimento, mas ainda é muito pouco. A grande maioria ainda não entende o papel do profissional de teste, não tem um processo de contratação adequado para esses profissionais e até mesmo se negam a contratar um profissional especializado devido ao seu valor, para contratar pessoas sem experiência, sem treinamento, sem preparo algum.
Teste de Software é uma área que vem crescendo mediante essas iniciativas acadêmicas e profissionais, entretanto ainda é uma área que sofre preconceito, muitas vezes é tida como uma área que não demanda conhecimento técnico e que inclusive empresas que buscam profissionais de Teste de Software, não sabem exatamente o que estão buscando. O profissional de teste, na verdade, é um agente de mudanças, trabalhando na prevenção de defeitos e colaborando para a melhoria contínua das equipes e processos.
Essa é uma realidade que vem sendo transformada aos poucos e que conta com a sede de conhecimento de cada um para crescer ainda mais e firmar o seu lugar no ciclo de desenvolvimento de software.
Fontes:
Associação Latino-Americana de Testes
Brazilian Software Testing Qualification Board
International Software Testing Qualifications Board
Quality Assurance Institute Brasil
Information Systems Examination Board
International Institute for Software Testing
segunda-feira, 30 de novembro de 2009
Gerenciamento de riscos
As principais atividades do gerenciamento de riscos são:
Identificação – identificar (ou as vezes imaginar) quais são/serão os riscos de projeto e de qualidade
Analise – classifica-los dentro de um nível, normalmente caracterizado por uma relação de impacto e probabilidade
Controle – abrange o conjunto de atividade de mitigação, contingência, transferência e aceitação de riscos
Um pouco mais de cada uma...:
IDENTIFICAÇÃO DE RISCOS
Como identificar riscos? Algumas sugestões:
-Entrevista com especialistas (na tecnologia e no negócio – pessoas diferentes, provavelmente)
-Checklists
-Analisar projetos similares já realizados
-Workshops, brainstorms
Pode ser interessante manter separadamente os riscos de projeto e os riscos de qualidade já que as pessoas que detém o conhecimento para elencá-los podem ser diferentes. O levantamento, entretanto pode ocorrer simultaneamente.
É possível detectar riscos estudando a documentação do projeto, nessa prática, essa revisão pode ajudar a encontrar erros na documentação.
As reuniões de identificação podem parar na detecção dos riscos, ou na própria reunião pode ser possível classificá-los ou mesmo detectar seu impacto. O acúmulo de atividades na reunião depende do andamento e produtividade dela.
ANÁLISE/AVALIAÇÃO DE RISCOS
Depois de identificá-los, deve ser feito um estudo emcima de cada risco categorizando-os e atribuindo-les um nível.
Sobre atribuir um nível, já foi mencionado que isso pode ser feito através da relação de impacto e probabilidade. Mas como definir isso? Probabilidade está normalmente relacionada a fatores técnicos e Impacto a fatores de negócio.
Exemplos de fatores técnicos:
-Complexidade da tecnologia
-Conhecimento do time
-Incompatibilidade de tecnologia legada com a aplicada
-Falta de quality assurance
-Ausência de testes em fases iniciais
E vários outros
Exemplos de fatores de negócio:
-Frequencia/Sazonalidade de uso de uma funcionalidade
-Possibilidade de sanções criminais
-Potenciais perdas de lucros
Entre outros
Pode-se atribuir o nível de risco quantitativamente ou qualitativamente. Quantitativamente pode-se considerar a probabilidade como um percentual e o impacto como um valor financeiro e assim teríamos exatamente o que representa o risco em números.
O mais comum é vermos essa atribuição qualitativamente, isso porque é difícil ter a base estatística necessária para pontuar quantitativamente. Qualitativamente os endereçaríamos como riscos de nível alto, médio ou baixo.
Sobre categoria, pode-se usar por exemplo as características descritas na ISO9126 (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade e suas sub caracteristicas). E pra que serve isso? No geral, para determinar os responsáveis (ou áreas responsáveis) pelos grupos de riscos. Isso, claro, se houver um motivo prático para categoriza-los.
MITIGAÇÃO/CONTROLE DE RISCOS
Os riscos podem ser controlados através das atividades de:
-Mitigação
-Contingência
-Transferência
-Aceitação
A mitigação consiste na definição de atividades que possam diminiur o impacto ou a probabilidade de um risco ocorrer.
A contigência é utilizada como uma ação caso o risco venha a ocorrer (quando um risco acontece, deixa de ser um risco, passa a ser um fato ou issue).
A tranferência consiste em transferir para outra parte o risco. E não interpretar isso como um jogo de culpas entre times. Nesse processo, no caso de uma empresa prestando serviço para um cliente, o risco pode ser assumido pelo cliente ao invés da empresa ou vice-versa, entre outras situações.
A abordagem analítica de teste baseado em riscos foca na criação de ações de mitigação, especialmente de riscos de qualidade, para o time de teste. O teste mitiga os riscos de qualidade durante todo o ciclo de desenvolvimento.
Alguns riscos de projeto também podem ser controlados, como:
Preparação adequada de ambiente de teste e ferramentas
Baixa qualidade de inputs para o teste
Falta de padrões, regras e tecnicas para o teste
Apesar de ser papel do gerente de controlar esses riscos, são riscos que afetam os analistas e estes devem controlá-los também.
Testes preventivos são parte da estratégica de testes baseados em riscos. A idéia é mitigar os riscos de qualidade antes mesmo da execução dos testes preparando bem o ambiente de testes, fazendo um pre teste antes de começar formalmente uma fase de testes, participando em reuniões e revisão/inspeção, monitorando o progresso e a qualidade do projeto, etc.
Oportunidades de aplicação de testes preventivos:
-Escolher a tecnica de testes adequada
-Realizar revisões e inspeções
-Revisar os projetos de teste
-Definir estratégias de testes de confirmação e regressão
Perceba que as atividades do teste preventivo não são as que comumente lembramos quando falamos de teste. Se os requisitos parecem não estar bem definidos, então o ideal é realizar revisões e inspeções, ao invés de postergar essas correções para a fase de testes.
Existem duas formas de priorizar os testes: depth-first ou breadth-first.
Depth-first: Todos os testes dos riscos mais altos são rodados primeiros e os riscos mais baixos por último.
Breadth-first: São selecionadas amostragens em todos os níveis de riscos, usando esses níveis para ponderar as seleções (são selecionados mais testes de níveis de risco mais alto, que de nivel mais baixo).
A melhor cobertura depende de uma análise do seu projeto.
E a famosa pergunta: quando parar de testar? Nessa abordagem a resposta é; Quando o risco residual for considerado aceitável.
Supondo que não tenhamos mais tempo para testar ou que o tempo foi reduzido e não será possível cumprir o planejamento inicial. Como realinhar a estratégia? Repriorizando os testes de acordo com os resultados obtidos. Mas exatamente o que olhar nesses resultados?
-Novos riscos de produtos
-Áreas muito modificadas
-Áreas instaveis descobertas durante os testes
-Riscos associados a defeitos
-Descoberta de bug clusters inesperados
-Descoberta de áreas críticas de negócio
Aproveite para atualizar o seu planejamento de riscos inicial.
Identificação – identificar (ou as vezes imaginar) quais são/serão os riscos de projeto e de qualidade
Analise – classifica-los dentro de um nível, normalmente caracterizado por uma relação de impacto e probabilidade
Controle – abrange o conjunto de atividade de mitigação, contingência, transferência e aceitação de riscos
Um pouco mais de cada uma...:
IDENTIFICAÇÃO DE RISCOS
Como identificar riscos? Algumas sugestões:
-Entrevista com especialistas (na tecnologia e no negócio – pessoas diferentes, provavelmente)
-Checklists
-Analisar projetos similares já realizados
-Workshops, brainstorms
Pode ser interessante manter separadamente os riscos de projeto e os riscos de qualidade já que as pessoas que detém o conhecimento para elencá-los podem ser diferentes. O levantamento, entretanto pode ocorrer simultaneamente.
É possível detectar riscos estudando a documentação do projeto, nessa prática, essa revisão pode ajudar a encontrar erros na documentação.
As reuniões de identificação podem parar na detecção dos riscos, ou na própria reunião pode ser possível classificá-los ou mesmo detectar seu impacto. O acúmulo de atividades na reunião depende do andamento e produtividade dela.
ANÁLISE/AVALIAÇÃO DE RISCOS
Depois de identificá-los, deve ser feito um estudo emcima de cada risco categorizando-os e atribuindo-les um nível.
Sobre atribuir um nível, já foi mencionado que isso pode ser feito através da relação de impacto e probabilidade. Mas como definir isso? Probabilidade está normalmente relacionada a fatores técnicos e Impacto a fatores de negócio.
Exemplos de fatores técnicos:
-Complexidade da tecnologia
-Conhecimento do time
-Incompatibilidade de tecnologia legada com a aplicada
-Falta de quality assurance
-Ausência de testes em fases iniciais
E vários outros
Exemplos de fatores de negócio:
-Frequencia/Sazonalidade de uso de uma funcionalidade
-Possibilidade de sanções criminais
-Potenciais perdas de lucros
Entre outros
Pode-se atribuir o nível de risco quantitativamente ou qualitativamente. Quantitativamente pode-se considerar a probabilidade como um percentual e o impacto como um valor financeiro e assim teríamos exatamente o que representa o risco em números.
O mais comum é vermos essa atribuição qualitativamente, isso porque é difícil ter a base estatística necessária para pontuar quantitativamente. Qualitativamente os endereçaríamos como riscos de nível alto, médio ou baixo.
Sobre categoria, pode-se usar por exemplo as características descritas na ISO9126 (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade e suas sub caracteristicas). E pra que serve isso? No geral, para determinar os responsáveis (ou áreas responsáveis) pelos grupos de riscos. Isso, claro, se houver um motivo prático para categoriza-los.
MITIGAÇÃO/CONTROLE DE RISCOS
Os riscos podem ser controlados através das atividades de:
-Mitigação
-Contingência
-Transferência
-Aceitação
A mitigação consiste na definição de atividades que possam diminiur o impacto ou a probabilidade de um risco ocorrer.
A contigência é utilizada como uma ação caso o risco venha a ocorrer (quando um risco acontece, deixa de ser um risco, passa a ser um fato ou issue).
A tranferência consiste em transferir para outra parte o risco. E não interpretar isso como um jogo de culpas entre times. Nesse processo, no caso de uma empresa prestando serviço para um cliente, o risco pode ser assumido pelo cliente ao invés da empresa ou vice-versa, entre outras situações.
A abordagem analítica de teste baseado em riscos foca na criação de ações de mitigação, especialmente de riscos de qualidade, para o time de teste. O teste mitiga os riscos de qualidade durante todo o ciclo de desenvolvimento.
Alguns riscos de projeto também podem ser controlados, como:
Preparação adequada de ambiente de teste e ferramentas
Baixa qualidade de inputs para o teste
Falta de padrões, regras e tecnicas para o teste
Apesar de ser papel do gerente de controlar esses riscos, são riscos que afetam os analistas e estes devem controlá-los também.
Testes preventivos são parte da estratégica de testes baseados em riscos. A idéia é mitigar os riscos de qualidade antes mesmo da execução dos testes preparando bem o ambiente de testes, fazendo um pre teste antes de começar formalmente uma fase de testes, participando em reuniões e revisão/inspeção, monitorando o progresso e a qualidade do projeto, etc.
Oportunidades de aplicação de testes preventivos:
-Escolher a tecnica de testes adequada
-Realizar revisões e inspeções
-Revisar os projetos de teste
-Definir estratégias de testes de confirmação e regressão
Perceba que as atividades do teste preventivo não são as que comumente lembramos quando falamos de teste. Se os requisitos parecem não estar bem definidos, então o ideal é realizar revisões e inspeções, ao invés de postergar essas correções para a fase de testes.
Existem duas formas de priorizar os testes: depth-first ou breadth-first.
Depth-first: Todos os testes dos riscos mais altos são rodados primeiros e os riscos mais baixos por último.
Breadth-first: São selecionadas amostragens em todos os níveis de riscos, usando esses níveis para ponderar as seleções (são selecionados mais testes de níveis de risco mais alto, que de nivel mais baixo).
A melhor cobertura depende de uma análise do seu projeto.
E a famosa pergunta: quando parar de testar? Nessa abordagem a resposta é; Quando o risco residual for considerado aceitável.
Supondo que não tenhamos mais tempo para testar ou que o tempo foi reduzido e não será possível cumprir o planejamento inicial. Como realinhar a estratégia? Repriorizando os testes de acordo com os resultados obtidos. Mas exatamente o que olhar nesses resultados?
-Novos riscos de produtos
-Áreas muito modificadas
-Áreas instaveis descobertas durante os testes
-Riscos associados a defeitos
-Descoberta de bug clusters inesperados
-Descoberta de áreas críticas de negócio
Aproveite para atualizar o seu planejamento de riscos inicial.
quinta-feira, 19 de novembro de 2009
IV EBTS
Já está aberto o prazo de submissão de artigos para o IV Encontro Brasileiro de Testes de Software em Recife/PE
Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.
Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.
O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.
O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.
Mais informações através do site http://www.gotest.biz/ebts2010/
Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.
Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.
O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.
O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.
Mais informações através do site http://www.gotest.biz/ebts2010/
Assinar:
Postagens (Atom)