Processo de teste ágil x tradicional

A área de testes, dentro da engenharia e desenvolvimento de software, vem ganhando cada vez mais espaço dentro de instituições de ensino, empresas e organizações, formando e qualificando profissionais, agregando conhecimento e contribuindo muito para melhoria da qualidade e valor de produtos, sejam eles de quaisquer tipos de sistemas.

Quando testadores participam de projetos onde os processos ou determinada metodologia escolhida não é a melhor, ou não flui de uma maneira eficiente, muitas vezes ficam desmotivados ou frustrados, pois o processo e a metodologia utilizados não são os melhores para a situação. Um processo mal definido ou com má utilização contribui negativamente para fatores como alta rotatividade de pessoas, baixa eficácia de testes, atrasos ou demoras em entregas e, como resultado, temos um sistema instável, com muitos erros e clientes insatisfeitos.

Exemplificando essa situação, podemos pensar em um sistema cujo desenvolvimento não atinge o esperado nem pela empresa construtora, nem pela empresa contratante, a qual utiliza e paga pelo usufruto do sistema. Conclui-se que a empresa responsável pelas entregas ou desenvolvimento não possui processos bem definidos de testes e não trabalha na melhoria e evolução de seus produtos, escolhendo e gerenciando mal a metodologia utilizada. Em um mundo onde o mercado é cada vez mais competitivo, isso é inadmissível. Com a alta concorrência, jamais a empresa pode pecar em ter um produto razoável e de qualidade duvidosa porque a metodologia utilizada no ciclo de desenvolvimento é falha ou não suporta determinado tipo de projeto. Fazer uma escolha errada e não admitir alteração é pior do que fazer a escolha errada e reconhecer os erros. O mercado é muito exigente quando paga por um serviço e não recebe o acordado ou recebe com diversas falhas e erros.

Ao longo deste artigo, vamos mostrar e discutir sobre a importância de uma boa metodologia e sobre como defini-la para determinado projeto, uma vez que uma metodologia adequada para projetos pequenos e pouco complexos pode não se adequar bem para projetos maiores de alta complexidade.

O que é um projeto de software?

Podemos definir um projeto de software como sendo um empreendimento temporário dividido em ciclos de vida ou fases com o objetivo de criar um produto, serviço ou resultado único de forma a atender às especificações e expectativas de negócio. Os ciclos de vida de um projeto de software normalmente definem: qual trabalho técnico será realizado, quais entregas serão geradas em cada fase, como serão verificadas e validadas, quais as pessoas ou papéis estarão envolvidos em cada fase e como será realizado o controle e aprovação de cada fase.

Todo o processo de testes, metodologias, equipes e definições são realizados em projetos, por isso é crucial que o conceito esteja claro e bem definido.

Processo de testes de software

De forma geral, o processo de testes de software representa uma estruturação de atividades, etapas, artefatos, papéis e responsabilidades que buscam a padronização de equipes e trabalhos buscando uma forma de ampliar a organização, a qualidade e o controle dos projetos de teste.

Para melhor eficácia e eficiência, o processo de teste, como qualquer outro processo, deve ser revisto continuamente de forma a aperfeiçoar sua atuação buscando a melhoria contínua, além de analisar sua aplicabilidade e continuidade possibilitando aos profissionais envolvidos uma maior visibilidade e organização de seus trabalhos, o que resulta em uma maior agilidade e controle operacional dos projetos.

Independentemente das metodologias utilizadas nos projetos, o processo pode ser dividido em sete partes: planejamento dos testes, especificação dos testes, modelagem dos testes, disponibilização ou preparação do ambiente de testes, execução dos testes, análise dos resultados e encerramento do processo. Segue um breve detalhamento da composição de cada parte:

