domingo, 28 de março de 2010

Teceirização dos Serviços de Teste

Na 17° Mesa Redonda DFTestes está rolando um thread sobre Terceiração de Teste, qual a realidade do mercado.
Daí resolvi escrever um pouco sobre os Tipos de Terceirização de Serviços de Teste

Hoje as empresas estão num ritmo cada vez mas acelerado em conta da crescente exigência de seus clientes. Quando um novo produto é lançado, ele precisa ser entregue rapidamente em casos de softwares COTS para ter uma vantagem competitiva. Ou se o próprio sistema é de uso interno, o ritmo também precisa ser acelerado dado muitas vezes pelos cronogramas apertados.

Muitas empresas não tem a equipe necessária para fazer estas atividades. Em Teste de Software essa realidade se faz presente nas empresas, pois empresas, dado o seu negócio, não necessariamente necessitam ter profissionais contratados para isso.

Pela demanda de software, os profissionais podem crescer ou diminuir rapidamente, onde a empresa nestes dois cenários precisa controlar suas metas de qualidade e restrições de orçamento.

Para atender a essa demanda um novo (mas velho conhecido) tipo de contratação se faz necessário: a Terceirização!

Existem diversos cenários comuns que
  •  Fornecedores atrasam as entregas
  •  Produto entregue com diversas falhas
  •  Cronogramas não cumpridos
  •  Testes de Sistema são realizados ou em Ambiente de Desenvolvimento ou Produção
  •  Área de negócio perde a confiança em TI
  •  Testes de Regressão são negligenciados
Isso mostra que muitas empresas ou não estão preparadas para ter uma área de Teste e Qualidade de Software ou estão fazendo da forma errada.

Existem diversas necessidades dentro de um ambiente de TI para
  •  Atender a demanda da área de Negócio
  •  Avaliar a Qualidade dos Fornecedores de Software
  •  Reduzir os riscos de atraso e problemas de produção
  •  Evoluir seu processo de desenvolvimento e seleção de fornecedores
  •  Medir a qualidade de seus sistemas

Atualmente, para buscar estas necessidades e outras, se faz necessário possuir um equipe Terceitizada para efetuar os testes no sistema

Com uma área de Testes Terceitizada poderemos:
  •  Reduzir o retrabalho e o risco na liberação de cada produto
  •  Reduzir o custo relacionados a teste de software, como processos, infra-estrutura e pessoal especializado
  •  Ter a garantia de resultado, considerando que "quem faz não testa"
  •  Maior tempo para execução de teste
  •  Maior volume de Casos de Teste
  •  Atendimento imediato de picos de demandada de teste

Existem alguns Tipos de Terceirização de Teste de Software

Terceirização Total COM Interface Técnica
Neste tipo, a empresa contratante possui profissionais de teste, mas contrata um empresa para ter um atendimento imediato a sua demanda. Como todos os requisitos serão validados por profissionais da contratante, o risco é muito pequeno pois eles já tem o conhecimento de negócio.
O lado negativo é que todo o "know-how" fica por parte da contratada, fazendo toda a organização do Projeto de Teste.

Terceirização SEM interface técnica
Nesse modelo a contratante tem alguns benefícios muito visíveis, como:
  •  A não preocupação com a formação da equipe e demandas de teste
  •  Impacto referente a demanda é minimizado
  •  Sem custos com uma equipe interna
O grande problema desse tipo é o entendimento de negócio do cliente, onde o cliente pode não ter todas as regras de negócio bem definidas e a exposição dos processos de negócio para as contratadas


Terceirização Parcial - Execução de Testes
Nesse tipo todo o conhecimento de negócio fica com a contratante, que também elabora os Casos de Teste não existindo a perda de maturidade de teste quando a contratada for trocada. A contratada só entra com a execução dos testes da contratante. O problema desse tipo é que, com uma demanda interna, a equipe de testes da contratante pode não criar todos os possíveis cenários para testes e não suportar a demanda.

Terceirização Parcial - Arquitetura de Teste
Nesse tipo os Arquitetos de Teste da contratante passam a parte mais complexa dos testes para os Arquitetos de Teste da contratada.
A execução de testes fica na contratante, o que eleva os riscos de negócio e o custo em contrstação. Se não for muito bem gerenciado, pode haver gastos desnecessários com profissionais alocados para cada atividade.

Terceirização Parcial - Automação de Teste
Nesse tipo os automatizadores ficam focados diretamente na automação do sistema, mas se o sistema não estiver maduro o suficiente para a automação, o trabalho não terá tanto ganho quanto o esperado. Scripts mal projetados para o cliente também vai dificultar na manutenção, elevado também os custos.


