Os Desafios de Iniciar um Projeto de Testes

Sempre que um projeto inicia, especialmente quando se trata de um relacionamento com um novo cliente, ele traz consigo uma série de reponsabilidades, afinal, este é o momento onde você está “vendendo o seu peixe” e precisa mostrar a que veio. Ora, se você está sendo contratado, é porque o cliente provavelmente não tem o conhecimento necessário dentro dos seus domínios para executar determinado trabalho e precisa que alguém o faça. Quando se fala em projetos de teste de software, especificamente com times distribuídos em diferentes países, as responsabilidades são ainda maiores.

Há diversas questões envolvidas, desde processos até a própria cultura da organização, passando, é claro, pelas pessoas. Ah, as pessoas... Por que precisamos lidar com elas em TI? Bem, este é o mundo. E se você é líder ou gerente de projetos, precisa saber lidar com gente, não tem jeito.

A partir de algumas experiências próprias, eu resolvi listar a seguir, sem comprometimentos didático-acadêmicos, algumas situações que normalmente enfrentamos quando precisamos iniciar um novo projeto internacional na área de teste de software, mas creio que a maioria dos itens pode servir para qualquer tipo de projeto, já que contemplam ações comuns ao dia-a-dia dessas atividades. É claro que cada projeto apresenta particularidades e alguns dos itens a seguir podem não fazer parte da sua realidade, mas creio que há mais coisas em comum do que distintas.

O Desafio

Lembram quando, na faculdade, os orientadores do trabalho de conclusão diziam que toda pesquisa parte de um problema? Ou seja, para que algo seja respondido, é preciso que exista o problema de pesquisa em si. Um projeto quase sempre inicia com um desafio, para o qual você é contratado para resolver ou fazer parte da solução. Vamos supor que a sua missão neste caso seja “montar um time offshore responsável pela execução de testes de regressão automatizados”.  Este é o começo de tudo. Provavelmente a empresa negociou um contrato com o cliente e esta é a proposta de trabalho, que partiu das necessidades dele. Você e sua equipe são as pessoas que irão executar esse serviço. Só com isso acertado é que as coisas começam, normalmente.

É também neste momento que você vai saber qual é o perfil do time que o cliente deseja, quanto ele vai pagar, quantas pessoas estarão envolvidas, enfim, a parte comercial da coisa toda. Pode ser que as pessoas já trabalhem na empresa e apenas sejam movidas para o seu projeto ou então exista a necessidade de contratação de novos profissionais. Se este último for o caso, adicione o processo de recrutamento e seleção na sua lista (você provavelmente será envolvido nele em algum momento).

O Início

Superadas as tratativas acima, chega a hora de operacionalizar o projeto, dar o pontapé inicial, o famoso kick-off. Quase sempre o início é uma fase meio “nebulosa”, onde você está recém conhecendo e se familiarizando com o que está por vir. Quando se tratar de um projeto internacional, as distâncias acentuam algumas dificuldades. Então tenha em mente que:

• As informações disponíveis ainda são escassas: como é o começo, é natural que muita coisa ainda precise ser descoberta. Ter habilidade em buscar essas informações certamente ajudará bastante, mas você provavelmente só vai ter o que precisa com o passar do tempo;

• A interação com times estrangeiros ainda é superficial: se você trabalhar com pessoas que estejam em outro país, as interações iniciais com elas normalmente são pontuais, mas vão aumentando com o tempo. Você pode ter algumas semanas junto a elas na sede do cliente, então procure saber com quem você irá trabalhar para poder estreitar esse relacionamento quando chegar a hora;

• Seu time pode não estar completo ainda: se você estiver em fase de montagem do time, é bom considerar que isso pode limitar suas atividades iniciais. Um bom planejamento de seleção evitará uma demora excessiva em trazer novos membros para a sua equipe;

• A infraestrutura ainda não está finalizada: perfeitamente normal. Afinal de contas, você pode não ter todo o time disponível para começar o trabalho. Sendo assim, itens como acessos a redes e bancos de dados, computadores, ferramentas, etc. ainda carecem de configuração;

• Treinamentos Internos: caso exista necessidade, você pode ter de treinar os novos membros do time nas ferramentas que serão utilizadas. O ideal é que isso seja feito o quanto antes;

• Viagens fazem parte do trabalho: em projetos internacionais que estão iniciando, você precisará passar algum tempo nas dependências do cliente para poder operacionalizar todo o processo. Esteja com a documentação em dia ou providencie passaporte e visto (se preciso) o quanto antes. O mesmo vale para o caso de mais pessoas irem com você;

• Outro país, outra cultura: lembre-se de que as coisas podem ser diferentes do lugar onde você mora. Sendo um país estrangeiro, tenha em mente regras básicas que ajudem a evitar gafes, se localizar, se comportar, etc. Isso pode fazer uma grande diferença na imagem que você vai passar para o cliente. E é justamente essa diversidade que é uma das partes mais fascinantes de se trabalhar nesse tipo de projeto. É um aprendizado único e cativante. Saiba aproveitar.

Ambientação

 

Depois que você “quebra o gelo” e começa efetivamente a planejar na prática o seu objetivo inicial, vem a etapa de imersão no mundo do cliente, onde você precisa absorver e descobrir todas as informações possíveis para depois poder aplicar no seu trabalho. Em linhas gerais, é hora de:

• Entender o negócio do cliente: parte fundamental do trabalho de um profissional de testes ou de desenvolvimento. Mesmo que seja complexo, ter um bom entendimento do negócio do cliente ajudará muito no trabalho de consultoria e na criação e execução de testes ou na codificação de programas. Para alguns clientes, inclusive, pode ser tão ou mais importante do que suas habilidades técnicas. Portanto, aprenda, tente compreender as regras de negócio envolvidas. Se possível, esteja próximo de alguém do time de business. Essa pessoa será uma ótima fonte de informação neste momento;

• Conhecer os sistemas e suas atribuições: é nesse ponto que você conhece a prática do negócio do cliente e também quais sistemas você irá testar ou dar manutenção. Treinamentos internos normalmente são necessários e são conduzidos por pessoas da área de business. Caso parte do time esteja em outro país, podem ser feitos de maneira remota, via videoconferência. Atenção aqui é fundamental, pois ajudará a desbravar os “caminhos” de cada aplicação envolvida;

