Encontro Internacional do ISTQB no Brasil em 2010

Muito boa a iniciativa do BSTQB,  o representante oficial do ISTQB no Brasil, de aproveitar a realização do encontro do Conselho do ISTQB, que ocorrerá no próximo ano no Rio de Janeiro, para também realizar um evento aberto em São Paulo, com duração de dois dias e voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB.

Segue abaixo, maiores informações retiradas do site do BSTQB:

Em março de 2010 o Brasil sediará o encontro do Conselho do ISTQB (International Software Qualifications Board). Esse encontro contará com a presença dos Conselhos nacionais de cada país, onde o ISTQB é representado. Estarão presentes diversos nomes de destaque da área de testes de software, colocando o Brasil em foco. Será na cidade do Rio de Janeiro, no dia 19 de março. Essa é a primeira oportunidade do Brasil em sediar esse evento internacional, tendo disputado essa oportunidade com outros países.

Em conjunto com a reunião do ISTQB, teremos um evento aberto em São Paulo, com duração de dois dias e será voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB. Esse evento terá a junção do público nacional e internacional, trazendo discussões atuais e relevantes sobre o tema ao nosso mercado. Diversos participantes do encontro do ISTQB estarão presentes nesse congresso, trazendo uma oportunidade única para o mercado brasileiro. Dados sobre esse evento serão divulgados pelo BSTQB.

O ISTQB é um Conselho internacional formado em 2002 e composto por representantes de mais de 40 países, os denominados conselhos membros. O número de Conselhos membros tem crescido a cada ano, demonstrando a importância e a abrangência do Conselho internacional. Esse Conselho é dedicado à disciplina de testes de software, e promove o profissionalismo na área através de um programa de certificações profissionais. O BSTQB é o Conselho membro brasileiro, formado em 2006 e com crescente aderência dos profissionais à suas atividades. Atualmente são mais de 120.000 certificados ISTQB no mundo, e mais de 500 certificados no Brasil, sendo a maior certificadora em testes de software no Brasil e no mundo. O ISTQB e seus Conselhos membros são entidades sem fins lucrativos. Essa estrutura traz transparência para suas ações, justificando seu sucesso e reconhecimento no mercado.

Três vezes ao ano, o ISTQB reúne seus membros dos Conselhos em uma reunião, o General Assembly Meeting, com diversas metas:

– Divulgação do status do programa de certificação;
– Tomada de decisões em relação a atividades do Conselho;
– Realização de votações relativas ao Conselho diretor; corpo de conhecimento, grupos de trabalhos, entre outros,
– Discussão e votação em relação à entrada de novos Conselhos membros.

Essa reunião tem uma grande importância para o encaminhamento das atividades do Conselho internacional. Também é de grande importância para o país que a sedia, visto que muitos nomes de destaque da área comparecem, contribuem com a comunidade, além de ser uma oportunidade de negócios e contatos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

P.S.: Agora é aguardar, maiores detalhes sobre o evento. 😀

O melhor da semana 18/10 a 24/10

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 11/10 a 17/10

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Como testamos o Basix? – Contratação

Como comentei neste post, na minha opinião, a contratação de um profissional é um processo de suma importância, para ambos os lados.

Falando mais especificamente do projeto Basix, eu não posso explicar como foi desde o começo, pois entrei no projeto após mais de 3 anos do seu início. Então, nada melhor do que conversar com o Antonio, que gerencia o projeto desde o seu início, e até já fez um post relacionado ao assunto: O que vale mais conhecimento técnico, ou características pessoais?

Abaixo, segue a entrevista que fiz com o Antonio, focada no assunto contratação e especificamente da área de Teste e Qualidade de Software. Espero que gostem.

Fabrício: Antonio, antes de mais nada, em qual momento você percebeu que o projeto necessitava de uma área de Teste e Qualidade de Software?

Antonio: Percebemos isto desde a concepção do projeto, pois vínhamos de experiências em desenvolvimento de software sem uma área de qualidade, e já que estávamos começando um novo projeto não podíamos errar novamente da mesma forma.

Fabrício: E como foi o processo de contratação?

