sexta-feira, 30 de abril de 2010

Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 5

 Esta é a quinta e último tópico sobre os Planejamento, Design e Desenvolvimento dos Testes automatizados.

Este tópico não diz respeito especificamente a Automação de Teste, mas é um ponto de grande impacto para ela. Toda a atividade de teste tem de estar apoiada em um bom ambiente técnico para que a mesma não tenha problemas durante sua execução. Este ambiente precisa ter todas as definições de hardware e software necessários para apoiar o desenvolvimento e execução dos testes, e este precisa estar especificado no Plano de Teste.

Para o planejamento do ambiente temos duas situações: ambiente de cliente e ambiente de testes

No ambiente de cliente devemos ter toda a estrutura de hardware e software real do cliente (ou bem próximo disso), para que os testes sejam fielmente simulados como no cliente. Com isso prevenimos muitos erros de configuração e execução.

No ambiente de testes temos que ter toda a infra-estrutura de hardware e software necessários, como as ferramentas de teste instaladas e configuradas, e o hardware que suporte estas ferramentas. É sempre importante executarmos a calibração do ambiente de testes, já que este ambiente é que nos dará todo o resultado esperado pelo software. Qualquer desvio ou erro neste ambiente pode nos trazer resultados falsos.

Para as duas situações de ambientes podemos levar em conta os seguintes requisitos de hardware e software:
  • Servidores e desktops com as configurações desejadas no Plano de Teste
  • Servidores para virtualização de ambientes, se necessário.
  • Banco de dados dedicado para ambos os ambientes
  • Configurações de rede
  • Acesos e velocidade à internet
  • Browser web específicos (distribuidor e versão)
  • Configuração de memória, resolução de vídeo, etc.
  • Privilégios administrativos no computador ou da rede

Contemplaremos todos estes itens criando um checklist com as configurações necessárias para os ambientes, que serão retiradas do Plano de Teste. Qualquer teste de instalação ou execução que não tenha seu resultado esperado deve ser documentado, investigado e corrigido até que o ambiente esteja de acordo com o especificado.

Se existirem manuais de instalação ou de configuração estes deve ser seguido e, caso ocorra algum desvio, o mesmo deve ser documentado e corrigido. É necessário também validarmos os requisitos mínimos de hardware e software que a aplicação exige.

Requisitos de performance, carga e stress devem ser consideradas para o ambiente, seja de testes ou cliente, para suportar estes tipos de teste.

A massa de dados deve estar de acordo para suportar todos os testes e trazer os resultados esperados de acordo com os requisitos. Devemos levar em consideração todo o processo de entrada da massa de dados como:
  • Identificação dos dados de acordo com os requisitos
  • Conversão da massa de dados para formato específico (banco de dados)
  • Carga dos dados no banco de dados
  • Gestão dos dados inter-relacionados (manual ou por scripts)

Após todas as etapas definidas podemos testar a instalação do ambiente completo, sempre guiados por um cronograma tendo uma baseline. Com isso teremos toda a experiência necessária para a instalação e configuração do ambiente, que nos ajuda não só a prepará-lo, mas também a ter tempos para esta tarefa mais bem definidos.

Não deixe de ler os outros posts relacionados:

terça-feira, 27 de abril de 2010

Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 4

Esta é a quarta parte de 5 tópicos sobre Planejamento, Design e Desenvolvimento dos Testes automatizados

4. Arquitetura do Desenvolvimento dos Testes
As pessoas responsáveis pelo desenvolvimento dos testes precisam preparar seus próprios materiais e a equipe de teste precisa seguir o modelo de arquitetura que pode incluir uma lista de procedimentos e uma lista com a análise dos testes manuais x automáticos.

Para o desenvolvimento dessa arquitetura é apresentado um modelo com as principais atividades realizadas. O desenvolvimento dos testes inicia com os testes de configuração e atividades de preparação de ambiente. Todas as informações pertinentes, que serão utilizadas para apoiar o desenvolvimento dos testes, devem ser documentadas. A equipe de teste deve modificar estes building blocks a fim de refletir as prioridades de cada projeto. O modelo apresentado deve ser lido de baixo para cima:



Não deixe de ler os outros posts relacionados:

segunda-feira, 26 de abril de 2010

Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 3

Esta é a terceira parte de 5 tópicos sobre Planejamento, Design e Desenvolvimento dos Testes automatizados

3. Desenvolvimento dos Testes Automatizados
Para que os testes automatizados sejam reutilizáveis e de fácil manutenção padrões para o Desenvolvimento dos Testes devem ser definidos e seguidos. Logo após passar por todas as etapas anteriores estamos aptos a realizar o desenvolvimento dos testes.

Todo o desenvolvimento dos testes deve seguir uma abordagem iterativa e incremental e o processo de desenvolvimento dos testes muito bem alinhados com o processo de desenvolvimento do produto e todos os testes executados pela equipe de desenvolvimento (como os de caixa branca) podem ser reaproveitados para os testes de integração e testes dos componentes.

A equipe de teste deve desenvolver os procedimentos de teste de acordo com o cronograma de desenvolvimento e execução. O coordenador da equipe de testes deve acompanhar as atividades do desenvolvimento dos testes e acompanhar o cronograma e produzir um relatório de andamento destes testes. Com estes resultados saberemos o tempo real de cada teste, ajudando a criar cronogramas de teste mais precisos. Devemos atualizar o desenho da arquitetura dos testes, pois visualizaremos melhor a dependência de módulos e os scripts que deverão ser executados repetidamente durante o processo.

Abaixo segue a tabela que relaciona as fases do processo de desenvolvimento com as fases do processo de teste:


Fase Processo de Desenvolvimento Processo de Teste
Desenv. de Módulos (unidade) Desenhando os módulos pelos requisitos Planejamento dos testes e criação do ambiente.
Codificação do módulo Criação do desenho do teste e desenvolvendo a massa de dados
Debug do módulo Escrevendo os scripts de teste ou gravando cenários usando módulos.
Teste unitário de módulo Revisando os scripts de teste executando-os novamente. Usar ferramentas de teste unitário para apoio.
Correção de defeitos Re-executar os scripts de teste efetando testes de regressão testando se os defeitos estão corrigidos.
Conduzindo os testes de desempenho Verificar a escalabilidade do sistema e reunir todos os requisitos de performance
Integração Construindo sistemas por conexão de módulos.
Teste de integração dos módulos.
Revisão de problemas

Combinar scripts de teste unitário e adicionar novos scripts para demonstrar a integração dos módulos.
Ferramentas de apoio podem ser utilizadas.
Corrigir defeitos e atualizar status dos defeitos Re-executar os scripts de teste efetuando testes de regressão testando se os defeitos estão corrigidos.
Continuação dos testes de performance Verificar a escalabilidade do sistema e reunir todos os requisitos de performance
Sistema Revisão de problemas Integrar scripts automatizados em nível dos testes de sistema sempre que possível e desenvolver novos scripts e procedimentos. Execute os testes de sistema e sempre anote os resultados de cada teste.
Corrigir defeitos e atualizar status dos defeitos. Re-executar os scripts de teste efetuando testes de regressão testando se os defeitos estão corrigidos.
Aceitação Revisão do relatório de incidente Execute parte do teste de sistema, de acordo com os requisitos, para demonstração do teste de aceitação do usuário.
Correção de defeitos Re-executar os scripts de teste efetuando testes de regressão testando se os defeitos estão corrigidos.

Ao desenvolver os processos de automação de teste, baseados nos processos de desenvolvimento, o engenheiro de teste deve criar uma infra-estrutura de Automação, como um building block. Esta infra-estrutura conterá uma biblioteca de scripts em comum sendo reutilizável.

Durante os ensaios dos testes e nos testes do produto o engenheiro de teste pode fazer uso dessa infra-estrutura para reutilizar os procedimentos de teste, minimizar duplicações e diminuir o esforço em automatizar os testes.

Não deixe de ler os outros posts relacionados:

Carreira e Certificação em Teste de Software - São Paulo/SP - 29 de Abril VAGAS LIMITADAS

Objetivo: Apresentar as oportunidades de carreira em Teste de Software, as certificações e os cursos indicados para cada momento profissional.

Público Alvo: Profissionais de Teste e interessados em ingressar na área

Pré-Requisito: Não há.