• Planejamento dos testes: é onde será definido como os testes serão realizados tendo como base as restrições do cliente em relação a prazos, custos e qualidade esperada. Fazem parte das atividades de planejamento: estudar o projeto (quais serão os requisitos, alterações de arquitetura do sistema, avaliar custos, riscos, prazos e impactos), realizar uma análise interna e externa de qual será o esforço (especificar quais serão as métricas utilizadas e fazer uma estimativa do esforço), definir os cenários possíveis (lista de prioridades e riscos), aprovação do planejamento (por meio de aceite da diretoria e dos clientes), definir responsabilidades (qual o papel de cada um no projeto) e mapear os artefatos (quais serão as documentações e onde será realizada a gestão do projeto).
• Especificação dos testes: nessa atividade são especificados os cenários e casos de teste considerando os requisitos especificados e a necessidade de cobertura dos testes a serem realizados. Casos de testes são escritos com base em requisitos ou documentos onde estão os critérios de aceite, casos de uso e checklists. Fazem parte das atividades de especificação: estudar os requisitos funcionais e não funcionais e demais documentos solicitados pelos clientes (com o objetivo de entender e identificar inconsistências ou pontos falhos), especificar adaptações da arquitetura dos testes (no que diz respeito às ferramentas utilizadas e exigidas, scripts de testes e de automação), identificar os casos de testes e cenários a serem validados (mapeando fluxos de casos de usos e garantindo que os requisitos estejam totalmente cobertos), refinamento e aceite dos casos de testes (por meio de uma reunião entre a equipe de teste, onde os casos de testes serão apresentados com o objetivo de encontrar pontos de melhoria e garantir a cobertura), definir as responsabilidades (qual o papel de cada membro na equipe de teste) e mapeamento dos artefatos (qual o padrão de casos de testes, quais ferramentas utilizar, onde reportar bugs).
• Modelagem dos testes: etapa onde é realizada a definição dos itens necessários para a implementação dos cenários de teste especificados. A tarefa central nessa etapa é a modelagem das massas de testes. Fazem parte das atividades de modelagem: criação dos roteiros de testes (identificação, especificação, organização e revisão dos roteiros e critérios de entrada/saída e de todos os procedimentos para execução dos testes), detalhamento da massa de testes (identificação dos pontos de validação, parametrização, detalhamento da massa de entrada/saída esperada), elaboração do plano de execução dos testes (identificação de quais sistemas estarão envolvidos, quais configurações de hardware, quais características e licenças de uso), quais artefatos e quais os papéis de cada membro da equipe também fazem parte da modelagem.
• Disponibilização ou preparação do ambiente de testes: atividades relacionadas à preparação do ambiente de testes da organização. Fazem parte das atividades de preparação do ambiente: instalação ou atualização do aplicativo a ser testado (atualização do sistema com últimas alterações e implementações, que inclui scripts de banco de dados e códigos fonte), instalação e homologação da arquitetura de testes (caso existam pontos automatizados) e geração da massa de dados (criação via tela, banco de dados ou scripts de um conjunto de informações que possam ser utilizadas para validação das alterações). A definição de papéis de cada membro da equipe de testes também faz parte da preparação do ambiente.
• Execução dos testes: etapa na qual os testes planejados são executados. Nessa etapa a coleta de artefatos e informações é importante para a validação plena das funcionalidades, de forma a garantir que os critérios de aceite foram totalmente ou parcialmente cobertos. Fazem parte da execução as seguintes atividades: execução dos casos de testes (seguindo prioridade pré-definida, coleta e análise de evidências, validação de conformidade e não conformidade) e confirmação dos resultados (revalidação das não conformidades e conformidades, análise de impactos). O papel de cada membro dentro da equipe de testes também faz parte da execução dos testes.
• Análise dos resultados: nessa atividade os resultados da execução dos testes são comparados com os resultados esperados. Aqueles que não estiverem em conformidade devem ser reportados em detalhes para facilitar a identificação dos defeitos pela equipe de desenvolvimento. Fazem parte das atividades de análise de resultados: revisão dos resultados de não conformidade (avaliar evidências de testes e avaliar e priorizar a lista de bugs), formalizar defeitos encontrados (coletar, detalhar e classificar os defeitos por nível de severidade e priorização), reexecutar testes falhos (avaliar impactos, reexecutar casos de testes com falhas e possíveis casos de sucesso — dependendo da correção, um defeito pode ocasionar outro). Também faz parte da execução dos testes o papel de cada membro dentro da equipe e quais artefatos serão utilizados como forma de evidenciar os testes executados (como prints de telas, gravação, geração de scripts, passo-a-passo, etc.).
• Encerramento do processo: nesta atividade são analisados indicadores extraídos durante a execução dos testes para o trabalho realizado de forma quantitativa e qualitativa. O resultado dessa análise permitirá registrar as lições aprendidas durante a execução dos testes. Fazem parte da atividade de encerramento de processo: extração de indicadores (indicadores quantitativos, de produtividade, confiabilidade, financeiros e de nível de satisfação, individuais e do projeto), resumo do processo de testes (registrar e analisar os indicadores de testes, lista de defeitos, horas planejadas x horas executadas, indicadores de sucesso, lições aprendidas, caminhos críticos e realizar uma divulgação corporativa sobre os resultados obtidos), versionamento dos processos de testes (versionar scripts, casos de testes, ferramentas, códigos fontes utilizados na automação, configurações e ferramentas de produtividade utilizadas), avaliação final e melhoria do processo (avaliar riscos planejados x concretizados, performance, atualizar plano de melhoria contínua e sinalizar o encerramento do processo).

