Medição, Medidas, Métricas e Indicadores

Métricas de software estão se tornando cada vez mais uma parte importante na prática da Engenharia de Software. A cada dia, um número maior de empresas e governos está adotando e reportando métricas de qualidade como parte dos requisitos contratuais de desenvolvimento.

Métricas: medidas para o sucesso

 

Fonte: Kenishirotie/Shutterstock

Padrões, modelos e normas como ISO (International Organization for Standardization), CMMI (Capability Maturity Model Integration), entre outros, consideram as métricas entre as suas práticas recomendadas. Empresas estão usando métricas para melhor compreender, mapear, controlar e predizer projetos, processos e produtos de software.

De acordo com Maitino Neto (2016, p. 148), a medição é o processo pelo qual “os números são atribuídos aos atributos de entidades do mundo real”. O autor exemplifica o conceito dizendo que quando medimos a separação entre dois pontos e obtemos 10, o valor 10 é atribuído à grandeza física denominada distância. Isso indica que a medição é uma quantificação direta, que utiliza um único valor. Mas quando tratamos de métrica, utilizamos uma medição indireta, pois esta envolve o cálculo e uso de mais de uma medida. Como exemplo, podemos utilizar a medida de número de linhas de código e a medida de número de defeitos encontrados no programa para determinar a métrica de quantidade de defeitos por linha de código.

Ainda como exemplos de medição, podemos considerar, no campo da Engenharia, medidas como consumo de energia, peso, dimensões físicas, temperatura voltagem etc.

Maitino Neto (2016) ainda afirma que é desejável que as métricas sejam capazes de fornecer informação relevante para auxiliar a tomada de decisão e ainda contribuir para que se possa realizar comparação de desempenhos.

Embora existam métricas referenciais, usadas de forma padronizada pelos desenvolvedores de software, métricas podem ser baseadas nos objetivos da organização e na sua necessidade de informação para a tomada de decisão.

No contexto da engenharia de software, Pressman e Maxim (2016, p. 654) definem medida como um valor que “fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo”. Os autores fazem referência ao IEEE Standard Glossary of Software Engineering Terminology que define métrica como uma “medida quantitativa do grau em que um sistema, componente ou processo possui um determinado atributo”.

Ainda de acordo com os autores, quando um único ponto de dados foi coletado (como, por exemplo, o número de erros descoberto em um único componente de software) uma medida foi estabelecida. Medição ocorre como resultado da coleção de um ou mais pontos de dados (por exemplo, um certo número de revisões de componentes e testes de unidade são investigados para coletar medidas do número de erros em cada um). Uma métrica de software relaciona as medidas individuais de algum modo, como, por exemplo, o número médio de erros encontrados por revisão ou número médio de erros encontrados por teste unitário.

Um engenheiro de software coleta medidas e desenvolve métricas de modo que indicadores sejam obtidos. Pressman e Maxim (2016, p. 655) definem um indicador como “uma métrica ou combinação de métricas que fornece profundidade na visão do processo, projeto ou produto de software”. Um indicador fornece um parâmetro que permite ao gerente do projeto ou engenheiros de software ajustarem o processo, projeto ou produto para torná-lo melhor e gerenciável. A figura ilustra esses conceitos.

De acordo com a figura, na Engenharia de Software a medição é útil principalmente quando relacionada ao processo, projeto e produto de software.

Visão geral sobre medidas, métricas e indicadores

Pode ser aplicada ao processo de software com o objetivo de melhorá-lo continuamente. No caso do projeto de software, as medidas podem auxiliar nas estimativas de prazos e custos, no controle de qualidade, na avaliação da produtividade, no controle do projeto e na tomada de decisões, conforme o projeto evolui. As medidas relacionadas ao produto de software focalizam atributos específicos de artefatos e são coletadas à medida que tarefas técnicas (análise, projeto, codificação e teste) são conduzidas.

Meirelles (2008) afirma que uma grande variedade de métricas já foram propostas, mas nem todas mostram resultados satisfatórios. Isso ocorre por vários fatores: algumas exigem medições muito complexas, outras são muito restritas, limitando sua aplicação, e outras violam as noções básicas dos atributos de um software (qualidade, por exemplo).

As métricas de software consideradas efetivas devem possuir alguns atributos que incluem:

• Simples e computáveis: deve ser relativamente fácil aprender como derivar a métrica e seu cálculo não deve exigir esforço ou tempo exagerado.
• Empíricas e intuitivamente persuasivas: a métrica deve satisfazer as noções intuitivas do engenheiro de software sobre o atributo do produto que está sendo considerado.
• Consistentes e objetivas: a métrica deve produzir sempre resultados que não sejam ambíguos.
• Independentes da linguagem de programação: métricas devem ser baseadas no modelo de análise, modelo de projeto ou na estrutura do programa.
• Capazes de atuar como mecanismo efetivo para realimentação de alta qualidade: isto é, a métrica deve levar a um produto final da mais alta qualidade.

Enfim, as métricas devem permitir a comparação dos resultados para medir qualidade, eficiência, custo, produtividade, entre outros aspectos mensuráveis da análise, desenho, codificação e testes de software.

Métricas de Software

As Métricas de Software é de grande relevância, para os profissionais envolvidos na produção do software. Este tema é parte fundamental da prática da Engenharia de Software e é cada vez mais comum nos requisitos contratuais para dimensionar o software e sua qualidade.

Organizações que criam padrões e modelos para a indústria, como os padrões ISO e CMMI, se preocupam com medidas e métricas a fim de apurar e garantir a qualidade de produtos e serviços. Empresas e órgãos governamentais, no Brasil e no mundo, estão usando métricas para compreender, controlar, prever e melhorar projetos, processos e produtos de software.

As métricas desempenham um papel fundamental em uma das áreas mais críticas do desenvolvimento de software: a área de estimativas de custos, prazos e recursos.

A importância de se ter um programa bem estabelecido de coleta de medidas, cálculo de métricas e armazenamento dessas informações em uma base de dados robusta, é fundamental para a precisão das estimativas realizadas para cada projeto em andamento.

Todo empreendimento, incluindo o desenvolvimento de software: a gestão de riscos. Todo projeto está exposto a riscos e é de suma importância que você adote uma estratégia proativa em relação a eles. Isso implica conseguir prever a quais riscos o projeto está vulnerável, qual a probabilidade desses riscos se tornarem realidade e qual o impacto deles no projeto, caso realmente venham a ocorrer.

A “Análise do Valor Agregado”, que pode auxiliar no monitoramento e controle do andamento de um projeto.

Organizações Envolvidas com Testes de Software no Brasil (Parte2)

Alats

A Alats (Associação Latino Americana de Testes de Software) é uma associação sem fins lucrativos cujo objetivo é incentivar e divulgar as boas práticas em teste de software.

Alats

 

Fonte: <http://www.alats.org.br/portal/>

A instituição trabalha para aproximar e integrar universidades, organizações empresariais e profissionais de TI, atuando como um facilitador para o desenvolvimento e aplicação de técnicas para atender a demanda e as necessidades da área de testes de software.

A Alats criou a CBTS - Certificação Brasileira de Teste de Software visando qualificar profissionais para atender o mercado brasileiro na área de teste de software.

De acordo com Alats (2017, s/p), o objetivo da CBTS

[...] é estabelecer um padrão em conformidade com os requisitos para uma avaliação da qualificação dos profissionais na área de Qualidade de Software. Adquirir o certificado CBTS para o profissional da área é um grande diferencial, pois indica que o mesmo possui um excelente nível de competência profissional nos princípios e nas práticas de Qualidade de Software, dentre os demais profissionais de TI. Tornar-se um certificado CBTS, significa tornar-se membro de um grupo seleto de profissionais reconhecidos na área de Área de Qualidade de Software. Receber este reconhecimento de sua competência é conseguir uma ascensão potencialmente mais rápida em sua carreira, e uma maior aceitação no mercado.

O certificado é válido por três anos, mas o profissional pode manter-se certificado através da recertificação, seguindo regras específicas. Estas regras, de acordo com informações da instituição, são:

a certificação é válida no ano da prova (a partir da data divulgada da aprovação) e nos 3 anos seguintes completos, terminando sempre em 31/12. O período de aquisição dos PDTS (Ponto de Teste de Software) é correspondente ao período de validade da certificação, ou seja no decorrer dos três anos. 50 PDTS devem ser obtidos neste período para que não seja necessário prestar novo exame. A partir do primeiro período, a cada 3 anos completos, novos 50 PDTS devem ser adquiridos, ou seja o certificado poderá ser validado sem a necessidade de outro exame.