Conteudo programático:
  • O que é Teste de Software?
  • Carreira
  • Atividades
  • Ferramentas
  • Crescimento do número de vagas
  • Salários
  • Certificações
  • Oportunidades para os profissionais certificados
  • Cursos para quem deseja ingressar, se especializar e se certificar

Valor: GRATUITO
Duração: 2 horas
Data: 29/abr
Horário: 18:45 - 20:45
Inscrições: http://www.iterasys.com.br/carreiraecertificacaosaopaulo-1.html
Local: Iterasys - Av. Paulista 726. São Paulo/SP

domingo, 25 de abril de 2010

Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 2

Esta é a segunda parte de 5 tópicos sobre Planejamento, Design e Desenvolvimento dos Testes automatizados
 


2. Desenhando os testes automatizados
Nesta fase abordamos a necessidade de definir o número de execuções que serão realizadas, os caminhos ou cenários que serão abordados.

Para uma ação mais efetiva dos testes, ocorre um mini-desenvolvimento dos testes automatizados, como o da codificação de uma aplicação do planejamento com objetivos, estratégias, definições dos scripts, analise, design e codificação dos scripts, mesmo que seja de forma automática (record-and-play). Sempre devemos ter toda esta preparação antes de começarmos a criar um script de automação, salvo a exceção de você automatizar seus Casos de Teste. Se você optar por automatizar todos os Casos de Teste já existentes uma matriz de rastreabilidade entre scripts e casos é bem-vinda para uma melhor organização. Lembre-se de que o planejamento destes scripts deve ter sempre o caminho percorrido pelo aplicativo, entradas e saídas esperadas, bem como os pontos de verificação de uma determinada parte da aplicação.

Após esta primeira fase de levantamento de ações e estratégias é necessário pôr em prática o teste interno destes scripts. Devemos agrupar scripts com ações/funções semelhantes e adotar uma convenção de nomes para cada script e para o grupo de scripts. Durante a execução destes scripts a equipe de teste será capaz de medir o número de técnicas utilizadas e uma estimativa do número de procedimentos testados durante esta execução. Com isso podemos confrontar o número de testes manuais e saber se aquele script seria mais viável se testado manualmente. Um documento contendo todas estas iterações, execuções e desenho gráfico da execução dos scripts devem ser criados. Também devemos ter todo o esforço necessário para o apoio dos testes tanto manuais como automáticos.

Seguido todos estes processos teremos toda a arquitetura dos testes automatizados criada descrevendo a estrutura destes testes e definindo a maneira e quando os testes serão inseridos e organizados em apoio ao esforço total de testes.
Agora é necessário identificarmos os procedimentos de testes que serão os mais sofisticados e obter seus resultados, que serão definidos como parte do desenho dos testes. Como temos a intenção de criarmos um documento reutilizável devemos criar padrões para estes desenhos. Somente então, depois que estes padrões forem seguidos, teremos um programa de automação eficiente. Abaixo seguem os procedimentos:

Passos Descrição
1 Teste de revisão da arquitetura. A equipe de teste revisa a arquitetura de testes a fim de identificar as técnicas de teste aplicáveis.
2 Definição do Procedimento de Teste (fase de desenvolvimento). Esta definição é construída na fase do desenvolvimento dos testes, que identifica a série dos procedimentos que se aplica para os diferentes componentes e técnicas de teste.
3 Definição do Procedimento de Teste (fase do sistema). Esta definição é construída na fase do desenvolvimento do sistema de teste, que identifica a série de procedimentos que se aplica para diferentes técnicas de teste.
4 Padrões do Procedimento de Desenhos dos Testes.
Padrões de desenho e uma conversão de nomenclatura são aprovados para identificar os procedimentos sobre projetos desenvolvidos no passado ou em outros projetos.
5 Teste Manual x Teste Automatizado. Um procedimento de teste é descrito como sendo realizado manualmente ou como parte de um teste automatizado.
6 Sinalização dos Procedimentos de Teste para o detalhamento do desenho. Os procedimentos que se destacam são sinalizados e definidos como parte do desenho detalhado dos testes.
7 Desenho Detalhado dos Testes. Os procedimentos descritos na etapa acima são concebidos de forma detalhado no documento de  Desenho Detalhado dos Testes.
8 Teste de Mapeamento de Dados. Uma Matriz de Procedimentos de Teste é modificada toda vez que alterarmos os requisitos de teste de dados de cada procedimento de teste.