• Estudar os processos atuais de testes e desenvolvimento e metodologias utilizadas: Normalmente o cliente já segue algum tipo de processo. Você poderá ou não sugerir ou implantar alguma melhoria. Mas sempre leve em conta que um processo ou metodologia deve ser uma ferramenta para auxiliar o seu trabalho e não uma filosofia de vida. Não se apegue demais a um conceito específico e procure focar na melhor solução para o cliente, pois você pode encontrar um ambiente que não seja tão favorável a mudanças radicais. Antes de sugerir algo, entenda primeiro o funcionamento atual das coisas. Lembre-se de que a melhor metodologia é o trabalho bem feito;

• Verificar quais ferramentas são usadas: podem ocorrer dois casos distintos: um onde o cliente já tenha ferramentas em uso e outro onde ainda não há nenhuma. O primeiro caso ocorre em processos já em andamento, mas que podem precisar de melhorias. O segundo é mais comum quando nem processo existe e você irá trabalhar nas definições dos mesmos. No caso de processo existente, o mais normal é você trabalhar com as ferramentas já conhecidas. Em muitos casos a equipe já é contratada pensando neste quesito. Se não há ferramenta, você pode sugerir alguma. E aí leve em conta o custo-benefício. Nem sempre uma ferramenta “free” significa um custo menor em relação a uma paga. Se o setup dela for muito complexo e sua utilização exigir mais habilidades dos membros do time, você terá um custo de especialização (leia-se salários) que poderá, no longo prazo, ultrapassar os custos dos salários e das licenças de uma ferramenta paga. Preste bem atenção a isso. Analise as intenções do cliente e faça os cálculos para trabalhar com a ferramenta certa;

•  Identificar as áreas onde o seu time irá trabalhar: conhecendo os sistemas, você precisa saber em quais efetivamente terá de atuar. Isso é o cliente quem vai dizer, de acordo com as necessidades de cobertura de teste ou desenvolvimento que ele tem.

Consultoria

É o momento onde você efetivamente passar a dar a sua contribuição para o projeto, identificando pontos de melhoria ou definindo padrões a serem usados. É a materialização da soma dos esforços feitos nas etapas anteriores. A sua experiência com projetos anteriores e as boas práticas já utilizadas valem muito neste estágio dos trabalhos. A quantidade de tarefas pode variar, mas há algumas mínimas que quase sempre aparecem:

• Desenho do processo: quando já há um processo com fluxo definido, o mais provável é que você tenha de segui-lo. No caso de haver possibilidade de inserções de melhorias ou então de não haver processo definido, seu trabalho será bem maior. Em comum acordo com o cliente, defina etapas ou ciclos, tempos, pessoal envolvido, mitigação de problemas, fluxo das atividades e critérios de entrada e saída. O processo também precisa ser replicável no futuro, de forma contínua. Deixe espaço para melhorias, afinal, o processo deve ser visto como um organismo vivo e dinâmico, que pode (e deve) evoluir constantemente;

• Definição dos padrões do projeto: a parte mais “braçal” e minuciosa do trabalho, mas uma das mais importantes. Você também pode aproveitar o que já existir, mas, caso não exista nada, terá de definir detalhadamente os padrões de nomenclatura (de testes, de objetos, etc.), tipos possíveis de defeitos, níveis de severidade e criticidade, padrões de código, tipos de status de criação e execução de testes, entre outros. Isso será utilizado pelo seu time ou por outros times, então desenvolva padrões que sejam claros e fáceis de serem seguidos. A utilização de padrões comuns em vários projetos ajuda em pontos como manutenção, rapidez de desenvolvimento e revisão. Uma boa prática, no caso das revisões, é criar um checklist com os itens que devem ser observados;

• Identificação dos cenários de testes para futura seleção do escopo: se você for trabalhar em um projeto de release única ou de várias, sempre precisará saber o que deverá entregar.  Selecione, juntamente com o cliente, uma gama de possíveis cenários de testes a serem escritos ou automatizados, dentro das áreas que você definiu anteriormente. Comprometa-se apenas com aquilo que pode entregar, mas tente sempre surpreender positivamente;

• Ouvir: pode não ser exatamente uma etapa, mas a parte mais importante de um trabalho de consultoria, e que está presente durante todo o tempo, é justamente saber ouvir. Dizem que não é à toa que temos dois ouvidos e apenas uma boca. Saiba utilizar isso. Faça suas propostas, busque a excelência, mas evite “bater o pé” com convicções exageradas. Em muitas vezes, você precisa abrir mão de algumas dessas convicções acadêmicas ou teóricas em detrimento ao bom senso, para que os objetivos sejam atingidos. É assim no mundo real dos projetos. Você não pode deixar de entregar um módulo do sistema que seja de suma importância apenas porque o código não está bonito. É um exemplo extremo, mas ilustrativo. Não há espaço para teimosias sem sentido quando há dinheiro em jogo, especialmente o dinheiro do cliente. Negocie o escopo e prazos se necessário, mas sempre procure entender o lado de quem precisa dos resultados do seu trabalho. Além disso, é ouvindo que você consegue aprender mais sobre o que está fazendo e é como você consegue obter a maioria das informações de que precisa. Saber ouvir, basicamente, é o que diferencia um bom consultor dos demais;

• Criação do documento de Test Strategy: aqui está o output de todo o planejamento que você fez, juntamente com seu time e com o cliente. Este documento é o guia que mostra, formalmente, como tudo no projeto vai funcionar: quem faz o quê, quais são os riscos, os padrões e tudo mais. É a primeira entrega formal a ser feita como esforço do seu trabalho. Quanto mais claro, melhor. Quer saber como fazer um bom documento de Test Strategy? Clique aqui.

Execução

Após todo o planejamento e definições feitas, chega a hora de colocar a “mão na massa” e começar a produzir resultados tangíveis. A operação, em geral, pode ser simples se tudo estiver corretamente definido e você seguir corretamente aquilo que planejou na etapa anterior. Mas o ponto principal será a qualidade com que você vai fazer a entrega projetada. Uma boa prática para validar o processo é criar uma simulação antes da release propriamente dita. A fase de execução pode conter:

• Estratégia: embora esteja traçada no documento de Test Strategy, é sempre bom ter uma versão revisada deste ponto antes de começar as atividades ou, ao menos, para servir como lembrança para a equipe daquilo que se pretende atingir;

• Time treinado e ambientado: assume-se que, neste estágio, o time de testes já tenha conhecimento das ferramentas que serão utilizadas e dos sistemas que serão testados, bem como um conhecimento a respeito das regras de negócio, fundamentais para a criação dos testes ou scripts automatizados;

• Definição do escopo: liste aqui a posição final em relação aos módulos ou scripts que você pretende entregar. A partir deste ponto, não há mais espaço para mudanças, portanto cerifique-se de que irá trabalhar em cima de um range realista de tarefas e entregas;

• Criação (testes, código): Oba, agora a coisa começa a ficar visível! Dentro do tempo definido para isso, trabalhe na criação dos testes ou scripts, respeitando os padrões que foram estabelecidos anteriormente. Revise (peer review é uma boa prática) aquilo que foi criado antes de considerar como versão final. Não se esqueça de montar o suíte de testes antes da execução, para que fique demonstrado visualmente e todos saibam o que será coberto pelos testes;

• Execução: com os testes construídos, é hora de executá-los. É importante manter um histórico das execuções, com os tempos, testes que passaram, falharam ou que não foram executados. Esses dados serão usados mais adiante quando forem reportadas as métricas. O processo precisa permitir que essas informações sejam guardadas de modo a serem acessadas no futuro, de preferência separadas por release;

• Cadastro de Defeitos: durante a execução, os defeitos encontrados devem ser cadastrados na ferramenta apropriada. Certifique-se de que cada defeito respeita os padrões e que está endereçado para a pessoa certa, que irá trabalhar na resolução do mesmo. Procure pedir algum retorno caso haja demora na solução;

• Relatórios de Métricas: ciclo terminado, é hora de contar a história da execução. O relatório de métricas deve fazer exatamente isso: mostrar como as coisas aconteceram, com números, claro, mas também com significado. Um número contextualizado fornece uma informação melhor do que apenas o valor “cru”. Use a criatividade ao apresentar os resultados, buscando fazer dessa informação um instrumento que auxilie os tomadores de decisão. Falconi já dizia que só aquilo que pode ser medido é que pode ser melhorado. É exatamente para isso que as métricas servem: para melhorar o processo e os sistemas, saber onde estão os gargalos, as maiores incidências de defeitos, mostrar o desempenho da aplicação, etc. Não use estas informações para servirem simplesmente como metas para a equipe. Você pode comprometer a qualidade do trabalho, criando competição em vez de colaboração;

• Aprovação do cliente: o famoso sign-off. Depois de todo o engajamento, planejamento, execução e apresentação dos resultados, chega a hora de o cliente dizer se aprovou ou não aquilo que foi entregue. Você vai descobrir se poderá ir adiante e trabalhar em outras releases ou projetos, ou se ficará pelo caminho. Uma grande expectativa paira sobre a equipe neste momento. Pode ser, inclusive, que seu emprego dependa disso, portanto, tenha ao menos a certeza de que tudo foi bem feito e que os resultados obtidos terão valor para o cliente. É a oportunidade única de estabelecer uma relação de longo prazo e este ponto é onde você será capaz de saber se isso será ou não possível. Capriche!

Maturação

Após estar estabelecido com sucesso, vem a fase de amadurecimento do projeto. É onde você começa a pensar em como as coisas podem ser melhores e também corrigir eventuais distorções. Aqui o funcionamento das coisas vai ficando mais natural para todos e se pode vislumbrar o futuro das atividades. Para isso, é preciso:

• Ajustes: todo motor precisa de revisão de tempos em tempos para que possa aumentar sua vida útil. Com um processo não é diferente. Depois de estar em operação pela primeira vez (e até bem depois disso), é adequado que ele passe por pequenos ajustes, seja de padrões que faltaram ou estão sobrando, correções no fluxo, troca de papéis e responsabilidades, etc.;

• Organização da documentação: documentação deficiente ou a falta dela são problemas comuns no universo dos projetos. Mantenha a sua documentação sempre organizada, se possível faça com que todos tenham acesso e compartilhem as alterações feitas. Os documentos do início de projeto são importantes e precisam ser mantidos, assim como os novos que estão sendo gerados a cada release;

•  Estabelecimento da rede de contatos: a primeira interação com o time já deve ter dado uma ideia de quem é responsável pelo quê e como você pode acessar essas pessoas. Se essa rede ainda não estiver clara, não se assuste.  Em muitos casos, novas situações exigirão novos contatos. Sua rede pode crescer sempre. Apenas cuide para que os contatos principais estejam na sua lista. E mantenha o relacionamento com essas pessoas o mais frequente possível. Isso faz uma diferença grande em termos de confiança percebida;

• Replicar o que foi feito com sucesso nas releases seguintes: parece óbvio, mas sempre tem gente disposta a reinventar a roda. Não tente elaborar uma forma de procedimento diferente a cada release. Se um padrão de processo foi definido, faça ajustes, mas não tente algo novo a cada interação. Além de passar uma impressão de que você não tem certeza do que está fazendo, isso custará muito tempo de setup;

• Revisar e melhorar o processo sempre que possível: mesmo tendo citado indiretamente em itens anteriores, nunca é demais lembrar que um processo deve ser encarado pela lógica Darwiniana, ou seja, algo que se modifica com a necessidade e se adapta às novas situações cotidianas. Quando você notar que há espaço para uma melhoria significativa, não hesite em sugerir ou aplicar as mudanças cabíveis. A eficiência vem daí.

Trabalhar com projetos internacionais, sejam de testes ou não, ainda tem diversos outros pormenores. Como já colocado, um nunca será igual ao outro e as variáveis são quase infinitas. Como dica final, há alguns pontos adicionais que eu considero relevantes:

Coisas com as quais que você precisa lidar

• Distância: trabalhar com equipes distribuídas é sempre um desafio. Se você tem a oportunidade de viajar com frequência, mantendo um contato mais próximo, excelente. Caso contrário, minimize os efeitos dos quilômetros usando todos os recursos de comunicação possíveis. Hoje em dia, isso é bem mais fácil. Tente não ficar apenas no virtual, utilize videoconferências ou reuniões por telefone com maior frequência. Faça-se presente, mesmo distante;

