Oportunidade de Emprego - Recife(PE)

A Ogilvy está ofereceno uma oportunidade para participar de uma seleção para Analista de Qualidade. Veja abaixo mais detalhes desta vaga.

Cargo: Analista de Qualidade (QA) - Projetos

Contratação: Bolsista

Atividades:

- Efetuar testes (validação e verificação) para a garantia da qualidade em projetos digitais;

 

Formação:

- Curso concluído na área de Tecnologia da Informação.

 

Perfil:

- Organização na disponibilização de resultados

- Noções básicas de estética e diagramação

- Domínio da língua portuguesa

- Perfil investigador, atencioso, detalhista e perfeccionista

- Gostar de trabalhar em equipe

- Gostar de atividades dinâmicas

- Interesse em aprender

- Disponibilidade para trabalhar de segunda a sexta-feira com carga horária de 08h diárias;

- Preferencialmente residir em Pernambuco.

Desejável:

- Certificação CTFL

- Experiência em testes de software

- Experiência em tecnologias WEB

Os interessados devem enviar o currículo com pretensão salarial até o dia 16/10/2013 para roberta_albuquerque@outlook.com, sob o título "QA Projetos"

Read More

Oportunidade de Emprego - Fortaleza (CE)

O GREat é composto por professores, pesquisadores colaboradores e estudantes de pós-graduação e graduação da Universidade Federal do Ceará (UFC) e de outras Instituições de Ensino Superior (IES). O grupo desenvolve projetos de pesquisa e desenvolvimento em parceria com outras instituições de ensino e empresas nas áreas de Redes de Computadores, Engenharia de Software e Sistemas. O grupo possui uma ótima estrutura, tanto física como humana, propiciando um ótimo local de trabalho e pesquisa, oferecendo possibilidades de aperfeiçoamento profissional e acadêmico.

O GREat está oferecendo uma oportunidade para Analista de Testes Júnior (Qualidade) 

Horário de Trabalho: Segunda a Sexta 08 horas diárias

Principais Atividades: 
- Análise do plano de testes 
- Criação de planos de testes 
- Criação de casos de testes 

Benefícios: 
Salário: R$ 2.500,00 
Vale alimentação Mensal Sodexo no valor de R$280,00 e plano de saúde UNIMED. 

Conhecimentos Técnicos Exigidos: 
• Graduação Completa em Computação ou áreas afins 
• Conhecimento da Linguagem Java Conhecimentos 

Técnicos Desejados: 
• Metodologia de testes; 
• Execução dos testes; 
• Testes unitários, testes de sistema e de aceitação do usuário; 
• Relatório de acompanhamento de teste; 
• Conhecimento em ferramentas de automação de testes; 
• Metodologias Ágeis (SCRUM) 

Habilidades: 
Atenção a detalhes, Espírito de Equipe, Organização, Boa Comunicação e Interesse em Pesquisa. 

*Os interessados deverão encaminhar currículo anexo atualizado e histórico acadêmico, até 1 de Outubro de 2013 para o email recrutamento@great.ufc.br.

Read More

Oportunidade de Estágio - João Pessoa (PB)

O Núcleo de Tecnologia da Informação – NTI da UFPB, abre 01 (uma) vaga para estágio não-obrigatório para alunos matriculados e com frequência regular nos cursos de Tecnologia da Informação.

A vaga será distribuída da seguinte forma:

• 01 (uma) vaga na área Testes de Software
  
  

Dos Requisitos

• Matriculado a partir do 3º período;
• CRE maior ou igual a 7,0 (sete);
• Disponibilidade no turno da manhã;
• Apenas alunos do IFPB e da UFPB podem participar do processo;
• Proatividade;
• Apenas para os candidatos postulantes a uma vaga na área de

Conhecimentos Desejados

• Conhecimento em Teste de Software.
• Conhecimento em UML.
• Conhecimento em Engenharia de Software.
• Conhecimento em Banco de dados SQL.

Das Características do Estágio

• 20 horas semanais;
• Possibilidade de estágio de no máximo dois anos;
• Previsão de início: 07/10/2013
• Bolsa de R$ 496,00

Das Atribuições Gerais

Área Testes de Software: O testador deverá revisar a especificação do sistema, elaborar roteiros de teste, executar testes manuais de sistema e descrever relatórios de erros.

Da Inscrição

Preencher formulário de inscrição disponível em http://www.nti.ufpb.br/~raphael/selecao durante o período de 06/09/2013 a 27/09/2013;

Da Seleção