De um modo geral, de uma metodologia para outra, poucas atividades são alteradas para os testadores. Normalmente o que difere é a ordem e a forma como as atividades são feitas, mas geralmente o processo não sofre alteração na sua essência. As poucas diferenças existentes serão tratadas e exploradas nos tópicos a seguir.

Desenvolvimento de software

Desenvolvimento de software é uma tarefa muito complexa, difícil e de alto risco. Inúmeros problemas são enfrentados diariamente, e nós, testadores, não estamos excluídos nesse processo, aliás, muito pelo contrário, como somos praticamente o final do processo, somos a ligação entre desenvolvedor e usuário.

Entre alguns desses problemas enfrentados, podemos destacar: alto consumo de tempo que supera estimativas e cronograma, funcionalidades que não solucionam os problemas dos usuários, baixa qualidade dos sistemas desenvolvidos, tempo para teste e qualidade reduzidos e, em alguns casos, até o cancelamento do projeto por inviabilidade.

Tendo como grande objetivo a redução de risco associado ao desenvolvimento de software, as metodologias definem uma maneira de trabalhar em projetos utilizando processos, sendo elas um conjunto de atividades e resultados associados que auxiliam no desenvolvimento e construção de softwares.

Metodologia tradicional

Nesse contexto temos a metodologia tradicional, possuindo como técnica ou modelo mais conhecido o modelo clássico ou cascata (waterfall), que também é conhecido como abordagem “top-down”. O modelo foi proposto por Royce em 1970, derivado de modelos industriais de diversos segmentos de engenharias; seu principal objetivo era de estabelecer ordem e padrão em desenvolvimento de software. Foi chamado de desenvolvimento tradicional, pois é a base para diversos modelos utilizados há décadas pela indústria de software e é considerado um modelo rígido de pouca flexibilidade, adaptabilidade e versatilidade, sendo utilizado em projetos de pequeno, médio e grande porte.

Grande parte de seu alto grau de aceitação e utilização está no fato de ser um modelo orientado para documentação, seja ela de qualquer tipo, como textos, representações gráficas, simulação, diagramas, casos de usos, entre outras. A ideia principal dessa metodologia é que o software é construído baseado em uma sequência de fases, sendo que cada uma delas depende da conclusão da outra para ser iniciada, com exceção da primeira, conforme ilustra a Figura 1.

Os resultados da primeira etapa, da Análise, são concluídos, então a saída “flui” para a segunda etapa, que é a de Projeto. Logo, quando a etapa de Projeto for concluída, sua saída ou resultado “flui” para a seguinte, sendo que uma etapa nunca se inicia antes da etapa anterior ser finalizada. As atividades são agrupadas em tarefas executadas sequencialmente.

Além do modelo clássico, existem também variações que são empregadas de forma iterativa e incremental, tendo ainda uma forte linearidade no processo, caracterizado por “cascatas menores” dentro de cada iteração.No decorrer das tarefas e para a conclusão das mesmas, fazem parte da metodologia tradicional algumas premissas que a influenciam, como:

• Linearidade do modelo: as atividades são feitas em sequência e uma só se inicia quando a anterior está finalizada;
• Determinismo: tendo como base as especificações, se elas forem seguidas rigorosamente, o resultado gerado também será o correto. Tem-se a ideia “equivocada” de que o uso do determinismo é uma forma de reduzir erros e perdas de tempo;
• Especialização: como as atividades são realizadas de forma independente, podem ser executadas por especialistas, com a rígida divisão de papéis entre seus membros, como analistas, projetistas, programadores, testadores e implantadores. Cada um realiza tarefas bem diferentes e especializadas e terão seus resultados integrados para compor o software finalizado;
• Foco na execução: como as pessoas são em sua grande maioria especialistas, as tarefas são simples e determinísticas, bastando a elas somente a execução. Presume-se que, se cada membro da equipe executar corretamente a tarefa que lhe cabe, a especificação será transformada corretamente em software. Isso gera uma grande valorização dos processos e, em consequência, uma grande desvalorização das pessoas no desenvolvimento de software;
• Crescimento exponencial do custo de alteração: o custo de uma alteração tende a crescer à medida que o processo de desenvolvimento avança.