• Cultura: além da questão de saber “se virar” em outro país, como já mencionado, é muito produtivo você ter “jogo de cintura” para lidar com formas de pensar diferentes da sua. Informe-se a respeito disso para evitar problemas de comunicação. Dizer “o que você fez está tudo errado” pode ter interpretações diferentes, dependendo de quem está falando. Para alguns pode soar ofensivo, para outros é apenas dia-a-dia de trabalho. Atente para essas particularidades;

• Fuso horário: este pode ser um grande desafio, dependendo de onde as pessoas do time estão. Fazer reuniões com diferença de uma hora do fuso horário é uma coisa. Fazer o mesmo com doze horas de diferença é outra. Muitas empresas pensam nisso ao contratar algum tipo de serviço, justamente porque está muito ligado à produtividade. Mas, em muitos casos, há períodos de tempo onde os times estão em sincronia. Aproveite isso ao máximo, marcando reuniões importantes para estes horários, assim todos podem participar;

• Ambiente e segurança: Considere que há políticas rígidas de segurança da informação e acesso a determinados ambientes ou sistemas em muitos lugares. Pode ser um fator determinante no momento de se validar um build ou acessar um banco de dados. Esteja informado acerca das políticas de confidencialidade que porventura existam. Elas estão ali justamente para indicar até onde você pode ir;

• Prazos de entrega: como em todo projeto, o prazo é quase sempre o vilão do trinômio. Saiba que você poderá ter de trabalhar com prazos mais ou menos apertados e, para isso, um bom plano de contingência ajuda. Organize seu trabalho de forma a terminar no prazo (ou antes), mas tenha um plano reserva caso adversidades apareçam e estabeleça isso com o cliente de forma transparente;

• Comunicação: além de comportar os itens de distância, fuso horário e cultura, a comunicação tem outros detalhes que influenciam diretamente no andamento das atividades. A frequência com que a comunicação é realizada, os meios como ela é transmitida e as abordagens usadas para cada tipo de comunicação podem fazer a diferença. Entenda que também pode haver ruídos que precisam ser trabalhados e a melhor forma para isso é manter tudo o mais claro possível e dentro de um espaço de tempo que não atrase os trabalhos. Use sempre a informação mais atualizada e dissemine-a aos interessados. Saiba como o cliente prefere que você reporte os dados de que ele precisa e de que todos estão recebendo as informações no tempo certo;

• Expectativas do cliente: um erro comum é tentarmos adivinhar o que o cliente quer. Evite achismos mantendo um diálogo permanente e procurando entender o que deve ser entregue. Dizem que, num projeto, a melhor surpresa é não haver surpresas. Para minimizar frustações e evitar aumento de custos, mantenha o seu trabalho e sua comunicação sempre alinhados com a expectativa do cliente;

Coisas que podem ajudar você

• Paixão: elemento primordial para ter sucesso. Se você não faz o que gosta, procure ao menos gostar do que faz. Parecem duas frases iguais, mas há uma grande diferença entre elas. Quanto você coloca paixão no seu trabalho, as coisas andam com mais tranquilidade e seus objetivos ficam mais claros até para você;

• Conhecimentos de testes: óbvio! Se você está trabalhando com um projeto de testes, é mais do que esperado que já possua um conhecimento no assunto. E isso nunca é demais. Quanto maior for sua vivência e experiência neste mercado, mais contribuições você tende a oferecer. Procure trazer pessoas especializadas para o seu time. Muitas empresas acham que qualquer um pode executar tarefas de teste, o que é um engano. Formação e carreira têm muito valor nessa área e o profissional de testes precisa ser valorizado;

• Automação: cada vez mais presente no mercado, a automação, antes usada apenas em ambientes de regressão, tem feito parte de outras fases dos projetos de testes. Não sei se isso é certo ou não, afinal sabe-se que há um custo-benefício envolvido que deveria ser calculado, mas o fato é que tais conhecimentos são sempre úteis, independente da ferramenta que está sendo utilizada. Estes conceitos podem representar um diferencial na sua carreira. Se ainda não sabe sobre automação, aprenda.

• Inglês: projetos internacionais normalmente tem o inglês como idioma oficial, mesmo quando há pessoas envolvidas em países que originalmente não falam a língua. Portanto, já passou da hora de os profissionais de TI que almejam carreira internacional aprenderem inglês. Outros idiomas podem complementar, mas inglês é o mínimo necessário para qualquer atividade desse tipo;

• Error Guessing: como profissional de testes, você precisa ser bom em encontrar defeitos. Por mais que alguns relutem ou inventem nomes rebuscados para as atividades, o cerne do nosso trabalho ainda é encontrar erros. Quanto melhor você for nisso, mais valor irá trazer para o cliente. Isso, claro, se a atividade for percebida dessa forma. Não há receita para isso, mas experiência, curiosidade e técnica são facilitadores;

• Ser proativo: clientes estrangeiros, especialmente os dos EUA, gostam bastante de profissionais proativos e que vão além das suas tarefas diárias. Saber fazer e deixar isso claro é importante, mas antecipar problemas ou situações não previstas, tomar a frente em tarefas de liderança ou organização são itens bem vistos aos olhos americanos, por exemplo.  Contribuir com algo mais é quase um dever e pode lhe dar uma visibilidade muito interessante frete a novas oportunidades;

• Negociação e Flexibilidade: assim como saber ouvir, saber negociar e ser flexível a possíveis mudanças demonstra um envolvimento com o cliente e passa confiança a ele quanto ao seu trabalho. Em caso de mudanças bruscas necessárias, converse com o cliente, sincronize as expectativas, informe sobre riscos, mas sempre procure ajudar;

• Ter um bom time trabalhando com você: ninguém trabalha sozinho, portanto tenha com você um time de pessoas comprometidas e competentes.  Busque agir de forma motivadora e colaborativa e estimule isso na equipe. Faça com que todos percebam a importância do trabalho coletivo, afinal, todos ganham ou perdem juntos. Ter um time do qual você tem orgulho de fazer parte não tem preço. E quando isso consegue se traduzir em conquistas e oportunidades, é bom para todos, inclusive para a sua empresa e para o cliente. 