O processo seletivo ocorrerá no dia 02/10/2013 em duas etapas:

1. Prova de conhecimentos básicos na área escolhida pelo candidato a ser realizado.

2. Entrevista e análise de Histórico Escolar realizado após a prova.

A cada candidato será atribuída uma nota obtida pela média aritmética da prova e da entrevista. Por fim, os candidatos serão classificados em ordem decrescente de nota.

O candidato deve trazer seu histórico escolar impresso no dia da seleção.

Observação:

Esclarecimentos e informações adicionais devem ser enviadas para raphael@nti.ufpb.br.

Read More

Oportunidade de Emprego - Campina Grande (PB)

Visando atender a alta demanda de soluções inteligentes em Tecnologia da Informação e Comunicação e fazendo uso do alto potencial intelectual formado em Campina Grande, que hoje é internacionalmente reconhecida por formar profissionais com qualidade, a CAMPINATEC oferece soluções para inserção das empresas em um universo onde a tecnologia é que faz a diferença.

CampinaTec abre oportunidades para Analista de Teste Pleno. Veja abaixo mais detalhes para a oportunidade em questão.

Analista de Teste Pleno

Experiência mínima de 3 anos em testes de software.

• Experiência em testes de software.
• Experiência em arquitetura de testes para aplicações Web.
• Experiência na elaboração de planos e casos de teste (integração, sistema, funcional, etc...)
• Experiência em elaboração de sumário de avaliação de teste;
• Experiência em técnicas de desenho de casos de teste
• Experiência como analista de teste nas ferramentas como Bugzilla, Mantis, Seleninum, etc...
• Experiência como analista em ferramentas de gerenciamento (exemplo: Quality Center,Testmanager, Testlink, etc)
• Definição e utilização de processos de teste de software;
• Automação de teste;

Desejáveis:

• Git
• Conhecimento da liguagem Java
• Certificação em teste de software (CBTS, CTFL – ISTQB);

Interessados enviem currículo para rh@campinatec.com.br

Read More

Oportunidade de Emprego - Recife(PE)

A Pitang é a Fábrica de Software do C.E.S.A.R., oferecendo serviços de desenvolvimento e manutenção de sistemas, consultoria, fábrica de software e de testes, migração de legados e outsourcing. Foi fundada em Abril de 2005, como fruto do spin-off da área de projetos comerciais do C.E.S.A.R., um dos principais institutos de inovação do país.

A Pintang está com um processo de seleção para preenchimento do seu quadro funcional. Abaixo segue mais informações para o cargo de Engenheiro de Testes /Pl.

• Quantidade de vagas: 4 vagas
• Localização: Recife
• Requisitos necessários:
  • Curso Superior em Ciência da Computação, Engenharia ou Áreas Afins;
  • Experiência profissional em projetos de testes, plano, implementação e execução de testes manuais e automatizados;
  • Experiência na utilização de ferramentas de teste de sistemas e controle de versão de software;
  • Experiência com ferramentas para gestão de defeitos (por exemplo: Jira, Bugzilla, Mantis);
  • Conhecimento de ferramentas e frameworks de testes, tais como: JUnit, JMeter, Selenium e/ou Testlink
• Requisitos desejáveis:
  • Experiência em projetos de automação de testes;
  • Ser produtivo, auto-gerenciável e possuir facilidade de trabalhar em equipe e sob pressão;
  • ISTQB Certified Tester Foundation Level (CTFL) ou similar;
  • Experiência no planejamento e estratégia de teste;
  • Inglês intermediário.
• Principais responsabilidades:
  • Projetar, implementar e executar testes de stress e carga;
  • Executar os testes de software de acordo com o processo e procedimentos adotados pela organização;
  • Elaborar casos de testes, observando as pré-condições, passos e resultados esperados, de acordo com os requisitos especificados;
  • Reportar problemas encontrados durante a execução dos testes, de modo claro e objetivo, gerando dados relevantes para futuras análises;
  • Elaborar relatórios de execução de testes;
  • Sugerir melhorias nos processos de teste, a fim de colaborar com o desenvolvimento contínuo dos processos e da qualidade dos produtos.
• Os interessados devem cadastrar-se no Banco de Currículos da Pitang e enviar confirmação do cadastro paraoportunidades@pitang.com com o título da vaga.

Read More

Oportunidade de Emprego - Recife(PE)

SELEÇÃO ANALISTA DE TESTES

 

 

Convênio inovador entre o CIn-UFPE e a Motorola - A Google Company - para testes de software em dispositivos móveis.

 

 

 

 