Metodologia ágil

A metodologia ágil surgiu da necessidade de minimizar riscos e custos associados ao desenvolvimento de software. Para a utilização da metodologia ágil, o framework Scrum é a ferramenta mais indicada. É um framework pois facilita o uso de diversos processos e técnicas. O Scrum vem sendo utilizado como uma ferramenta para controlar e gerenciar o processo de desenvolvimento de produtos complexos que agregam maior valor para o cliente.

O framework Scrum é composto por ciclos de desenvolvimentos, mais conhecidos como Sprints, com duração fixa não ultrapassando mais de um mês. Ele é maleável, mas pouco adaptativo, ou seja, deve-se evitar ao máximo realizar mudanças desnecessárias que afetem o objetivo da sprint. Essas mudanças devem ser discutidas entre o product owner e a equipe de desenvolvimento.

Para a execução dos ciclos iterativos, o Scrum é composto por equipes com um número razoavelmente baixo de participantes para facilitar o gerenciamento, e, associados aos membros que formam as equipes, temos: papéis, artefatos e cerimônias.

• Papéis: em uma equipe ágil, existem três papéis: product owner, que é o responsável por maximizar o valor de retorno do produto para o cliente e fornecer o trabalho para o development team, que é formado pelos profissionais que irão trabalhar no desenvolvimento e teste de uma versão do produto. Ao final de cada iteração, o scrum master é o responsável por assegurar que o Scrum seja entendido e disseminado, por resolver impedimentos e ajudar o product owner e o development team;
• Artefatos: basicamente, são utilizados quatro artefatos:- Product backlog: engloba todos os requisitos que precisam ser implementados. Ele é controlado pelo product owner e priorizado de acordo com o valor de negócio para o cliente;- Sprint backlog: é uma lista de itens que define o objetivo da sprint. Esses itens são priorizados e aqueles que entram no sprint backlog são os que possuem maior valor de negócio apresentado pelo product owner;- Definition of Done: documento que explica quais serão as definições de concluído ou pronto para as user stories;- Burndown: gráfico que mostra o andamento do desenvolvimento do produto e do andamento da sprint. É utilizado para monitorar o andamento da sprint, indicando se as tarefas serão completadas de acordo com o planejamento.
• Cerimônias: no total são definidas cinco cerimônias:- Grooming: cerimônia realizada para apresentação e estimativa das histórias. Deve envolver os product owners e o development team. Com base nas alterações e levando-se em conta a complexidade, nível de abstração ou alterações, são realizadas estimativas de histórias que podem ou não entrar na(s) próxima(s) sprint(s) dependendo das prioridades negociadas entre o product owner e o cliente;- Sprint Planning: é a cerimônia de planejamento da sprint onde são definidas quais serão as user stories entregues. Após as definições das user stories que entram na sprint, cabe ao development team decidir como implementá-las durante a sprint, de modo que são realizadas quebras nas user stories em tarefas menores, chamadas de tasks. Nas tasks devem estar as atividades detalhadas que servirão como base para a conclusão da história;- Daily Scrum; é uma reunião diária e curta (máximo de 15 minutos) do scrum team com o objetivo de observar o progresso do desenvolvimento do produto. Cada membro do development team basicamente deve informar para os demais o andamento de seu trabalho, respondendo a três questões: O que foi feito desde a última reunião? O que pretende fazer até a próxima reunião? Quais os impedimentos que bloqueiam esse trabalho?;- Sprint Review Meeting: é a cerimônia na qual as user stories desenvolvidas são apresentadas para o product owner e demais envolvidos, e o product owner analisa se o que foi desenvolvido pode ser considerado concluído. O resultado dessa reunião é a definição se temos um incremento do software aprovado ou não pelo product owner;- Sprint Retrospective: é uma reunião aberta onde todos devem expressar suas opiniões a fim de implementar melhorias para as próximas sprints. Os pontos levantados devem ir para um plano de ação com itens a serem melhorados.

Testes na metodologia tradicional

Anteriormente vimos como o modelo tradicional funciona sob o ponto de vista de todos os envolvidos, agora vamos detalhar um pouco mais sobre as atividades da equipe de testes dentro desse contexto.

