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

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

E se o Capitão Nascimento fosse Gerente de Projetos?

Projeto de software é coisa séria. Mas, à medida que passamos um tempo trabalhando com isso, vê-se quase de tudo: desde cenas ou acontecimentos dos quais nos arrependemos de ter presenciado até alguns dos quais simplesmente achamos graça mais tarde. Enfim, histórias não faltam. Personagens sempre aparecem e acabam se tornando ícones da vida real para nós. Uns viram exemplos de trabalho bem feito, outros não. Há algum tempo, quando assistia uma reprise do filme "Tropa de Elite", comecei a pensar sobre muitas cenas que, se traduzidas para o mundo dos projetos corporativos, poderiam facilmente ser identificadas por muitos que trabalham na área. 

À época do lançamento, o filme acentuou um movimento que no Brasil é extremamente comum: a avalanche dos bordões. É impressionante como essas coisas pegam. Nas ruas a gente vê muito isso. É batata: basta um novo bordão aparecer num filme ou no "Zorra Total" ou um novo "artista" lançar um sucesso popular que no dia seguinte estará na boca do povo, sendo usado em diversas situações corriqueiras.

Embora simples, é possível notar que muitas coisas relatadas aqui acabam acontecendo mesmo no dia-a-dia. Logicamente que temos um tom de sarcasmo em muitas das frases a seguir, mas no fundo sabemos que há um pouco de verdade e quase nenhum exagero. Para quem é da área técnica, especialmente desenvolvimento e teste de software, as expressões utilizadas certamente são bem familiares. Prometo que explico para quem não entender, basta solicitar.

Talvez esse post possa não ter um apelo intelectual muito relevante, mas confesso que as frases começaram a surgir na minha cabeça e não consegui evitar. Tudo bem que é um texto bem menos ortodoxo do que os de costume, mas, depois de tantos outros mais sérios, achei que seria interessante postar algo mais descontraído. 

Basicamente, comecei a imaginar como o Capitão Nascimento se comportaria se fosse Gerente de Projetos. As frases a seguir foram baseadas em trechos do filme, facilmente reconhecidos por quem já assistiu. Claro que nem todas as frases utilizadas foram faladas pelo personagem mencionado, mas poderiam ter sido, caso ele tivesse esse cargo. Reservei-me ao direito de usar a censura (em forma de asterisco) para as palavras de baixo calão. 

Como seria a reação dele às diferentes situações de um projeto? Sabendo das suas facetas, tais como seu jeito rude e firme para resolver problemas e sua capacidade de mandar tudo às favas em nome de suas convicções, o que ele faria se estivesse nessa função? Devo dizer que, além de divertido, foi um exercício de reflexão. O resultado desse devaneio você vê a seguir:

O Projeto na Versão Tropa de Elite (Com Cortes):

Approval no “Canetaço”

- Sabe por que você é o zero-um?

- Não senhor!

- Porque você vai ser o 1° a dar o approval nessa m*! Aprova, p*!

- Não senhor!

- Aprova! (tapas na cara)

- Eu aprovo, senhor!

- O zero-um aprovou!

- Êeeeeeeeeeeeeeeeee...

Rodando os Testes - 1
- A essa altura do campeonato e você tá sem o SRS, zero-três?
- Esqueci, senhor!
- Ah, esqueceu? E se um companheiro seu ficar doente durante a fase de testes e precisar que o senhor assuma o lugar dele? Vai fazer o que com esses Casos de Teste? Vai colocar no lixo?
- Não, senhor!
- Vai enfiar no c*?
- Não, senhor!
- Então imprime esse SRS, p*!


Rodando os Testes - 2
- Bom dia filho, queria pedir sua permissão pra revisar a suas tarefas de teste, posso ficar à vontade?
- Sim senhor.
- Zero-quatro, dá uma geral nesse diretório aqui.
- Ihhh, senhor! Olha só o que eu achei... Só esse caso de teste “Não rodado” tem mais "steps" que a escada lá da favela!
- De onde veio esse Caso de Teste, meu filho?
- Eu ganhei, senhor.
- Ganhou não, filho da p*! Perdeu! Tô encaminhando pra outro Testador! Tá demitido! Vambora!

Antes de Iniciar o Deploy

- Os senhores estão bem?

- Sim, senhor!

- Os senhores estão feridos?

- Não, senhor!

- Algum dos senhores está cansado?

- Não, senhor!

- Então hoje vocês vão aprender a carregar TODO o banco de dados global!

Durante o Deploy na madrugada...
- O senhor está dormindo, seu zero-cinco?
- Não, senhor!
- Segura esse Post-Install aqui, seu zero-cinco.
- Mas senhor...
- Seu zero-cinco, se o senhor não segurar esse Post-Install, o senhor vai explodir o projeto, vai explodir seus colegas, o senhor vai ME explodir... O senhor vai deixar esse projeto afundar de novo, seu zero-cinco?
- Não, senhor! Não, senhor!
- Contamos com o senhor, seu zero-cinco!


Uma hora depois do início do Deploy...
- Dezesseis, o senhor é o novo DEV Lead!
- Eu desisto, senhor!
- Fala mais alto, para que todos os seus colegas vejam como o senhor é um fraco!
- EU DESISTO, SENHOR!
- Vocês estão fazendo seu gerente muito feliz!


Na sala de reunião do time de Dev...
- Eu fiz exatamente como o senhor mandou, seu gerente! Mas é que são aqueles filhos da p* da área de testes: eu rejeitava os defeitos e eles reabriam, eu rejeitava e eles reabriam. É a guerra do projeto...
- 50 defeitos de severidade 1 só esse mês em uma mesma aplicação? É muito defeito! Precisamos reduzir número de defeitos já, antes do Go-Live!
- Mas senhor, esses defeitos estão todos com prioridade máxima...
- P* que pariu! Me dá esse relatório aqui! Deixa eu ver... Olha aqui! C*, tem 15 defeitos de recursividade na mesma rotina! Ô Estagiário, tu quer f* comigo? Mais do que um defeito de recursividade tem que ser considerado como duplicado!
- Mas senhor, são todos com combinações diferentes...
- Ô Estagiário, tu por acaso é do Business?
- Não senhor...
- Então faz o que eu tô mandando, pô!


Durante o Post-Install
- Seu zero-dois! Em quanto tempo o senhor acha que dá pra rodar o script de regressão, seu zero-dois?
- Em 10 minutos tá pronto, senhor!
- 10 minutos? Hahaha. O senhor é um fanfarrão, seu zero-dois! Vocês vão ter 10 SE-GUN-DOS pra rodar esse script! E ainda ter que passar sem erro! AGORA!
- Senhor, a ferramenta de automação tá demorando pra rodar o script, senhor! Acho que tem que otimizar, mas eu não sei se consigo, tá muito ruim esse código..
- Tá com nojinho, zero-dois? Tu vai meter a mão e otimizar esse script AGORA!


Após o Post-Install
- Essa p* não é mais minha! Essa p* agora é do Business!



Reunião Final com o Business
- Você aí do Business! Viu quem deu o No-Go aqui?
- Não vi não senhor!
- Viu sim!
- Não vi não senhor!
- Como que não viu se você estava aqui?
- Não vi não!
- Viu sim, pode falar!
- Não vi!
- Fala, filho da p*!
- Foi um de vocês!
- (Tapa na cara) Foi um de nós o c*! Foi você! Você que afundou esse projeto! Você que financia essa m* aqui!



* Adaptação do texto publicado em 08/05/2008 

Leia Mais