CAPÍTULO 4 ESTUDO DE CASO
4.2 Central IT – CITSaúde
4.2.2 Relatos dos profissionais da Central IT
“... olha eu acho que funcionaria e que ficaria bem mais fácil com esse Processo. Pegamos meu caso agora, sou uma funcionária nova e pouco conheço do sistema, toda essa documentação que esta sendo proposta a fazer, auxiliaria na sintonia da pessoa com o projeto.“(Layanne Batista – Analista de Teste).
“... com a aplicação das verificações antes do desenvolvimento, buscando um entendimento da equipe de desenvolvimento, ficou mais fácil a programação e maior confiança ao desenvolvedor, que programa sabendo o que realmente é para fazer. Isso evitou retrabalhos.” (Lincoln Amorim – Analista e Desenvolvedor).
CONCLUSÃO / RECOMENDAÇÕES
As atividades de teste de sofware estão cada vez mais presentes nos cotidianos das empresas desenvolvedoras de sistemas. Não há como competir no mercado com um produto sem qualidade, que traz prejuizos aos clientes e que acarreta inúmeras implicações à empresa que o desenvolveu. Logo essas empresas buscam implementar processos que melhoram sua rotina de trabalho, trazendo maior credibilidade ao produto com um menor prazo e custo.
Nesse interesse de mercado, a pesquisa procurou fundamentizar desde o início do processo de teste de software, juntamente com aplicações de metodologias ágeis que contribuem no desenvolvimento de sistemas e estudos práticos buscando a concepção real de como as empresas desenvolvedoras de Softwares produzem seus produtos, quais seus receios e seus almejos.
Em um primeiro encontro com os profissionais da EVV, ficou levantando a necessidade de um processo de teste de software a partir dos recursos (pessoas) que eles despunham. Logo o trabalho em seu carácter em pesquisa bibliográficas relevou a possibilidade de uma modelagem de um processo, a partir de características relevantes dos profissionais. Com isso foi realizado a busca por uma elaboração de um processo de teste de software de forma empírica através do alinhamento entre a teoria e a prática priorizando as características particulares da equipe de desenvolvimento de software. Para tanto, o trabalho buscou conhecimentos já relatados e publicados sobre Processo de Teste de Software, aplicou a pesquisa de campo, que vivenciou a realidade de mercado, a fim de construir um modelo difundido por características de duas equipes de empresas desenvolvedoras de softwares distintas, porém com profissionais que possuem perfis semelhantes e que trabalham com métodos ágeis análogos.
Para construção do processo, o trabalho necessitou de uma aquisição de conhecimento em metodologias agéis em parte teórica e prática. Ao qual se pode concluir sobre métodos ágeis, que eles se complementam e são eficientes quando adaptados na realidade e necessidade da empresa que o está implemetando, porém, pelas suas características de pouco registros formais das fases de desenvolvimento de software, o processo proposto por esse projeto encontrou dificuldades, pois há a necessidade de geração de documentos entre as fases, que dão continuidade do processo, que foram apresentados no item 3.2.1 Atividades do processo.
Com esse conhecimento adquirido após observações das rotinas das duas empresas, a pesquisa buscou captar características dos profissionais que compõe as equipes desenvolvedoras de softwares.
O processo proposto foi desenvolvido de acordo com referências teóricas que apresentaram quais os profissionais que devem compor uma equipe de teste de software e suas características e qualidades. Com a figura dos profissionais propostos pelas bibliografias, que foi apresentada no capítulo 1 item 1.2, procurou-se observar os cenários onde seriam aplicados os estudos de casos, EVV e Central IT, buscando obter um relacionamento das características ditas pelo estudo feito aos profissionais dispostos por essas empresas. A princípio, a pesquisa buscou propor um modelo de processo com a necessidade da presença dos profissionais delegados pela bibliografia, porém, isso fugia do problema de pesquisa, que é: É possível elaborar um processo de teste de software de forma empírica através do alinhamento entre a teoria e prática priorizando as características particulares da equipe de desenvolvimento de software? Então, foram definidos quais os profissionais que podiam participar na execução do processo e realizado um paralelo das características destes com as levantadas, e assim desenvolver o processo.
O processo após execução trouxe benefícios às empresas relatados pelos próprios profissionais que tiveram contato com o software. E também foi possível observar, que é possível propor um processo de acordo com as características relevantes dos profissionais. Essa afirmação é dada pela observação de execução e resultados apresentados no estudo de caso Programa EVV (seção 4.1) e estudo de caso Central IT – CITSaúde (seção 4.2). As empresas dispunham de profissionais que possuem as características listadas pelo referencial teórico, entretando havia uma diferença em número de profissional. A EVV disponibilizou de um profissional (Braully Rocha da Silva) que realizou os papéis do Analista de Teste; Arquiteto de Teste; Testador e Desenvolvedor, isso foi possível, pois esse profissional apresentou as qualidades necessárias para execução do processo. Logo a Central IT, dispôs de mais profissionais, em que cada um continha uma ou mais qualidades necessária para compor as características fundamentais para executar o processo. Com essa observação dos dois estudos de casos, conclui-se que não é fator determinante ter as figuras dos profissionais apresentadas pela bibliografia, mas sim ter as características relevantes que esse grupo deteria nos profissionais que compõem uma equipe de desenvolvimento de software independente do número de integrantes que a formam. É válido atentar a necessidade de uma equipe de profissionais para execução do processo, e não realizar da forma que foi executado no cenário da EVV, onde um profissional executou quase todas as tarefas, colocando a fase de testes em
baixo nível de independência, perdendo credibilidade e confiança nos testes realizados. Então para um consistente sucesso do processo, a empresa deverá ter essa disponibilidade de profissionais.
Pelos estudos de casos realizados e registrados nesse trabalho, é possível observar sobre as lacunas comuns vivenciadas pelas empresas de Desenvolvimento de Sistemas em questão de Teste de Software. A execução da atividade de Testes de Software, que proporcionaria uma maior confiabilidade nos sistema produzido, é deixada de lado por falta do prazo e planejamento dessas atividades, pois consideram - se que é mais aceitável a realização da entrega do projeto dentro do prazo. E ainda as atividades de testes são encaradas como uma forma dispendiosa, que consome muito tempo para sua execução, atrasando a entrega do projeto.
Certo de que esse modelo trará benefícios, recomendo às empresas desenvolvedoras de sistemas, que buscam melhorias em seus produtos. A leitura desse material em conciliação com suas realidades, realizando adaptações caso seja preciso sobre o processo aqui proposto, permitirá um melhor aproveitando dos recursos disponíveis e menor custo para desenvolvimento dos sistemas.
O primeiro passo está dado, o modelo de implementação do processo de teste de software está indicado, agora há a necessidade de uma modelagem de documentos que viabilizem os testes necessários em cada etapa das atividades do processo de teste de software proposto. Um levantamento de estudos para sanar as lacunas comuns vivenciadas pelas empresas desenvolvedoras de software aqui foram apresentadas.
REFERÊNCIAS
BARBI, Fernando C. Análise dos Stakeholders. Disponível em: <http://www.gestaodeprojeto.info/analise-dos-stakeholders>. Acessado em 07/11/2012.
BARTIÉ, Alenxadre. Garantia da Qualidade de Software . Rio de Janeiro: Editora Elsevier, 2002.
BARTIE, Alexandre. Processo de Software – Parte 01. 2007. Disponível em: < com.br/artigo/6102/des_de_software/processo_de_teste_de_software_parte_01/ >. Acessado em 25/05/2012.
BIAZON, Leandro Coletto; PATRÍCIO, Nathalia Sautchuk. Um pouco sobre XP. Disponível em: <http://febracev.wordpress.com/2009/12/07/um-pouco-sobre-xp/> Acesso em: 18/10/2012.
CAMPOS, Fábio Martinho. Formando Equipes Eficientes de Teste de Software. 2007. Disponível em: < http://www.testexpert.com.br/?q=node/101>. Acessado em 02/06/2012.
CAMPOS, Fabrício Ferrari de. Scrum. Disponível em: <
http://qualidadebr.wordpress.com/2009/07/12/scrum/ > Acesso em: 18/10/2012.
CASTRO, Vinicius Almeida. Introdução ao Desenvolvimento Ágil. Disponível em: < http://www.devmedia.com.br/introducao-ao-desenvolvimento-agil/5916>
Acesso em: 18/10/2012.
CENTRAL IT. Central IT. Disponível em: < http://www.centralit.com.br/a-centralit/nossos- ideais CENTRAL IT 2012> Acesso em: 18/10/2012.
CHAPIEWSKI, Guilherme. Documentação Ágil. Disponível em: < http://devagil.wordpress.com/2010/10/21/documentacao-agil/>. Acesso em: 18/10/2012.
CORP, Rational Software. Artefato: Log de Testes. Disponível em<http://www.wthreex.com/rup/process/artifact/ar_tstlog.htm>. Acesso em 07/11/2012.
DAVIDSON, Edgard. EXtreme Programming em Cinco Minutos. Disponível em: < http://rederia.net/2010/09/08/extreme-programming-em-cinco-minutos/> Acesso em: 18/10/2012.
DIAS, Marissa Villas. Gerenciamento Ágil de Projetos de Software. Disponível em: < http://www.devmedia.com.br/artigo-engenharia-de-software-20-metodos-ageis-de-
desenvolvimento-de-software/15459>. Acesso em: 18/10/2012.
ELIZA, Renata; LAGARES, Vivian. Processo de Teste de Software. Java Magazine, p.77 – 84, Edição 101.
EVV. Programa EVV. Disponível em: < http://www.evv.ueg.br/index.php/o-programa> Acesso em: 18/10/2012.
FERREIRA, E. P.; RAMOS, S. E.; LAGARES, V. C. Scrum no Teste de Software.
Disponível em: <http://dc226.4shared.com/download/emifvo-
F/Scrum_no_Teste_de_Software.pdf?tsid=20120323-003145-4dac9ce5>. Acessado em: 22/03/2012.
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. São Paulo: Editora Atlas, 2002.
GRIEBLER, Fabricio. Ciclo do Scrum. Disponível em: < http://blog.fasagri.com.br/?p=125 > Acesso em: 18/10/2012.
IEEE. Draft IEEE Standard for software and system test documentation. 2007.ANSI/IEEE Std P829-2007.
IMPROVEIT. SCRUM. Disponível em: <
http://improveit.com.br/images/br/scrum/ciclo_scrum.gif> Acesso em: 18/10/2012.
ISQTB. Certified Tester Foundation Level Syllabus. 2011.
KOSCIANSKI, André; SOARES, Michel dos Santos. Qualidade de Software Aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. São Paulo: Novatec Editora, 2007.
MELO, Walter. “Qualidade” + “Testes de Softwares” = “Qualidade de Software”. 2006. Disponível em: http://www.ogerente.com.br/qual/dt/qualidade-dt- ws-testes_software.htm >. Acessado em 27/05/2012.
MYERS, Glendorf J. The Art of Software Testing. Wiley, 1979.
ORACLE. O que é a tecnologia Java e por que é necessária?. Disponível em <http://www.java.com/pt_BR/download/faq/whatis_java.xml>. Acesso em 07/11/2012.
PATRIARCA, Aline Corrêa. Teste de Software: Proposição de Metodologia de Teste de Software Simplificada. Anápolis: UEG/UnUCET, 2010.
PRESSMAN, Roger S. Engenharia de Software . São Paulo: Makron Books, 1995.
Disponível em: <http://www.testset.com.br/material/introducao_ao_tmm.pdf>. Acessado em: 22/03/2012.
SABBAGH, Rafael. Visão Geral do Ciclo do Scrum. Disponível em: < http://scrumemacao.com.br/web/index.php?option=com_content&view=article&id=11&Itemi d=11 > Acesso em: 18/10/2012.
TI EXAMES. Curso e-Learning (24 horas) Fundamentos em Teste de Software Preparatório CTFL – Certified Tester Foundation Level. 2011. Disponível em: < http://www.tiexames.com.br/curso_Teste_Software_CTFL.php>. Acessado em 13/04/2012.
VASCO, Carlos G.; VITHOFT, Marcelo Henrique; Estante, Paulo Roberto C. Comparação entre Metodologias RUP e XP. Disponível em: < http://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0 CCEQFjAA&url=http%3A%2F%2Fwww.ppgia.pucpr.br%2F~alcides%2FTeaching%2Fmest rado%2FFundamentosEngenhariaSoftware%2Fartigos%2FResumosApresentacoes%2FRUPv sXP_draft.pdf&ei=be2CUOLRJqmT0QGpmIHQBA&usg=AFQjCNHPk9DrANo17DZpjjJzF AYq6_eMfQ> Acesso em: 18/10/2012.
VERGARA, Sylvia Constant. Projetos e Relatórios de Pesquisa em Administração. São Paulo: Editora Atlas, 2007.
VIANA, Antônio Geraldo Gonçalves. Gerenciamento de projetos em processo ágil de desenvolvimento de software. Disponível em: http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/393> Acesso em: 18/10/2012.
APÊNDICES
Apêndice A – Cronograma de Atividades do Trabalho de Conclusão de Curso
Apêndice B – PÔSTER APRESENTADO NO IV SIMPÓSIO DE TECNOLOGIA DA INFORMAÇÃO E IV SEMANA DE INICIAÇÃO CIENTÍFICA DO CURSO DE SISTEMAS DE INFORMAÇÃO UNUCET-UEG/2012
Figura 9 Pôster – Teste de Software: Aplicação de uma política de Teste de Software Eficiente em Desenvolvimento Ágil
Apêndice C – Plano de Teste - EVV
Plano de Testes
Prova Digital – Módulo Externo
Histórico de Revisões
Data Versão Descrição Autor
23/03/12 V 1.0 Versão Inicial Pedro Carneiro Jr.
23/03/12 COORDENAÇÃO TECNOLÓGICA UNIVERSIDADE ESTADUAL DE GOIÁS
POLO DE PROJETOS ESPECIAIS - UEG/DEL
Introdução Objetivos
Esse documento do Plano de Testes compõe-se dos seguintes objetivos:
• Identificar informações de projeto existentes e os componentes de software que devem ser testados.
• Listar os Requisitos a Testar recomendados (alto nível).
• Recomendar e descrever as estratégias de teste a serem empregadas.
• Identificar os recursos necessários e prover uma estimativa dos esforços de teste. • Listar os elementos resultantes do projeto de testes.
Sobre o Sistema
Nome do Sistema
Prova Digital - Módulo Externo.
Breve descrição do Sistema
O Módulo Externo da Prova Digital é responsável por intercambiar a troca de dados com as entidades externas a UEG, envolvendo informações de resultado de provas e dados biometricos.
Escopo dos Testes
Percentagem de Cobertura dos Testes de Requisitos
100 % de cobertura nos requisitos de criptografia.
Percentagem de Cobertura dos Testes de Código
/* informe aqui a percentagem de cobertura de testes de código do sistema */
Obs.: Dificilmente consegue-se 100% de cobertura de testes, sendo necessário contentar-se com 99%; Quanto maior a cobertura dos testes na aplicação, maior a confiabilidade nas alterações e novos recursos.
Tipos de Testes que Serão Realizados e Motivos Principais testes:
Tipo de Teste Realizado Motivação
Análise de Cobertura de Testes
Sim Não
Unitário (caixa branca)
Sim Não Teste unitário em todas as classes do Módulo.
Funcionais (caixa preta)
Sim Não Testar as funções criticas de criptografia e conversão de dados.
Integração (caixa preta)
Sim Não Testar a integração com as entidades externas usando um 'mock' do webservice definido para a comunicação.
Sistema (caixa preta)
Sim Não
Carga e Estresse
Sim Não Teste de performance com uma amaostragem razoavel de digitais, para averiguação do tempo medio de identificação biométrica do candidato.
Aceitação (caixa preta)
Sim Não
Outros tipos de teste:
Tipo de Teste Realizado Motivação
Testes do Banco de Dados
Sim Não
Teste do Ciclo de Negócios
Sim Não
Testes de Instalação
Testes de Configuração Sim Não Testes de Segurança e Controle de Acesso Sim Não Testes de Falha e Recuperação Sim Não Testes da Interface do Usuário Sim Não
Considerações Adicionais Sobre os Testes
O numero de digitais no teste de performance de biometria será de 1.500, que é uma proporção razoável baseada no numero máximo de 150 candidatos/dia e com 10 digitais cada.
Documentação do Projeto
A tabela abaixo identifica a documentação e disponibilidade usados para desenvolver o plano de testes:
Especificação de Requisitos Sim Não Diagrama de Fluxo de Dados
(DFD)
Sim Não
Diagrama de Casos de Uso Sim Não Descrições de Casos de Uso Sim Não
Diagrama de Classes Sim Não
Diagrama de Entidade- Relacionamento (MER)
Sim Não
Plano de Projeto Sim Não
Modelo de Análise Sim Não
Modelo de Projeto Sim Não
Documento de Arquitetura Sim Não
Protótipo Sim Não
Manual do Usuário Sim Não
Lista de Riscos Sim Não
Solicitações para nova versão Sim Não
Requisitos a Testar
A lista abaixo identifica aqueles itens – use cases, requisitos funcionais e não funcionais – que foram identificados como alvos de teste. Essa lista representa o que será testado. Análise de Cobertura de Testes
/*************************************************************************** Enumere aqui os itens que serão analisados durante a ANÁLISE DE COBERTURA DE TESTES, informando: Objetivo do Teste; Técnica; Critério de Finalização; Considerações Especiais. ***************************************************************************/
Testes Unitários (caixa branca)
Testar os requisitos a seguir com testes unitários: * Geração de par de chaves RSA;
* Criptografia RSA; * Decriptografia RSA; * Gerar chave Rijndael; * Criptografia Rijndael; * Decriptografia Rijndael;
* Conversão de dados Serializados;
* Importação de dados biometricos WSQ para a plataforma Griaule.
Testes de Integração (caixa preta)
Testar integração do Prova Digital Módulo Externo com a interface de WebService disponibilizado pelos clientes. Desenvolver um Stub provendo a interface previamente acordada para simular o serviço da empresa externa no ambientes de teste.
Testes de Carga e Estresse
Executar uma sequência de testes de comparação biométrica com um dominio alvo de 1500 digitais de amostras, o tempo de identificação não deve exceder o tempo de timeout padrão de uma requisição http (100 segundos).
Recursos
Essa seção apresenta os recursos recomendados para o projeto do Sistema, suas principais responsabilidades, e seus conhecimentos ou conjunto de habilidades.
Trabalhadores
Essa tabela mostra as suposições de recrutamento para o projeto.
Recursos Humanos Função Recursos Mínimos
Recomendados Responsabilidades Específicas ou Comentários Gerente de Teste ou Gerente do Pedro Carneiro
Projeto de Teste Responsabilidades:
provê direcionamento técnico
adquire recursos apropriados
fornece relatórios de gerenciamento Projetista de
Testes
Braully Rocha da
Silva Identifica, prioriza, e implementa os casos de teste.
Responsabilidades:
gera o plano de teste
cria o modelo de teste
avalia a efetividade do esforço de teste
Testador Braully Rocha da
Silva Executa os testes. Responsabilidades:
executar os testes
registrar os resultados
restabelecer-se dos erros
Apêndice D – Plano de Teste – Central IT
Plano de Teste
1. Introdução
O objetivo deste teste é garantir a funcionalidade apropriada do alvo do teste, incluindo navegação, entrada de dados, processamento e recuperação. Verificação do tempo de resposta para as transações designadas ou casos de negócio sob condições variantes de carga de trabalho.
2. Casos de Teste
A tela Relatório para Repasse é responsável pela geração de relatórios referentes ao profissional executante e seu respectivo procedimento realizado. Cada relatório gerado deverá conter o nome do profissional, o nome dos pacientes atendidos, valores para repasse, valores glosados e o valor total a receber. Para que seja feito o repasse aos mesmos.
ESPECIFICAÇÃO DE CASO DE TESTE
Projeto CitSaúde
Caso de teste Módulo Filtro Geração Repasse Tipo Teste caixa preta
Requisito Funcional
Descrição geral
Este teste valida como o sistema deverá se comportar caso receba valores válidos para a geração dos relatórios para repasse.
Roteiro para a realização do teste Entrada:
- Inserção de data;
-Inserção de Convênio/Plano; -Inserção do tipo de Atendimento; -Seleção de campo em Profissional;
-Seleção de tipo de relatório(s) a ser gerado; Saída:
-Lista de nome de profissionais de acordo com a seleção escolhida; -Geração do relatório(s) escolhido
Cenários de teste
Objetivo específico Especificação
das entradas ou ações
Saídas esperadas 1 Tratar datas inválidas, e
verificar se a data inicial é menor que a data final. 20/20/2012 – 00/00/00 Sistema deverá trazer uma mensagem de erro
informando a situação da mesma. 2 Buscar profissionais de
acordo com a opção desejada, se o profissional já recebeu ou não. Seleção de opção no campo de profissional. Trazer o nome dos profissionais de acordo com a opção selecionada.
Apêndice E – Casos de Teste Unitário (ComparadorNbisUegTest) - EVV
/*
* To change this template, choose Tools | Templates * and open the template in the editor.
*/ package br.ueg.biometria.negocio.nbis; import java.io.FileNotFoundException; import java.io.IOException; import java.net.URL; import junit.framework.TestCase; /**
* Testa o comparador NbisUEG *
* @author Braully Rocha da Silva */
public class ComparadorNbisUegTest extends TestCase { public ComparadorNbisUegTest(String testName) { super(testName);
} /**
* Test of compararDigital method, of class ComparadorNbisUeg. */
public void testCompararDigital() throws FileNotFoundException, IOException { System.out.println("compararDigital");
byte[] digit1; byte[] digit2; byte[] digit3;
ComparadorNbisUeg instance = new ComparadorNbisUeg(); byte[] buffImgPgm =
ComparadorNbisUeg.carregarImagem(busarArquivo("imgs/c007_02p.pgm")); byte[] imgWsq = instance.pgmToWsq(buffImgPgm, 384, 289);
digit1 = instance.wsqToXYT(imgWsq); buffImgPgm = ComparadorNbisUeg.carregarImagem(busarArquivo("imgs/c007_05p.pgm")); imgWsq = instance.pgmToWsq(buffImgPgm, 384, 289); digit2 = instance.wsqToXYT(imgWsq); buffImgPgm = ComparadorNbisUeg.carregarImagem(busarArquivo("imgs/c007_01p.pgm"));
imgWsq = instance.pgmToWsq(buffImgPgm, 384, 289); digit3 = instance.wsqToXYT(imgWsq);
System.out.println("Reconhecimento Positivo");
boolean result = instance.compararDigital(digit1, digit2); assertTrue(result);
System.out.println("Repudiando digitais"); result = instance.compararDigital(digit1, digit3); assertFalse(result);
} /**
* Test of matchScore method, of class ComparadorNbisUeg. */
public void testMatchScore() throws FileNotFoundException, IOException { System.out.println("matchScore");
ComparadorNbisUeg instance = new ComparadorNbisUeg(); byte[] buffImgPgm =
ComparadorNbisUeg.carregarImagem(busarArquivo("imgs/a001_03p.pgm")); byte[] imgWsq = instance.pgmToWsq(buffImgPgm, 364, 536);
byte[] xyt1 = instance.wsqToXYT(imgWsq); buffImgPgm =
ComparadorNbisUeg.carregarImagem(busarArquivo("imgs/a001_07p.pgm")); imgWsq = instance.pgmToWsq(buffImgPgm, 310, 500);
byte[] xyt2 = instance.wsqToXYT(imgWsq); int result = instance.matchScore(xyt1, xyt2); int expResult = 11;
assertTrue(result <= expResult); }
/**
* Test of pgmToWsq method, of class ComparadorNbisUeg. */
public void testPgmToWsq() throws FileNotFoundException, IOException {