Antonio: Foi complicado, pois há 5 anos atrás era muito difícil convencer profissionais a trabalhar na área de qualidade de software, pois esta área não tinha a ênfase que tem hoje no Brasil, e as faculdades de TI não tinham disciplinas que ensinavam qualidade de software, no geral elas preparam os estudante para serem desenvolvedores.

Fabrício: A pessoa para atuar na área, necessita ter características específicas? Se sim, quais?

Antonio: Precisa sim Fabrício, aqui vou reproduzir o perfil que divulgamos no último processo seletivo que fizemos para a área de qualidade:

  • Conhecimentos técnicos
    • Boa base de informática;
    • Raciocínio lógico;
    • Capacidade de abstração;
    • Capacidade de análise de problemas;
    • Inglês técnico (quanto mais experiente melhor).
  • Funcionamento do grupo
    • O grupo de qualidade é um grupo que trabalha com atividades rotineiras, pois sempre que é liberado uma nova versão do software é necessário refazer todos os testes, necessário muita acuidade no trabalho, pois é o controle de qualidade do produto. É um grupo de generalistas, pois é necessário ter conhecimento de muitos componentes que constroem o produto.
  • Personalidade que ajudaria a desenvolver o grupo
    • Perfeccionismo;
    • Organização;
    • Crítico;
    • Pesquisador.
  • Características pessoais
    • Boa auto estima;
    • Extrovertido;
    • Bom relacionamento interpessoal;
    • Estar aberto a aprender;
    • Pró atividade;
    • Estar aberto a receber criticas.

Fabrício: Qual foi a maior dificuldade encontrada na contratação dos profissionais?

Antonio: Por ser uma área relativamente nova, foi bem difícil encontrar pessoas que queriam trabalhar na área de testes, a grande maioria queria desenvolver, então o processo de contratação também era um processo de convencimento, pois procuramos as pessoas que tinham as características ideais para trabalhar com qualidade, e muitos destes nós tivemos que convencer que era uma boa trabalhar na área de qualidade, e de qualquer forma tivemos muitos profissionais que depois de um tempo decidiram ir para o desenvolvimento, esta rotatividade foi uma dificuldade muito peculiar da área de qualidade.

Fabrício: Na sua opinião, até que ponto uma certificação ou especialização (ex. Pós-Graduação) ajuda o candidato durante o processo seletivo?

Antonio: Acredito que certificação ou cursos de especialização são sempre bem vindos, principalmente porque se um profissional decidiu  por conta própria estudar para conseguir um titulo deste isto no mínimo significa que a pessoa está interessada na área, e teve competência para obter o título, mas existe um outro lado para mim certificações e títulos não são de forma alguma os principais fatores para avaliar um bom profissional, pois existem profissionais excelentes que não tem nem a graduação completa.

Fabrício: Para fechar, de 2005 até hoje, a contração de profissionais para a área de Teste e Qualidade de Software ficou mais fácil? Ou ainda é difícil encontrar pessoas com o perfil e conhecimento para entrar na área?

Antonio: Com certeza o panorama do mercado da área de qualidade de software mudou completamente nestes últimos 4 anos, hoje já temos faculdades ministrando disciplinas voltadas para qualidade de software, existem comunidades de  que fomentam a área, e isto já reflete no mercado como um todo, hoje é muito mais fácil você achar pessoas que querem trabalhar com teste de software, e posso falar isto com tranqüilidade pois até o problema de rotatividade que tivemos diminuiu muito ao longo do tempo, hoje temos uma equipe de qualidade bem estável e onde todos realmente gostam de testar!!!

Muito obrigado Antonio pela entrevista. 😀

No próximo post da série, irei falar sobre a complexidade do projeto e o papel da área de Teste e Qualidade de Software. Até lá! 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Precisa sim, Fabricio aqui vou reproduzir o perfil que divulgamos no ultimo processo seletivo que fizemos para a àrea de qualidade:

Conhecimentos técnicos:

Boa base de informática
Raciocinio lógico
Capacidade de abstração
Capacidade de análise de problemas
Inglês técnico (quanto mais experiente melhor)

Funcionamento do grupo:

O grupo de qualidade é um grupo que trabalha com atividades rotineiras, pois sempre que é liberado uma nova versão do software é necessário refazer todos os testes, necessário muita acuidade no trabalho pois é o controle de qualidade do produto, é um grupo de generalistas pois é necessário ter conhecimento de muitos componentes que constroem o produto.

