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.

Testes em Métodos Ágeis

Métodos ágeis e testes de software

A modelagem ágil é uma realidade para as empresas que necessitam de desenvolvimento eficiente. Os métodos ágeis estabelecem um conjunto de práticas no desenvolvimento de software que está cada vez mais se tornando habitual. Mas, diferente do que muitos pensam, não existe um modelo predefinido ou um conjunto de regras a serem adotadas.

Desenvolvimento ágil

Fonte: Trueffelpix / shutterstock

Na modelagem ágil, cada equipe, dentro de suas atribuições e de acordo com as características dos projetos da empresa, adota uma forma ágil mais adequada para atender suas demandas. Isto quer dizer que, em modelagem ágil, apenas é mostrado o caminho, e a equipe adota as práticas mais adequadas dentro do conceito ágil. Não há procedimentos ideais preestabelecidos apenas princípios adotados a partir da necessidade particular do negócio.

Segundo Highsmith e Cockburn (2001), a novidade nos modelos ágeis não está nos métodos ágeis, mas no envolvimento de pessoas que participam no sucesso do projeto e que estão focadas na capacidade de gestão do negócio.

A modelagem ágil visa colocar em prática o conjunto de valores que o negócio já possui. Vamos imaginar um brainstorm no qual todas as ideias são apresentadas e depois colocadas em uma desafiadora sequência de ações e procedimentos. A modelagem ágil começa a ser aplicada desta forma. Durante este processo é que definimos os procedimentos relacionados aos testes de software.

Vamos voltar a um conceito antigo relacionado à lógica de programação. Os mais experientes se lembram de que, muito antes de começar a desenvolver um programa, o programador desenhava um diagrama de fluxo de dados estruturado do sistema e somente depois começava a programação em si. Estes profissionais mais experientes entendiam que, se você soubesse passar por esta fase antes da programação, a linguagem de programação seria apenas um detalhe. Assim, você poderia escolher qualquer linguagem, pois a lógica de funcionamento seria a mesma. Na modelagem ágil ocorre o mesmo: a linguagem é um detalhe que pode ser pensado e adotado depois do entendimento dos requisitos que o software precisa atender.

Em teste de software, encontramos a figura do testador, que atua junto com a equipe de desenvolvimento estabelecendo técnicas ou definindo conceitos que serão aplicados durante o desenvolvimento para testar a integridade e validar os resultados.

De acordo com Nogueira (2016), uma equipe ágil reúne basicamente dois times:

• o time do cliente, que representa os que estão do lado do negócio no projeto e tem a responsabilidade de escrever histórias e funcionalidades que fornecem os requisitos que o time de desenvolvimento utiliza para a criação do produto;
• o time de desenvolvimento, que reúne todos os programadores, com papeis que variam conforme as necessidades do projeto, responsáveis por transformar as histórias do time do cliente em software.

Seguindo as práticas ágeis, esses dois times trabalham próximos na maior parte do tempo e colaboram para que o resultado do trabalho resulte em um produto que agregue valor para a organização. Muitos times ágeis não possuem membros com a função de testadores. Entretanto, o time de desenvolvimento precisa de alguém que ajude na tarefa de escrever testes, verificar se as histórias estão de acordo com os requisitos e automatizar os testes de regressão, que são essenciais para que haja um feedback rápido e contínuo sobre a qualidade do produto sendo desenvolvido.

Assim, Nogueira (2016, s/p) define o testador ágil como

[...] aquele profissional que abraça as mudanças, colabora com pessoas técnicas e de negócio e entende o conceito de usar testes para documentar requisitos e guiar o desenvolvimento. Esse profissional tende a ter bons conhecimentos técnicos para colaborar com o time de desenvolvimento a automatizar os testes e também para explorar o sistema à procura de comportamentos, erros e problemas.

O testador não precisa ser um componente externo, pois, dependendo das definições prévias das funções do time, ele poderá ser um dos integrantes de dentro do time de desenvolvimento. Este testador será um membro valioso e, como tal, participará ativamente no apoio para as entregas consecutivas que ocorrem no método ágil de desenvolvimento.

“Equipes de desenvolvimento ágil trabalham com testes automatizados. Ter agilidade e não contar com as atividades específicas automatizadas não condiz com o mundo real. O que aconteceria se todos os testes tivessem que ser aplicados manualmente pela equipe a cada incremento de código? Acredito que você saiba a resposta: desperdício de tempo, retrabalho e falta de qualidade.”

Fonte: Vidal (2017, p. 220).

O Manifesto ágil (BECK et al., 2001, s/p, tradução nossa) diz que:

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

- Indivíduos e interação entre eles, mais do que processos e ferramentas

- Software em funcionamento, mais do que documentação abrangente

- Colaboração com o cliente, mais do que negociação de contratos

- Responder a mudanças, mais do que seguir um plano

Seguindo os princípios ágeis, em intervalos regulares, o time deve refletir sobre como se tornar mais eficaz e então refinar e ajustar seu comportamento de acordo. Portanto, podemos perfeitamente concluir que as condições ideais existentes que levam um negócio a implantar o modelo ágil também são ideais para se implantar os testes de software de forma muito eficiente.

Assim, o mesmo princípio de modelo ágil se aplica em teste de software: não existe uma fórmula mágica padronizada e ideal, cada empresa, de acordo com suas necessidades específicas, adotará o procedimento ideal. E se este modelo não existir, deve ser criado um que atenda as suas necessidades.

Desta forma, exposto o cenário em que os métodos ágeis se aplicam, podemos chegar à definição do que são os testes ágeis.