Monday, September 19, 2011

Mudanças

Pessoal, após um bom tempo sem postar aqui no meu blog pessoal, venho com este post aqui para dar uma excelente noticia.

Fui convidado pela equipe do http://bytesdontbite.com/ para me tornar colaborador deles.
Como 2 ou mais cabeças pensam melhor que uma, eu vou deixar de postar nesse blog e passar a postar tudo relativo a testes no Bdb. Lá será melhor para todos os leitores pois além da área de teste, tem posts relacionados a outras áreas da Engenharia de software tambem. E como eu disse no meu primeiro post: Um bom engenheiro de teste não deve somente dominar a sua área , e sim conhecer bastante as outras áreas tambem. Meu primeiro post: Código: cobrir ou não cobrir, como e quando? dá continuidade ao meu último post daqui.
Forte abraços e vamos que vamos.

Monday, June 27, 2011

100% de corbertura de código em testes é válido ?


Você deve estar se perguntando o que cobertura de código tem haver com o post anterior no qual prometi dar um exemplo do porque é preciso ter conhecimento de outras áreas da engenharia de software para ser um bom engenheiro de teste. É justamente com a área de codificação que quero mostrar como é importante um engenheiro de teste ter conhecimento de linguagens de programação para tomar decisões importantíssimas em um projeto.

Dias atrás me deparei com a pergunta do título deste post em uma das comunidades de teste que participo e por coincidência no mesmo momento estava estudando a linguagem Python que é uma linguagem bastante usada na web e que possui algumas particularidades bem interessantes e que pude utiliza-la para justificar 100% de cobertura de código com testes pode se tornar válido dependendo do contexto do projeto. Vamos ao exemplo.

Imagine que você esteja para definir o plano de teste de um projeto de desenvolvimento de um sistema web, que tenha uma criticidade média e será desenvolvido em Python apenas com o complilador oficial, sem uso de ferramentas como eclipse, por diversos motivos plausíveis. No plano de teste do projeto, o que você definiria como um critério de saída na fase de teste de componenente ?

Antes de responder esta pergunta, um bom engenheiro de teste deve ter conhecimento mínimo das características da linguagem utilizada. Python apenas verifica os erros de codificação no último momento possível, isto significa em tempo de execução. Python é uma linguagem muito flexível e tem como objetivo de ser muito rápida por isso a mesma, diferentemente de java, não faz quase nenhuma verificação de sintaxe em sua compilação, ou seja, se o programador utilizar uma função que não foi definida previamente, o erro só será descoberto no momento que a instrução de código que utiliza a esta função for executada (o que chamamos de "runtime error").

Um bom engenheiro de teste tendo conhecimento dessa caracteristica da linguagem e sabendo que o sitema tem um criticidade mediana, deveria definir a meta de 100% de cobertura das instruções de código como um critério de saida importante na fase de testes de componentes para que todos o código Python seja exercitado e pelo menos garanta que não existirá nenhum "runtime error" no sistema.


Alguns de vocês podem achar que testes de componentes/unitários são de responsabilidade da equipe de desenvolvimento e que você poderia simplesmente questionar o líder da equipe de desenvolvimento para definir os critérios de saída para a fase de teste de componente. Se prestar atenção você perceberá que está exigindo que este engenheiro de software tenha conhecimento mínimo de teste que teoricamente esta fora do escopo dele. O que também pode acontecer é deste seu colega definir esta meta de 100% de cobertura do código e você não entender tão facilmente a exigência dele e achar que o mesmo está infrigindo justamente um dos princípios mais importantes de teste que é: "Testes exaustivos em impossível" e que 100% de cobertura é um absurdo, quando na verdade o critério de saída que ele está surgerindo faz algum sentido e deve ser levado em consideração.

Resumindo, para que você se destaque como engenheiro de teste será necessário um eforço maior do que dominar todos os conceitos e técnicas de teste. Também não é a toa que umas das mais famosas certificações de teste (ISTQB) na sua versão básica exige o conhecimento das técnicas relacionadas a cobertura de código conhecidas como "statement" e "decision coverage". No próximo post veremos um pouco mais dessas duas técnicas em detalhes.

Espero ter conseguido exemplificar bem o que havia prometido no post anterior e até breve. :)

Sunday, June 19, 2011

Engenheiro de Teste

Para um primeiro post deste blog vou escrever sobre o que sempre falo para meus alunos e colegas que querem iniciar uma carreira na área de teste.



Alguns anos atrás eu era apenas um executor de teste, e o simples fato de mudar de equipe já era o suficiente para me satisfazer e não ficar entediado. E foi após assistir uma palestra de um amigo meu em um evento de teste de software que eu percebi que estava no caminho errado e que tinha muito o que aprender para ter uma carreira interessante nesta área. A partir dai eu comecei a estudar mais e buscar novos conhecimentos em outras áreas da engenharia de software e naturalmente com o passar do tempo fui gradativamente sendo reconhecido pelos colegas de trabalho, gerentes de projetos e clientes. 

Um bom engenheiro de teste, não é aquele que conhece todas os princípios de teste de software, nem aquele que conhece todas as fases de teste (componente, integração, sistema, etc...) , muito menos aquele que domina todas as técnicas de teste (fronteira, particionamento de equivalência, exploratório, etc). Quem apenas sabe todos estes conceitos e técnicas de teste muitas vezes é apenas um testador, não que esse papel não seja importante, mas quem realmente tem um plano de carreira e deseja com o tempo alcançar papéis de liderança de um time de teste precisa ir mais além destes conceitos e técnicas de teste.

Para conseguir desempenhar um papel de líder de teste, é preciso provar com o tempo que você tem conhecimento mínimos em outras disciplinas da engenharia de software, como gerência de configuração, padrões de projetos, arquitetura de software e linguagens de programação e outras. E quanto mais profundo o seu conhecimento em outras áreas mais reconhecido você será, pois é com este conhecimento que um bom engenheiro de teste consegue ter o senso crítico para avaliar, entender e opinar de forma contundente nas diversas situações de um projeto de desenvolvimento de software. Se você parar e observar, um projeto de desenvolvimento de software não funciona direito com todas essas áreas trabalhando separadamente, então porque um engenheiro de teste vai apenas se preocupar com as suas atividades ? A não ser que este seja apenas um executor de tarefas e tenha alguém sempre tomando as por ele, ou seja, alguém que sempre vai ficar "estagnado" no tempo sem perspectiva de crescimento profissional.

No próximo post, vou citar alguns exemplos claros de como o conhecimento em outras disciplinas é importante para ser um bom engenheiro de teste e agregar um maior valor no projeto e empresa que você trabalha.

Até breve !!!

Objetivo do blog

Olá pessoal,
após muitas tentativas estou aqui novamente tentando manter um blog pessoal. Desta vez acredito que vou conseguir manter este blog ativo pois realmente encontrei um objetivo para ter um blog. Além dos objetivos pessoais o principal objetivo deste blog é discutir assuntos relacionados a área de qualidade de software, mais especificamente as atividades de teste de software que é a minha especialidade.

Gostaria de ressaltar que o post que colocarei aqui pode vir de vários lugares que eu tenha discutido no meu dia-a-dia, como discussões em comunidades de teste que participo, discussões com alunos dos cursos que ministro, discussões dentro do meu trabalho, etc.

Percebam que os momentos que vou trazer assuntos para esse blog é sempre de uma discussão, justamente porque o objetivo deste blog é trazer assuntos atuais, relevantes e talvez polêmicos no dia-a-dia da área de qualidade.

Espero que gostem e participem das discussões.
Abraços e até breve.