Comparação entre os certificados CTFL e CBTS

As certificações mais conhecidas na área de testes de software no Brasil são a CTFL e a CBTS. Apesar de ambas serem muito conhecidas, as principais diferenças entre elas são desconhecidas pela maioria dos profissionais. Para facilitar a identificação destas diferenças, Findeis (2016) faz um comparativo entre essas certificações que está apresentado no Quadro 2.

É importante ressaltar que a validade do CBTS pode ser sempre revalidada através de aquisição de 50 pontos (PDTS).

Comparativo entre certificações de testes CTFL e CBTS

	CTFL	CBTS
Órgão certificador	BSTQB/ISTQB	ALATS
Validade	Nunca expira	3 anos, Depois tem que refazer
Território de aceitação	Internacional	Exclusiva do Brasil
Material	Apostila de 77 páginas. tem também um glossário de 111 para tirar dúvidas sobre siglas	Livro "Base de conhecimento em teste de Software", com 263 páginas
Valor do material	Gratuito no site	Entre 50 e 80 reais na internet
Simulado oficial	Sim	Não
Simulados variados na internet	Sim	Sim
Língua da prova	Português ou Inglês	Português
Valor da prova	350 reais	90 dólares

Fonte: Findeis (2016)

Observação: Os valores não estão atualizados. Eles são referentes a data de pesquisa da publicação.

Organizações Envolvidas com Testes de Software no Brasil

Certificações em testes de software

De forma similar a outras áreas da engenharia de software, há diversas certificações em teste de software. Uma certificação em testes de software indica que o profissional que a possui adquiriu determinado nível de conhecimento na área. Isso funciona, por um lado, como um facilitador para que as organizações contratantes identifiquem profissionais qualificados e, por outro lado, fornece ao profissional certificado um diferencial que o destaca, aumentando suas chances de contratação.

A disseminação dos processos de testes no Brasil é relativamente nova. Algumas organizações e institutos foram criados com o objetivo de profissionalizar a atividade, realizando avaliações e fornecendo certificação para os profissionais da área.

Dentre as principais instituições certificadoras mundiais estão:

Certificações

 

Fonte: <www.qaiglobalinstitute.com>, <ertifications.bcs.org/>, <testinginstitute.com>

• QAI - Quality Assurance Institute, que oferece a certificação CSTE (Certified Software Tester).
• BSC - British Computer Society, cujas certificações são divididas em Foundation Level, Intermediate Level e Higher Level.
• IIST - International Institute of Software Testing, cujas certificações são divididas em Professional Testing, Agile Testing, Test Automation, Test Management e Mobile Testing.
• ISTQB - International Software Testing Qualifications Board
• Alats - Associação Latino Americana de Testes de Software

Aqui vamos tratar das certificações oferecidas pelo ISTQB e Alats.

BSTQB

O BSTQB (Brazilian Software Testing Qualifications Board) é o representante do ISTQB (International Software Testing Qualifications Board) no Brasil.

BSTQB

 

Fonte: <bstqb.org.br>

De acordo com o BSTQB (2006), a certificação em teste de software começou no Reino Unido em 1998, com a criação de uma comissão de testes de software pela British Computer Society´s Information Systems Examination Board (ISEB) e, em 2002, a Alemanha passou a dar suporte a um sistema de qualificação de testadores.

Foi criado um guia de estudo para orientar os interessados em obter as certificações denominado Syllabus. De acordo com o ISTQB (2011, p. 8), o Syllabus

[...] forma a base de conhecimento para a Qualificação Internacional de Teste de Software no nível Foundation. O International Software Testing Qualifications Board (ISTQB) disponibiliza o Syllabus às comissões nacionais para que elas autorizem os fornecedores de treinamento e também derivem as questões do exame em suas línguas locais. Os fornecedores de treinamento produzirão o material de curso e determinarão os métodos de ensino apropriados para certificação, e o Syllabus ajudará os candidatos em sua preparação para o exame.

Cada certificação possui um syllabus e um glossário. Os syllabi formam a base de conhecimento para a qualificação internacional em teste de software, tanto para o nível fundamental (CTFL) quanto para o nível avançado (CTAL).

A Figura ilustra o rol de certificações oferecidas pelo ISTQB.

