terça-feira, 13 de abril de 2010

Oficina de Automação de Testes com TestComplete (a distância)

Oficina de automação de testes com TestComplete (a distância)

Modalidade: Ensino a distância - Webconferência (o participante assiste a  aula online no seu computador via Internet)
Data: 17 de abril
Carga horária: 8 horas
Valor: R$ 290 reais (cartão de crédito em até 12x, boleto ou transferência)
Maiores informações e inscrições: treinamento@qualister.com.br

Conteúdo programático:
  • Criando um novo projeto
  • Conhecendo o Project Workspace
  • Gravando um script de teste
  • Stores e Checkpoints
  • Checkpoints (Property checkpoint)
  • Checkpoints (Region checkpoint)
  • Gravando o script em tempo real
  • Visualizer
  • Definindo a ordem de execução dos scripts
  • Data-driven
  • Acesso ao banco de dados
  • Object Browser
  • Timer
  • Chamando uma função ou procedimento localizado em outra unit
  • Auto-complete
  • Code Template
  • Debugging scripts
  • Project Items
  • Tested Applications
  • Name mapping
  • Low Level Procedures
  • User Forms
  • Events
  • Manual Test
  • Tests Log
  • Testes distribuídos
  • Tratamento de janelas inesperadas
  • Procura de imagens
  • Localização de objetos por propriedades
  • Optical Character Recognition (OCR)

Iterasys Confirma: Automação de Testes, CBTS e CSQA em SP

Iterasys, principal centro de treinamento brasileiro em Teste de Software e Garantia da Qualidade, único credenciado ALATS, BSTQB/ISTQB e QAI confirma o início de  3 novas turmas:

  • Automação de Testes - 7 sábados - 56 horas - Unidade Paulista I 
  • Preparatório para a CBTS/ALATS - 5 sábados - 40 horas - Unidade Paulista II 
  • Preparatório para a CSQA/QAI - 4 sábados - 32 horas - Unidade Paulista II

Data de início: 17 de Abril
Horário: 9 às 18 horas
Últimas vagas disponíveis - Visite o site www.iterasys.com.br ou pelo contato@iterasys.com.br ou (11) 3254-7625

domingo, 11 de abril de 2010

Automação de Teste - Aquisição de Ferramentas de Teste


Em continuação ao post  Automação de Teste - Decisão por Automatizar irei colocar alguns pontos sobre a Aquisição de Ferramentas de Teste, segundo o modelo ATML.

Esta fase tem por objetivo criar um documento que guie o Arquiteto/Engenheiro de Teste à escolha da ferramenta mais apropriada para a empresa.  Nesta fase o Arquiteto/Engenheiro, depois de ter efetuado todos os testes com as ferramentas escolhidas como candidatas a serem utilizadas, revê todas as necessidades que a ferramenta deve cobrir e revê também a necessidade da empresa em relação a uma ferramenta.


A partir daí o Arquiteto/Engenheiro de Teste lista as ferramentas selecionadas com seus principais benefícios, considerações, tipos de licença da ferramenta e tipo de ferramenta para todos os futuros envolvidos na utilização da ferramenta e os interessados. Os testes efetuados com estas ferramentas não precisam estar no domínio global do negócio, precisa apenas atacar alguns pontos mínimos para ser candidata. Quem decidirá pela escolha da ferramenta não é o Arquiteto/Engenheiro de Testes, e sim todas as pessoas envolvidas.

Se realmente a empresa está disposta a pagar por uma ferramenta que trabalhe dentro do ciclo de vida dos testes a mesma precisa estar ciente de que temos custos embutidos na aquisição da ferramenta como, por exemplo, treinamento dos funcionários. Por mais que o Arquiteto/Engenheiro de Testes tenha aprendido a ferramenta e aplicado casos para validar se a ferramenta é adequada, cabe também um ponto de imersão em toda a utilização da ferramenta, para que se tire o maior proveito da ferramenta dentro do projeto de testes. Todos os riscos inerentes à compra de uma ferramenta devem ser listados e informados.

Fora os custos de treinamento também teremos custos adicionais dentro do projeto de testes com o pessoal, uma vez que a utilização da ferramenta está no início, a produtividade deste colaborador pode ficar prejudicada num primeiro momento. Também teremos alterações e custos adicionais na atualização ou mudança de processo, uma vez que a utilização de uma ferramenta altera o processo de testes.