Nunca é demais ressaltar que as dicas aqui mencionadas nem sempre podem representar a realidade de todos os projetos. Sendo assim, aproveite aquelas que possam ajuda-lo no seu trabalho e construa as bases daquilo que é distinto em relação ao seu caso. Lembre-se de que é um exercício diário que trás reponsabilidades, mas que pode render grandes frutos em termos profissionais. O maior legado que fica é que, à medida que vai enfrentando situações como essa, você enriquece sua mente e aumenta seu conhecimento. Isso nuca tem fim e é assim que se amadurece como profissional. Boa sorte!

Leia Mais

QTP Tips: Repositório de Objetos Global x Local

Para as pessoas da área de testes que usam o QTP (QuickTest Professional) como ferramenta para a criação de testes automatizados, certamente esta é uma questão recorrente, em especial quando se está iniciando um novo projeto ou um suite de regressão para uma aplicação existente.

Afinal, o que é melhor? Utilizar um repositório de objetos global, onde todos os scripts vão compartilhar os mesmos objetos ou deixar um repositório sendo utilizado localmente, para cada script criado?

O uso de um repositório local pode parecer mais fácil, especialmente se você estiver desenvolvendo seu script através da função Record/Playback. Você clica no botão de gravar, segue os passos definidos na aplicação e, ao final, todos os objetos com os quais você interagiu estarão gravados no repositório daquele script. Grosso modo, bastaria clicar no play para que o QTP executasse automaticamente as mesmas ações gravadas previamente. Sua única preocupação seria ajeitar o código VBScript gerado, parametrizar algumas entradas e pronto: utilizar o script sempre que precisar.

Conheço muita gente que utiliza a ferramenta dessa forma. Mas, a meu ver, há dois problemas com esse tipo de abordagem que podem aparecer individualmente ou simultaneamente, dependendo de como estiver o seu projeto:

1 - Manutenção: a menos que exista apenas um script interagindo naquela aplicação, haverá um grande trabalho com a manutenção dos objetos. E é bem fácil entender por que: à medida que o suite vai crescendo e dezenas de scripts passam pelas mesmas telas, qualquer mudança em um objeto em comum ou nas suas propriedades significa cada um dessas dezenas de scripts terá de ser acessado para que sejam feitas as mudanças necessárias nos seus repositórios de objetos locais. Especialmente em aplicações web, é comum os desenvolvedores alterarem características de objetos em uma página ou formulário. Imagine que uma dropdown utilizada em todos os seus scripts tenha mudado alguma propriedade usada na verificação? O QTP não vai reconhecer o novo objeto durante a execução a menos que este seja capturado de novo. E essa alteração teria de ser feita em todos os scripts, pois o objeto foi gravado uma vez em cada um deles. Isso certamente demandaria algumas horas de trabalho. Utilizar programmatic descriptions também não resolve, pois, embora essa técnica não precise de objetos físicos gravados no repositório, ela requer que as propriedades dos objetos que foram escolhidas para a validação não mudem. Se a página mudar, você não precisa alterar nos repositórios, mas terá de alterar o código VBScript de cada teste. Ou seja, dá na mesma, praticamente.

2 - Um repositório local pode jogar contra a organização do processo: com os mesmos objetos repetidos em vários lugares, fica difícil ter uma ideia do tamanho do repositório, da quantidade de objetos manipulados até de se estabelecer um padrão de nomenclatura ou classificação, por exemplo. Isso fica ainda mais difícil quando há várias pessoas envolvidas na criação dos scripts, pois elas podem seguir padrões distintos. E mesmo que um sistema de nomenclatura ou classificação exista e seja seguido por todos, ainda assim não se terá a visualização nem as características globais de todos os objetos. Também pode acontecer de as pessoas terem capturado objetos diferentes entre os scripts para uma mesma página da aplicação, pois cada uma delas interagiu com aquela tela de forma diferente.

Particularmente, considero que a abordagem de se ter um repositório global, compartilhado por todos os scripts, seja mais adequada. Ela tem algumas limitações, mas me parece melhor do que manter um repositório para cada script, desde que bem feita. Algumas coisas que eu pude notar com o tempo e que podem ajudar bastante:

Defina alguns padrões mínimos antes de tudo: É muito importante, antes de começar qualquer script ou capturar os objetos, estabelecer os padrões a serem utilizados. Há muitas formas de criar padrões e muitas opções de critérios. Eu diria que, no mínimo, deva-se considerar:

·      Local de armazenamento: A partir da versão 10, o Quality Center introduziu uma aba chamada “Test Resources”, onde podem ser criados e armazenados, por exemplo, bibliotecas de funções, recovery scenarios e repositórios de objetos. Você pode estabelecer uma estrutura de pastas internas e armazenas esses dados ali, diretamente no servidor. O QTP pode ser integrado ao Quality Center e aproveitar a mesma estrutura;

·      Padrões de nomenclatura dos objetos: os objetos ficam ordenados no repositório primeiramente por tipo. Portanto, todos os objetos de mesmo tipo ficarão agrupados um abaixo do outro ao se visualizar o repositório. Nem sempre os desenvolvedores se preocupam com algum sistema para nomear ou classificar os objetos ou então não há no projeto algo que considere isso. Vê-se de tudo nesses ambientes! Então, ter um padrão de nomenclatura facilita a identificação e utilização. Renomeie os objetos capturados para um padrão estabelecido, de preferência por tipo. Você pode até aproveitar o nome original, mas ponha um prefixo que identifique o seu tipo, ao menos. Por exemplo, use “img“ para imagens, “dpw” para dropdowns, “edt” para editboxes, etc. No caso de sistemas web, não se esqueça de estabelecer um padrão para nomear cada página armazenada também, pois elas serão como diretórios que conterão os demais objetos.

Capture todos os objetos antes de iniciar a criação dos scripts: Essa é uma parte importante do processo que vai gastar um tempo considerável no começo, mas que certamente irá economizar muito mais tempo lá na frente. Definidos local de armazenamento e padrões de nomenclatura, acesse a aplicação e utilize o QTP para capturar e renomear todos os objetos possíveis, não apenas aqueles que você acredita que irá precisar. Só depois que o repositório estiver com todos os objetos capturados, associe o script a ele. Assim, ao gravar os passos pelo QTP, a ferramenta já vai identificar e reconhecer os objetos do repositório (sem ficar adicionando-os como se fossem novos) e irá colocá-los no código VBScript automaticamente e da forma como você os definiu. Isso é muito útil especialmente em aplicações web, que possuem diversas páginas e as usam para separar os objetos. Uma vez feito isso, você só precisará adicionar novos objetos quando e se a aplicação mudar, o que é uma manutenção razoavelmente pequena.