Tipos e níveis de certificações ISTQB

 

Fonte: <bstqb.org.br>

Certificações de nível fundamental

Certified Tester Foundation Level - CTFL, que pode ser obtida por qualquer profissional envolvido em teste de software como desenvolvedores e testadores, engenheiros, gerentes, consultores e analistas de testes, mas também se aplica a pessoas interessadas em adquirir conhecimento sobre teste de software, como gerentes de projetos, gerentes de qualidade, analistas de negócios, gestores de TI, consultores etc. Sendo um nível inicial, as pessoas certificadas neste nível poderão buscar níveis mais altos de qualificação na área.

CTFL Agile Tester, que segue os princípios do desenvolvimento ágil de software, em consonância com o Manifesto ágil. Um profissional com esta certificação trabalhará de forma diferente de um testador em um projeto tradicional, pois passa a entender e a seguir os valores e princípios de projetos ágeis.

CTFL Model Based Test, que oferece ao testador com esta certificação conhecimento em modelos inovadores para conduzir a análise e modelagem do teste, complementando o nível CTFL como um módulo de especialização.

Certificações de nível avançado

As certificações de nível avançado iniciam-se por CTAL (Certified Tester Advanced Level). Reúnem um conjunto de certificações destinadas a profissionais que já têm experiência consolidada em teste de software. A certificação CTFL é pré-requisito, e o candidato ainda deve comprovar sua experiência na prática para ser qualificado para o CTAL. As certificações deste nível são:

• CTAL Test Manager
• CTAL Test Analyst
• CTAL Technical Test Analyst
• CTAL Security Tester
• CTAL Test Automation Engineer

“ISTQB has created the world’s most successful scheme for certifying software testers. As of December 2016, ISTQB® has administered over 700,000 exams and issued more than 500,000 certifications in over 117 countries world-wide. The scheme relies on a Body of Knowledge (Syllabi and Glossary) and exam rules that are applied consistently all over the world, with exams and supporting material being available in many languages.”

“O ISTQB criou o mais bem sucedido esquema de certificação de testadores de software do mundo. Até dezembro de 2016, o ISTQB aplicou mais de 700 mil exames e expediu mais de 500 mil certificações em mais de 117 países do mundo. O esquema é baseado em um Corpo de Conhecimento (composto por Syllabi e Glossário) e regras de exame que são aplicados de forma consistente por todo o mundo, com exames e material de suporte disponíveis em muitas línguas.”

Fonte: <http://www.istqb.org/>, tradução nossa.

Testes no Scrum

No scrum não existe uma fase específica de teste. De acordo com Schwaber e Sutherland (2016, p. 6), no scrum, os times de desenvolvimento

[...] são multifuncionais, possuindo todas as habilidades necessárias, como equipe, para criar o incremento do produto. O scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa e não há exceções para esta regra. Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo.

Na prática, testes iterativos são executados durante todo o desenvolvimento, como os testes de unidade e os testes de caixa preta. Uma funcionalidade só é considerada concluída quando todos os testes foram executados durante o desenvolvimento. O analista de teste, no scrum, faz parte do time de desenvolvimento e assume várias responsabilidades, como as de líder, arquiteto e responsável pela automatização. Este profissional participa ativamente no levantamento de requisitos e definição de escopo, tratando com grande relevância a necessidade do cliente, considerando os objetivos que o software deve alcançar à medida que ele é entregue. Ao fim de cada sprint, o analista de testes, junto com o time, é responsável por garantir que todos os testes automatizados tenham sido executados sem falhas.

De acordo com Cockburn e Highsmith (2001), para alcançar os resultados adequados, o testador realizará algumas tarefas, como:

• participar das discussões de definição de arquitetura;
• participar das definições de tecnologias utilizadas;
• identificar as necessidades do ambiente de teste;
• identificar restrições tecnológicas;
• identificar ferramentas de teste necessárias para auxiliar na execução do projeto;
• utilizar mapa mental para auxiliar no entendimento das funcionalidades/requisitos;
• identificar os “melhores” analistas de teste para o projeto em questão;
• identificar a necessidade de suporte do time de suporte/operações.
• estimar o tempo de teste.

Este profissional ganha um papel importante na modelagem ágil, pois participará ativamente do desenvolvimento, implantando técnicas eficientes de testes de software, levando em consideração o negócio e suas necessidades.

