Logomarca IETEC

Buscar no TecHoje

Preencha o campo abaixo para realizar sua busca

Qualidade de software em projetos que utilizam metodologia Scrum

Isabela de Oliveira Gonçalves

Analista de Testes da Marph Serviços e Soluções, graduada em Sistema de Informação e pós-graduada em Engenharia de Software pelo IETEC.

 

RESUMO

A crescente competitividade do mercado, a globalização, a transformação da sociedade industrial numa sociedade baseada na informação, estão desafiando as empresas, exigindo mudança na maneira de gerir, tornando a tecnologia ferramenta fundamental para o crescimento e sobrevivência das organizações. Para isso é necessário que os softwares respondam rapidamente à essas mudanças, para atenderem às expectativas das organizações que os utilizam; com isso surge um desafio: a entrega rápida de softwares de alta qualidade e que atendam às necessidades dos usuários, e para conseguir este objetivo se faz necessário à validação das funcionalidades através de Testes de software. Somente através dos testes é possível garantir a qualidade do produto a ser entregue.

Palavras-chave: Qualidade, Teste de software, Scrum.

1. INTRODUÇÃO

Atualmente com o avanço da tecnologia, e a crescente competitividade no mercado de TI, as empresas se veem obrigadas a desenvolver, testar e entregar softwares com maior agilidade. Outra preocupação das empresas é que essas entregas gerem satisfação dos clientes, para isso é necessário que esses softwares funcionem de acordo com a especificação, e que erros sejam minimizados, gerando garantia de qualidade do produto e confiabilidade entre empresa e cliente.

Muitas empresas tem utilizado metodologias ágeis para adequarem seus processos de desenvolvimento de software, pois estas prometem aumentar a satisfação do cliente através do desenvolvimento de software com alta qualidade em um curto prazo, como por exemplo o framework Scrum. (SOMMERVILLE, 2011)

Diante dos fatos descritos nos parágrafos anteriores é possível levantar a seguinte questão norteadora deste estudo: como e em que momento são realizados os testes das funcionalidades durante o ciclo de vida de um projeto, que utiliza metodologia Scrum, para a garantia da qualidade do produto final entregue ao cliente?

1.1 Objetivo

O objetivo deste artigo é analisar como são realizados os testes durante o desenvolvimento de um projeto que utiliza a metodologia Scrum, para a garantia da qualidade na entrega do produto final.

1.2 Justificativa

A escolha deste tema justifica-se pelo seguinte fato: o Scrum prega que o desenvolvimento de uma funcionalidade deve ser realizado em um curto prazo, entregando-se sempre um produto de qualidade para o cliente. Neste cenário é necessário analisar qual é o ponto de partida e como são realizados os testes do software em desenvolvimento, para que seja garantida a qualidade do mesmo na entrega do produto final.

2. REFERENCIAL TEÓRICO

2.1 Teste de Software

Teste de software se fundamenta na execução do software de uma forma controlada, para a verificação e validação, através da avaliação do seu comportamento. Através desta avaliação é possível relatar o estado do software e repassar esta informação aos interessados. A realização de um bom teste depende do seu planejamento, testar o sistema aleatoriamente não é uma boa prática, o registro do que está sendo testado permite menor esforço e ganho de tempo. (NOBIATO, 2014)

Segundo Claudio (2014), através dos testes é possível verificar se a execução do produto atingiu as expectativas esperadas, e se ele funcionou corretamente no ambiente para o qual ele foi projetado; é durante os testes que as falhas do produto são reveladas para consequentemente serem reportadas à equipe de desenvolvimento para serem tomadas medidas corretivas.

2.2 Scrum

O Scrum é um framework usado para gerenciar projetos ágeis, é muito utilizado para o desenvolvimento de software, mais pode ser utilizado para o gerenciamento de desenvolvimento de qualquer produto, por ser um framework iterativo e incremental. Dentro deste framework podem ser inseridas diversas técnicas e processos, trazendo melhora para as praticas de desenvolvimento gradativamente. (CRUZ, 2013)

O scrum possui 3 fases que são planejamento, ciclos da Sprint e encerramento do projeto (SOMMERVILLE, 2011). Uma Sprint é uma unidade de planejamento, com um tempo fixo, onde o que será entregue ao cliente é definido, os recursos que irão atuar no trabalho desta entrega são determinados e o produto é implementado, ao final de cada Sprint o trabalho é revisado e apresentado aos envolvidos do projeto, com isso o produto é construído iterativamente. Cada iteração (LARMAN, 2005) possui suas próprias atividades de análise de requisitos, projeto, implementação, teste e entrega; o implemento entregue após a iteração é um sistema parcial que pode ser executado, testado e integrado.

2.2.1 O time Scrum

O conjunto de profissionais envolvido em um projeto que utiliza a metodologia Scrum é chamado de time. De acordo com Schwaber e Sutherland (2014), os times são auto-organizáveis, pois ao invés de serem dirigidos por outros que estão fora do projeto, o próprio time escolhe qual a melhor forma de completarem o trabalho, com isso o time tem toda as confiabilidade para concluir o trabalho que está sendo realizado sem depender de fatores externos. “O Time Scrum é composto pelo Product Owner, o time de desenvolvimento e o Scrum Master.” (SCHWABER, SUTHERLAND, 2014)