Mantenha os objetos do tipo checkpoint localmente. Diferentemente dos demais tipos de objetos, os checkpoints só dizem respeito ao script que estão validando e, portanto, não faz sentido enviá-los para o repositório global. E, no caso de ser usado o controle de versão (QTP 10 ou superior), você não precisa ficar fazendo check-out/check-in do servidor cada vez que precisar atualizá-los. Basta abrir o objeto e alterar manualmente ou rodar o script em update mode, para que os novos valores sejam atualizados. Resumindo: ao final, haverá um repositório com todos os objetos interativos vindos do servidor (repositório global) e apenas os checkpoints do script corrente como objetos locais.

Como nem tudo é perfeito, e sempre algo pode sair diferente do que se espera, há algumas observações que considero importantes serem feitas para o bom funcionamento dessas dicas:

1 – Até a versão 9.2, quando ainda era uma ferramenta da Mercury, o QTP não mostrava os objetos tipo checkpoint no repositório. Você só conseguia editá-los se fosse direto ao código, clicasse com o botão direito em cima do nome do checkpoint e selecionasse a opção “checkpoint properties”. Se por acaso o seu checkpoint estivesse escrito em forma de variável parametrizada (utilizando-se a referência da data table em vez do nome), você simplesmente não teria como acessá-lo. A partir da versão 9.5 (já como produto da Hewlett-Packard), os checkpoints passaram a ser tratados como qualquer outro objeto, estando disponíveis no repositório, visualmente. Dessa forma, ficou muito mais fácil editá-los ou renomeá-los, bastando um click em cima deles para isso. Portanto, a utilização de alguns padrões mencionados antes pode depender muito da versão do QTP que você está utilizando.

2 – Uma coisa que notei é que a migração de versões pode causar certa incompatibilidade ao converter os repositórios de objetos. Uma vez migramos da versão 9.2 direto para a versão 10 (sem passar pela 9.5). Acontece que os repositórios criados na versão 9.2 não eram prontamente reconhecidos pela versão 10. Ao tentar gravar um script em uma página cujos objetos já estavam no repositório, o esperado era que o código VBScript utilizasse esses objetos. Mas o QTP sempre os adicionava localmente, como se fossem novos. Em alguns casos, o simples fato de editar o repositório e excluir e incluir um objeto novamente já fazia o QTP reconhecer normalmente os demais. Mas houve casos em que isso não funcionou. Daí o jeito foi gravar o código e editar manualmente cada objeto não reconhecido. É uma grande mão-de-obra, mas é necessário. Da versão 10 para a 11 isso não aconteceu mais.

3 – A versão 10 apresenta um bug no gerenciamento de alterações nos objetos locais de diferentes actions, quando feitas diretamente pela janela do repositório. Se você possui um script com mais de uma action e abre o repositório de objetos, notará que há uma dropdown onde é possível escolher a action cujos objetos devem ser mostrados. Suponha que o script esteja aberto na Action1. Abre-se a janela do repositório e, como padrão, a Action1, que estava sendo utilizada, aparece com seus objetos. Se por acaso a Action2 for selecionada na dropdown, for feita qualquer mudança em um checkpoint, por exemplo, e acionado o botão de salvar, essa alteração não fica gravada. Só funciona se for alterada a mesma action que estava sendo usada na tela do script. Se você quiser alterar alguma coisa nos objetos da Action2, deve fechar o repositório, voltar para a tela principal do script, selecionar a Action2 e só então abrir o repositório e alterar os objetos dela. O pior é que, no meu caso, só descobri isso depois de alterar dezenas de checkpoints. Por isso, preste atenção nesse detalhe se estiver usando a versão 10. A partir da 11 isso não acontece mais.

Essas dicas são oriundas da minha experiência com a ferramenta, espero que sejam úteis de alguma forma para quem trabalha com ela e que resolva algumas dúvidas que vocês tenham. São sugestões apenas, mas funcionaram bem no meu caso e creio que podem ser úteis para outras pessoas. Prometo que tentarei colocar mais algumas dicas aqui no blog referente à utilização do QTP como ferramenta de automação de testes. Fiquem ligados!

Leia Mais

Dicas Para Criar um Documento de Test Strategy

Que um projeto de software requer planejamento e definições claras, todo mundo sabe. O mesmo vale para a parte relativa aos testes do software. Assim como as demais, a fase de testes precisa estar bem organizada para evitar surpresas e comprometer qualquer um dos itens do trinômio do projeto (custo x escopo x tempo).

Quando se define uma estratégia de testes, deve-se colocá-la de forma explicita para os interessados (stakeholders) do projeto. E, para isso, existe um documento chamado Test Strategy, ou Estratégia de Testes. De acordo com a empresa e o processo vigente, esse documento pode ser também chamado de “Plano de Testes”, “Definição de Testes”, entre outros. Irei utilizar Test Strategy por ser de uso mais comum.

Tentarei, baseado em experiências anteriores, vividas ao longo da minha breve carreira, elencar uma série de pontos que considero importantes no estabelecimento de um documento desses. Indo direto ao ponto, cada empresa tem um processo interno de TI diferente e, por isso, alguns itens podem ou não ser relevantes, mas mencionarei aqueles que eu acho fundamentais, supondo que você precise desenhar um processo de testes desde o início.   

O Test Strategy funciona como um "desenho" do processo, sendo enviado às partes interessadas e, normalmente, necessitando de um approval antes de ser oficializado. É comum serem geradas algumas versões até que se chegue à definitiva. E mesmo esta ainda pode sofrer pequenos ajustes no decorrer da implantação do processo, uma vez que fatos novos ou não considerados antes podem surgir. 

Considero importante que o documento contenha, ao menos, as seções a seguir. Algumas podem estar ou não subdivididas, isso dependerá da preferência de quem escreve ou de formatos padrões que cada empresa adota para suas documentações. O mesmo vale para a ordem de apresentação de cada seção:

Capa

Parece óbvio dizer que um documento precisa de capa, mas ela é sua carta de apresentação. É através dela que os interessados irão identificar do que o documento se trata com exatidão. Em formato digital, o nome do arquivo também deve ser de fácil identificação. Uma boa capa apresenta:

- Título: nomenclatura usada para definir o documento (Test Plan, Test Strategy, Test Definitions, etc. e suas variantes em português);

- Nome/Logotipo/Timbre da Empresa: importante para identificar que se trata de um documento interno e de uso corporativo. Em algumas empresas, por exemplo, esse tipo de documento sequer é descartado e uma lixeira comum; há umas especiais só para eles, ou então são triturados para preservar a segurança das informações;

- Área/Sistema/Projeto: referência ao objeto do teste, o que será testado. Pode-se mencionar também se o sistema é novo ou se é uma reescrita;

- Autor e Data de Criação: usado como referência para que se saiba a idade do documento e quem foi que o elaborou.

Histórico de Versões/Revisões

Como já mencionado, um documento de Test Strategy pode ter várias versões até ser considerado pronto. Isso porque ele é analisado por diversas pessoas, que podem contribuir apontando problemas ou fazendo sugestões. Para que se tenha a real noção do quanto de esforço foi desprendido para a criação do documento, manter um histórico de revisões é fundamental. Além disso, este registro nos permite saber em qual ponto da história determinada modificação foi inserida, fato que pode ajudar a entender acontecimentos no futuro. Pode ser uma seção bem simples, contendo apenas:

- Data: registro do dia em que a inclusão/alteração foi feita;

- Versão: qual a versão corrente do documento. A forma de numerar fica por conta dos padrões adotados pela empresa;

- Autor: quem fez as modificações;

- Descrição das Alterações: o que foi feito durante aquela revisão, quais seções do documento foram alteradas e por que.

Índice/Sumário:

Parte óbvia. Utilizada como guia para que se saiba em que página está cada item e facilitar a navegação visual.

Introdução:

Costumo dizer que é pela introdução que você faz uma pessoa se interessar mais por uma leitura. No caso do Test Strategy, não é muito diferente. Documentação técnica em geral é bem sisuda e, se você conseguir ser objetivo e passar a mensagem correta, pode ser a diferença ente um leitor ler todo o documento ou apenas partes deles. Por, isso, inclua na introdução:

- Propósito do documento: o quê motivou a criação deste documento? Qual a sua razão? Sobre o que ele versa? No caso de um novo sistema, você pode mencionar que uma necessidade nova de negócio gerou uma nova aplicação e que esta precisa ser testada corretamente. Caso seja uma reescrita, você pode passar um breve histórico da verão anterior e as limitações que levaram a uma modificação, que também precisa ser testada. Esses são apenas dois exemplos, isso pode variar de acordo com o projeto;

- Objetivos: quais são os objetivos de teste que se pretende atingir com o processo proposto no documento?  

- Escopo de Teste: defina aqui exatamente o que vai ser testado: módulos, sistema inteiro, integração com outros sistemas, etc. É muito importante para cobranças futuras e serve como base para possíveis negociações, caso sejam necessárias mais adiante;

- Referências: qualquer documentação auxiliar que originou o documento atual ou que possa ser usada como complemento;

- Recursos Humanos: Quantas pessoas serão necessárias para o desenvolvimento do projeto de testes e em quais funções elas serão alocadas. Aqui é apenas um número usado para estimativas, não necessariamente precisa conter nomes.

Ferramentas Utilizadas

Essa seção deve conter todas as ferramentas necessárias para a realização das tarefas de testes. É importante também mencionar possíveis necessidades de licenças de usuários, mas aqui, teoricamente, a ferramenta já foi adquirida, portanto é mais uma questão de liberação do que qualquer outra coisa. Algumas ferramentas do mercado atendem a mais de um dos itens abaixo. Basicamente, são elas:

- Ferramenta de Gerenciamento: se houver, listar qual ferramenta (suíte) está sendo utilizada para gerenciar e/ou integrar todo o processo de teste;

- Test Design: ferramenta que será utilizada para a confecção dos test cases ou scripts automatizados; 

- Test Execution: aplicação que será usada para execução e registro dos resultados dos test cases ou scripts automatizados;

- Bug Tracking: utilizada para abrir/gerenciar/reportar os defeitos encontrados;

- Métricas: O que será usado para coletar e comunicar as métricas do projeto. Pode ser um simples relatório, obtido através do próprio suite de testes ou até mesmo um arquivo PowerPoint com as informações.

Gerenciamento de Defeitos

Aqui deve ser relatado como será conduzido o processo de gerenciamento dos defeitos encontrados durante o teste. É um ponto muito importante, uma vez que o simples ato de abrir um ticket pode envolver outros times além do de teste, como desenvolvimento e business. Por esse motivo, quanto mais claro estiver essa parte do processo, melhor. É igualmente importante que os padrões estabelecidos aqui sejam consenso entre o time de testes e os demais times que possam estar envolvidos. Devem estar descritos itens como:

- Fluxo e Status do Defeito: quais os caminhos que um defeito deve seguir a partir do momento em que é encontrado e/ou inserido no sistema de bug tracking até ter um destino final, e como cada fase será denominada. Por exemplo, o defeito terá como status inicial "Open" e final "Closed", podendo passar por outros status à medida que vai sendo trabalhado. Mencionar também quais pessoas/funções estão incumbidas de cada parte do fluxo ou mudança de status do defeito e a interação entre elas. 

- Níveis de Severidade: varia de empresa para empresa, mas pode-se usar a convenção adotada pela maioria, que vai de 1 a 4, onde 1 é o mais alto e 4 o mais baixo. É possível utilizar uma tabela informativa contendo o nível e sua respectiva descrição;

- Tipos de Defeito: classificação de cada tipo de defeito que pode ser encontrado durante o projeto. Pode ir desde os mais comuns, como defeitos de código, ambiente e dados, até outros relacionados ao design dos testes e requisitos ou problemas em outros artefatos.  