Nessa metodologia, a atividade de teste é realizada ao final de cada versão, sendo esse o momento em que o analista de testes analisa os requisitos a partir das especificações e das documentações geradas. Entre as atividades de teste podemos destacar:

• Plano de Projeto: atividade realizada entre o gerente de testes ou outro membro qualificado da equipe e demais gerentes de desenvolvimento, requisitos e o cliente. Esse documento descreverá a aplicação da estratégia de teste no sentido de evidenciar os níveis de teste e especificidades para o projeto em particular.
• Elaboração do documento de plano de teste: o gerente de teste ou outro membro da equipe qualificado deverá gerar o plano de teste baseando-se nas demandas existentes no plano de projeto, para isso deverá realizar o preenchimento do template ou modelo de plano de teste utilizado pela empresa. Esse modelo deverá conter algumas referências para apoiar o planejamento das atividades. O projeto e plano de testes devem ser criados na ferramenta utilizada pela empresa, a qual pode ser o jira, testlink, mantis, docs, entre outras.
• Solicitação da validação do documento de plano de teste: o gerente de teste ou o integrante qualificado para tal atividade deverá solicitar a validação do documento de plano de teste. Esse plano deverá ser validado e aprovado pelos stakeholders e, em casos em que haja necessidade, quando as características do projeto, como complexidade, tamanho e importância, forem críticas, pode-se realizar uma reunião de inspeção em grupo.
• Avaliação, convocação e solicitação de inspeção em grupo: essa atividade é orientada por um representante da equipe, intitulado líder de inspeção, que deverá avaliar se a lista de participantes proposta é suficiente para a inspeção e se o prazo entre o envio do material a ser inspecionado e a realização da reunião é suficiente para a preparação dos inspetores. Esse prazo é negociável e fica a cargo dos envolvidos. Para a inspeção é necessário seguir algumas formalidades na convocação dos participantes (nesse caso farão o papel de inspetores), como envio de convites via e-mail contendo a documentação anexa para que os inspetores leiam e avaliem o conteúdo do material, fazendo as anotações, sugestões, dúvidas ou melhorias pertinentes que deverão ser levadas para a reunião, além da data, horário e local da reunião. O objetivo da reunião é encontrar brechas e realizar melhorias e correções no documento, que devem ser feitas pelo gerente. Outra questão importante é manter um histórico de revisão dos documentos e, após as correções e melhorias, os documentos e artefatos gerados devem ser novamente encaminhados aos interessados.
• Realização da reunião de inspeção: o líder de inspeção e os inspetores se reúnem para discutir o material analisado e decidir qual será o resultado da inspeção. Os resultados, sendo eles sugestões ou alterações, serão registrados em um documento, podendo ser uma planilha de inspeção. Em caso de ausência de algum inspetor, deve-se avaliar a necessidade de cancelamento ou não da inspeção. Faz-se também, nesse caso, o acompanhamento de retrabalho, já que pode ocorrer de a inspeção ter algum documento reprovado. O líder de inspeção deverá acompanhar as correções na documentação. Uma nova reunião também pode ser necessária e deve ser seguido o mesmo padrão para sua convocatória e realização.
• Criação de cenários de testes: a documentação referente aos cenários de teste deverá ser preenchida conforme obrigatoriedade em um template seguindo um modelo específico. São nos cenários que as condições de teste são identificadas a partir de uma análise sobre os artefatos de especificação (documentos inspecionados nas atividades anteriores, normalmente são documentos de requisitos, casos de uso e/ou especificações funcionais), histórico existente e mesmo experiência do próprio analista de teste envolvido. Com a identificação das condições de teste, é possível agrupá-las de forma a obter uma maior otimização de importância/tempo/recursos na execução dos testes.
• Criação do plano de teste: documento que deverá conter as técnicas de teste a serem utilizadas para identificação das condições de teste e cenários de teste. Devem ser avaliadas possíveis fontes de dados existentes relacionadas ao projeto em questão, de forma a complementar os artefatos de especificação existentes. É papel do analista de teste ou do membro experiente na equipe o preenchimento e criação dos planos e cenários de testes, sendo necessário haver posteriormente a inspeção desse documento com a avaliação do analista de requisitos responsável pela documentação do projeto. A inspeção deve seguir o mesmo padrão da atividade relatada anteriormente nos itens “Avaliação, convocação e solicitação de inspeção em grupo” e “Realização da reunião de inspeção”.
• Criação dos casos de testes: nessa etapa deve-se utilizar os documentos e artefatos gerados anteriormente, como plano e cenário, e detalhá-los, informando as ações em passos e seus respectivos resultados esperados. A função do analista experiente é realizar uma análise nos documentos de testes com o intuito de escrever o passo-a-passo, contendo título, objetivo, pré-condições, passos e resultados esperados para que os cenários sejam validados. Esses documentos e os casos de testes devem ser armazenados na ferramenta utilizada pela empresa.
• Revisão e atribuição dos casos de testes: após os documentos de casos de testes serem concluídos, deve-se avaliar a possibilidade e a necessidade de haver revisão sobre eles para melhorar e analisar se todos os requisitos estão cobertos pelos testes. Havendo a necessidade, pode ser realizada uma reunião de inspeção seguindo também os passos 4 e 5 conforme citado no item “Criação dos casos de testes”, mas nessa etapa o importante seria a participação de todo o time de testes. Concluída a revisão, o caso de teste é atribuído ao responsável por executá-lo no sistema.
• Execução dos testes: primeiramente, o membro da equipe responsável pela execução do teste deve avaliar a disponibilidade do ambiente em que serão realizados os testes verificando os requisitos necessários especificados no plano de teste. Deve realizar também a identificação do banco de dados utilizado, informação que também deverá constar no plano de teste. A instalação ou atualização do sistema também é de responsabilidade do executor dos testes, caso não exista uma equipe específica alocada para esse fim. Caso haja alguma automação a ser realizada, ela deverá ser iniciada nessa etapa.
• Aceite e reprovação dos testes: é papel do testador identificar falhas e erros na execução dos testes, logo eles devem ser executados como consta na especificação. Para isso, o executor ou testador deve acessar a ferramenta utilizada e executar os casos de testes que lhe foram atribuídos, categorizando os resultados obtidos conforme um template, se houver, seguindo um padrão que pode ser: “Teste Passou” - execução sem falha; “Teste Falhou” - execução com falha (obrigatoriamente informando passo a passo resultados esperados e qual a falha); “Bloqueado” - impossibilidade de execução do caso de teste devido a um pré-requisito não atendido ou motivo que não possibilite avaliar o item desejado e “Não executado”. Os defeitos devem ser registrados e notificados aos responsáveis. Em alguns casos, quando são ou não identificados defeitos após o término da execução dos testes, se faz ou não obrigatória a confecção de um documento de comprovação dos testes, ficando a cargo dos envolvidos avaliar sua necessidade. Algumas vezes pode ocorrer de o defeito não ser priorizado ou não fazer parte do escopo inicial das alterações que estavam em teste. Nesses casos devem ser avaliados quais caminhos seguir.