2.2.1.1 Product Owner

O Product Owner, ou dono do produto, é o gerenciador do Backlog do Produto (que é a lista do trabalho a ser feito em uma Sprint), é ele que define os itens de backlog, garante o valor do trabalho da equipe de desenvolvimento, promove a visibilidade, transparência e entendimento do backlog para a equipe, e define o que será feito posteriormente. É uma pessoa que pode representar os desejos de um comitê, porém qualquer alteração nas prioridades dos itens de backlog deve ser decidido por ele. Mesmo que o time de desenvolvimento execute o trabalho, o product owner continua sendo o responsável pelos trabalhos. (SCHWABER, SUTHERLAND, 2014)

2.2.1.2 Time de Desenvolvimento

O Time de Desenvolvimento é responsável por entregar o backlog “Pronto” ao final de cada Sprint, são eles que criam os incrementos. São autorizados a gerenciar seu próprio trabalho, com isso são equipes auto organizadas, podendo definir suas ferramentas e métodos de desenvolvimento, sem que ninguém interfira nos trabalhos. As equipes de desenvolvimento também são multifuncionais, portanto possuem habilidades para criar o incremento do produto. Não existe subequipes como teste ou análise de negócios, portanto não há títulos para os integrantes da equipe, com exceção do desenvolvedor. O tamanho da equipe de desenvolvimento deve ser pequena o suficiente para se manter ágil, porém grande o suficiente para completar os trabalhos no tempo estimado. (SCHWABER, SUTHERLAND, 2014)

2.2.1.3 Scrum Master

