ce229 scai relatorio de teste final

(1)

Divisão de Engenharia da Computação

CE-229 – Teste de Software

Prof. Dr. Luiz Alberto Vieira Dias

Prof. Dr. Adilson Marques da Cunha

Exame Final

Sistema de Controle de Acessos Indevidos (SCAI)

Relatório de Teste

(2)

i

Histórico e Distribuição de Documentos

1. Histórico da Revisão

Versão Data Descrição Autor(es)

1.0 15/06/2012 Primeira versão Roberto Pepato Mellado

Juvenal Silva Neto Reginaldo Rangel Luma Maia Ferreira Marcio Cravo

Luiz Felipe Simões Hoffmann Ednelson Oliveira

Luiz Eduardo Guarino Robson Cassol

(3)

ii

SUMÁRIO

PARTE I: RELATÓRIO DE TESTE ... 1

1.1 INTRODUÇÃO ... 2

PARTE II: PLANO DE TESTE ... 3

2.1 IDENTIFICADOR DO PLANO DE TESTE ... 4

2.2 REFERÊNCIAS ... 4

2.3 INTRODUÇÃO ... 5

2.4 ITENS DE TESTE ... 6

2.5 QUESTÕES DE RISCO DE SOFTWARE ... 7

2.6 CARACTERÍSTICAS A SEREM TESTADAS ... 7

2.7 CARACTERÍSTICAS QUE NÃO SERÃO TESTADAS ... 8

2.8 ABORDAGEM ... 8

2.9 CRITÉRIOS DE APROVAÇÃO E FALHA ... 9

2.10 CRITÉRIOS DE ENTRADA E SAÍDA ... 10

2.11 CRITÉRIOS DE SUSPENSÃO E REQUISITOS DE REINÍCIO ... 10

2.12 ENTREGÁVEIS DE TESTE ... 10

2.13 TAREFAS DE TESTES RESTANTES ... 10

2.14 NECESSIDADES DE AMBIENTE ... 11

2.15 NECESSIDADES DE PESSOAL E TREINAMENTO ... 12

2.16 RESPONSABILIDADES ... 12

2.17 PLANEJAMENTO DE RISCOS E CONTINGÊNCIAS ... 12

2.18 APROVAÇÕES ... 12

2.19 GLOSSÁRIO ... 13

PARTE III: CASOS DE TESTE ... 14

3.1 CASO DE TESTE 01 ... 15 3.2 CASO DE TESTE 02 ... 16 3.3 CASO DE TESTE 03 ... 17 3.4 CASO DE TESTE 04 ... 18 3.5 CASO DE TESTE 05 ... 19 3.6 CASO DE TESTE 06 ... 20 3.7 CASO DE TESTE 07 ... 21 3.8 CASO DE TESTE 08 ... 22 3.9 CASO DE TESTE 09 ... 23

(4)

iii 3.10 CASO DE TESTE 10 ... 24 3.11 CASO DE TESTE 11 ... 26 3.12 CASO DE TESTE 12 ... 27 3.13 CASO DE TESTE 13 ... 28 3.14 CASO DE TESTE 14 ... 29 3.15 CASO DE TESTE 15 ... 30 3.16 CASO DE TESTE 16 ... 31 3.17 CASO DE TESTE 17 ... 32 3.18 CASO DE TESTE 18 ... 33 3.19 CASO DE TESTE 19 ... 34 3.20 CASO DE TESTE 20 ... 35 3.21 CASO DE TESTE 21 ... 36 3.22 CASO DE TESTE 22 ... 37 3.23 CASO DE TESTE 23 ... 38 3.24 CASO DE TESTE 24 ... 39 3.25 CASO DE TESTE 25 ... 40

PARTE IV: RESULTADOS E CONSIDERAÇÕES ... 41

4.1 RESULTADO GERAL ... 42

4.2 RESULTADO DO TBD ... 42

4.3 RESULTADO DO TIC ... 42

4.4 CONSIDERAÇÕES ... 43

(5)

1

(6)

2

1.1 INTRODUÇÃO

Este documento tem como objetivo o planejamento das atividades de elaboração, execução e apresentação dos resultados de teste do Sistema de Controle de Acessos Indevidos (SCAI) do Projeto do Sistema de Controle de Acessos e Fraudes (SCAF). Está dividido em quatro partes conforme a tabela 1.1.1:

Tabela 1.1.1 – Partes do Relatório de Teste

Parte I Introdução Apresentação deste documento de relatório de teste

Parte II Plano de Teste Documento descrevendo o escopo, abordagem, recursos e

cronograma das atividades de teste. Ele identifica os itens de teste, recursos testados, o ambiente de teste, os critérios de entrada e saída do teste utilizado, ou seja, é o registro do planejamento de teste.

Parte III Casos de Teste Conjunto de condições descritas em passos e resultados

esperados desenvolvidos com o objetivo de exercitar o sistema para verificar e validar os requisitos.

Parte IV Resultados Documento produzido no final do processo de teste com os

resultados, relatórios de métricas de teste e avaliação do processo de teste.

(7)

3

(8)

4

2.1 IDENTIFICADOR DO PLANO DE TESTE

SCAI-PTM-01.0

2.2 REFERÊNCIAS

[1] Project Backlog (PJB) – SCAF, Versão 1.4. Disponível em:

https://sites.google.com/site/projetoscaf/

[2] Documento da Arquitetura de Software, Versão 1.0. Disponível em:

[3] Planilha Gerenciamento_Scrum_SCAF.xls. Disponível em:

[4] Modelo de plano de teste para projetos de software. Disponível em:

http://www.softwaretestingvídeos.com/

[5] IEEE 829 – 2008. IEEE Standard for Software and System Test Documentation. [6] Test Plan Outline. Disponível em:

http://www.computing.dcu.ie/~davids/courses/CA267/ieee829mtp.pdf

[7] Software Test Plan Template. Disponível em:

http://www.epmo.scio.nc.gov/library/docs/TESTPLAN.doc

[8] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/rpepato/ce-229.

[9] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/juvsnt

[10] ListEx4 – Casos de Teste. Disponível em:

https://sites.google.com/site/rerangel2012/home/ce-229

[11] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/lumamaia229/

https://sites.google.com/site/macramo229/disciplinas/ce-229---teste-de-software

[13] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/lfelipesh/

[14] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/ednelsonoliveira/

https://sites.google.com/site/luizeduardoguarino/

[16] ListEx4 – Casos de Teste. Disponível em: https://sites.google.com/site/robsoncassol/

[17] Test-driven development. Disponível em:

http://en.wikipedia.org/wiki/Test-driven_development

[18] Coding Standards. Disponível em: http://pear.php.net/manual/en/standards.php

[19] MySQL 5.5: Storage Engine Performance Benchmark for MyISAM and InnoDB.

(9)

5

2.3 INTRODUÇÃO

Este é o Plano de Teste Mestre com o objetivo de testar a integração do componente de Sistema de Controle de Acessos Indevidos (SCAI) do Projeto do Sistema de Controle de Acessos e Fraudes (SCAF). Este plano abordará os seguintes módulos:

• Gerenciamento de Versões de Software (GVS); • Gerenciamento de Interface (GDI);

• Gerenciamento de Permissões (GDP);

• Gerenciamento de Segurança de Dados (GSD); • Gerenciamento de Middleware (GDM);

• Gerenciamento de Interoperabilidade (GRI); • Gerenciamento de Mídias de Validação (GMV); • Gerenciamento de Registros de Acesso (GRA).

O escopo deste plano de teste é verificar e validar as User Stories com o objetivo de atender aos requisitos estabelecidos definidos no documento de backlog do projeto [1].

O plano de teste será desenvolvido em níveis de Unidade, Integração, Sistema e Aceitação. Os detalhes estão especificados na seção “Abordagem”.

A Figura 2.3.1 ilustra a visão geral dos componentes do sistema SCAF.

(10)

6

2.4 ITENS DE TESTE

Serão testadas as User Stories conforme especificação do documento

“Gerenciamento_Scrum_SCAF.xls”, planilha “PRODUCT BACKLOG”. São estas:

• item 11: “Como GDP, devo receber a lista de códigos de permissão de um usuário pedindo acesso, enviada pelo GSD.”;

• item 12: “Como GDP, devo verificar todos os setores autorizados ao usuário, correspondentes aos códigos de permissão associados a seu nome e senha.”;

• item 13: “Como GDP, devo liberar a permissão de acesso do usuário a todos os setores da lista de setores autorizados.”;

• item 14: “Como GRI, é necessário cadastrar os contratos entre funções, serviços e usuários, dizendo quais usuários podem acessar quais serviços através de quais métodos.”;

• item 15: “Como GRI, é necessário validar o pedido de acesso de certo usuário, utilizando certa função a um serviço ativo.”;

• item 16: “Como GRI, é necessário liberar o acesso ao serviço pedido a quem tem direitos ou retornar uma mensagem dizendo que o acesso foi negado.”;

• item 17: “Como GSD, é necessário capturar o nome e a senha digitados pelo usuário e verificar se os mesmos são válidos.”;

• item 18: “Como GSD, é necessário descobrir o código de permissão deste usuário cadastrado que entrou como nome e senha para obter acesso.”;

• item 19: “Como GSD, é necessário enviar estes códigos (podem ser vários) em uma lista ao módulo GDP.”;

• item 28: “Como GMV, devo permitir cadastro e listagem de emissores”; • item 29: “Como GMV, devo permitir cadastro e listagem de mídias”; • item 30: “Como GMV, devo permitir cadastro e listagem de acessos”; • item 31: “Como GMV, devo permitir listagem de validações”;

• item 32: “Como GDI, é necessário disponibilizar ambiente de autenticação para o usuário.”;

• item 33: “Como GDI, é necessário disponibilizar informações do gerenciamento de interface a quem necessitar.”;

• item 34: “Como GDI, é necessário receber as informações necessárias para devida integração dos demais módulos”;

• item 35: “Como GVS, é necessário receber a informação passada pelo GSD e validá-las.” • item 36: “Como GVS, é necessário descobrir os níveis deste usuário cadastrado que entrou com nome e senha para obter acesso e gerenciar as versões do software disponível.”;

• item 37: “Como GVS, é necessário disponibilizar as informações das versões (podem ser várias) a quem necessite utilizar.”.

Observação: O módulo GDM não foi previamente listado como item de teste, pelo fato de não existir um profissional responsável pela camada de apresentação (web) deste módulo. Os testes aplicados ao módulo GDM são os previamente descritos em [8], derivados dos casos de uso descritos no mesmo documento.

(11)

7

2.5 QUESTÕES DE RISCO DE SOFTWARE

As seguintes questões têm impacto direto no processo de desenvolvimento e testes:

• Backup e restauração de arquivos de código, documentação e base de dados devem ser verificados;

• Disponibilidade de infraestrutura de rede para testes;

• Disponibilidade e integridade dos arquivos de código fonte armazenados no repositório do projeto.

• Segurança da base de dados.

2.6 CARACTERÍSTICAS A SEREM TESTADAS

Seguem-se abaixo as características que serão focadas durante os testes da aplicação: • acesso e segurança do sistema;

• acesso e segurança do módulos; • acesso e validação de serviços; • atribuição das permissões de acesso; • verificação das permissões de acesso; • verificação dos registros de acesso; • gerenciamento das interfaces;

• integração dos softwares de interface; • interface da listagem e cadastro de versões;

• interface da listagem e cadastro de emissores e mídias; • inclusão de uma nova versão;

• inclusão de um novo usuário; • inclusão de um novo middleware; • inclusão de um novo contrato; • inclusão de uma nova mídia; • inclusão de um novo emissor;