O exercício de desenvolver o procedimento de definição dos testes ajuda a quantificar a necessidade de esforço necessário. O desenvolvimento das definições envolve a definição do conjunto de cenários que serão desenvolvidos e executados pela equipe de teste. O exercício de desenhar este procedimento ajuda a organizar estes em grupos, sendo que uma nomenclatura deve ser adotada para nomear este grupo de procedimentos.

Na arquitetura dos testes temos basicamente duas abordagens: os testes baseados na arquitetura e os testes baseados em componentes.
Nos testes baseados em arquitetura desenhamos como e em qual componente os scripts serão executados e como faremos para integrar os testes de diversos componentes. Todos os resultados gerados e comportamentos terão de ser coletado, a fim de assegurar o funcionamento de todo o sistema. Uma atenção deve ser dada para a massa de testes utilizada, que deverá ser bem elaborada.

Já nos testes baseados em componentes temos os testes na unidade/produto especifico, nos preocupando com a assertividade de casos específicos dentro do componente, mas este deve também ser mapeado no desenho da arquitetura, já que podemos ter mais de um script validando a mesma funcionalidade ou um script validando várias funcionalidades ao mesmo tempo.

Não deixe de ler os outros posts relacionados:

sexta-feira, 23 de abril de 2010

Automação de Teste - Planejamento, Design e Desenvolvimento dos Testes - parte 1

Esta é a primeira parte de 5 tópicos sobre Planejamento, Design e Desenvolvimento dos Testes automatizados


1. Planejando os testes automatizados

Esta fase representa a necessidade rever, ao longo do tempo de teste, as atividades de planejamento. Durante esta fase a equipe de teste identifica todo o procedimento para a criação de normas e diretrizes, necessidade de hardware, software e rede necessários para o apoio aos testes. Teste da massa de dados, cronograma preliminar dos testes, requisitos de performance, gerência de configuração e ambiente necessários para a execução dos testes e procedimentos de controle e acompanhamento de defeitos para o gerenciamento da execução dos testes.

O Plano de Teste deve conter todas estas informações e considerações ligadas ao CVTA, para que possa suportar todos estes procedimentos.

Para a configuração de ambiente, que é parte do planejamento, temos que planejar monitorar e gerenciar as atividades ligadas ao ambiente. Com isso a equipe de teste terá de agendar e acompanhar as instalações e configurações de ambiente, como hardware, software e recursos de rede, melhorar a massa de dados de teste a cada acompanhamento e execução e desenvolver scripts de teste para a validação do ambiente.

Não deixe de ler os outros posts relacionados:

quarta-feira, 21 de abril de 2010

Corrigindo o problema de Lost Password no Mantis 1.2.0

Demorou, mas agora estou fazendo um "pente fino" na versão 1.2.0 do Mantis que está estável  foi lançado dia 24/02/2010.

Porém, como toda ferramenta as open source também passam por alguma problemas, é o caso da funcionalidade "Lost Password" (Esqueci minha senha) na tela de entrada do Mantis.

 


Hoje se tu tentar utilizar essa funcionalidade, verás que o não acontecerá nada e também não chegará um email para a troca de senha.

Já existe um bug aberto para este problema: http://www.mantisbt.org/bugs/view.php?id=11394
O bug está apontado para entrar na próxima release estável no Mantis, mas é ruim ficar aguardando a versão estável para solucionar o problema.

Para resolver o problema abra o arquivo email_api.php localizado dentro da pasta core no diretório de instalação do Mantis. Abra o arquivo e localize o seguinte trecho do código: lang_push( user_pref_get_language( $p_user_id ) );
Comente este trecho de código, colocando um "//" no inicio da linha, ficando assim: //lang_push( user_pref_get_language( $p_user_id ) );


Pronto! Agora é só testar a funcionalidade. Abaixo segue a utilização dela:


Clicando no link "Lost Password"













Recebe retorno da ferramenta sobre o envio do email








Recebendo o email para o reset da senha.