Segundo Desenvolvimento Ágil (2014) o Scrum Master pode ser considerado um facilitador, no sentido de assegurar que nenhum fator externo comprometa o andamento da Sprint. Ele também assegura que a equipe respeite os valores e práticas do Scrum, mantendo o foco da equipe. Qualquer pessoa da equipe pode ser o Scrum Master, porém habitualmente o cargo é exercido por um líder técnico ou gerente de projeto (http://desenvolvimentoagil.com.br/scrum/scrum_master).

2.2.2 Eventos Scrum

Os eventos existem no Scrum para a criação de rotinas e minimização de reuniões inesperadas durante o processo de implementação do software. Todos os eventos no Scrum possuem uma duração, isso evita desperdício de tempo, e ganho de produtividade. Os eventos são importantes, pois através deles o projeto ganha transparência. (BONFIM, 2014)

Sprint

A Sprint pode ser considerada o coração do Scrum, é durante sua existência que o produto é implementado pela equipe de desenvolvimento, e no final dela é entregue o incremento utilizável do produto. Cada Sprint possui uma definição do que deve ser entregue, junto com o prazo, que geralmente varia entre 2 a 4 semanas, não podendo passar disso. Caso haja alteração no escopo, é necessário que o Time de Desenvolvimento e o Product Ower se reúnam para negociarem prazos e alterações na Sprint. (BONFIM, 2014)

Reunião de Planejamento da Sprint

Nesta reunião são definidos os itens que farão parte da próxima Sprint. Duas questões devem ser respondidas nesta reunião: (BONFIM, 2014)

- O que será entregue como incremento ao fim da próxima Sprint?

- Como o trabalho será realizado para que esse incremento seja entregue?

O tempo de duração da reunião de planejamento será proporcional à duração da Sprint, por exemplo, para uma Sprint de um mês, a reunião irá durar em média 8 horas, para Sprints menores esse tempo será proporcionalmente menor. (SCHWABER, SUTHERLAND, 2014)

Reunião Diária

As reuniões diárias envolvem todos os membros da equipe, e são realizadas com o intuito de analisar o progresso do desenvolvimento do produto, e caso necessário alterar a prioridade dos trabalhos. Durante esse evento, o time está isolado do cliente, e o Scrum Master tem papel importante neste momento, pois é ele que irá registrar as decisões e medir o progresso do que está sendo realizado. É neste momento também, que a equipe expõe os impedimentos que ocorreram no dia, impossibilitando a realização das atividades diárias, e o que está planejado para ser feito no dia seguinte. A reunião diária é rápida, e é realizada com os participantes em pé (‘stand-up’), para o foco da equipe. (SOMMERVILLE, 2011)

Revisão da Sprint

A reunião de revisão da Sprint é realizada com o Time Scrum e com as partes interessadas; durante a reunião de revisão é apresentado o incremento, e o Product Owner definirá o que está „Pronto‟ e o não está „Pronto‟. Esta reunião é importante pois através dela a equipe discute quais os problemas ocorreram durante a Sprint, o que pode melhorar, as lições aprendidas; essas informações são valiosas para a próxima reunião de planejamento, a caráter de melhoria de cada Sprint que se segue. (SCHWABER, SUTHERLAND, 2014)

Retrospectiva da Sprint

Segundo Freire (2014), é na reunião de retrospectiva da Sprint, que é identificado o „o que deu certo‟ e o que „não deu certo‟. É um momento de reflexão, onde são levantados os impedimentos que atrapalharam o desempenho do time, e as lições aprendidas durante a execução da Sprint, por isso participam desta reunião apenas os membros da equipe e o Scrum Master.

3. PERCEPÇÃO

Scrum é uma estrutura para gerenciamento de processos ágeis, onde as esquipes se auto-organizam para definirem um plano de entrega das funcionalidades de maior valor no menor tempo possível, com isso a documentação é reduzida consideravelmente, pois o foco é na entrega rápida do produto em funcionamento. Diante deste cenário percebe-se a dificuldade dos analistas de testes em realizar o levantamento dos cenários e casos de testes, pela falta de documentação. Porém, o papel do analista de testes em um projeto Scrum vai muito além de elaborar casos de testes, enquanto em métodos tradicionais ele é envolvido somente no final do projeto, no Scrum ele tem um papel importante desde o levantamento de requisitos até a entrega do produto. O analista de testes, através de seu olhar crítico e clínico, conseguem apoiar a equipe, questionando e criticando os requisitos, sendo portanto um porta voz do Product Owner.

Durante a realização da Sprint, o analista de testes tem os seguintes papéis:

Escreve os casos e cenários de testes. Executa os testes a cada entrega de funcionalidade. Automatiza os testes. Auxilia os desenvolvedores na execução dos testes unitários. Reporta os erros e inconformidades a equipe de desenvolvimento para correção. É ele quem diz quando o produto está „pronto‟.

O seu foco é na qualidade do produto, ele deve garantir que o que foi feito está de acordo com o que foi levantado com o cliente, ou seja, o que está descrito na documentação anteriormente aprovada pelo cliente.

Segundo Dutra e Silva (2014), os principais benefícios do teste de software em um projeto ágil são:

- Software correto: Uma vez que o cliente está diretamente envolvido no projeto, é assegurado que o que será entregue satisfaz os requisitos de acordo com sua prioridade.

- Qualidade: Os testes são realizados durante todo o ciclo de vida da Sprint, com isso o foco é na qualidade do que está sendo desenvolvido.

- Prazos e custos: Como o desenvolvimento é realizado através de iterações curtas, os atrasos são menores; isso incentiva a entrega constante o mais rápido possível.

- Alertas mais cedo: Como os projetos são curtos, os problemas são identificados e resolvidos com maior antecedência.

Por se tratar de um processo ágil, os feedbacks em relação a erros encontrados durante os testes devem ser reportados o quanto antes a equipe de desenvolvimento, para que medidas corretivas sejam tomadas o mais rápido possível, para que não seja comprometido o prazo de entrega do produto. Um dos princípios do Scrum é o trabalho em equipe, com isso a sincronização entre as tarefas de cada equipe é um fator positivo, pois o reporte de erros fica mais fácil, uma vez que todos da equipe estão engajados no projeto.

A parte negativa do teste de software em um projeto que utiliza a metodologia Scrum, é que como a equipe é multidisciplinar, muitas das vezes o teste é realizado pelo próprio desenvolvedor, o que não é suficiente, e muitas das vezes não é efetivo, pois o desenvolvedor está „viciado‟ em seu código, e dificilmente realiza casos de testes de alta complexidade.

4. CONCLUSÃO

É necessário que a equipe perceba a importância da participação do analista de testes durante todo o clico de vida de uma Sprint. A qualidade do software depende de todo o time, mais é responsabilidade do analista de testes direcionar a equipe neste processo de melhoria do software.

Baseado no estudo realizado percebeu-se que ainda existe uma dificuldade no processo de teste de software dentro de um projeto ágil, uma vez que as entregas são realizadas em um curto período de tempo. A problemática da qualidade dos testes realizados por todos os integrantes da equipe também é um fator relevante, pois a visão do analista de teste é muito mais criteriosa comparada ao teste realizado por um outro membro da equipe.

REFERÊNCIAS

BONFIM, Márcio. Introdução ao Scrum. Disponível em: . Acesso em: 23 fev. 2014

CLAUDIO, Arilo. Introdução a teste de software. Disponível em: . Acesso em: 22 abr. 2014

CRUZ, Fábio. Scrum e PMBOK, unidos no gerenciamento de projeto. Brasport, 2013.

DESENVOLVIMENTO ÁGIL. Disponível em: . Acesso em 22 fev. 2014.

DUTRA, Maíra; SILVA, Patrícia. Utilização de Processos Ágeis no Teste de Software. Disponível em: . Acesso em: 20 abr. 2014.

NOBIATO, Adalberto. O que é teste de software? Disponível em: . Acesso em: 22 abr. 2014

LARMAN, Craig. Utilizando UML e padrões, Uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. Bookman, 2005.

SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum. Um guia definitivo para o Scrum: As regras do jogo. Disponível em: < https://www.scrum.org/Scrum-Guide >. Acesso em: 21 fev. 2014.

SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.

Indique este artigo a um amigo

Indique o artigo