• associação de um usuário a um grupo; • conexão de uma middleware ao sistema; • métodos de acesso ao banco de dados;

(12)

8

2.7 CARACTERÍSTICAS QUE NÃO SERÃO TESTADAS

Seguem-se abaixo as características que não serão focadas durante os testes da aplicação. Estas características não serão validadas por não fazerem parte do escopo do componente SCAI, ou por ainda não estarem completamente implementadas:

• nenhuma função não relacionada ao componente de software SCAI; • operações de alteração e exclusão de versões;

• operações de alteração e exclusão de usuários; • operações de alteração e exclusão de middleware; • operações de alteração e exclusão de contratos; • operações de alteração e exclusão de mídias; • operações de alteração e exclusão de acessos; • operações de alteração e exclusão de validações; • operações de alteração e exclusão de emissores.

2.8 ABORDAGEM

8.1 Níveis de Testes

Os testes para o componente de software SCAI ocorrerão em níveis de Unidade, Integração, Sistema e Aceitação.

Os testes de Unidade serão realizados pela equipe de desenvolvimento. Deverão ser provados e aprovados pelo Prof. Dr. Adilson Marques da Cunha.

Os testes de Integração e Sistemas serão realizados pela equipe de testes com a assistência da equipe de desenvolvimento, quando necessário. Deverão ser aprovados pelo Project Owner (PO) e pelo Prof. Dr. Luiz Alberto Vieira Dias.

Os testes de Aceitação serão realizados pelo PO, com a assistência dos times de desenvolvimento e testes.

O componente de software SCAI entrará na fase de teste de Aceitação somente quando todos os defeitos críticos forem corrigidos.

8.2 Ferramentas

É indispensável a utilização de uma ferramenta de suporte, como “Selenium Web Browser Automation”, para automação dos testes de regressão baseados na camada de apresentação.

(13)

9

8.3 Reuniões

Os times de desenvolvimento de testes deverão manter-se atualizados através do Software de Gerenciamento de Projetos “Pivotal Tracker”.

Os membros do time deverão, sempre que necessário, solicitar reuniões presenciais para alinhamento de atividades e esclarecimento de dúvidas que não puderem ser resolvidas remotamente.

8.4 Medidas e Métricas

As seguintes informações serão coletadas pela equipe de desenvolvimento durante os testes de Unidade:

• Defeitos por módulo e gravidade;

• Origem dos defeitos (requisitos, design, codificação).

As seguintes informações serão coletadas pela equipe de testes durante todas as fases de testes:

• Defeitos por módulo e gravidade;

• Origem dos defeitos (requisitos, design, codificação);

• Defeitos identificados em níveis mais altos que deveriam ser identificados em níveis inferiores.

2.9 CRITÉRIOS DE APROVAÇÃO E FALHA

O percentual de falhas durante a execução dos testes deve ser inferior a 55% para assegurar a finalização deste evento.

Os resultados obtidos na execução de cada caso de teste serão disponibilizados pela Equipe de Teste no final da atividade de execução de cada evento permitindo o acompanhamento do progresso dos testes e reporte das métricas de execução.

Os códigos de status definidos para o reporte das métricas de execução são apresentados na Tabela 2.9.1.

Tabela 2.9.1 – Status de Execução

Status de Execução Descrição

Não executou O caso de teste não foi executado.

Passou O caso de teste foi executado com sucesso de acordo com os

resultados esperados.

Com falha O caso de teste foi executado e não atingiu os resultados

esperados.

Bloqueado O caso de teste não pode ser executado porque depende de um

caso de teste anterior cuja execução falhou ou estão esperando por dados ou recursos que não estão disponíveis.

(14)

10

2.10 CRITÉRIOS DE ENTRADA E SAÍDA

10.1 Critérios de Entrada

Cronograma de desenvolvimento, prevendo quantas horas serão utilizadas com testes (e em quantas iterações). Tal cronograma será elaborado pelo Gerente do Projeto de Software.

10.2 Critérios de Saída

Revisão formal do mesmo com todos os membros do time de software. Uma vez revisado, qualquer modificação deverá seguir o fluxo do Gerenciamento de Mudanças.

2.11 CRITÉRIOS DE SUSPENSÃO E REQUISITOS DE REINÍCIO

11.1 Alterações no Cronograma

Alterações no cronograma (internos e do cliente), que necessitem de replanejamento das atividades de desenvolvimento e testes.

11.2 Indisponibilidade de Função / Módulo

Módulos ou funções não implementadas podem exigir tanto a suspensão de um teste específico, como de um grupo de testes relacionados.

11.3 Falhas Graves

Falhas que impeçam a continuidade dos testes ou gerem “falsos positivos” no resultados de testes subsequentes.

2.12 ENTREGÁVEIS DE TESTE

Os seguintes itens de teste serão entregues: • Plano de Teste de Aceitação;

• Plano de Teste de Sistema;

• Plano de Teste de Aplicação de Banco de Dados; • Plano de Teste de Integração das Camadas; • Plano de Teste de Unidade;

• Casos de Teste;

• Relatórios de Falhas (Log de Testes).

2.13 TAREFAS DE TESTES RESTANTES

Tarefa Atribuído a

Criar Plano de Teste de Aceitação TT

Criar Plano de Teste de Unidade TD

(15)

11

2.14 NECESSIDADES DE AMBIENTE

O sistema SCAF deve ser instalado em computador local padrão, com sistema operacional que suporte as ferramentas “Apache” e “PHP”, como Windows e Linux.