Testes na metodologia ágil

Após conhecermos quais as atribuições e como funciona o teste na metodologia tradicional, vamos detalhar e explorar um pouco mais sobre as atividades da equipe de testes dentro da metodologia ágil.

Diferentemente da metodologia tradicional, a atividade de teste no sistema propriamente dito é um processo empírico, sendo realizado em todas as fases do projeto, do início ao fim, onde os profissionais de testes contribuem para o processo como um todo, validando os requisitos desde a sua criação até a entrega final. Como não há necessidade explícita de uma documentação extensa e abrangente, a comunicação entre a equipe é fator crucial de sucesso. Existe a validação de documentos em todos os passos e momentos do processo e isso contribui para o aprendizado de todos, já que todos participam de todo o processo. O analista de teste é responsável por monitorar se as atividades do time estão aderentes ao processo de desenvolvimento além de coletar as métricas do processo de teste.

Entre essas atividades realizadas, podemos destacar:

• Avaliação da documentação: com base na documentação ou artefatos é que os profissionais de teste membros do development team irão definir os cenários, fluxos e escrever os casos de testes. Dessa forma, logo que os artefatos forem apresentados, a equipe já deverá trabalhar para validá-los, participando do refinamento e eliminando possíveis brechas, pensando além do descrito nos documentos. Para isso, os testadores devem ler, entender e analisar as user stories. Nessa função deve-se ter sempre em mente a visão do usuário e quais são os possíveis casos reais que ele poderá executar.
• Criação da documentação de testes: com os artefatos revisados, melhorados e atualizados, deve-se dar início à escrita de casos de testes. A documentação de testes deve ser simples, direta e clara na medida do possível e deve descrever o passo-a-passo para validação dos critérios de aceite. Fazem parte dessa atividade a criação, manutenção e atualização dos documentos, além da criação de scripts. A documentação normalmente é criada em alguma ferramenta utilizada pela empresa e fica armazenada como histórico, servindo posteriormente como base de testes e criação de templates para funcionalidades mais complexas. Todos na equipe devem ser capacitados para criar a documentação de testes. É uma boa prática sempre realizar uma “validação” dos casos de testes escritos para verificar se a cobertura está completa e/ou se é necessário atualizar, acrescentar ou remover algum teste ou cenário que seja desnecessário. Essa validação pode ser feita por outro membro de testes do development team.
• Preparação do ambiente de testes: após os casos de testes e demais artefatos estarem concluídos, os profissionais devem fazer a preparação do ambiente que será utilizado nos testes. Essa preparação poderá incluir a montagem do ambiente, que engloba configuração no banco de dados, instalação e configuração de máquinas virtuais e servidores. Além disso, tem-se também a criação de massa de dados e parametrização no sistema, com o objetivo de deixar o ambiente completo e preparado para receber as atualizações e alterações para o teste. Além dos testadores, pode haver times específicos que trabalham para a disponibilização do ambiente.
• Execução dos testes: após a criação dos casos de testes e demais artefatos, e a verificação de que o ambiente está disponível e com as alterações das user stories aplicadas, os testadores podem iniciar a execução. A instalação ou atualização do sistema pode ser de responsabilidade da equipe de testes caso não exista uma equipe específica alocada para esse fim. Os testes são executados seguindo os artefatos criados e demais documentações. Após a execução, o testador deverá observar se algum outro cenário ou caso não foi coberto pelos artefatos, por isso, testes exploratórios são muito importantes. Sempre deve haver uma boa comunicação entre o time de testes e desenvolvimento dentro do development team, possibilitando a troca de informações, análise do que foi alterado, dúvidas e outras questões que podem ser tratadas.
• Aceite e reprovação dos testes: quando algum comportamento estranho é identificado, é reportado ao desenvolvedor para que possa ser corrigido e depois retestado. Os resultados obtidos também devem ser categorizados conforme um template, se houver, seguindo um padrão, que pode ser: “Teste Passou” - execução sem falha; “Teste Falhou” - execução com falha (onde deve ser informado o passo-a-passo, resultados obtidos e esperados e qual a falha); “Bloqueado” -impossibilidade de execução do caso de teste devido a um pré-requisito não atendido ou motivo que não possibilite avaliar o item desejado e “Não executado”. As user stories somente são aprovadas após todos os defeitos priorizados serem corrigidos e retestados. Após isso, cabe ao product owner e/ou analista funcional realizar o aceite.