Requisitos Obrigatórios

• Formação em Computação ou áreas afins
• Inglês intermediário
• Capacidade de investigação
• Pro-atividade
• Trabalho em equipe
• Comprometimento
• Disponibilidade para viajar

Requisitos Desejáveis

Experiência em teste de software
ISTQB Foundation Level (CTFL)
IREB Certified Professional for Requirements Engineering - Foundation Level (CPRE FL)
CAT - Certified Agile Tester


• Conhecimento em metodologias ágeis
Experiência com ferramentas para gestão de defeitos (por exemplo: Jira, Bugzilla, Mantis)
Experiência com desenvolvimento de software
Conhecimento no sistema operacional Linux

 

Características do Cargo

• Regime de 8 horas diárias
• Vínculo CLT: Remuneração + Ótimos Benefícios

Local de trabalho: Campus UFPE - Recife-PE

Caso atenda aos requisitos obrigatórios acima e esteja disposto a fazer parte de um time vencedor, por favor preencha o formulário no site: 

http://goo.gl/9SL4A OU https://sites.google.com/a/cin.ufpe.br/motorola-mobility-partnership/test-engineer

Read More

Proporção de testadores em relação ao número de desenvolvedores de um projeto: Melhores práticas e a realidade Brasileira

Estimar a quantidade de testadores de um projeto é uma tarefa árdua e imprecisa. Frequentemente esta estimativa é realizada com base no número de desenvolvedores. No entanto, diversos especialistas na área de testes de software alertam que nem sempre é possível estimar a proporção de testadores em relação aos desenvolvedores em virtude de que existem muitos fatores externos que podem afetar e influenciar o resultado final.

Para Michael Eason [1], a relação entre os testadores e os desenvolvedores de um projeto pode ser estimada com base na seguinte generalização (testador:desenvolvedor):

• 1:3: Quando o processo é bastante maduro e os requisitos são detalhados e consistentes;
• 1:1: Quando o processo é imaturo, ou não existe processo e os requisitos são ambíguos, inconsistentes e desatualizados.

Kathy Iberle [2] defende que a proporção entre testadores e desenvolvedores não pode ser definida linearmente. Para ela, a quantidade de testadores em relação aos desenvolvedores de um projeto deve ser estimada com base no histórico dos projetos anteriores da organização e num modelo (proposto por ela) onde essa relação é calibrada em função de fatores ambientais (complexidade do projeto, nível de experiência dos desenvolvedores ou testadores, entre outros). Dentre os principais fatores descritos por Iberle, podemos destacar:

• A experiência dos testadores e desenvolvedores;
• A freqüência em que o desenvolvedor insere defeitos na aplicação (e a severidade desses defeitos);
• A eficiência do desenvolvedor em detectar e resolver defeitos antes de liberar a aplicação para a execução dos testes;
• A eficiência do testador em detectar defeitos;
• Entre outros.

Johanna Rothman [3], no seu artigo “It Depends: Deciding on the Correct Ratio of Developers to Testers”, corrobora a visão de Iberle. Para ela, não existe uma melhor prática que possa ser aplicada em todas as organizações. Ou seja, não existe resposta certa para a proporção entre testadores e desenvolvedores de um projeto. Cada organização deve analisar a sua realidade e definir os seus próprios patamares. Adicionalmente, Rothman afirma que durante essa análise, devem ser considerados os seguintes pontos:

• Produto: a qualidade dos requisitos, o tamanho e a complexidade do produto;
• Projeto: o processo de desenvolvimento, a tolerância do cliente em relação à quantidade defeitos ou atrasos nas entregas;
• Pessoal: a experiência dos testadores e desenvolvedores e as suas responsabilidades.

Randall Rice [4], realizou uma pesquisa informal em 2000 durante a conferência “QAI's 20th Annual Software Testing Conference” e chegou à seguinte conclusão:

• Proporção mais comum: 1 testador para cada 3 desenvolvedores;
• Proporção média: 1 testador para cada 7 desenvolvedores.

Para Rice, não existe um número mágico que possa ser adotado para qualquer organização. Além disso, as pesquisas sobre a relação testador:desenvolvedor normalmente não adotam metodologias formais e não representam a realidade do mercado em virtude de que o número de participantes não é suficiente para determinar uma média precisa.

Realidade Brasileira