Após clicar no link recebido no email, aparecerá a tela para inserir e confirmar a nova senha













É isso ai!
Qualquer dúvida deixe um comentário e não deixe de ver os outros post relacionados ao Mantis: http://sembugs.blogspot.com/search/label/mantis

terça-feira, 20 de abril de 2010

Automação de Teste - Processos de Introdução dos Testes Automatizados

Continuando com a série de posts, agora vou falar um pouco sobre o Processo de Introdução aos Testes Automatizados.

Não deixe de visualizar os outros posts:





Nesta fase começamos a introduzir os testes automatizados dentro da organização.
Temos que revisar o Processo de Teste atual e, se necessário efetuar melhorias e alterações neste processo, a fim de comportar os testes automatizados em todo o processo do teste. Todas as metas, objetivos, estratégias e métricas devem ser definidas, documentadas e enviadas a  equipe de teste.

Para obter um nível real de testes teremos que aplicar a execução da ferramenta em um ambiente de testes para validarmos o processo que esta sendo alterado ou definido e também como ensaio aos testes reais com a ferramenta. Com todas estas execuções conseguiremos definir as melhores práticas de utilização da ferramenta, bem como os dados que devem ser  coletados e analisados.

Após levantarmos todos os itens relatados acima teremos uma real visão da incorporação dos testes automatizados dentro do Ciclo de Vida dos Testes. Todas estas percepções que foram adquiridas nesta fase devem ser anotadas e revisadas no inicio dos testes que estiverem dentro do ciclo, ou seja, na aplicação real dos testes. Também teremos a estimativa de quanto tempo o teste automatizado irá tomar do cronograma de testes. Teste de comparações entre o teste automático e manual pode ser documentados como forma de benefícios que podem ser internalizados para as demais pessoas da equipe e os gerentes.

Toda a compatibilidade de aplicação, browser e ambiente deve ser verificada, validada e todos os ajustes na ferramenta ou scripts deve ser executados.

quarta-feira, 14 de abril de 2010

O que é um Arquiteto de Teste de Software

Update: não deixe de ler o post Como aprender a programar para teste de software que é um dos pontos que um Arquiteto de Teste deve conhecer.


Bom pessoal, faz tempo que eu estava querendo escrever este post. Acho ainda que ele está muito resumido, mas é bom compartilhar com vocês a minha visão desse profissional que está aparecendo timidamente no mercado de Teste de Software.

Se você tem qualquer coisa para complementar, por favor faça! Faço questão de atualizar o post e referenciar cada complemento.
Então, vamos lá!


O que é um Arquiteto de Teste de Software
Para ser um Arquiteto de Teste obviamente é mandatório ter sido um Testador. Para ocupar uma posição como esta o profissional de teste precisa ter um perfil sênior, conhecendo muitas linhas dentro do Teste de Software. Geralmente um Arquiteto de Teste tem que estar apto a executar quase que qualquer tarefa dentro do Teste de Software. Ele deve ser o líder técnico das soluções em teste e pode possuir uma linha de especialização específica dentro do Teste de Software: Automação, Performance, Segurança, etc..
Um Arquiteto deve trazer a inovação para a Área de Teste, sempre ligado nas tendências, tecnologias e abordagens dentro da área, internalizando todo esse conhecimento e analisando a aplicabilidade dentro da organização. Ele deve conhecer não somente da disciplina de Teste de Software dentro da Engenharia de Software, mas de outras disciplinas.

Eu, particularmente, acredito que a possível comparação de Engenheiro de Teste e Arquiteto de Teste é quase a mesma, mas com uma pequena diferença que pode ser entendida pela comparação abaixo:
"Um Arquiteto na Engenharia Civil é aquela capaz de criar toda uma estrutura/solução a partir de uma desejo do seu cliente. O Engenheiro, por sua vez, é aquele que irá colocar o plano de Arquiteto em prática, acompanhando todo o trabalho dos operários na obra."

Qual o dia-a-dia de um Arquiteto de Teste?
As atividades mais comuns são a de criação de ambientes de teste (hardware e software), criação de Casos de Teste mais complexos, aplicação das Técnicas de Teste corretas em todos os Casos de Teste.
Dentro da Automação de Teste, ele vai entender um problema de um cliente e criar uma solução de automação, utilizando alguma ferramenta existente no mercado ou até mesmo. Apóia e ensina a equipe a crescer tecnicamente na área e ajuda a melhorar todos os processos existentes na área de Teste de Software.