Diferenças entre as metodologias

A metodologia tradicional é fundamentada em processos definidos e a metodologia ágil em processos empíricos. De forma mais resumida e direta, podemos observar na Tabela 1, e também na Figura 2, o que foi discutido até aqui, enfatizando as diferenças e características entre os dois tipos de metodologias, sendo que todos os pontos levantados afetam direta ou indiretamente o processo de testes e a forma sob como e quando são executados.

Vantagens e desvantagens de cada metodologia

As duas metodologias vistas até aqui, de um modo geral e do ponto de vista do teste, possuem suas vantagens e desvantagens. Agora que já sabemos como é o funcionamento e quais as diferenças entre elas, vamos observar na Tabela 2 as vantagens e desvantagens da metodologia tradicional e, na Tabela 3, as vantagens e desvantagens da metodologia ágil para então concluirmos em análise, qual delas é viável ou inviável para um determinado projeto.

Análise comparativa

Já vimos que as metodologias possuem seus pontos altos e baixos, as diferenças entre elas e como funciona o processo de testes dentro de cada uma. Em síntese, todos os modelos assumem que o projeto irá passar por cada etapa apenas uma vez. A diferença é que o ágil preza por uma melhor comunicação, ciclos incrementais, pouca documentação e retrabalho antes da entrega ao cliente e não após a entrega como funciona no modelo tradicional.

A seleção da abordagem mais adequada dependerá de diferentes variáveis, como: características de cada projeto, da empresa e do que é requisitado pelo cliente. Metodologias tradicionais costumam ser mais indicadas em cenários mais formais, além de serem mais recomendadas caso a equipe seja grande e os sistemas a serem desenvolvidos sejam de alto risco (muitas vezes requerem mais documentação). Já métodos ágeis são normalmente mais recomendados para equipes pequenas nas quais a flexibilidade diante de constantes mudanças é fundamental. Embora isso não queira dizer que abordagens ágeis, como o Scrum, não sejam recomendadas para projetos grandes. Vale lembrar que se, na visão do cliente, o produto apenas faz sentido quando for entregue completo, então utilizar métodos ágeis pode não ser a escolha mais adequada.