Para delinear a proporção mais comum de testadores em relação aos desenvolvedores no cenário Brasileiro, foi realizada uma enquete no portal gratuito de testes e qualidade de software TestExpert (www.testexpert.com.br). Esta enquete foi realizada no período de 11 de outubro de 2007 a 22 de novembro de 2007 e contou com a participação de 231 respondentes. O resultado da enquete pode ser observado na Figura 1. Curiosamente, o resultado mais comum é compatível ao resultado da pesquisa realizada por Randall Rice. A proporção mais comum foi de 1 testador para cada 3 desenvolvedores.

Figura 1: Resultado da Enquete (Testador:Desenvolvedor)

Trocando em miúdos: não existe uma solução que sirva para todas as organizações. O orçamento do projeto e o risco que um defeito na aplicação pode trazer ao negócio são fatores que influenciam diretamente a quantidade de testadores de um projeto. Ou seja, uma aplicação simples de baixo risco, pode estimar uma proporção de “1:>10”. No entanto, se a aplicação for utilizada em equipamentos médicos, sem dúvida, a proporção deverá ser muito próxima de “1:1”. De qualquer forma, uma grande quantidade de testadores por si só não garante que a aplicação tenha mais qualidade e seja livre de defeitos críticos. Grandes empresas como por exemplo, a Microsoft, que podem dar-se ao luxo de ter a proporção de “1:1” em praticamente todos os projetos , frequentemente liberam produtos no mercado repletos de defeitos críticos. Ou seja: Tudo depende!

Referências

[1] EASON, Michael. Sizing a Software Quality Assurance Group: Theory and Application

[2] IBERLE, Kathy. Estimating Tester to Developer Ratios (or Not)

[3] ROTHMAN, Johanna. It Depends: Deciding on the Correct Ratio of Developers to Testers.

[4] RICE, Randall. The Elusive Tester to Developer Ratio.

[5] Microsoft Test center aims to help corporate programmers avoid buggy code. Disponível em: http://www.networkworld.com/community/node/20877

[6] Qual é a proporção de testadores em relação aos desenvolvedores nos seus projetos (Testador:Desenvolvedor)?. Disponível em: http://www.testexpert.com.br/?q=node/263

 

Post criado por: Cristiano Caetano - É certificado CBTS pela ALATS. Consultor de teste de software sênior com mais de 10 anos de experiência, já trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP Invent.

Fonte: http://www.linhadecodigo.com.br/artigo/1585/proporcao-de-testadores-em-relacao-ao-numero-de-desenvolvedores-de-um-projeto-melhores-praticas-e-a-realidade-brasileira.aspx#ixzz2cRAnyFLl

Read More

Epidemia dos bugs: corrigir agora ou postergar?

Elizabeth Hendrickson , consultora norte-americana focada em automação de testes e desenvolvimento ágil, publicou recentemente em seu blog uma análise a respeito do tempo desperdiçado em reuniões para a análise de bugs. Em seu post, a autora cita empresas que gastam muito tempo e dinheiro realizando testes, sem aproveitar bem as informações reveladas por eles.

Hendrickson relata que há uma concepção comum, mas equivocada, na comunidade de engenharia de software, de que os bugs são inevitáveis e que nem todos podem ser corrigidos. Isso justificaria a tomada de decisões de se fazer a correção ou postergá-la, com base em ROI (retorno do investimento) do projeto.

A autora trabalhou em duas companhias em que essa linha de pensamento tornou-se uma armadilha. Segundo Hendrickson, as empresas não faliram diretamente por causa dos bugs, mas esses bugs se tornaram uma "infecção generalizada" que derrubou a produtividade e paralisou times de testes e de engenheiros.

Foram os custos ocultos que nos esgotaram: horas perdidas argumentando sobre bugs em reuniões de análise; horas perdidas debatendo sobre assuntos já discutidos várias outras vezes; lutando contra um código frágil e propenso a gerar erros mesmo com alterações simples; registrando e categorizando o backlog. Isso era desmoralizante e extremamente caro.

A autora elabora algumas conclusões, de acordo com as suas experiências:

Cancele todas as reuniões para avaliação de bugs; gaste seu tempo prevenindo e corrigindo defeitos. Teste cedo e frequentemente para encontrar os bugs o quanto antes. Corrija os bugs assim que forem identificados; cuide cedo de suas janelas quebradas.

Leitores do blog registraram seus comentários a respeito do artigo. Jim Gay, por exemplo, disse:

Vi bugs que indicavam que o processo de desenvolvimento estava errado. Por exemplo, um analista diz que você deve fazer X e você implementa X, e depois os usuários perguntam porque o programa não está fazendo Y. Um erro no código ou um erro no processo significam que alguma coisa deve ser corrigida.