-  Principais campos de um Defeito: listar todos os campos que serão obrigatórios e opcionais de serem preenchidos no momento de abrir um defeito. Devem constar na lista ao menos o nome do campo, sua descrição e alguma flag que indique se ele é obrigatório ou não. Obviamente, a ferramenta de bug tracking deve ser configurada para refletir essas definições. Incluem-se aqui campos como código, data de abertura, data de fechamento, severidade, criticidade, área de negócio, responsável, etc.

Critérios de Entrada e Saída do Teste

São aqueles obtidos quando determinadas ações acontecerem. Listar quais são essas ações e qual função é responsável por ela. Ambos dependerão de um acordo entre os membros do projeto. 

Os critérios de entrada dizem respeito a tudo aquilo que deve ser configurado antes dos testes serem criados ou executados. Por exemplo, esses critérios podem ser obtidos quando as seguintes ações ocorrerem:

- Os dados da baseline estarem previamente setados, a fim de que se saiba quais são as configurações iniciais do banco para futuras comparações de resultados esperados versus atingidos;

- O ambiente de testes deve estar funcionando corretamente; 

- O processo de gerenciamento de defeitos foi estabelecido e aprovado;

- As reuniões de status do projeto foram previamente agendadas;

- Entre outros.

Já os critérios de saída,, por exemplo, podem ser atingidos quando as seguintes ações ocorrerem: 

- Todos os test cases ou scripts foram escritos e aprovados para execução; 

- Cada test case ou script foi executado ao menos uma vez antes de um ciclo regular, tendo seu tempo de execução registrado e funcionamento atestado; 

- Os testes aprovados foram executados em um ciclo regular de testes;

- Os defeitos encontrados foram gerenciados conforme o processo definido;

- Entre outros. 

Entregas/Deliverables

Esta seção diz respeito ao que será entregue ao final do processo de teste cada vez que ele for executado, ou seja, os produtos que serão mostrados para os interessados e que serão usados para demonstrar os resultados do processo e se chegar ao valor do trabalho em si. Atenção: aqui não são mostrados os resultados, apenas os produtos finais que serão usados para atingi-los, tais como:

- Test Cases Manuais ou Scripts Automatizados;

- Histórico de Execuções de testes;

- Relatórios Diversos (Status, Execução, Métricas, Defeitos, etc.).

Ambiente de Teste 

Normalmente são listados aqui todos os critérios que devem ser preenchidos para que o processo de teste seja realizado com sucesso em um determinado ambiente, como:

- Ambiente: em qual ambiente os testes serão utilizados. Podem ser ambientes específicos ou compartilhados (ambientes de teste, desenvolvimento, produção, pré-produção, etc.); 

- Colaboração: estabelecer quais são as equipes que deverão estar envolvidas na manutenção do ambiente (analistas de negócio, time de infraestrutura, DBAs, time de testes, desenvolvimento, etc.);

- Acesso: como se dará o acesso ao ambiente (máquina física, virtual, com uso de token, etc.) e os servidores utilizados;

- Dados: que tipo de dados serão usados (dados fictícios, de produção, cópias de produção); 

- Qualquer outra informação relevante que seja relativa ao ambiente.

Estrutura do Time e Responsabilidades

Deve ser descrita toda a estrutura da equipe e quais papéis cada membro tem. Pode ser utilizada uma tabela simples para listar isso, contendo colunas como: função, nome dos membros e responsabilidade de cada um. Colocar um campo contendo o contato da pessoa também pode facilitar na hora de procurar ajuda.

Adicionalmente, pode-se incluir fora desta tabela uma subseção relatando possíveis necessidades e estratégias de treinamento para o time, a fim de que se possa executar o processo com mais qualidade. Essas necessidades compreendem treinamento de negócios, processos internos já existentes, treinamento em novas ferramentas que serão utilizadas, conhecimento de sistemas específicos, etc.

Riscos, Dependências, Suposições e Restrições do Projeto

Também podendo ser uma tabela simples, deve considerar todas as variáveis que podem influenciar no sucesso ou andamento do processo de testes. É importante porque relata possíveis pontos deficientes na estrutura atual ou prevê possíveis situações que apresentem desvios dos resultados esperados. A tabela pode conter as seguintes colunas:

- Tipo: se é um risco, dependência, suposição (assumption) ou restrição;

- Titulo: a que se refere;

- Descrição: detalhes do item em questão, o que ele representa, quais possíveis alternativas a ele.

Abordagem do Teste

É uma descrição formalizada da parte operacional dos testes. É como a coisa toda vai funcionar em detalhes e quais padrões deverão ser seguidos. É sempre importante mencionar que é uma seção dinâmica e que alguns padrões podem ser modificados no futuro. Algumas partes importantes:

- Estágios de teste: relatar como o processo se dará desde o começo. Por exemplo: o primeiro passo será a compreensão do negócio e da aplicação, com possíveis treinamentos. Depois, parte-se para a escrita de testes manuais que serão usados nas fases de testes funcionais. Em seguida, serão desenvolvidos scripts automatizados para executar testes de regressão. O passo seguinte pode ser a seleção dos testes a serem executados, seguido da execução dos mesmos e terminando com a apresentação dos relatórios de resultados;

- Padrões de testes: descrever como serão construídos os test cases ou scripts automatizados. Relatar o sistema de nomenclatura, quais campos eles deverão conter, quais os valores esperados para cada campo, por quais status eles passarão entre escrita e aprovação, etc.; 

- Local de Armazenamento: em que pasta ou diretório os testes ou scripts estão localizados/armazenados e como fazer para acessá-los;

- Agenda (schedule): descrever a agenda  do processo, mostrando as datas iniciais e finais de cada atividade prevista; 

- Indicadores: quais serão os critérios utilizados para a geração das métricas, baseados nos resultados obtidos.

Como eu disse, muitos dos padrões aqui relatados podem variar, de acordo com cada empresa e como cada processo é estabelecido. Por esse motivo, procurei não aprofundar muito cada item (acreditem, normalmente o nível de detalhe é maior). Mas acho que estes pontos acima podem ser úteis para a confecção de um bom Test Strategy. O mais importante ter em mente que um documento desses deve ser dinâmico, que a cada novo projeto a documentação tem de evoluir em relação ao projeto anterior. E não deve ser considerada como mera parte burocrática. Ao contrário, mesmo para processos ágeis a documentação é importante. Quanto melhor definida, menos questionamentos gera e mais produtividade se consegue.

Leia Mais