Quais os conhecimentos necessários para um Arquiteto de Teste?
Abaixo seguem alguns dos conhecimentos necessários do Arquiteto de Teste com um foco técnico voltado para a Automação de Teste:
  • Linguagem de programação (se puder mais que uma)
  • Sistemas Operacionais
  • Conhecimentos avançados sobre Técnicas de Teste
  • Ferramentas de Automação de Teste (em todos os níveis de teste)
  • Linguagem SQL intermediária
  • Arquitetura de Software e Design Patterns
  • Configuração de Ambientes
  • Execução de Testes Funcionais e Não Funcionais
  • Habilidade de Comunicação com pessoas técnicas

Podemos dar duas razões para que o Arquiteto precise conhecer uma linguagem de programação:
  • As ferramentas de automação de teste funcional será ou em uma linguagem padrão de mercado (VBScript ou Java) ou uma linguagem própria, o que necessita de conhecimento de programação
  • Quando não existe uma ferramenta de automação para determinada tarefa, o Arquiteto precisa criar uma, e isso é feito através de uma linguagem de programação
O conhecimento de Sistemas Operacionais é importante, pois além de utiliza-os para efetuar os testes também pode ser necessária a criação de máquinas virtuais para montar o ambiente de teste e, conseqüentemente conhecer sobre como configurar estes ambientes (no caso aqui, de hardware e software).
Conhecer a fundo as técnicas de teste também é obrigatório. Um Arquiteto que não conheça uma determinada técnica de teste pode não fazer o trabalho da melhor forma possível. Também é extremamente necessário que o arquiteto conheça as técnicas para a automação de teste funcional (data drive, keyword driven, decomposição funcional, baseado em modelos, etc...)

Saber como trabalhar com a linguagem SQL as vezes é básico para um testador, que precisa aplicar certas queries no banco para garantir que os resultados passados para o sistema estão contidos lá e estão íntegros. O conhecimento do Arquiteto deve ir mais além: ele deve ser capaz de conhecer mais a fundo o SQL e também aspectos específicos do SGDB utilizado (Oracle, MySQL, PostgreSQL, DB2, etc...)
Saber criar e executar testes não funcionais também é desejável, pois podemos nos deparar com alguma situação em que tenhamos que medir o tempo de resposta de uma aplicação, ou mesmo efetuar um teste de portabilidade ou recuperação da aplicação.

E falar 'grego' como o pessoal do desenvolvimento fala também é importante. Imaginem que tu vai conversar com um desenvolvedor ou Arquiteto Java e ele diz: "o problema ocorreu na ESB, onde um parâmetro da Inversão de Controle no Spring não foi colocado corretamente, o que fez o a camada DAO gerar uma NullPointerExepction dentro do Bean."

E é claro que o Arquiteto precisa conhecer de Ferramentas de Teste em todos os níveis: unitário, integração, sistema e aceitação. Conhecer uma Ferramenta de Automação de Teste Funcional é obrigatório, e também é muito desejável que ele conheça as diversas ferramentas para cada parte do Processo de Teste. Por exemplo: como fazer um teste de integração para validar e o pagamento por cartão de crédito está OK? E se eu disser que a aplicação se comunica com um WebServices para isso? O Arquiteto tem que ser capaz ou de criar ou de ajudar na criação de um driver para essa comunicação e depois efetuar o teste de integração com o WebService com o SoapUI, por exemplo.


Algumas empresas que tem um cargo definido para Arquiteto/Engenheiro de Teste:
Google Testing Engineer: http://www.google.com/intl/en/jobs/uslocations/mountain-view/swe/test-engineer-mountain-view/index.html

ThoughtWorks Test Architect: http://www.thoughtworker.com/jobs/test-architect

Microsoft Testing Engineer: https://careers.microsoft.com/Search.aspx#&&p4=all&p0=&p5=all&p1=20&p2=all&p3=all

Não deixem de colocar os seus comentários e visões sobre esse perfil...
Abraços!

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