Liderança em Testes: Ferramentas de Teste

As equipas de software autogeridas utilizam uma variedade de ferramentas maior do que nunca. Numa equipa de software típica, podem estar em utilização vinte ou até trinta ferramentas. Para o ajudar a orientar-se neste contexto, neste artigo iremos abordar:

• Ferramentas para testes
• Arquitetura das ferramentas
• Gestão de testes
• Conceção de testes
• Proprietárias ou de código aberto?
• Um exercício de seleção de ferramentas

Comecemos por analisar os principais tipos de ferramentas que irá utilizar nos testes.

Ferramentas para testes

É conveniente dividir as ferramentas relevantes para os testes em três tipos:

• Ferramentas de colaboração: permitem registar ideias e requisitos, comunicar em toda a equipa e realizar alguma integração com processos automatizados, por vezes através de bots.
• Ferramentas de testes: um vasto conjunto de ferramentas que permitem gerir dados de teste, conceber testes, utilizar estruturas de testes unitários, executar testes funcionais, realizar testes de desempenho e de carga, testes estáticos, conceber testes, gerir o processo de testes, casos de teste, registar testes e elaborar relatórios.
• Ferramentas de DevOps ou de gestão de infraestruturas: estas ferramentas permitem gerir ambientes e plataformas, efetuar implementações utilizando infraestrutura como código e tecnologias de contentores, bem como registar, monitorizar e analisar sistemas em produção.

The Tools Knowledge Base é um registo online de ferramentas que se diferencia da maioria dos registos online pelo facto de abranger ferramentas de colaboração, testes e DevOps. Existem mais de 1700 ferramentas distribuídas por estas três áreas. As páginas Web das ferramentas estão indexadas e podem ser pesquisadas.

O site também agrega e indexa mais de 300 bloguistas, e mais de 52 000 blogues estão igualmente indexados e podem ser pesquisados. Fornecemos URLs para as principais categorias de ferramentas e atalhos para pesquisar essas categorias nos blogues.

Existem mais de 1700 ferramentas que permitem a colaboração, os testes e o DevOps.

Mais adiante neste artigo, analisaremos as principais preocupações que afetam e apoiam a gestão de testes.

Arquitetura das ferramentas

Na imagem abaixo, identificámos a variedade de tipos de ferramentas utilizados pela maioria das equipas de software modernas. Separámos as ferramentas que tendem a ser utilizadas nos ambientes de desenvolvimento, testes e produção. 

Estas ferramentas assentam em ferramentas de infraestrutura que fornecem plataformas, máquinas virtuais e contentores para alojar ambientes, bem como ferramentas que executam implementações automatizadas. As ferramentas utilizadas para gerir implementações e versões são designadas por ferramentas de orquestração de versões e pipelines. As comunicações dentro da equipa, bem como com muitos dos processos automatizados, são geridas por ferramentas de colaboração ou ChatOps.

Embora a transição para o DevOps esteja a impulsionar o desenvolvimento e a adoção de ferramentas de apoio ao desenvolvimento contínuo, quase todas estas ferramentas são úteis para qualquer equipa de desenvolvimento ou operações de software.

Não é necessário ter uma cultura DevOps para utilizar ferramentas de “DevOps”.

Gestão de testes

Ferramentas de gestão de testes são indispensáveis em todos os projetos de grande dimensão. Os projetos ágeis costumam adotar uma ferramenta de gestão de incidentes e, no que diz respeito aos testes, baseiam-se em parte na utilização de histórias e cenários de negócio para acompanhar exemplos fundamentais de todos, ou pelo menos de alguns, testes. As ferramentas de gestão de testes variam em abrangência, desde soluções muito simples, como o Microsoft Excel, até produtos abrangentes de Gestão do Ciclo de Vida das Aplicações (ALM).

De um modo geral, o âmbito das ferramentas de gestão de testes abrange várias áreas:

Modelo de Cobertura de Testes: A maioria das ferramentas de gestão de testes permite definir um conjunto de requisitos aos quais associar casos de teste e/ou verificações nos testes. Por vezes, estes requisitos podem ser hierárquicos, de modo a refletir o índice de um documento. Cada vez mais, é possível registar outros modelos, como casos de utilização ou fluxos de processos de negócio. Normalmente, estão disponíveis relatórios de cobertura do planeamento e da execução dos testes.

Gestão de Casos de Teste: Os casos de teste e o respetivo conteúdo podem ser geridos para fornecer um registo documentado dos testes. O conteúdo dos casos de teste pode ser preparado antes dos testes ou servir como registo dos testes executados. Os casos de teste podem ter um formato de texto livre ou ser estruturados em passos com resultados esperados. É comum importar documentos e imagens para os associar aos testes ou aos passos.

