TestExpert A sua comunidade de teste e qualidade de software

Publicação oficial: http://blog.camiloribeiro.com/
Críticas, sugestões e correções: camilo@camiloribeiro.com.
Obrigado :)

Uma tarefa que parece fácil (e efetivamente é) pode se tornar um problema que dura quase um mês. Foi exatamente isso que aconteceu quando eu comecei a pesquisar sobre como integrar o TestLink, ferramenta Open Source de gerencia de testes ao Active Directory.

Alguns motivos que dificultaram a configuração:

Publicado originalmente em: http://blog.camiloribeiro.com 

Bom dia, vou publicar algumas customizações de ferramentas open-source e sempre vou postar uma cópia aqui para facilitar a pesquisa.

Mantenho-me disponível para quaisquer esclarecimentos através do e-mail camilo@camiloribeiro.com.

Essa publicação é uma customização do TestLink: 

Apesar de trabalhar muito com a "mega suíte" de ferramentas de engenharia de software da IBM Rational, acredito que o open-source TestLink é uma ferramenta sob medida para nós analistas de teste coordenarmos os nossos projetos. O TestLink tem recursos muito interessantes e pouquíssimos problemas e inconformidades com os padrões e nomenclatura do ISTQB .

Bom, como toda ferramenta, o TestLink não é perfeito, e possui alguns problemas pontuais que podem ser corrigidos com menos ou mais esforço, um pouco de dedicação e conhecimento básico sobre PHP e MySQL.

Na empresa onde eu trabalho, estou ajudando a implantar e customizar o TestLink e durante essa customização um dos problemas foi identificado.

Não existe uma maneira de exibir os requisitos, escopo, nos documentos “Plano de teste” e “Relatório de teste”, apenas o seu título e identificação.

Um dos nossos clientes tem uma exigência contratual que obriga a presença desse conteúdo nos casos de teste, o que tornaria o TestLink uma ferramenta incompleta para os projetos desse cliente.

Bom dia,

Publicação original em: http://www.camiloribeiro.com/blog/?p=1 

Estou escrevendo esse post para passar para frente um pensamento que tenho ha algum tempo sobre o nosso popular termo "BUG".
Acredito que todo mundo já conhece essa história e nunca cansa de contar para todas as pessoas que perguntam o porquê desse termo.

O que quero perguntar é: Esse termo ainda é adequado?

Meu ponto de vista é que o nosso tradicional bug, ainda é o bug de 1945, atribuído a construção e a engenharia.

Se pensarmos nas fases do RUP, o bug é identificado em um código fonte ou em um produto de trabalho derivado da fase de construção ou identificado em um produto já em testes, homologação ou produção.
O problema é que ao longo de vários anos estamos aprendendo que o bug, aquele que está no código fonte, não é o único problema proveniente da engenharia de software, na verdade, muitas das vezes ele é somente uma consequência de um defeito em outra atividade ou em outro produto de trabalho.