Então, se decidimos por comprar uma ferramenta, temos que levar em consideração os seguintes itens:
  • Contratação de pessoal com conhecimento na ferramenta
  • Utilizar a ferramenta correta para o trabalho
  • Desenvolver e implementar um processo automatizado, que inclui o desenvolvimento destes testes
  • Analisar diversas aplicações para determinar qual é a melhor opção
  • Analisar os requisitos de teste para determinar a ferramenta adequada
  • Treinamento da equipe de teste no processo automatizado, em todas as fases
  • Aumento inicial dos custos do projeto de teste

Não deixe de ler a primeira parte: Automação de Teste - Decisão por Automatizar
Aguardo o comentário e a contribuição de vocês!

Abraços!

sábado, 10 de abril de 2010

Como contornar o problema do Testlink 1.9 beta 3

Se alguém já baixou para avaliar o Testlink 1.9 beta 3 notou que ele vem com um pequeno "problema": na página de login são apresentados dois erros:



Notice: Undefined property: stdClass::$filter_methods in C:\wamp\www\testlink-1.9.3b\cfg\const.inc.php on line 487
Notice: Undefined property: stdClass::$filter_methods in C:\wamp\www\testlink-1.9.3b\cfg\const.inc.php on line 503



Pois bem, estes são dois errosde uma propriedade não definida onde duas variáveis não estavam definidas ($filter_methods). Isso gera um bug que bloqueia a utilização do Testlink.
O teste que eu efetuei foi sobre um Windows XP SP3 com o WampServer 2.0 (Apache 2.2.11, PHP 5.3.1 e MySQL 5.1.36).

Um bug foi aberto no bugtracker do Testlink (necessita de cadastro para visualizar). E a correção já foi feita. Só não existe ainda a definição se sairá um beta 4 ou será fechada a versão para produção.
Hoje existem 76 bugs abertos para o Testlink 1.9 beta 3 sendo 23 resolvidos e 2 fechados.

Para contornar esse problema, podemos baixar o arquivo alterado diretamente do CVS do projeto.
No link abaixo podemos visualizar o arquivo alterado e salvá-lo...
http://testlink.cvs.sourceforge.net/viewvc/*checkout*/testlink/testlink/cfg/const.inc.php?revision=1.139

Para que você possa ir utilizando o Testlink na versão beta até que a versão com o bug fix saia, faça um backup (por precaução) do arquivo INSTALACAO_TESTLINK/cfg/const.inc.php, salve o arquivo do link acima (do CVS) e coloque na mesma pasta, onde INSTALACAO_TESTLINK é o diretório onde o Testlink é encontrado.

Você vai notar que o bug estará corrigido, e uma diferença é que o Testlink será apresentado como Beta 4 (por causa das alterações de bug fix).

Em breve postarei aqui sobre as mudanças desta nova versão, e também oficializar a tradução completa da ferramenta para o Português do Brasil...

Abraços!

quinta-feira, 8 de abril de 2010

Automação de Teste - Decisão por Automatizar

Elfriede Dustin, um dos maiores ícones sobre Automação de Teste de Software e autora de diversos livros sobre o tema lançou em 1999 um livro chamado Automated Software Testing: Introduction, Management, and Performance, e o livro mesmo que lançado a mais de 10 anos é muito atual.
Vou colocar aqui no Sem Bugs uma série de post's sobre ATML - Automated Testing Life cycle Methodology, que contém uma gama de boas práticas em todos os passos para implantar a automação dentro de uma organização.

clique para ampliar

Vou iniciar a série de post's sobre Decisão por Automatizar os Testes!

A Decisão por Automatizar os Testes é a primeira etapa da ATML é uma fase importante para seguir os próximos passos do ciclo de vida. Durante esta fase é importante a equipe de teste (isso envolve desde o Gerente até o Testador) levantar todas as expectativas e benéficos esperados na aplicação da automação no processo de teste.

Lembre-se que devemos seguir este ciclo de vida para cada ferramenta de automação no respectivo processo ou técnica de teste. Mesmo sabendo que automatizando parte do processo de teste o Retorno de Investimento (ROI) não é imediato, nem sempre ele tem um retorno em curto prazo. Por isso todas as expectativas devem ser muito bem gerenciadas para não colocar sob o processo de automação todas as soluções para resolver problemas de tempo e maior qualidade de entrega.

Sabemos que hoje existem algumas ferramentas que tem o intuito de apoiar o Arquiteto/Engenheiro de Teste a planejar os testes, desde o Plano de Teste até seu controle e execução, mas muitos gerentes pensam ainda que “ferramentas de automação” farão toda a execução dos testes, desde o planejamento, execução e métricas.