Gabe Newcomb não concorda com todas as considerações de Hendrickson:

O texto deixa a entender que todos os bugs devem ser corridos e o esforço para fazer isso é mais importante que o desenvolvimento de novas funcionalidades. Mas isso não bate com a minha experiência. O processo de triagem de bugs responde a questões importantes como: quando (e se) o bug deverá ser corrigido e onde se encaixa em relação a outras atividades.

Steve Fenton é um desenvolvedor que acredita que todos os bugs devem ser corrigidos:

O tempo gasto para corrigir um bug é quase sempre menor que o tempo necessário para discutir se deve ou não ser corrigido. Além do impacto no cliente, um defeito já existente pode ser lançado novamente pelo time de testes e ser fechado como duplicado diversas vezes pelos desenvolvedores. Quanto mais tempo se postergar uma correção, maiores são as chances de que custe mais do que se o defeito tivesse sido corrigido rapidamente.

O assunto relatado por Hendrickson é polêmico e sempre rende boas discussões. Você acredita que os bugs são inevitáveis? Considera que essa mentalidade pode ser classificada como uma armadilha?

Post escrito por: Michael Stal, traduzido por Leandro Guimarães. Fonte:  http://www.infoq.com/br/news/2012/09/epidemia-bugs

Read More

O que é e o que faz o testador de software?

Bom dia pessoal, 

Abaixo coloquei um post muito legal sobre o que faz um testador, leiam e comentem sobre o texto.

Um testador de software, como o nome já sugere, testa softwares das empresas desenvolvedoras. Apesar de pouco conhecida, a profissão está em alta no mercado e os profissionais estão escassos.  

O profissional que testa softwares possui a função principal de avaliar a qualidade das aplicações dentro das normas internacionais estabelecidas. Se necessário, o profissional deve corrigir as possíveis falhas que forem encontradas.

O testador de software é responsável por todas as atividades dentro do processo de desenvolvimento que garantem a qualidade e eficiência do sistema que está sendo desenvolvido.

Vista como uma atividade nova no mercado, os testadores de software estão ganhando cada vez mais espaço no mercado brasileiro. Já existem muitos órgãos que só contratam empresas que produzem software somente após a avaliação do produto por testadores de software. Com o tempo, a estimativa é que as fábricas de software sejam obrigadas a ter um profissional específico do ramo.

Vale notar que apenas há pouco tempo os profissionais que queriam se especializar nesta área conseguiram obter a certificação no Brasil. Até 2006 era necessário buscar o certificado fora do país. Agora o BSTQB (Braszillian Software Testing Qualifications Board), braço oficial do ISTQB (International Software Testing Qualificationn Board) está no país para qualificar esta mão-de-obra.

Quais são as tarefas?

O testador possui uma função específica, ou seja, precisa analisar as aplicações para que possíveis bugs sejam corrigidos enquanto estão sendo desenvolvidos. Por isso é importante que o trabalho seja iniciado antes de os códigos serem escritos.

Com isso, o objetivo geral é corrigir as falhas antes que o produto final fique pronto. Qualquer falha não detectada no desenvolvimento de um determinado software pode causar grandes transtornos. Além disso, o teste feito nos softwares evita que o trabalho precise ser feito novamente, causando atrasos. Também dá mais credibilidade ao serviço.

O testador não pode poupar o software. Bem ao contrário, ele precisa ser exercitado de forma constante, assim, terá mais chances de encontrar uma falha. Deste modo, se for encontrado qualquer tipo de problema, é melhor que seja detectado na sua fase de elaboração, pois quando ele já estiver na prática, além de trabalho redobrado, poderá causar sérios danos onde ele está sendo usado.

O testador de software costuma seguir um roteiro de testes e, após o sistema estar rodando, os testes são realizados. Tais testes são feitos de forma manual ou mesmo automática. Todos os resultados costumam ser relatos em um relatório, apresentando todas a as impressões. O relatório costuma ser repassado ao desenvolvedor do sistema, para que, se necessário, realize a correção dos erros.

Logo após todo o processo, o software volta ao testador, e novos testes são feitos. Após todos os testes serem realizados e não encontrado mais qualquer erro, o software passa a ser enviado para a produção.

 

Média salarial