Personalidade que ajudaria a desenvolver o grupo:

Perfeccionismo
Organização
Critíco
Pesquisador

Caracteristicas pessoais:

Boa auto estima
Extrovertido
Bom relacionamento interpessoal
Estar aberto a aprender
Pró atividade

Estar aberto a receber criticas

Impressões do 6º Encontro Mensal da ALATS São Paulo – parte 2

Ontem, às 19:00 teve início a segunda parte da palestra “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, feita pelo Jorge Diz, no 6º Encontro Mensal da ALATS. A primeira parte da palestra ocorreu no final do mês setembro (30/09/09), porém teve que ser encerrada, antes do seu término, por ter ultrapassado o tempo disponível.

Abaixo, compartilho as minhas impressões sobre o encontro.

Sprint 1

Como de costume (aliás, um mal costume) cheguei em cima da hora. Ao entrar no auditório percebi que público presente era menor do que da última palestra, totalizando 9 pessoas. E dentro do auditório tinha uma mesinha, com o coffee, o que me fez pensar que não haveria o break, fato que acabou se concretizando. Ou seja, o Jorge planejou passar todo conteúdo numa sprint única.

O início da palestra se deu com o palestrante falando sobre o novo modelo de testes, necessário ao se utilizar metodologias ágeis. Utilizando a excelente explicação do fluxo ponta-a-ponta (erro -> defeito -> falha -> diagnóstico -> correção), influenciado pela metodologias ágeis, onde:

  • O erro pode ser evitado utilizando o conceito de Poka-yoke, como por exemplo, usando linguagens de tipagem forte (ex. Ruby);
  • Outra maneira de utilizar uma ferramenta que execute automaticamente os testes, a cada mudança nos arquivos do projeto relacionados com a mudança, ou seja, uma ferramenta que faça um teste de regressão de acordo com a mudança realizada, para verificar se a mesma não quebrou nada. Exemplo de tal ferramenta é o Autotest (que faz parte do pacote ZenTest);
  • Para encontrar defeitos é necessário… testes :);
  • É possível facilitar a identificação do motivo da falha, analisando a pilha de execução, exceções, logs e utilizando predicados fluentes (uma maneira de torna mais legível o método);
  • Para realizar o diagnostico é necessário ter uma gestão de configuração e depois reportar utilizando uma ferramenta de gestão de incidentes, famoso bugtracking;
  • Após a correção, se faz necessário a realização dos testes de regressão.

Agora você pode está pensando: mas boa parte das coisas que foram citadas eu já realizo no meu dia-a-dia?

Porém, utilizando agile muita dessas tarefas são realizadas de forma automatizada, realizando integração contínua, que acaba minimizando a quantidade de defeitos que seriam encontrados pela pessoa que fosse realizar o teste. E o mais importante é que o foco das metodologias ágeis é que o feedback  possa ser o mais rápido possível (lembra do manifesto ágil: “Indivíduos e interação entre eles mais que processos e ferramentas”. Trazendo isso para a realidade de Teste de Software, significa que o fluxo ponta-a-ponta será mais ágil;) o desenvolvedor pode receber o feedback da existência do defeito em “tempo de programação”, utilizando uma ferramenta do tipo Autotest.

Um ponto interessante que o Jorge Diz levantou, foi a carência de fontes falando sobre Teste de Software em metodologias ágeis, porém há uma excelente fonte, o livro da Lisa Crispin e Janet Gregory chamado Agile Testing (eu tenho ele, e recomendo fortemente aos interessados, é sem dúvida, a melhor bibliografia sobre o assunto até o momento).

Em seguida, o palestrante apresentou novamente a pirâmide frágil, na qual a maioria dos testes executados são testes de interface e poucos testes de unidade e integração são realizados. E o modelo ágil propõe uma inversão dessa pirâmide, como pode ser visto na figura abaixo.

TestingPyramid