Para todos os tipos de Terceirização dos serviços de Teste se faz necessário criar SLA's (Acordo de Nível de Serviço) entre a contratante e contratada, além de o acompanhamento constante das atividades para que o projeto não saia do controle e esteja no rumo certo, além é claro de cumprir os prazos estabelecidos.

Na contração dos serviços de testes como terceirização, podemos ter duas formas de contração: equipe interna ou equipe externa (birôs de teste)

Equipe Interna
Fica alocada dentro da empresa contratante e utiliza todo o ambiente da mesma. Exsitem alguns benefícios em ter uma equipe interna:
  •  Disponibilidade de recursos contratados
  •  Fácil gerenciamento de testes
  •  Controle direto sobre o projeto
  •  Fácil comunicação com o cliente
  •  Conhecimento fácil de ser adquirido

Equipe Externa
Fica alocada dentro da contratada, prestando serviços remotos. Isso acarreta em maior custo para a contratada em termos de ambiente de teste, que por sua vez diminui os custos de ambiente da contratante.
Essa forma de contratação se não for muito bem gerenciada pode fazer com que as restrições de projeto não sejam cumpridas.
Se a equipe de testes não tiver conhecimento total sobre o negócio do cliente que contratou os serviços, o projeto pode ter um aumento significativo de demanda e tempo, elevando assim os custos do projeto.

O que vejo um pouco são empresas "vendendo pessoas" sem que exista um escopo de trabalho bem definido. Quando vamos prestar serviço para uma contratante, percebemos que existem diversas falhar no processo como um todo, mas nem sempre é possível melhorar algo devido a demanda e devido a própria burocracia do cliente.

Eu tenho três cases de trabalho de terceirização, dois em testes manuais e um em automatizado:

Empresa X
Ambiente organizacional muito bem definido e político. Serviço parte dentro da contratada e parte na contratante. Entramos na Empresa X sem o cliente (nível mais baixo do sistema) saber que estavamos ali para ajudar e testar suas aplicações. Resultado: não colaboração do cliente.
Isso dificultava muito o trabalho, pois tinhamos que sair atrás de tudo quando era coisa pra poder prestar um serviço razoável. O sucesso do projeto era diretamente proporcional a senioridade dos profissionais de Teste.

Empresa Y
Ambimente organizacional muito bem definido e político. Serviço parte dentro da contratada e parte na contratante. O cliente era um grande colaborador e tinhamos mais uma empresa prestando serviços de teste (uma grande empresa azul). No início eu fiquei me perguntando o porquê de duas empresas de teste, mas após alguns dias eu vi que a outra empresa possuia muito conhecimento de negócio, mas que não tinha um lado técnico muito forte. O trabalho em conjunto foi ótimo. O próprio cliente cobrava das duas contratadas a qualidade do serviço e "corria atrás" de qualquer empecilho político, deixando as duas empresas livres para executar suas atividades.

Empresa Z
Ambiente organizacional tradicional. Projeto de Automação. Serviço na contratante. Este cliente preza pela qualidade dos seus produtos e vê a qualidade como um principal para o seu sucesso. Inicialmente queria automatizar tudo o que era possível, mas depois enxergou o que realmente agregava valor.
Um ponto muito interessante é que em automação, tu precisas de pequenos ajustes na aplicação (não mandatório) para que seja possível contornar ou solucionar alguns problemas em automatizar um funcionalidade.
Essa empresa analisava o pedido de alteração e executava, sem empecilhos nenhum, claro que com uma análise bem focada.

Bem, por enquanto era isso!
Crédito para minha professora de Pós Graduação em Teste de Software da Unieruo Wilsa Sette, que aborda este tema em uma de suas matérias.

Acompanhem também o blog QualidadeBR, que tratá um resumo dessa thread.

Abraços!

sábado, 27 de março de 2010

Tecnicas de Teste - Camilo Ribeiro

O meu amigo Camilo Ribeiro do blog The Bug Bang Theory fez uma apresentação sobre Técnicas de Teste, e o material é muito bom!!!

O Camilo é uma das poucas pessoas que conheço na área de Teste que conhece muito bem o lado da qualidade e o lado técnico, tornando-se assim um profissional completo.

Parabéns pela apresentação Camilo!

PS: Meu tempo depois de terminar o MBA ainda tá escasso por conta do projeto que estou atualmente. Logo logo postarei muitas coisas sobre Automação, Selenium e Testlink... :)

Selenium IDE 1.0.6 released!