A média salarial de um profissional testador de software não costuma ser muito alta, apesar da crescente ascensão no mercado. Cada empresa acaba determinando um valor para o profissional contratado, bem como cada estado costuma ter alguma variação salarial. Tendo em vista tais fatores, a média que um testador de software recebe no Brasil varia entre R$ 1.500 e R$ 5.000.

Fonte: Oficina da Net: http://www.oficinadanet.com.br/post/11183-o-que-e-e-o-que-faz-o-testador-de-software?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+oficinadanet_rss+%28Oficina+da+Net+-+Feed%29

Read More

Oportunidade de Emprego - Recife (PE)

Bom dia pessoal,

Um projeto da MOTOROLA MOBILITY em Convênio inovador do CIn/UFPE, está abrindo uma seleção para Engenheiros de Testes. Vejam abaixo os requisitos para participar da vaga.

ENGENHEIRO DE TESTES

Habilidades necessárias

• Qualificações de nível superior (Ciências da Computação ou equivalente)
• Nível Intermediário: Inglês
• Capacidade de investigação
• Proatividade
• Trabalho em equipe
• Compromisso
• Disponibilidade para viagens

Habilidades Desejáveis

• Experiência em teste de software
• ISTQB Foundation Level (CTFL)
• IREB Certified Professional for Requirements Engineering - Foundation Level (CPRE FL)
• CAT - Certified Agile Tester
• Scrum Alliance - Certified Scrum Master (CSM)
• Scrum.org - Professional Scrum Master level 1 (PSM I)
• Experiência com ferramentas para gestão de defeitos (por exemplo: Jira, Bugzilla, Mantis)
• Experiência com desenvolvimento de software
• Conhecimento no sistema operacional Linux

Características do Cargo

• Regime de 8 horas diárias
• Vínculo CLT: Remuneração + Benefícios

Local de trabalho: Recife - PE

Caso atenda aos requisitos obrigatórios acima e esteja disposto a fazer parte de um time vencedor, por favor preencha o formulário no site:

https://sites.google.com/a/cin.ufpe.br/motorola-mobility-partnership/test-engineer
 

Read More

O que fazer quando o defeito está no teste ?

Contribuir para o aumento do nível de confiança, prevenir e encontrar defeitos estão entre os principais objetivos que queremos alcançar quando testamos um software. Porém, para atingirmos essas metas não existe uma simples receita de bolo e precisamos estar sempre atentos para maximizar as nossas chances de entregarmos constantemente software de qualidade e que atenda às necessidades dos clientes.

Apesar de nossos esforços, invariavelmente temos que lidar com os defeitos escapados, que normalmente implicam em stress, re-trabalho e desgaste na relação com o cliente. Em meio ao problema, uma das primeiras ações que temos é a análise da causa raiz, ou seja, identificar o porquê do defeito ter ocorrido e consequentemente do mesmo não ter sido identificado nas etapas anteriores de validação.

Diversos podem ser os motivos para a falha na detecção do defeito, por exemplo:

- Cenário de teste não estava coberto.

- Teste existia, mas não foi priorizado para o ciclo de execução.

- Teste existia, foi priorizado, porém não foi executado corretamente.

- Teste existia, foi priorizado, executado corretamente, porém diferenças de ambiente não permitiram a detecção da falha.

- Etc.

Porém, ainda há um outro motivo, que talvez seja um dos mais frustrantes – O teste existe, mas está errado.

Quando isso acontece, independente de planejarmos corretamente, o teste, seja ele manual ou automático, nunca nos trará o resultado correto e a falha inevitavelmente aparecerá em produção. Nesses casos, ainda temos como dificuldade adicional o fato de que a re-execução do nosso teste não ajudará na reprodução do erro, podendo inclusive gerar ruído na comunicação e dificuldades na identificação da causa do problema e consequentemente em sua correção.

Identificar testes com defeito não é algo simples e corremos o risco de executá-lo diversas vezes e confiarmos em resultados enganosos. Para tentar minimizar esse tipo de situação, podemos realizar algumas ações:
- Revisar os testes existentes

- Se forem testes manuais, mudar o responsável pela execução

- Aprofundar-se no funcionamento de mocks e stubs utilizados para teste

- Conhecer as limitações das ferramentas utilizadas

- Revisar as pré-condições e o ambiente de validação

E você já enfrentou o problema de ter falhas escapadas devido a testes defeituosos? Que ações tomou para tentar evitar que o problema se repetisse?

Post criado por JOSÉ CARRERA. Fonte: http://bytesdontbite.com/2013/07/29/o-que-fazer-quando-o-defeito-esta-no-teste/

Read More