O time, como um todo, sempre atuará para o benefício do projeto, portanto, o testador, componente agora agregado ao time, integra-se, participando ativamente e colaborando de forma significativa na criação de um software com o mínimo de falhas, defeitos e erros.

De acordo com Duong (2016), o analista de teste, como importante membro do time, participa ativamente de todos os processos, apoiando o scrum master, que faz a mediação, e consultando o product owner para esclarecer eventuais dúvidas. A Figura mostra as principais etapas e membros envolvidos em um projeto scrum:

Metodologia ágil scrum

 

Fonte: Kalakruthi / shutterstock

Como engajar efetivamente os analistas de testes durante uma sprint, uma vez que nada ainda foi construído? De acordo com Hasija (2012), os analistas de testes participam de cerimônias e cumprem suas responsabilidades junto com outros membros do time scrum. Além de criar os casos de teste, os analistas de testes também podem colaborar com o product owner, ajudando-o a escrever os casos de teste de aceitação. Os analistas criam cenários de caso de teste, com base nos requisitos do usuário, identificando e documentando cenários complexos. A participação dos testadores durante o planejamento de entregas e iterações, quando as histórias de usuário estão sendo estimadas, pode ajudar o time a elaborar estimativas mais reais.

Ainda de acordo com Hasija (2012), os analistas de testes devem assumir a responsabilidade de planejar, organizar e envolver o time scrum nos testes. Considerando que poucos desenvolvedores gostam de fazer testes, os analistas e o scrum master devem procurar manter o objetivo e as metas de testes visíveis a todos e manter o time motivado. Todos os membros do time devem estar preparados para participar dos testes, sempre que requisitados. Essa prática mantém a equipe mais equilibrada, divide entre todos a responsabilidade de concluir os testes e dar a velocidade necessária para retornar os testes mais rapidamente, contribuindo para a aumentar a qualidade do produto. O analista de testes também deve registrar o resultado dos testes e reportá-lo ao product owner.

“A automação é o melhor amigo do analista de testes, pois possibilita maior capacidade de repetição, consistência e melhor cobertura dos testes de cada funcionalidade do software. De certa forma, isso é verdadeiro em um projeto Scrum, com ciclos de sprint curtos, de duas a quatro semanas, pois o analista geralmente tem pouco tempo para testar a aplicação. Durante cada sprint de duas semanas, o analista deve desempenhar os testes completos dos novos recursos sendo incluídos durante o sprint, assim como deve desempenhar testes de regressão completos para todas as funcionalidades já implementadas. Como seria esperado, essa responsabilidade cresce significativamente a cada sprint, na mesma proporção que a automação dos testes reduz a pressão sofrida pelos testadores.

Testes automatizados retornam rapidamente resultados, quando o Time implementa o processo de Integração Contínua. Sempre que é necessário construir uma nova versão do produto, os testes automatizados podem ser executados, retornando os resultados imediatamente, tanto para indicar se os novos recursos estão funcionando corretamente, como para dizer se houve problemas em recursos que estavam funcionando em versões anteriores. Sem automação, o analista de testes precisaria realizar esses testes manualmente - uma tarefa monótona e sujeita a erros. A automação dos testes é útil para detectar os defeitos o quanto antes, e para dar ao analista mais tempo para testar os casos limítrofes dos novos recursos sendo desenvolvidos. Por fim, a automação dos testes ajuda o analista a realizar os testes com muito mais eficiência e efetividade”.

Fonte: Hasija (2012).

Integração Contínua como Prática de Testes Ágeis

Saff e Ernst (2003) afirmam que o uso de metodologia ágil incentiva a criação do ambiente de integração contínua, no qual se mantém o código-fonte sempre testado e confiável, diminuindo a alocação de recursos humanos em atividades de teste, pois os métodos ágeis atuam com entregas imediatas, o que exige validação imediata.

A integração contínua é uma prática que normalmente utiliza ferramentas automatizadas, de forma que qualquer alteração no código provoca uma reavaliação de todas as rotinas.

Teste de aceitação

 

Fonte: Bakhtiar Zein

