42
4.1 RESULTADO GERAL
Este relatório contém 25 casos de testes, subdivididos em 40 casos, sendo que destes, 21 são Testes de Aplicação de Banco de Dados (TBD) e 19 são Testes de Integração das Camadas (TIC). A tabela 4.1.1 apresenta o resultado geral dos testes:
Tabela 4.1.1 – Resultado Geral dos Testes
Sucesso Falha
TBD 16 (76,19 %) 5 (23,81 %)
TIC 6 (31,58 %) 13 (68,42 %)
4.2 RESULTADO DO TBD
A tabela 4.2.1 apresenta os resultados e motivos de falha dos Testes de Aplicação de Banco de Dados.
Tabela 4.2.1 – Resultado / Motivo de Falha do TBD
Quantidade Motivo
4 Restrição de campo incorreta
1 Informação do campo inconsistente
4.3 RESULTADO DO TIC
A tabela 4.3.1 apresenta os resultados e motivos de falha dos Testes de Integração das Camadas.
Tabela 4.3.1 – Resultado / Motivo de Falha do TIC
Quantidade Motivo
43
4.4 CONSIDERAÇÕES
A princípio as atividades de teste relacionadas neste relatório foram priorizadas em níveis de sistema e aceitação. Contudo observou-se um índice de rejeição superior a 55% no resultados dos mesmos, categoricamente identificado pela falta de implementação dos respectivos módulos. Consequentemente, tornou-se inviável a aplicação do sistema SCAI em ambiente de produção (ver seção 2.9).
Assim, os casos de testes foram adaptados e endereçados em sua maioria à aplicação de banco de dados, com os resultados descritos acima.
Finalmente as seguintes características foram identificadas: 4.4.1 Gestão do Projeto
Positivamente foi escolhida a metodologia de desenvolvimento ágil Scrum para gestão do projeto SCAF. No entanto sua aplicação não foi satisfatória. Os principais motivos identificados são:
• falta de comunicação entre os integrantes das três disciplinas envolvidas no projeto;
• falta de treinamento no Scrum;
• incompletude de requisitos e casos de testes;
• sprints não produziram produtos de software completos; • definição tardia do PO.
4.4.2 TDD e Refatoração
A criação de testes para auxílio na especificação dos requisitos tem a cada dia se tornado mais indispensável no desenvolvimento de projetos ágeis. Assim como a utilização de padrão de codificação e refatoração. Ambas as características não foram aplicadas neste projeto. Maiores informações em [17, 18].
4.4.3 Modelagem do Banco de Dados
Os testes de banco de dados apresentaram índice satisfatório de aprovação (76,19 %). No entanto, falta refinamento na identificação do tamanho e restrições dos campos. A Tabela 4.4.3.1 apresenta um exemplo.
Tabela 4.4.3.1 – Exemplo de modelagem incorreta
Requisito Especificação no Banco de Dados
Versionamento deve obedecer ao padrão: X.Y-B, onde:
• X e Y: novas funcionalidades; • B: correção de bugs.
• Tipo: varchar(255); • Aceita entrada nula.
44
Observou-se ainda a utilização da engine “MyISAM” para a criação das tabelas. Embora a ferramenta “MySQL” permita a configuração da engine (Ex.: “MyISAM”, “InnoDB”) na criação de novas tabelas, é importante atentar-se tanto para os pontos fortes como os fracos do tipo escolhido. A Figura 4.4.3.1 [19] apresenta uma comparação entre as características das engines “InnoDB” e “MyISAM”.
45
4.5 RECOMENDAÇÕES
É fundamental que a equipe de desenvolvimento se baseie neste documento para identificação e correção dos defeitos.
Durante a realização do exame final das disciplinas CE-229, CE-245 e CE-240 observou-se algumas dificuldades no tocante à integração das mesmas. Este grupo observou algumas influências de processo e comportamentais como causa destes problemas. Desta forma, visando à resolução dos problemas que causaram tais efeitos, esta seção apresenta algumas sugestões para evitar a ocorrência de tais problemas em futuras turmas da(s) mesma(s) disciplina(s).
Os passos abaixo definem a política (o que fazer) proposta para uma execução mais harmoniosa no tocante ao aspecto de integração das disciplinas. Em alguns passos, o esboço de um método de implementação (como fazer) é relatado, entretanto não é objetivo desta seção definir um método para implementação da política proposta. Esta abordagem é definida intencionalmente desta forma, visando permitir ao implementador desta política escolher o método que lhe parecer mais adequado.
Política para Integração dos Cursos Utilizando Métodos Ágeis: 4.5.1 Definir um Especialista de Domínio
Ao escolher um domínio de atuação é necessário que exista a figura de especialista de domínio. Esta pessoa deverá ser responsável por representar o cliente (ser o próprio cliente ou auxiliar os professores neste papel) e deverá conhecer muito bem o domínio de problema utilizado no curso. Esta pessoa deverá representar o PO da solução. Não é necessário que tal pessoa conheça o domínio da solução, mas esta pessoa deve conhecer muito bem o domínio do problema. Esta abordagem visa a solicitação e validação de funcionalidades mais realistas, impedindo que o desenvolvimento saia dos trilhos devido ao escopo desconhecido (cabe observar que escopo aberto não é o mesmo que escopo desconhecido).
4.5.2 Clarificar o Domínio de Problema aos Participantes do Curso
Utilizar uma ou duas aulas para explicar em detalhes qual é o domínio de problema que estamos atuando. Por exemplo, se estivermos tratando de smart grids, é importante que alguém clarifique para a classe, desse a primeira aula, qual é o domínio de problema que estamos inseridos, e quais são os problemas que mais afetam tal domínio.
4.5.3 Definir o Conceito de Pronto
Determinar em conjunto (as três disciplinas) o que significa dizer que um item do
backlog está “pronto” (ex.: especificado, codificado, testado unitariamente e com
cobertura de testes de no mínimo 75%).
46
4.5.4 Definir Releases e Objetivos de Release
Definir quantos releases são esperadas para o sistema e planejar quais são as funcionalidades para estes releases. A utilização de métodos ágeis encoraja ao time aproveitar as oportunidades oferecidas pelas mudanças, entretanto é necessário definir uma linha mestra, pois sem ela as possibilidades são infinitas. Ex.: vamos fazer um carro, será um carro de motor 1.0 (daí pra frente pode-se variar uma série de pontos, mas considerar somente um carro permite um nível de variabilidade enorme e que não pode ser acomodado em 17 semanas: estamos fazendo um fusca ou uma Ferrari?).
4.5.5 Definir Estórias a serem Implementadas e seus Critérios de Aceite em Conjunto
Para cada sprint, determinar quais estórias serão implementadas e quais os critérios de aceite. Para tanto, é necessário conhecer o domínio de problema e a velocidade da equipe, além de realizar estimativas.
4.5.6 Utilizar Abordagem Iterativa / Incremental de Produtos de Software
As entregas dos sprints devem caracterizar produtos de software completos (atendidos 100% pela definição de pronto). Um exemplo desta abordagem seria no Sprint 1 entregar
feature A funcionando em produção, no Sprint 2 entregar features D e F funcionando em
produção, etc. Um contra-exemplo seria no Sprint 1 entregar documentação, no Sprint 2 entregar implementação, etc.
4.5.7 Trabalhar Juntos
Os exercícios em laboratórios e listas de exercícios devem ser realizados por grupos de alunos de disciplinas distintas, mas presencialmente e em conjunto. Cada grupo deve contar com um ou mais alunos de cada uma das disciplinas envolvidas, formando times multi-funcionais no entorno de um objetivo específico.
4.5.8 Avaliar por Meta de Sprint e não Individualmente
Metas devem ser de todo o grupo. A meta do sprint é uma para o grupo, ou todo o grupo falha ou todo o grupo obtém sucesso. A utilização de metas para o grupo visa garantir o foco no objetivo do sprint e eliminar o desbalanceamento de carga de trabalho.
4.5.9 Realizar Scrum Of Scrums
Deverá existir apenas um PO (domain expert), entretanto existirão vários scrum masters (um para cada grupo formado). Em intervalos de tempos, estes scrum masters formarão grupos de comunicação para alinhamento de metas de grupos e de toda a equipe.