Planeamento da Execução de Testes: Os testes podem ser estruturados numa hierarquia ou receber etiquetas, de modo a proporcionar uma estrutura mais dinâmica. Os membros da equipa de testes podem ter testes atribuídos. As durações planeadas dos testes podem ser utilizadas para publicar um calendário sincronizado dos testes a executar pela equipa. Podem ser selecionados subconjuntos de testes para garantir a cobertura dos requisitos, testar funcionalidades específicas e voltar a executar conjuntos de testes de regressão. Também podem ser selecionados para execução testes registados como ainda não executados, bloqueados, falhados ou com outro estado.

Execução e Registo de Testes: À medida que a equipa executa os testes, o estado dos testes é registado. Em todos os testes executados devem ser identificados o testador, a data e hora e a duração. Aos testes aprovados pode ser atribuído um simples estado de aprovação. Os resultados de testes falhados, bloqueados ou anómalos podem incluir capturas de ecrã, resultados de testes associados e um relatório de incidente associado. Muitas ferramentas disponibilizam integrações com ferramentas de execução de testes que gerem e executam testes, registam resultados e até criam rascunhos de relatórios de incidentes.

Gestão de Incidentes: As falhas dos testes são registadas no registo de execução. Normalmente, estas requerem investigação adicional, com depuração e correção quando uma falha é causada por um erro. As falhas que requerem investigação são normalmente registadas através de relatórios de erros, de incidentes ou de observações. Os relatórios de incidentes podem conter uma grande quantidade de informações de apoio. Normalmente, é atribuído aos incidentes um tipo, um objeto sob teste, uma prioridade e uma gravidade. Algumas empresas registam uma enorme quantidade de informações e associam-nas a um processo sofisticado de gestão de incidentes.

Relatórios: Relatórios e análises dos dados provenientes de todas as funcionalidades acima mencionadas, conforme adequado. O conjunto de relatórios varia entre a cobertura de testes planeada versus real e o estado dos relatórios de incidentes para acompanhar investigações pendentes, correções e novos testes, incluindo análises do tempo necessário para corrigir vários tipos de falhas, por funcionalidade, gravidade, urgência, entre outros.

A ferramenta de gestão de testes mais popular do planeta continua a ser o Microsoft Excel.

Conceção de Testes

A conceção de testes baseia-se em modelos. No caso dos testadores de sistemas e de aceitação, os modelos típicos são documentos de requisitos, casos de utilização, fluxogramas ou diagramas de raias. Modelos mais técnicos, como modelos de estados, diagramas de colaboração, diagramas de sequência, entre outros, também constituem uma base sólida para a conceção de testes.

Em muitos projetos, os modelos são utilizados para registar requisitos ou conceções de alto nível. Quando são disponibilizados aos testadores, podem ser utilizados para rastrear caminhos e selecionar diretamente itens de cobertura no modelo. Se modelos deste tipo não estiverem disponíveis, é muitas vezes útil que a equipa de testes registe, por exemplo, fluxogramas de processos ou diagramas de raias. Estes ajudam os testadores a ter discussões mais pertinentes com as partes interessadas, sobretudo no que diz respeito à abordagem de cobertura.

No domínio das soluções proprietárias, estão a surgir ferramentas que permitem registar modelos, como fluxogramas, e utilizá-los para gerar casos de teste através do rastreio de caminhos de acordo com um determinado objetivo de cobertura, por exemplo, todas as ligações, todos os processos, todos os resultados de decisões, todos os pares e todos os caminhos. Estas ferramentas podem ser ligadas a ferramentas de gestão e geração de dados de teste para gerar combinações de dados de teste a utilizar com testes manuais ou automatizados.

Existem também ferramentas que permitem efetuar a modelação em ferramentas de execução de testes. Por exemplo, estas ferramentas permitiriam ao programador de testes registar todos os campos de uma página Web, criar ligações para ‘unir’ os campos e criar um modelo de navegação para a página – tudo num formato gráfico.

O modelo é então utilizado para criar caminhos de navegação e uma bateria de testes que cumpra determinados critérios de cobertura – tal como nas ferramentas de modelação acima referidas. Estas ferramentas de execução podem criar caminhos de teste automatizados utilizando critérios selecionados ou gerá-los aleatoriamente, além de comunicarem a cobertura relativamente a estes modelos.

Este é atualmente um domínio dinâmico – procure ferramentas de modelação que suportem a conceção e a geração de testes, bem como ferramentas de execução que suportem a modelação do sistema sob teste e a seleção e comunicação automatizadas dos caminhos de teste.

Proprietário ou de Código Aberto?

Ao longo dos últimos vinte anos, a utilização de produtos de software gratuito e de código aberto (FOSS), especialmente para executar infraestruturas, tem sido generalizada. O custo das licenças de sistemas operativos e do software de servidor Web associado da Microsoft, bem como a convicção generalizada de que o Linux/Unix é mais fiável e seguro do que o Windows, faz com que, em muitos ambientes, o Linux/Unix seja o sistema operativo escolhido para os servidores. 