Uma boa metáfora existente para explicar a diferença entre os três níveis de teste apresentados na pirâmide, feita pelo Patrick Wilson-Welsh, citado no livro Agile Testing, é a do três porquinhos. A camada de baixo é feita de tijolos, os testes são sólidos, e não vulneráveis ao sopro do lobo mau. Já a camada do meio é feita de madeira, precisa ser modificada com uma frequência maior do que a camada de tijolos, para permanecer resistente ao sopro do lobo mau. Por fim, a camada do topo é feita de palha, é difícil ela ser mantida no seu lugar e o lobo pode facilmente derrubá-la. Ou seja, se temos muitos testes feitos de palha, iremos precisar gastar muito tempo colocando-os no lugar.

Logo após, a explicação sobre a pirâmide dos testes, Jorge Diz falou sobre as escolas de teste, e os consensos que existem em comum entre elas:

  • Não é possível testar tudo;
  • Quem testa deve ter atitude crítica;
  • Testes tem custo;
  • Testes informam sobre risco;
  • Áreas concentram defeitos (bug clusters).

Encerrada a parte dos consensos, chegou a hora de falar sobre automação de testes no contexto ágil. Parte na qual foi apresentada uma série de ferramentas, de acordo com cada nível de teste e também uma explicação de alguns conceitos.

Para iniciar o assunto, o Jorge Diz logo apresentou as vantagens e desvantagens da automação:

Vantagens

  • Menos sujeita a falhas humanas, desatenção;
  • Menos sujeita a interpretações;
  • Executar testes automatizados é muito mais barato que manualmente, quando repetidos;
  • Regressão torna-se mais abrangente.

Desvantagens/Dificuldades

  • Dependência de sistemas externos;
  • Dependência internas do sistemas;
  • Controle sobre o ambiente;
  • Lentidão em alguns tipos de teste;
  • Fragilidade da API/interface usuário;
  • Custo da automação pode ser alto;
  • Necessidades de pessoas especializadas, o que geralmente, gera um maior custo.

O Jorge explicou um paradoxo bem interessante, o do campo minado,  no qual ficou bem claro a necessidade de realizar variações de cenários/caminhos de teste. Afinal, o intuito testes é que as minas explodam. 😉

Continuando a explicação sobre automação de testes, foi a vez de falar sobre as ferramentas existentes para realizar testes de sistemas Web:

  • Simular o browser – htmlUnit, Webrat;
  • Executar in browser em javascript – Selenium;
  • Adicionar browser a partir de um programa em Java – Selenium RC;
  • Acionar browser a partir de um plugin do browser – Selenium IDE;
  • Acionar browser a partir de um wiki – StoryTest IQ (Selenium + FitNesse);
  • Acionar browser a partir de um editor de workflow – CubicTest (Selenium + plugin Eclipse).

E necessário ter conhecimento sobre o que estamos testando, com determinada ferramenta, e para explicar isso, o Jorge citou as seguintes ferramentas:

  • Xunit – Módulos, classes isoladamente;
  • FIT – regras de negócio;
  • Cactus – funcionalidades de componentes web;
  • Selenium– Interface usuário;
  • JMeter – Estresse/desempenho.

Depois foi a vez de falar sobre as ferramentas XUnit, onde o Jorge começou falando que o programador gosta de programa e não gosta de tarefas manuais e repetitivas e por isso devem investir na utilização de tais ferramentas, para realizar os testes de forma automática e aumentar a qualidade do código.

Com testes automatizados,  os programadores conseguem gostar de testes, e testar torna-se uma tarefa central do desenvolvimento.

Em um time focado em automação de testes, há algumas mudanças:

  • Testes passam a ser ferramentas de desenvolvimento;
  • Teste unitário ocorre paralelo à codificação;
  • Rede de segurança para refatoramento;
  • Exemplos de uso do código sendo desenvolvido;
  • Complementos à compilação passam a existir (testes unitários, por exemplo);
  • Especificação de comportamento;
  • Validação para a integração contínua;
  • Adoção de um ambiente comum;
  • Infraestrutura para outros tipos de teste.

É importante também salientar as premissas para os testes unitários:

  • Teste unitário centrado no desenvolvedor;
  • Resultado independente da ordem de execução;
  • Independência entre métodos de teste;
  • A suíte de testes deve ser executada em alguns segundos;
  • Todo recurso está sob controle do programador (não pode depender do link de internet, banco de dados, sistema legado, etc);
  • Não é testada a integração;
  • Testes na mesma linguagem que o código sob teste;
  • Resultado não sujeito a interpretação (ou passou ou não passou);
  • Não colocar if no método de teste, se tiver ele é suspeito.