Desta forma, a integração contínua se torna viável com base na utilização de testes automatizados. De acordo com Vidal (2017, p. 221), a automação dos testes deve ser realizada em níveis diferentes. O autor sugere que os testes manuais sejam feitos apenas em casos exploratórios, deixando que a maior parte do trabalho de testes seja realizada de forma automatizada. Além de suportar a integração continuada, esta estratégia fornece agilidade ao trabalho do time e ainda reduz os custos do projeto, pois, uma vez que o teste seja escrito, este pode ser executado tantas vezes quanto for necessário.

No cenário de integração contínua, os testes de aceitação, a serem realizados pelo cliente, mantêm-se presentes. Estes testes ajudam a delimitar o escopo das funcionalidades que estão sendo construídas pelo time de desenvolvimento, além de fornecer feedback para decisões a serem tomadas pelo time.

Como já mencionamos quando tratamos dos testes automatizados, também é importante que, em métodos ágeis, os ambientes de desenvolvimento, teste e produção sejam mantidos separados e com condições de infraestrutura adequadas. Isso garante que os ambientes se mantenham controlados, assegurando que o produto não fique fracionado e tenha a qualidade mantida.

Vidal (2017), ainda propõe a criação de uma massa de testes, conforme indica a Figura. Esta massa de testes, além de contribuir para a redução da carga de trabalho, fornece insumos importantes para o time quando for necessário executar testes durante a construção do produto.

De acordo com a Figura, deve-se selecionar no backlog, que reúne as histórias do usuário, as que devem ser implementadas na release. Casos de uso e cenários devem ser criados para as histórias selecionadas, que servirão de insumos para se definirem os casos de teste, formando a massa de testes. Quando forem aplicados os testes de aceitação junto ao cliente, deve ser criada uma massa de dados adequada para a sua execução.

Criação da massa de testes

 

Fonte: Vidal (2017, p. 224)

Definida a massa de testes, é essencial o uso de uma ferramenta de integração contínua para executar os testes automatizados periodicamente, a fim de garantir que todos eles continuem passando, ou seja, funcionando adequadamente.

De acordo com Barbosa (2012), após a escolha da ferramenta de integração, deve-se informar à ferramenta

[...] o repositório no qual o projeto está armazenado (entende-se como repositório a URL em que o projeto está sob um sistema de controle de versão, como SVN, CVS, Git, Mercurial etc) e um conjunto de tarefas que devem ser executadas para garantir que a integração ocorreu com sucesso. Em geral, criam-se tarefas para a realização do build (quando necessário) e execução de um determinado tipo de teste. Por exemplo, se estamos desenvolvendo um projeto fictício chamado XPTO, criamos uma entrada na ferramenta chamada XTPO-Unit que, de tempos em tempos, irá baixar o código do repositório do controle de versão, executar o build e depois executar todo o conjunto de testes unitários existentes no projeto. Caso todos os testes passem, a integração ocorreu com sucesso; caso contrário, não.

Ainda segundo Barbosa (2012), algumas ferramentas de integração permitem a inclusão de plug-ins que fornecem serviços complementares como relatórios que informam quanto do código está coberto por testes, envio de mensagens por e-mail, informando ocorrência de eventuais falhas na integração etc.

As ferramentas automatizadas de integração contínua, na ocorrência de erro, disparam mensagens para os responsáveis, acusando uma integração mal sucedida. No caso de sucesso, também disparam mensagens informando que a operação foi realizada de forma bem sucedida. A isto se aplica um conceito chamado servidor de construção (build). Este servidor de construção atua como “juiz”, julgando ou considerando as alterações, validando-as quando detectado sucesso nos procedimentos. Em suma, integração contínua automatizada envolve a construção de um código e seu teste de forma automática, e em intervalos frequentes, em um servidor de integração.

Tipos de Testes Usados em Métodos Ágeis

Os processos ágeis se destacam dos métodos tradicionais de desenvolvimento, devido principalmente à priorização das funcionalidades através do código executável, ao invés da produção extensa da documentação escrita. Um ponto essencial para garantir a fidelidade das implementações em relação aos requisitos está nos testes executados sobre o código produzido.

Processos ágeis

Fonte: Digital Saint / shutterstock