Em menos de dois meses sai uma nova versão do Selenium IDE com pequenas modificações.
Um dos bugs mais visíveis, porém inofensivo era o de logar um erro de Xml Http Request no log da IDE sempre que um Caso de Teste era executado.
Issue #388 (reportada por mim) http://code.google.com/p/selenium/issues/detail?id=388

As demais issues corrigidas podem ser visualizadas em http://code.google.com/p/selenium/wiki/SeIDEReleaseNotes

Download do Selenium IDE: http://release.seleniumhq.org/selenium-ide/1.0.6/selenium-ide-1.0.6.xpi

    segunda-feira, 22 de março de 2010

    CInTeQ 2010 - Test Automation

    Olá pessoal!
    Hoje participei do treinamento no CInTeQ 2010 com a Dorothy Graham e gostaria de passar pra vocês minha experiência em ter participado deste treinamento.


    O início
    Cheguei bem mais cedo do que estava previsto (as 8:00 e o curso iniciaria as 09:30), mas até aí tudo bem. Desci e tomei um café. Quando a sala estava disponível entrei e me deparei com uma senhora com aparência de vovó (daquelas que dá vontade de apertar os bochechas) sentada. Logo o meu raciocínio lógico e a apurado me diz: essa é a Dorothy.


    Objetivos do treinamento
    O treinamento, basicamente, segue essa ordem (mas no nosso curso ela fez uma ordem diferente do material que recebemos, diz ela que com o intuito de experimentar para ver se o entendimento fica melhor):
    1. Planejando e Gerenciando a Automação de Teste
    2. Técnicas de Desenvolvimento
    3. Arquitetura de Testes Automatizados
    4. Pré e Pós processamento
    5. Comparação da Automação (resultados)
    6. Recomendações e Direções
    Planejando e Gerenciando a Automação de Teste
    Foram colocados alguns pontos  interessantes nessa primeira parte.
    • A Automação é um projeto (com todos as fases), e ainda é um projeto de desenvolvimento
    • Que ele precisa de objetivos bem definidos para ser desenvolvido
    São objetivos da Automação de Teste
    • Executar testes tediosos ou difíceis de serem executados manualmente
    • Executar Testes de Regressão com maior frequencia
    • Garantir a repetibilidade dos Testes Regressivos
    • Ter o ROI (Retorno de Investimento) em não mais do que 6 interações de teste
    Não são objetivos da Automação de Teste
    • Melhorar os testes
    • Reduzir a equipe
    • Reduzir o tempo e custo para arquitetar os testes
    • Automatizar todos os testes
    As Métricas úteis para a Automação de Teste são aquelas que dão suporte a uma efetiva análise e decisão, e que são fáceis de coletar.
    Dentro das Métricas de Automação de Teste, podemos citar
    • Esforço para automatizar e executar os testes automatizados
    • Esforço para desenvolver um novo teste automatizado
    • Esforço para analisar as falhas
    • Tempo para executar os testes automatizados x testes manuais
    A recomendação de métricas é a seguinte:
    • Não medir tudo!
    • Escolher três ou quatro métricas
    • Coletar e monitoras as métricas por alguns meses
    • Trocar a métrica se ela não fazer mais sentido

    Sempre que quisermos aplicar a Automação de Testes pela primeira vez, devemos escolher um Projeto Piloto. Devemos lembrar que esse projeto deve:
    • Ser pequeno: de 3 a 6 meses e possuir de 3 a 6 pessoas (não é mandatório)
    • Não crítico: que não ponha em risco a entrega do projeto
    E como um resumo deste item:
    • Conhecer os seus reais objetivos para a Automação de Teste
    • Medir o que é importante pra você e sua empresa
    • Utilizar de Projetos Pilotos para iniciar com sucesso a Automação de Teste
    • Atribuir responsabilidades para a Automação

    Técnicas de Desenvolvimento (Scripting Techniques)
    As Técnicas de Desenvolvimento de Testes Automatizado tem como objetivos:
    • Reduzir custos
    • Ter um bom ROI (Retorno de Investimento)
    • Aumentar a capacidade dos testes
    • Evitar os custos excessivos de manutenção
    Existem diversas técnicas de Desenvolvimento de Testes Automatizados, as apresentadas foram:

    Linear
    O famoso "Record and Playback" (gravar e executar). Ele é rápido de criar mais difícil de manter.
    Pode trazer diversas ações duplicadas, que poderiam ser reaproveitadas

    Estruturada
    Utiliza-se da reutilização de scripts, criando assim uma biblioteca com as ações mais comuns automatizadas e executadas no sistema-alvo (SUT). Reduz custos de manutenção e geração de testes.

    Data Driven (Orientada a dados)
    São scripts voltado para a massa de dados do teste onde os dados de testes são extraídos dos scripts e colocados em algum local (data source). O controle do script (execução) é feita pela leitura destes arquivos e esta técnica reduz custos de desenvolvimento do scripts, uma vez que os testadores podem criar os data sources.

    Keywords (Palavras Chave)
    São scripts de controle de onde extraímos as instruções mais comuns em alto nível onde colocamos a definição destes scripts em uma linguagem de usuário (requisitos), podendo ser utilizadas em todos os níveis de teste (unitário, teste e aceitação)

    Como resumo deste item temos:
    • Uma boa técnica aplicada a nossa realizada reduz custos de manutenção
    • A técnica de keyword é a mais sofisticada atualmente

    Arquitetura de Testes Automatizados
    A arquitetura é um fator crítico de sucesso para a automação que deve ser separado da visualização que os testadores tem e que devemos separar os testes da ferramenta.
    Na arquitetura devemos pensar nos itens de Testware, como:
    • Dados do teste
    • Resultados esperados
    • Resultados obtidos
    • Logs
    • Scritps
    • Documentos
    • Utilitários
    • etc... (existe uma série de outros itens de testware)
    Os benefícios de criar uma boa Arquitetura para a Automação de Testes são:
    • As ferramentas podem assumir o conhecimento
    • Podemos automatizar mais atividades/tarefas
    • Portabilidade dos testes
    • Baixa curva de aprendizado
     Como resumo deste item temos:
    • Precisamos de padrões de configuração para tornar a automação mais eficiente
    • Testware
    • Criar um boa arquitetura a fim de reutilizar ao máximo os testes

    Pré e Pós Processamento
    O pré-processamento são todas as atividades iniciais antes de iniciar efetivamente a automação, como a criação dos diretórios, carregamento de dados, etc...

    O pós-processamento são todas as atividades quando o script termina sua execução, como a remoção dos arquivos temporários que não serão mais utilizados, remoção dos dados, etc..

    Durante o processamento dos testes e sua execução devemos fornecer o status do teste.
    A ferramenta não pode ter a certeza que os testes realmente passaram, a ferramenta apenas faz uma suposição se os resultados estiverem dentro do esperado.
    O que nós devemos fazer é sempre analisar o resultado obtido da ferramenta e comparar com os resultados esperados.

    Comparação da Automação (resultados)
    Existem diversos tipos de comparação de resultados da Automação de Teste e diferente forma de faze-los. Padrões para a comparação de resultados nos dá ganhos de eficiência e efetividade.
    Existem dois tipos de comparações: as dinâmicas e as de pós-execução.

    Comparações dinâmicas:
    • Executadas durante a execução dos testes
    • Executadas pela ferramenta de teste
    • Informações de falha são geralmente gravadas em log.
    Comparações de pós-execução:
    • Executadas depois que a execução de teste termina
    • Muito bom para comparar arquivos ou bases de dados
    • Pode ser separado da execução de teste
    • Pode ter diferentes níveis de comparação

    Recomendações e Direções
    Basicamente foi uma resumo de toda a apresentação, onde podemos citar os seguintes pontos:
    • Criar scritps usáveis e reutilizáveis
    • Selecionar bons candidatos para a automação
      • que podem ser executados diversas vezes
      • demorados para executar manualmente
      • difíceis de executar manualmente
    • Começar o Projeto Piloto com poucos testes automatizados (10 a 20 testes)
    • Executar a automação em uma versão estável do software
    • Executar a automação em uma versão não estável do software, a fim de estudar seu comportamento e impacto
    • Medir sempre e criar estratégias para reportar os resultados (ROI)
    • Criar padrões para a automação
    • Separar a Arquitetura de Automação de Teste em níveis de abstração

    A Dorothy tem uma excelente didática, além de dar diversos exemplos de estudo de casos. O interessante é que ela apresentou estudos de casos reais que não deram certo e o porquê de eles não terem dado certo.

    Tivemos exercícios de fixação do conteúdo, como responder quais eram objetivos aceitáveis para a automação de teste e quais não eram e no final do dia tivemos um joginho para descontrair e aprender um pouco mais sobre automação.

    Links
    Site do CInTeQ 2010: http://www.cinteq.com.br/
    Site da Dorothy Graham: http://www.dorothygraham.co.uk/

    Para ver a cobertura completa do CInTeQ 2010, acesse o blog QualidadeBR do Fabrício Ferrari

    Abraços!