O Jorge Diz falou que o grande problema de realizar testes unitários é lidar com dependências. Levantando os seguintes pontos:

  • Se não consigo instanciar facilmente, não consigo testar;
  • Dependências podem se manifestar apenas em tempo de execução;
  • Dependências problemáticas precisam ser eliminadas ou substituídas.

Então a dúvida que surgiu foi: como lidar com dependências?

E a resposta: é preciso eliminar ou substituir.

Eliminar

  • Mudança no design para melhorar a testabilidade (exemplo da “vareta” para verificar o nível de óleo do motor);
  • Código-alvo precisa mudar para poder ser testado.

Substituir

  • Colaboradores substitutos em tempo de testes;
  • Dependências configuráveis(injeção de dependência, instrumentação).

E o importante: Se não conseguir eliminar ou substituir, não é teste unitário!

Em seguida o Jorge fez uma bela explicação sobre os colaboradores:

  • Dummy (sub objeto) – esta aí apenas para cumprir tabela;
  • Stub (método) – retorna uma resposta pré-definida;
  • Mock (objeto)- define previamente o comportamento esperado das interações da classe-alvo com o colaborador (proativo se ver algo errado ele já avisa, pois ele já tem incorporado o que tem que ser feito no Play[quando executa o teste]);
  • Fake (serviço/objeto) – substitui um serviço por uma implementação mais apropriada para o testes;
  • Spy (método/objeto)- registra comportamento para verificação posterior.

E há duas maneiras de testar de forma unitária:

  • Teste de estado – Verifica o estado da classe-alvo depois de exercitar uma funcionalidade;
  • Teste de interação- Verifica a comunicação da classe alvo com seus colaboradores.

Logo após a explicação sobre testes unitários e o uso de Xunit, o Jorge começou a explicação sobre o Selenium, e suas variações, que é voltado para testes de interface Web. E na sequência o Jorge falou sobre o FitNesse, voltado para testes de aceite.

O FitNesse tem as seguintes características:

  • Ferramenta wiki, que pode ser utilizada por Analista de Teste e de negócios;
  • Especificação de requisitos em planilhas;
  • É possível utilizar o FitNess usando DSL (Domain specific language), que serve para que seja criada uma linguagem mais próxima do usuário, você cria um conjunto de frases que podem ser utilizados depois;
  • Codificação de fixtures pode ser feita por programadores.

Também é possível importar um arquivo do excel para html, que é interpretado pelo FIT (FiTNess = Fit + Wiki).

Depois o tema foi BDD (Behavior-driven development), no qual há um formalismo para escrita de testes de cenários de negócio, geralmente da seguinte maneira:

  • Parte explicativa: Sendo um <Papel>, eu quero <funcionalidade>, porque <motivação>;
  • Parte executável: Dado que <pré-condições>, quando <ação>, então <verificações>.

Por fim, o Jorge citou as ferramentas que podemos usar com BDD:

Após, o término da palestra começou uma sessão de perguntas, que logo se tornou numa “mesa” de discussão (muito boa por sinal), onde variados temas foram discutidos: CMMI e metodologias ágeis, RUP é ágil ou não, dificuldades de implantar agile, as mudanças que ocorrem na área de Teste de Software e a maneira que ser realiza os  testes e vários outros assuntos relacionados a palestra.

Conclusão

A segunda parte da palestra do Jorge Diz, foi muito boa. Ele começou já falando sobre metodologias ágeis, e a palestra fluiu muito bem, sobrando até um bom tempo para as perguntas, que acabaram gerando uma excelente discussão (não é todo dia que você consegue discutir sobre agile e Teste de Software). 🙂

Com a palestra do Jorge Diz, acredito que ficou claro para todos os presentes, que o tsunami da agilidade pode melhorar muito a maneira como realizamos os testes, tornando o processo muito mais efetivo, além disso, as metodologias ágeis já tem na sua essência a preocupação com a qualidade do software, e ela não é uma preocupação/responsabilidade de apenas uma área, e sim de todos comprometidos com o projeto. 😀

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 04/10 a 10/10

Pessoal,

Segue abaixo, o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 27/09 a 03/10

Pessoal,

Segue abaixo, os links para o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.