Certamente durante uma reunião ou apresentação sobre uma determinada ferramenta de automação de testes os participantes, geralmente gerentes de diversas áreas com pouco conhecimento técnico sobre Teste de Software e sem ter a consciência da complexidade envolvida no esforço dos Testes Automatizados, esperam ouvir é que a ferramenta que você está propondo cria o Plano de Teste, Casos de Teste, executa os testes e analisa os resultados. Você, no entanto, como o profissional de teste, deve apresentar aos participantes que a ferramenta em questão ou quaisquer ferramentas de automação tem um propósito no Ciclo de Vida de Teste de Software e que tais ferramentas devem ser encaradas como melhorias no processo manual de teste.

Ao longo da apresentação pode ser que a realidade empregada por um participante irá mudar, pois o termo Ferramenta de Automação de Teste pode trazer duvidas e uma dose de ilusão para quem não é um profissional de testes. Uma colocação sempre válida e regra para nós são de que uma ferramenta de automação de teste não substitui o fator humano, necessário para testar um produto.
Profissionais de teste ou especialistas em Garantia da Qualidade ainda serão necessários para garantir todo o Ciclo de Vida dos Testes. Uma ferramenta de automação pode se encarada como mais um elemento de liberação de um bom produto.

Atualmente não temos uma única ferramenta que contemplem todos os testes em Sistemas Operacionais e Browsers web. É importante realçar este item, pois sempre teremos mais de uma ferramenta para o mesmo processo do Ciclo de Vida dos Testes quando temos diversos tipos de aplicações, tecnologias, sistemas operacionais e browsers.

Outra expectativa errônea sobre as Ferramentas de Automação de Testes é de que elas vão minimizar o tempo total de teste já no primeiro projeto que utilizará uma ferramenta. Na verdade devemos acrescentar mais tempo de teste no projeto e, que estamos inserindo a ferramenta, já que um novo processo de teste está sendo implantado. Todas as pessoas da equipe de testes e até mesmo os desenvolvedores devem se familiarizar com o novo processo e segui-lo, podendo também ajudar a melhorar o processo. O retorno não virá em apenas um teste sob determinado produto, mas uma vez que o processo automatizado foi criado efetivamente, devemos esperar a diminuição de tempo e custos sob o projeto e ganhos de produtividade.

Sempre que tentarmos inserir uma nova tecnologia dentro da empresa onde trabalhamos temos sempre um esforço extra para adaptar esta tecnologia as necessidades da empresa.
Com ferramentas de automação de teste não é muito diferente, o principal ponto é apresentar corretamente um caso para a aplicação da ferramenta de automação e sua utilização pela equipe.

O Arquiteto/Engenheiro de Teste deve ser o evangelizador dentro da empresa e deve gerir as expectativas dos stakeholders transmitindo informações úteis, desenvolvendo um material de divulgação ou treinamento ou até mesmo desenvolvendo workshops sobre estas ferramentas. O primeiro passo para a tomada de decisão em automatizar os testes exige um conhecimento sobre o assunto e o alinhamento de expectativas, para que os gestores compreendam a aplicação destes testes, os principais benefícios, custos, etc.
Se a ferramenta que está sendo proposta for freeware (grátis), temos sempre que levar em consideração os custos sobre treinamento e aprendizado da equipe de testes. Mesmo a ferramenta sendo freeware ou paga temos que levar em consideração que os custos iniciais em qualquer projeto aumentarão ate que se tenha dominado a utilização e aplicação da ferramenta de automação de teste. Isso é assunto para o nosso próximo item.

Em resumo à Decisão por Automação de Testes temos que:
  • Ferramentas de Automação não executarão todo o Ciclo de Vida de Teste sozinha
  • Ferramentas de Automação não substituirão o trabalho manual
  • Às vezes mais de uma ferramenta da mesma técnica de teste ou processo poderá ser utilizada
  • Escolher a ferramenta certa para a automação da tarefa em questão, analisando os requisitos da aplicação
  • Desenvolver e implementar um processo automatizado de teste
  • Treinar a equipe de teste no processo, elaboração e execução dos testes automatizados
  • Sempre levar em consideração que haverá um aumento inicial nos custos do projeto

Abraços!!!

Referências:
DUSTIN, Elfriede; RASHKA, Jeff; PAUL, John. Automated Software Testing: Introduction, Management, and Performance. Canadá. Addison-Wesley Professional. 1999

Link do livro na Amazon: http://www.amazon.com/reader/0201432870?_encoding=UTF8&ref_=sib_dp_pt#reader_0201432870

Livros escritos pela Elfried Dustin: http://www.amazon.com/Elfriede-Dustin/e/B001IO9RTM/ref=ntt_dp_epwbk_0