Hendrickson (2012) afirma que, para a implementação de técnicas ágeis no ambiente de testes, é necessário mudar a maneira que as equipes estão acostumadas a trabalhar. Uma das mudanças necessárias é a introdução ao conceito de colaboração com o cliente, ao invés de se utilizar documentação abrangente, em consonância com o manifesto ágil. Desta maneira, passamos a fazer um trabalho mais próximo com o cliente, e sua participação no processo é peça-chave para que a técnica ágil de testes possa ser adotada. Outro ponto importante é que todos da equipe devem realizar testes, e não apenas o analista de testes. De acordo com a autora, em um método ágil costuma-se dizer que a equipe é contagiada por testes, e desta maneira o sistema é construído para ser testado desde o início do projeto, e não apenas no fim da codificação. A qualidade passa a ser da equipe toda, não somente dos analistas de testes ou profissionais que possuem a palavra “qualidade” nos seus cargos.

Os requisitos de testes para a metodologia ágil não possuem grande diferenciação em processos guiados por planos. O que realmente difere é o grau de importância dado aos testes em cada um dos processos.

Nos processos guiados por planos, existe uma série extensa de artefatos documentais resultantes da análise profunda realizada sobre o sistema a ser desenvolvido. Os testes, neste caso, são apenas mais um artefato produzido pelo processo, visando garantir a detecção de erros antes da liberação da versão final.

O projeto que nasce com cobertura de teste desde início permite a realização de testes de regressão, que implica em se executar testes em todo o sistema, e não apenas na funcionalidade implementada.

Ainda de acordo Elisabeth Hendrickson (2012), um sistema com cobertura de testes desde o início deve realizar o máximo possível de testes automatizados para que o trabalho manual e repetitivo não venha a ocorrer. Isso trará ganho de tempo na execução do teste, e o custo de transformar um caso de teste em automatizado rapidamente se paga. A autora afirma que “[...] eu tenho observado em minhas equipes um custo de 30% a mais na execução e transformação do teste em automatizado, mas após a 3ª vez que eu executo a bateria de testes, eu já vejo como este custo de 30% foi pequeno”. A autora segue dizendo que o tempo de execução do teste automatizado em relação ao manual é incomparável, os ganhos de velocidade de execução e a possibilidade de a qualquer momento realizar um teste de regressão são maiores.

Os testes em métodos ágeis devem seguir o conceito de pequenas interações para que a informação de como o sistema está sendo construído e os erros que são detectados possam ser rapidamente identificados e corrigidos. Ao término de uma interação, todos os testes devem ter sido executados com êxito.

Segundo Erdogmus et al. (2005), os testes nas metodologias ágeis são importantes, e os autores fazem as seguintes considerações em relação aos dois tipos de teste:

• Testes manuais: objetivam utilizar o sistema para tentar encontrar anomalias no funcionamento do software. Geralmente são pouco eficientes, pois dificilmente se conseguiria chegar à exaustão detectando todas as anomalias. Mas, mesmo com pouca eficiência e fragilidade, ainda são utilizados pela facilidade e simplicidade de sua aplicação, já que basta inserir o sistema em ambiente de validação, simular as entradas e considerar os resultados obtidos.
• Testes automatizados: utilizam aplicativos específicos que testam exaustivamente um software através de scripts preconfigurados. O fato de o teste ser automatizado não garante cobertura total, pois algumas falhas só ocorrem com uma combinação específica de entrada de dados. Um script bem definido colaborará muito para a eficácia dos testes, portanto, o profissional que definirá estes scripts é, na verdade, a chave para o sucesso desta atividade. Seu conhecimento e visão abrangente serão decisivos, assim como a análise dos resultados adquiridos versus resultados esperados serão essenciais na busca e identificação de anomalias.

Extreme programming – Metodologia ágil

 

Fonte: <astephan / shutterstock>

A metodologia ágil XP (eXtreme Programming) adota a técnica test-first, em que, para cada nova funcionalidade, a nova estória é interpretada e em seguida se escreve um teste que atenda especificamente esta nova funcionalidade. Na implementação do código, a implementação do teste é realizada, sendo adicionada à bateria de testes que já foram definidos pelas outras implementações. A implementação do código só será aceita após toda a bateria de testes ser realizada. Nesta modalidade, a implementação dos testes antecede a implementação do código da funcionalidade.

Em outra abordagem do XP, há o test-last. Neste caso, o mesmo conceito do test-first é aplicado, com apenas uma diferença: a implementação desses testes ocorre depois da implementação do código, sem alteração no restante do processo.