O banco de dados pode ser local.Neste caso é necessária a instalação da ferramenta “MySQL”. No entanto recomenda-se a utilização da base de dados de homologação (http://mysql06.logistica.servicos.ws).

É importante também que o código-fonte esteja sempre atualizado. Para isto, é necessário o uso da ferramenta de controle de versões “Subversion”, através do link:

https://scaf.googlecode.com/svn/trunk/.

A Figura 2.14.1 apresenta o ambiente de desenvolvimento.

(16)

12

2.15 NECESSIDADES DE PESSOAL E TREINAMENTO

É recomendável que os testadores se mantenham atualizados em relação ao Projeto SCAF, através:

• do site oficial do projeto (https://sites.google.com/site/projetoscaf/);

• do Software de Gerenciamento de Projetos “Pivotal Tracker” (http://www.pivotaltracker.com/).

A equipe de teste deverá ter suporte dos alunos da disciplina CE-240 e CE-245 e ter conhecimento das técnicas de software a serem executadas.

2.16 RESPONSABILIDADES

TD TT PO Cliente Teste de Aceitação X X X Teste de Sistema X Teste de Integração X X Teste de Unidade X X Teste de Regressão X X Revisões de Requisitos X X X X

Revisões de Design Interno X X X

2.17 PLANEJAMENTO DE RISCOS E CONTINGÊNCIAS

Em função de o projeto SCAF ser baseado na metodologia de desenvolvimento ágil de software Scrum, os requisitos estão sendo definidos de forma iterativa e incremental. Neste caso, estes poderão sofrer alterações durante todo o processo de testes.

Assim, torna-se imprescindível que os testadores se mantenham constantemente atualizados e adaptem-se às mudanças. O processo de teste deve ser ágil e automatizado para alcançar resultados positivos.

Além disto, os testadores devem estar familiarizados com todo projeto (e não somente com os seus módulos), para darem continuidade ao processo de testes, em caso de indisponibilidade do principal testador em um módulo específico.

2.18 APROVAÇÕES

A estrutura de aprovações para o componente SCAI envolve a figura de um PO, responsável por clarificar a visão do cliente aos membros da equipe. O PO pode aprovar uma entrega no controle de qualidade interno, para apresentação cliente, entretanto, somente o cliente pode formalizar o aceite do produto.

Roberto Pepato Mellado – PO

Prof. Dr. Luiz Alberto Vieira Dias – Cliente Prof. Dr. Adilson Marques da Cunha – Cliente

(17)

13

2.19 GLOSSÁRIO

Termo Definição

GDI Gerenciamento de Interface

GDM Gerenciamento de Middleware

GDP Gerenciamento de Permissões

GMV Gerenciamento de Mídias de Validação

GRA Gerenciamento de Registros de Acesso

GRI Gerenciamento de Interoperabilidade

GSD Gerenciamento de Segurança de Dados

GVS Gerenciamento de Versões de Software

PJB Project Backlog

PO Project Owner

PTM Plano de Teste Mestre

SCAF Sistema de Controle de Acessos Indevidos e Fraudes

SCAI Sistema de Controle de Acessos Indevidos

TD Time de Desenvolvimento

(18)

14

(19)

15

3.1 Caso de Teste 01

Identificador: GVS_CDT_01 Nome: Estrutura da tabela versão

Sistema: SCAI Subsistema: GVS

Elaborado por: Luiz Felipe Simões Hoffmann Data de criação: 24/06/2012

Executado por: Luiz Felipe Simões Hoffmann Data de execução: 24/06/2012

Descrição: Verificar a estrutura da tabela de versões (SCAF_VERSAO). Pré-condições

1. O usuário deve se conectar ao servidor de banco de dados de homologação (https://mysql06.logistica.servicos.ws).

# Ação Resultado Esperado Sucesso/

Falha Comentário 1 Executar o comando SQL: DESCRIBE SCAF_VERSAO; A consulta deve apresentar os campos: - VER_ID, - VER_NUMERO, - VER_DATA e, - VER_NOME.

Os campos não devem

aceitar dado nulo

(Null=NO).

Falha Modelagem incorreta.

Os campos: - VER_NUMERO, - VER_DATA e, - VER_NOME, aceitam a entrada de dado nulo (Null=YES). Pós-condições 1. Não se aplica.

(20)

16

3.2 Caso de Teste 02

Identificador: GVS_CDT_02 Nome: Lista registro de interface

Descrição: Listar registro da tabela de interface (SCAF_INTERFACE). Pré-condições

Falha Comentário 1 Executar o comando SQL: SELECT INT_DESCRICAO FROM SCAF_INTERFACE WHERE INT_ID = 1;

A consulta deve apresentar um

registro com a seguinte

informação: ‘Tela de Login’.

Sucesso

Pós-condições 1. Não se aplica.

(21)

17

3.3 Caso de Teste 03

Identificador: GVS_CDT_03 Nome: Usuário não autenticado

Descrição: Verificar se o usuário não autenticado no sistema tem acesso ao módulo GVS. Pré-condições

1. O usuário não deve estar autenticado no sistema.

Falha Comentário 1 O usuário tenta se conectar ao

módulo GVS diretamente através do link:

http://localhost/scaf/scai/view/list a-versao.php

O sistema deve ser

redirecionado para a página inicial:

http://localhost/scaf/index.p hp

Falha Módulo não

implementado.

Pós-condições

(22)

18

3.4 Caso de Teste 04

Identificador: GVS_CDT_04 Nome: Incluir nova versão

Descrição: Verificar se o módulo GVS processa a inclusão de uma nova versão corretamente. Pré-condições

1. O sistema deve possuir uma versão previamente cadastrada com os seguintes dados: a. ID com valor “1”;

b. Número com valor “01”; c. Data com valor “07/06/2012”; d. Nome com valor “Versão 01”.

2. O usuário deve acessar a página inicial do sistema.

3. O usuário deve se autenticar no sistema com uma conta válida, e com permissão de acesso ao módulo GVS.

4. O usuário deve clicar no link “Gerenciamento de Versões de Software (GVS)” do menu superior “OLTP (Online Transaction Processing)”.

5. O usuário deve clicar no link “Listar Versões” do menu lateral da página inicial do módulo GVS.

6. O usuário deve clicar no link “Cadastrar Versões” do menu lateral do módulo GVS.

Falha

Comentário 1 O usuário digita o número da

versão “02”.

O número é exibido. Falha Módulo não

implementado. 2 O usuário digita a data da versão

“24/06/2012”.

A data é exibida. Falha Módulo não

implementado. 3 O usuário digita o nome da versão

“Versão 02”.

O nome é exibido. Falha Módulo não

implementado. 4 O usuário clica no botão “enviar”. O sistema inclui a nova

versão. Falha Módulo implementado. não

(23)

19

3.5 Caso de Teste 05

Identificador: GDI_CDT_01 Nome: Disponibilizar informações do

gerenciamento de Interface

Sistema: SCAI Subsistema: GDI

Elaborado por: Juvenal Silva Neto Data de criação: 09/06/2012

Executado por: Juvenal Silva Neto Data de execução: 27/06/2012

Descrição: O caso de teste deve verificar se usuários com perfis diferentes conseguem gerenciar a interface do sistema.

Pré-condições

1. Os usuários, logados no sistema, precisam ter suas permissões de acesso especificadas.

Falha

Comentário

1 Acessar todas as funções

disponíveis no ambiente e tentar modificá-las.

O sistema deve retornar uma saída/resposta para todos os

objetos da interface,

manipuladas pelo usuário, retornando a mensagem

“acesso não permitido”

quando assim ocorrer.

Sucesso

1. As funcionalidades restritas deverão ser apresentadas apenas aos usuários com permissão de acesso.

(24)

20

3.6 Caso de Teste 06

Identificador: GDI_CDT_02 Nome: Disponibilizar ambiente de

autenticação para o usuário

Descrição: O caso de teste deve verificar se o sistema oferece ambiente de autenticação para o usuário.

1. O usuário precisa estar cadastrado no sistema e acessar a tela de login.

Falha

Comentário 1 O usuário deverá digitar seu login

de usuário e senha válidos. Valores testados: USU_LOGIN: admin USU_SENHA: admin USU_LOGIN: maria.santos USU_SENHA: 123456 USU_LOGIN: Teste USU_SENHA: NULL

O sistema deve permitir que o usuário com login e senha

válidos autentique no

sistema e confirme a autenticação apresentando o nome completo na tela. A autenticação deve ser recusada para cadastros inválidos e/ou incompletos

Sucesso

(25)

21

3.7 Caso de Teste 07

Identificador: GDI_CDT_03 Nome: Receberas informações necessárias _{para devida integração dos demais módulos.}

Descrição: O caso de teste deve verificar se o módulo recebe as informações de outros módulos Pré-condições

1. Os usuários, logados no sistema, precisam identificar áreas / funcionalidades para gerenciamento da interface.

Falha

Comentário

1 Acessar o ambiente para

atribuição de permissões de acesso ao sistema. SELECT * FROM SCAF_PER_GRUPO_PERMISSAO WHERE 1 LIMIT 0 , 50 e SELECT * FROM SCAF_USU_GRUPO_PERMISSAO LIMIT 0 , 30

O sistema deve retornar as entradas para atribuição de permissões de acesso a usuários.

Sucesso

2 Receber as permissões de acesso

já atribuídas aos usuários

cadastrados no sistema. SELECT P.per_nome FROM SCAF_PERMISSAO P, SCAF_USUARIO U, SCAF_GRUPO_PERMISSAO GP, SCAF_USU_GRUPO_PERMISSAO UGP, SCAF_PER_GRUPO_PERMISSAO PGP

WHERE U.usu_id = UGP.usu_id AND UGP.gru_per_id = GP.gru_per_id AND GP.gru_per_id = PGP.gru_per_id AND PGP.per_id = P.per_id AND

U.usu_nome = 'Maria Carmen Santos';

O sistema deve informar todas as permissões de

acesso concedidas ao

usuário.

Sucesso

(26)

22

3.8 Caso de Teste 08

Identificador: GSD_CDT_01 Nome: Verificar acesso ao sistema com login

válido

Sistema: SCAI Subsistema: GSD

Elaborado por: Marcio Cravo Moreira Data de criação: 08/06/2012

Executado por: Marcio Cravo Moreira Data de execução: 26/06/2012

Descrição: Entrar com um login e senha válidos para verificar se o sistema GSD captura o nome e a senha digitada pelo usuário.

1. Usuário cadastrado no sistema. 2. Login e senha ativa no sistema. 3. Sistema disponível.

Dados

Login = joaquin.souza Senha = 123456

Falha Comentário

1 Entrar com login O login digitado é exibido Sucesso

2 Entrar com a senha A senha digitada não é

exibida aparecendo apenas um caractere identificando a entrada do dado

Sucesso

3 Entrar no sistema GSD O sistema GSD exibe a

pagina inicial identificando o nome correspondente ao login digitado

Sucesso

4 Executar o SQL para consultar os

dados armazenados na tabela de log.

Select from a.log_id, a.log_data, a.log_ip, b.usu_cpf

from log.a; usuario.b

where a.usu_cpf = b.usu_cpf.

O resultado da query é: log_id = identificação no log usu_cpf = 3279541428 log_ip = IP da máquina log_data = data e hora corrente de teste

Sucesso

(27)

23

3.9 Caso de Teste 09

Identificador: GSD_CDT_02 Nome: Verificar obtenção de código de

permissão

Executado por: Data de execução:

Descrição: Entrar com um login e senha válidos para verificar se o sistema GSD captura o código de permissão.

1. Usuário cadastrado no sistema.

2. Usuário com permissão de acesso a uma localidade. 3. Login e senha ativo no sistema.

4. Sistema disponível. Dados

Falha

Comentário

2 Entrar com a senha A senha digitada não é

exibida aparecendo apenas um caractere identificando a entrada do dado

Sucesso

3 Entrar no sistema GSD O sistema GSD exibe a

pagina inicial identificando o nome correspondente ao login digitado Sucesso 4 Executar o SQL: Select a.log_id, a.log_data, a.log_ip, b.usu_cpf, c.per_id c.per_nome from log.a; usuario.b permissao.c where a.usu_cpf = b.usu_cpf and a.per_id = c.per_id

O resultado da query é: log_id = identificação no log usu_cpf = 3279541428 log_ip = IP da máquina log_data = data e hora corrente de teste

per_id = identificação de permissão

per_nome = Jose Silva Oliveira

Sucesso

(28)

24

3.10 Caso de Teste 10

Identificador: GSD_CDT_03 Nome: Verificar a exibição dos códigos de

permissão no GDP.

Executado por: Marcio Cravo Moreira Data de execução: 26/06/2012

Descrição: Entrar com um login e senha válida para verificar se o sistema GSD envia o código de permissão para o sistema GDP.

1. Usuário cadastrado no sistema.

2. Usuário com permissão de acesso a uma localidade. 3. Login e senha ativo no sistema.

4. Sistema disponível. Dados

Falha

Comentário

2 Entrar com a senha A senha digitada não é exibida

aparecendo apenas um caractere identificando a entrada do dado

Sucesso

3 Entrar no sistema GSD O sistema GSD exibe a pagina

inicial identificando o nome correspondente ao login digitado

Sucesso

4 Executar o SQL:

Select a.log_id, a.log_data, a.log_ip, b.usu_cpf, c.per_id c.per_nome from log.a; usuario.b permissao.c where a.usu_cpf = b.usu_cpf and a.per_id = c.per_id

O resultado da query é: log_id = identificação no log usu_cpf = 3279541428 log_ip = IP da máquina

log_data = data e hora corrente

per_id = identificação de

permissão

per_nome = Jose Silva Oliveira

Falha O SQL não foi

executado.. O log foi limpo antes do teste, o usuário foi logado novamente e a tabela SCAF_LOG consultada que não exibe registros. O log também é exibido sem registros quando

(29)

25 acessado pela URL http://www.pro jscaf.com.br/sc af/index.php com admin/admin. Conclusão: 1 – Teste falhado porque o sistema não registra o acesso na tabela de log. 2 – Retestar também o caso de teste SCAI_GSD_0 01 limpando a tabela log antes da execução do teste.

5 Anotar o id de permissão Id igual a _______________ Não

executado

6 Acessar a lista de códigos

de permissão no sistema GDP.

O id correspondente ao usuário logado é exibido numa lista do sistema GDP.

Não executado

(30)

26

3.11 Caso de Teste 11

Identificador: GDP_CDT_01 Nome: Verificar se a lista de códigos para

atribuição da permissão não existe no módulo GDP.

Sistema: SCAI Subsistema: GDP

Elaborado por: Reginaldo Rangel Data de criação: 24/06/2012

Executado por: Reginaldo Rangel Data de execução: 24/06/2012

Descrição: Realizar a atribuição dos códigos a um usuário para verificar caso algum código não exista disponível no sistema, impossibilitando a atribuição da permissão.

1. Logar no sistema como usuário “admin”

2. Acessar a opção de “atribuir permissão” no menu do sistema

3. Atribuir a permissão conforme lista de códigos disponíveis no sistema 4. Os códigos não devem estar cadastrados nos sistema

Falha Comentário 1 Entrar no sistema com login como

Admin

Acesso concedido Sucesso

2 Acessar o modulo de atribuição de acesso(permissão)

Gerenciador de acessos para atribuição das permissões a um usuário

Falha Modulo não

implementado e não previsto no sprint

3 Acessar o banco de dados mysql Acesso concedido Sucesso

4 Realizar a consulta SQL nas tabelas SCAF_PERMISSAO e SCAF_GRUPO_PERMISSAO e verificar se estão populadas

Verificar se existe a relação de códigos para atribuição da permissão a algum setor.

Sucesso

5 Executar os comandos : SELECT * FROM

`SCAF_GRUPO_PERMISSAO` WHERE 1 e SELECT * FROM `SCAF_PERMISSAO` WHERE 1

Verificar o conteudo das tabelas para analise dos codigos de permissão.

Sucesso

6 O sistema informa caso o código não exista disponível para atribuição

Mensagem de erro "Codigo não disponivel"

Falha Modulo não

implementado e não previsto no sprint Pós-condições

(31)

27

3.12 Caso de Teste 12

Identificador: GDP_CDT_02 Nome: Verificar se para uma determinada

transação ou setor autorizado ao usuário, o mesmo deve acessar as transações não atribuídas ao seu perfil de acesso.

Descrição: Realizar a atribuição dos códigos a um usuário e verificar se é possível acessar outro setor não autorizado, o sistema deve informar qual acesso não autorizado pelo usuário. Pré-condições

1. O usuário deve acessar o sistema (tela inicial).

2. O usuário deve acessar uma transação ou setor não correspondente ao perfil atribuído. 3. O sistema deve informar caso alguma das transações ou setores não existirem disponível no

sistema , impossibilitando o acesso.

Falha

Comentário 1 Entrar no sistema com login como

Admin

Acesso concedido Sucesso

2 Acessar o modulo de atribuição de

acesso(permissão) Gerenciador de acessos de setores do sistema Falha Modulo implementado não

e não previsto no sprint

4 Realizar a consulta SQL nas tabelas SCAF_USUARIO e SCAF_GRUPO_PERMISSAO e verificar se estão populadas

Verificar se existe a relação de códigos para atribuição da permissão a usuarios.

Sucesso

5 Executar os comandos : SELECT * FROM `SCAF_USUARIO` WHERE 1 e SELECT * FROM `SCAF_PERMISSAO` WHERE 1

Verificar o conteudo das tabelas para analise dos codigos de permissão a usuario.

Sucesso

6 O sistema informa caso algum código não foi acessado pelo usuário sem autorização

Mensagem de alerta

"Acesso XXX acessado pelo usuário YYY"

Falha Modulo não

implementado e não previsto no sprint Pós-condições

(32)

28

3.13 Caso de Teste 13

Identificador: GDP_CDT_03 Nome: Verificar se todos os setores estão

mapeados e autorizados correspondente a lista de permissão recebida pelo GSD.

Descrição: Realizar a verificação dos códigos de um usuário recebidos do modulo GSD e verificar se o sistema indica os setores não disponíveis no sistema com relação à lista de códigos, impossibilitando a atribuição da permissão.

1. Logar no sistema como usuário “admin”.

2. Acessar a opção de “atribuir permissão” no menu do sistema.

3. Atribuir a permissão conforme lista de códigos disponíveis no sistema.

4. Os setores não devem estar mapeados nos sistema.

# Ação Resultado Esperado Sucess

o/Falha

Comentário 1 Entrar no sistema com login como

Admin Acesso concedido Sucesso

2 Acessar o módulo de atribuição de acesso (permissão)

Gerenciador de acessos de setores do sistema

Falha Módulo não

implementado

4 Realizar a consulta SQL nas tabelas

SCAF_PER_GRUPO_PERMISSAO e

SCAF_USU_GRUPO_PERMISSAO

e verificar se estão populadas

Verificar se existe a relação de códigos para atribuição da permissão a usuários. Falha As tabelas populadas e mescladas com o setor de segurança tem 2 que fazem uma ponte (n:n)

5 Executar os comandos: SELECT *

FROM SCAF_PER_GRUPO_PERMISSAO WHERE 1 LIMIT 0 , 50 e SELECT * FROM SCAF_USU_GRUPO_PERMISSAO LIMIT 0 , 30

Verificar o conteúdo das tabelas para analise dos códigos de permissão dos setores recebidos pelo GSD.

Sucesso

6 O sistema informa caso algum código não foi mapeado e recebido pelo modulo GSD

Mensagem de alerta

"Código XXX não

atribuído ao sistema

SCAF"

Falha Módulo não

implementado

(33)

29

3.14 Caso de Teste 14

Identificador: GDM_CDT_01 Nome: Lista registro de middleware

Sistema: SCAI Subsistema: GDM

Elaborado por: Roberto Pepato Mellado Data de criação: 25/06/2012

Executado por: Roberto Pepato Mellado Data de execução: 25/06/2012

Descrição: Listar registro da tabela de middleware (SCAF_MIDIA). Pré-condições

Falha

Comentário 1 Executar o comando SQL:

SELECT MID_NOME FROM SCAF_MIDIA;

A consulta deve apresentar uma lista de registros, com um deles contendo a informação: ‘Cartao Maestro’.

Sucesso

(34)

30

3.15 Caso de Teste 15

Identificador: GDM_CDT_02 Nome: Validar Preenchimento de Data de

Validade

Descrição: Validar preenchimento de data de validade de middleware (SCAF_MIDIA). Pré-condições

Falha

Comentário 1 Executar o comando DESC

SCAF_MIDIA e verificar o valor do atributo Null da coluna MID_DT_VALIDADE

No Falha Coluna de data

de validade

aceita valor

null 2 Executar o comando SELECT *

FROM SCAF_MIDIA WHERE

MID_DT_VALIDADE IS

NULL

Não deve retornar nenhum

registro (Console deve

imprimir ‘Empty set’)

Sucesso

(35)

31

3.16 Caso de Teste 16

Identificador: GDM_CDT_03 Nome: Verificar permissão de mídia

Descrição: Verificar limite de permissão de serviço por mídia (SCAF_MIDIA). Pré-condições

Falha

Comentário 1 Executar o comando SELECT

PER_SER_PER_LIMITE FROM

VW_PERMISSAO_MIDIA WHERE MID_NUMERO = '111111'

Deve retornar o valor 1000 Sucesso

(36)

32

3.17 Caso de Teste 17

Identificador: GSD_CDT_01 Nome: Verificar inserção de usuário com

login nulo.

Elaborado por: Luma Maia Ferreira Data de criação: 26/06/2012

Executado por: Luma Maia Ferreira Data de execução: 26/06/2012

Descrição: Verificar se o sistema permite inserir um usuário com usu_login = null. Pré-condições

Falha

Comentário 1 Executar o comando INSERT

INTO `SCAF_USUARIO`(ÙSU_ID`, ÙSU_CPF`, ÙSU_NOME`, ÙSU_LOGIN`, ÙSU_SENHA`) VALUES (101, 11111111111, 'Teste de Inserção', null, 123456)

Erro, não deve deixar inserir um usuário sem o login.

Falha O registro foi

inserido com sucesso.

(37)

33

3.18 Caso de Teste 18

Identificador: GSD_CDT_02 Nome: Listar Permissões do Usuário

Descrição: Verificar se é possível listar as permissões de um usuário dado seu login. Pré-condições

Falha

Comentário

1 Executar o comando SELECT

P.per_nome FROM SCAF_PERMISSAO P, SCAF_USUARIO U, SCAF_GRUPO_PERMISSAO GP, SCAF_USU_GRUPO_PERMISSA O UGP, SCAF_PER_GRUPO_PERMISSA O PGP

WHERE U.usu_id = UGP.usu_id AND

UGP.gru_per_id = GP.gru_per_id AND

GP.gru_per_id = PGP.gru_per_id AND

PGP.per_id = P.per_id AND U.usu_nome = 'Joaquin Souza';

A consulta deverá retornar uma lista de permissões sendo elas: - gerarRelatorio; - consultarRelatorio; - exportarRelatorio; - trocarSenha; - analiseFraude Sucesso Pós-condições 1. Não se aplica.

(38)

34

3.19 Caso de Teste 19

Identificador: GSD_CDT_03 Nome: Recuperar Nome e CPF a partir do

Login

Descrição: Verificar se é possível recuperar Nome e CPF de um usuário dado seu Login Pré-condições

Falha

Comentário

1 Executar o comando SELECT

U.usu_nome, U.usu_cpf FROM SCAF_USUARIO U

WHERE U.usu_login='jose.oliveira';

A consulta deverá retornar uma

tupla com as seguinter

informações:

Usu_nome = José Silva Oliveira;

Usu_cpf = 3749787644;

Sucesso

(39)

35

3.20 Caso de Teste 20

Identificador: GRI_CDT_01 Nome: Inserir Contrato

Sistema: SCAI Subsistema: GRI

Elaborado por: Ednelson Silva de Oliveira Data de criação: 07/06/2012

Executado por: Ednelson Silva de Oliveira Data de execução: 27/06/2012

Descrição: Como GRI, é necessário cadastrar os contratos entre funções, serviços e usuários, dizendo quais usuários podem acessar quais serviços através de quais métodos.

1. O usuário deve acessar a página inicial do sistema.

2. O usuário deve se autenticar no sistema com uma conta válida, e com permissão de acesso ao módulo GRI.

3. O usuário deve clicar no link “Gerenciamento de Interoperabilidade”. 4. O usuário deve clicar no link “Contratos” na página inicial do módulo GRI.

Falha

Comentário 1 O usuário define funções, serviços

que são objeto do contrato. Definem-se os usuário que são cobertos pelo contrato e quais serviços e funções cada um tem.

Funções, Serviços e

Usuários são exibidos.

Falha Módulo não

implementado.

2 O usuário clica no botão “enviar”. O sistema inclui o novo

contrato. Falha Módulo implementado. não

(40)

36

3.21 Caso de Teste 21

Identificador: GRI_CDT_02 Nome: Validar Pedido de Serviço

Descrição: Como GRI, é necessário validar o pedido de acesso de certo usuário, utilizando certa função a um serviço ativo.

1. O usuário deve usar um serviço.

Falha

Comentário 1 O usuário solicita um serviço

usando uma função.

O sistema cria um Pedido de Serviço.

Falha Módulo não

implementado. 2 O sistema verifica que o usuário

tem acesso ao serviço usando a função

O sistema torna o Pedido de Serviço válido.

Falha Módulo não

implementado. Pós-condições

(41)

37

3.22 Caso de Teste 22

Identificador: GRI_CDT_03 Nome: Liberar Acesso a Serviço

Descrição: Como GRI, é necessário liberar o acesso ao serviço pedido a quem tem direito ou retornar uma mensagem dizendo que o acesso foi negado.

1. Deve existir um pedido válido.

Falha

Comentário 1 O Pedido de Serviço válido é

executado.

O usuário recebe uma mensagem de sucesso.

Falha Módulo não

implementado. 2 É criado um log referente à

execução do pedido de serviço.

Deve constar um log referente ao pedido de serviço.

Falha Módulo não

implementado. Pós-condições

(42)

38

3.23 Caso de Teste 23

Identificador: GRI_CDT_04 Nome:Listar Serviços e seus respectivos tipos.

Descrição: :Listar Serviços e seus respectivos tipos, para fim de exibição na GUI. Pré-condições

Falha Comentário 1 Executar o comando SELECT * FROM `SCAF_TIPO_SERVICO` AS TIPO, `SCAF_SERVICO` AS SERV WHERE SERV.TIP_SERV_ID=TIPO .TIP_SER_ID

A consulta deverá retornar todos os registros de serviços combinado com o respectivo tipo

Sucesso

(43)

39

3.24 Caso de Teste 24

Identificador: GRA_CDT_01 Nome:Verificar registros de acessos

Sistema: SCAI Subsistema: GRA

Elaborado por: Robson Cassol Data de criação: 26/06/2012

Executado por: Robson Cassol Data de execução: 27/06/2012

Descrição: Verificar se o sistema está efetuando o registro de acessos. Pré-condições

1. O usuário Ricardo Rodrigues com login “ricardo.rodrigues” e senha “123456” deve estar previamente cadastrado no sistema.

2. O usuário administrador com login “admin” e senha “admin” deve estar previamente cadastrado no sistema, e deve possuir permissão de acesso ao módulo GRA.

3. Acessar a página de login do SCAF (http://www.projscaf.com.br/scaf/index.php)

Falha Comentário 1 Efetuar o login no sistema com o

usuário “Ricardo Rodrigues” A página principal do sistema SCAF deve ser exibida. Sucesso

2 Efetuar o logout do sistema. Clicar na opção “sair” no canto superior direito.

A página inicial deve ser exibida.

(http://www.projscaf.com.br/sc af/index.php)

Sucesso

3 Efetuar o login com o usuário “admin”

O sistema deve apresentar a página principal

Sucesso

4 Clicar na opção “Lista de Log” O sistema deve exibir os

últimos acessos feitos pelo usuário “Ricardo Rodrigues”.

Falha O sistema exibiu uma página com uma tabela, mas sem nenhum registro. Pós-condições 1. Não se aplica.

(44)

40

3.25 Caso de Teste 25

Identificador: GRA_CDT_02 Nome: Acessar o módulo de gerenciamento de

registros de acesso.

Sistema: SCAI Subsistema: GRA

Elaborado por: Robson Cassol Data de criação: 26/06/2012

Executado por: Robson Cassol Data de execução: 27/06/2012

Descrição: Verificar se o módulo GRA (gerenciamento de registros de acessos) está funcional. Pré-condições

1. Estar logado no sistema como administrador.

Falha

Comentário 1 Acessar o menu “OLTP” clicar

na opção “Acessos”

O sistema deve exibir o módulo de controle de acessos

Falha Retorna o erro

404. Página

não

encontrada. Pós-condições

(45)

41

(46)

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

(47)

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.

(48)

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”.

(49)

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%).

(50)

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.