Embora o artigo discuta as vantagens e desvantagens das ferramentas de código aberto e proprietárias, se estiver especificamente à procura de soluções que se integrem bem com o Jira, o nosso guia abrangente sobre ferramentas de gestão de testes específicas para o Jira pode ajudá-lo a tomar uma decisão informada.

As duas tabelas abaixo (atualizadas diariamente em w3techs.com) mostram a popularidade relativa dos sistemas operativos e dos produtos de servidores Web. Cerca de 85% dos sites utilizam os produtos de servidor Web de código aberto mais conhecidos, o Apache e o Nginx.

A popularidade destes produtos de infraestrutura FOSS comprova que o código aberto pode ser tão fiável como, ou até mais fiável do que, os produtos proprietários.

Para uma equipa de software que necessita de vinte ou trinta ferramentas de software para apoiar as suas atividades, existem ferramentas FOSS e proprietárias fiáveis e funcionais para realizar todas as tarefas. Como escolher entre um produto proprietário e um produto FOSS?

A tabela abaixo resume alguns dos aspetos que poderá considerar ao selecionar um tipo de ferramenta.

Os produtos FOSS podem ser mais baratos de obter, mas os outros custos e responsabilidades podem ser significativos. O fator decisivo entre os dois é normalmente uma combinação da sua cultura, da sua tolerância ao risco e da sua capacidade técnica.

Quando compra produtos proprietários e contratos de suporte, os riscos associados à incompatibilidade (com outros produtos), à fiabilidade, à facilidade de utilização e a um suporte técnico atento são geralmente baixos, embora por vezes dispendiosos.

Com produtos FOSS, normalmente tem de realizar uma investigação muito mais aprofundada antes de se comprometer a utilizar um deles. Afinal, não existe um vendedor com quem falar e a documentação pode ser funcional, em vez de informativa. Naturalmente, é fácil configurar um período de avaliação e pode utilizar tantas ferramentas quantas quiser, mas terá de investigar mais detalhadamente as capacidades da ferramenta. 

Uma menor facilidade de utilização e a incompatibilidade com as ferramentas existentes podem criar problemas, pelo que poderá ter de escrever software de interface ou suplementos, bem como utilitários de criação de relatórios ou de importação/exportação de dados. 

Além disso, terá de formar-se a si próprio e à sua equipa para os atualizar e, normalmente, assegurar o seu próprio suporte de software. No entanto, a sua equipa terá um conhecimento mais profundo do funcionamento da ferramenta e será, em grande medida, autossuficiente.

Uma ferramenta FOSS pode ajudá-lo a ganhar experiência com um novo tipo de ferramenta a baixo custo. Com essa experiência, estará mais bem preparado para escolher uma ferramenta proprietária a longo prazo.

Um exercício de seleção de ferramentas

Se procura uma ferramenta de gestão de testes para apoiar o seu projeto e a sua aplicação atuais, ou um projeto e uma aplicação recentes com os quais esteja familiarizado, elabore uma lista de 15-20 funcionalidades com base nas áreas funcionais abordadas na discussão anterior sobre ferramentas de gestão de testes. Essas funcionalidades devem ser:

• Obrigatórias
• Desejáveis

Esta lista pode incluir capacidades funcionais, integrações, uma aposta na facilidade de utilização, no suporte ou numa grande base de utilizadores, ou ainda fóruns online/perguntas frequentes. Se já tiver uma ferramenta implementada, não escolha essa.

Utilizando o texto dos seus requisitos, pesquise na Base de Conhecimento de Ferramentas para encontrar três ferramentas (incluindo um produto proprietário e um produto FOSS) que pareçam corresponder aos seus requisitos. Utilizando as descrições das funcionalidades das ferramentas, crie uma tabela de comparação de funcionalidades dos três produtos. Adicione uma quarta coluna para a ferramenta que está efetivamente a utilizar — para comparação.

• Como se comparam as ferramentas em termos de funcionalidades?
• Que funcionalidades faltam à(s) ferramenta(s) FOSS em comparação com as ferramentas proprietárias?
• Quantas ferramentas existem que cumprem, de forma geral, os seus requisitos?
• Quanto tempo acha que precisaria de dedicar à pesquisa de ferramentas para elaborar uma lista final de, digamos, três?

Subscreva a newsletter The QA Lead para ser notificado quando forem publicados novos capítulos da série. Estas publicações são excertos do curso Liderança em Testes do Paul — altamente recomendado para quem pretende aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de $60 no preço total do curso!

Aprenda com outros profissionais de testes ouvindo os nossos podcasts ou consultando os nossos blogues. Eis um que achamos que lhe ensinará imenso: COMO AS COMPETÊNCIAS DE TESTES ME TORNARAM NUM MELHOR PROGRAMADOR DE AUTOMAÇÃO