A escolha da metodologia também deve levar em conta a cultura da empresa, que em situações onde a metodologia ágil pode ser utilizada, não é possível implantá-la, pois o development team não é familiarizado com essa forma de trabalho, com entregas rápidas e percepção de valor antes do produto final. No caso, optar pelo ágil pode aumentar drasticamente os gastos, já que a equipe precisará de treinamento, absorção de conhecimento, além da curva de aprendizado.

Outros fatores que ajudam na escolha da metodologia podem ser: nível de maturidade dos processos na empresa, natureza da aplicação ou sistema, acordos com clientes e tendências de mercado. Cada modelo possui cenários de trabalho diferentes para tratar esses pontos, mas ambos podem ser utilizados. Uma análise de alguns pontos, como o development team, a cultura da empresa, os riscos do projeto, acordos com clientes e gastos, combinados com os pontos positivos e negativos de cada método apresentado devem ajudar a escolher qual a melhor opção.

Existem casos onde, por motivos que levam desde a adaptação até a complexidade do negócio, as duas metodologias podem andar lado a lado, de forma que uma apoie a outra, combinando características das duas metodologias. Pode parecer estranho, mas é muito comum.

Ambas as abordagens são excelentes dentro do que propõem, mas não perfeitas,e possuem pontos altos e baixos em áreas específicas ou em determinados tipos de aplicações utilizadas em projetos distintos.

Ao longo deste artigo, vimos alguns conceitos relativos a processos, desenvolvimento de software, processos de testes, como funcionam as metodologias e como elas podem ajudar ou atrapalhar dependendo do tipo de projeto, analisando suas vantagens e desvantagens.

Definir uma metodologia ou saber como utilizá-la tem fator de importância decisivo entre obter ou não sucesso. Uma má definição ou, ainda, uma má utilização dos recursos providos por elas aumenta consideravelmente os riscos do projeto não obter êxito. Saber utilizar é tão importante quanto a escolha de qual delas utilizar. A definição da metodologia impacta drasticamente na qualidade, já que a equipe de testes é afetada diretamente. Além disso, a escolha da metodologia também afeta a escolha do perfil de profissionais necessários para compor a equipe.

Testes são fundamentais atualmente e fatores como tecnologia, desempenho, performance, rapidez em resposta e qualidade são indispensáveis e devem fazer parte do cotidiano de todos os profissionais e membros do development team. Eles devem ter sempre em mente a intenção de melhoria de qualidade final dos sistemas ou produtos. Toda a equipe deve estar qualificada e engajada no propósito de produzir um produto de confiança e com a velocidade esperada pelos seus clientes. A forma com que isso será feito é onde a metodologia atua.

Criar mais ou menos documentos não é fator decisivo para a escolha de uma metodologia, mas poder opinar, discutir pontos e propor melhorias, sim. Nesse caso, a metodologia tradicional é muito mais engessada do que a ágil, já que a ágil abre espaço a discussões e opiniões de todos os envolvidos, enquanto que na tradicional pouco disso é aproveitado, pois a equipe de testes é tardiamente envolvida.

Mais do que uma mudança, a escolha quebra o paradigma de que só existe uma forma de sucesso para desenvolver e fabricar software. Vimos que tudo depende de vários fatores e, com toda certeza, pode-se ter sucesso tanto com o ágil quanto com o tradicional.

Com diferentes métodos podemos ganhar agilidade, tempo e melhoramos a nossa qualidade nas entregas, mas não garantimos obtenção de sucesso. Para aprimorar a decisão sobre a escolha de métodos, nada melhor do que ter em mente os seguintes pontos: quão receptivos a mudanças são os profissionais que fazem parte da equipe? Qual o acordo sobre entregas com o cliente? Qual nível de exigência do cliente em relação a qualidade? Qual o tamanho da equipe que irá trabalhar no projeto? Qual o nível de conhecimento dos profissionais que fazem parte do time? Qual o risco que se está disposto a assumir para o negócio? Baseado nessas questões e analisando as duas metodologias, conseguimos escolher qual é melhor ou pior para se obter sucesso dentro de um projeto.