V Projeto Integrado Multidisciplinar

Prévia do material em texto

UNIP INTERATIVA
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia
ROTEIRO DE TESTES EM UM SITE DE FORMATAÇÃO DE TRABALHOS ACADÊMICOS
Polo Unip Chapecó-SC
2018
Nome: Denivan Lucas Dal Berto
RA: 1701471
Curso: Análise e Desenvolvimento de Sistemas
Semestre: 3º Semestre
ROTEIRO DE TESTES EM UM SITE DE FORMATAÇÃO DE TRABALHOS ACADÊMICOS
Trabalho de conclusão de curso 
para obtenção de título de
graduação em Análise de Sistemas
 Operacionais apresentado à
 Universidade Paulista- UNIP
Chapecó- SC
2018
Nome: Denivan Lucas Dal Berto
RA: 1701471
Curso: Analise e Desenvolvimento de Sistemas
Semestre: 3º Semestre
Trabalho de conclusão de curso
para a obtenção de título de
graduação em Análise e 
Desenvolvimento de Sistemas
Operacionais apresentada à
Universidade Paulista- UNIP
Aprovado em: 
BANCA EXAMINADORA
_______________________/__/___
Prof. Nome do Professor
Universidade Paulista – UNIP
_______________________/__/___
Prof. Nome do Professor
Universidade Paulista – UNIP
_______________________/__/___
Prof. Nome do Professor
Universidade Paulista UNIP
RESUMO
	Hoje em dia os estudantes devem seguir o padrão ABNT em seus artigos, para facilitar a vida dos estudantes foi criado um sistema para isso.
	Esse sistema está programado para depois de o texto ser inserido nos devidos campos, formatar o texto de acordo com as regras estabelecidas.
	Estando nas fases finais, este sistema precisa ser testado para futuramente ser liberado ao público.
	O sistema conta com campos de título, autores, resumo palavras-chave, abstract, keywords, corpo do texto, notas.
	
	
Palavras-Chave: ZICA, TOPZEIRA, 
.
ABSTRACT 
	
	
Keyword: Elderly, Social inclusion, Network.
SUMÁRIO
6
1. INTRODUÇÃO
	
	Logo após o software estar pronto, para garantir a sua qualidade é necessário saber qual o tipo de teste que mais está de acordo com a situação, e aplica-lo, sendo testado com as diversas combinações possíveis de saída, incluindo todos os campos.
	
	
2. TÉCNICAS DE TESTES.
	Devemos efetuar os testes no software para garantir a qualidade e total satisfação do cliente e reduzir os custos totais do software, já que pode ser demorado para corrigir um erro grande que poderia ser prevenido se fossem efetuados testes a cada ciclo de vida do produto. Sendo que quanto mais perto do fim esteja o desenvolvimento do software, mais caro será para encontrar o problema e corrigi-lo. 
	No desenvolvimento de softwares, o teste antigamente era utilizado somente para mostrar que o programa funciona, mas hoje em dia é necessário em todas as etapas de desenvolvimento desse produto, de modo a afirmar que este software está atendendo às exigências dos stakeholders. 
	Os testes atuam de forma em que previna problemas futuros e não somente na a localização de erros, sendo que, para a realização destes testes se tem engenheiros com funções focadas nos testes, gerente, analista e operador de testes.
	É essencial fazer os testes no decorrer da confecção do produto por causa da concorrência e qualidade, a complexidade, segurança e integração com outros sistemas.
	Possivelmente os programadores podem se confundir com o conceito de teste e de compilação, sendo que, o teste é um processo manual feito pelo programador que verificará o código em busca de erros, já a compilação é uma ferramenta inclusa no programa que dá auxílio no desenvolvimento do software, que busca por erros estruturais para poder compilar o software possibilitando sua execução.
	Os testes são de responsabilidade de todos os integrantes de desenvolvimento do software, os testes unitários ficam a encargo dos programadores, os testadores ficam com o conjunto de testes guiado por um roteiro de testes feitos a partir dos requisitos iniciais e será a verificada a aceitação por parte do usuário.
 	Baseado nos estudos da apostila de Engenharia de Software II, há grande diferença entre as palavras erro, defeito e falha. Uma vez que é possível se enganar por estar palavras serem utilizadas em inglês.
Engano- ação humana que produz resultado incorreto;
Falha- Manifestação de um engano cometido pelo desenvolvedor;
Erro- Diferença entre o valor obtido e o valor esperado;
Defeito- Incapacidade de o software fornecer o serviço conforme especificado.
	Há diversos tipos de testes que podem ser feitos no decorrer do desenvolvimento do programa, depois de pronto, e aceitação, para aplicação destes testes é necessário que o programador domine as técnicas de testes bem como habilidade para a aplicação das mesmas e inclusive entender o sistema em todos os seus detalhes.
	O modelo em que são feitos os testes a cada ciclo de vida do software é o Modelo V que foi feito com base no processo de desenvolvimento de software chamado de cascata.
	A equipe de testes entra no processo logo após de ser feito o levantamento das necessidades do cliente, sendo assim, os testadores já se adiantam para saber como serão feitos os testes com base nos requisitos do cliente (casos de teste).
	Depois de os modelos de testes prontos e aprovados, é elaborado um roteiro para a realização dos testes que incluem o que deve ser feito e o resultado esperado. Este roteiro deve ser claro a ponto de que outras pessoas externas ao projeto possam entender.
	Nas fazes iniciais é feito o uso dos roteiros de teste para saber se está sendo supridas todas as necessidades do cliente, bem como os registros para garantir que os testes foram feitos. Logo após o término do produto, o software será submetido a testes de aceitação por parte dos usuários.
	Podemos classificar os testes de acordo com requisitos, os funcionais, que ficam a encargo do funcionamento do software, mas também há requisitos não funcionais que não são especificados pelo usuário, são as características comportamentais do produto.
	Tipos de testes para requisitos funcionais:
Testes de regressão- garante a funcionalidade mesmo depois de passar por mudanças e manutenções;
Testes de interoperabilidade- garantir o funcionamento da comunicação entre os sistemas envolvidos;
Testes alfa e beta- depois de o software concluído, os usuários devem fazer um teste para garantir o funcionamento e eliminar erros;
Testes de usabilidade- garante a facilidade de uso do software por parte do usuário bem como todos os elementos dispostos na interface;
	Tipos de testes para requisitos não funcionais:
Testes de carga ou stress- como o próprio nome diz este teste submete o sistema a situações extremas com vários acesos simultâneos;
Testes de desempenho ou performance- é verificado o tempo de resposta do software, ou seja, quanto tempo ele demora para realizar uma solicitação feita pelo usuário, sendo aceitável até 5 segundos;
Testes de segurança- testes contra a entrada de pessoal não autorizado;
Testes de recuperação- verificar como o software se recupera de um fechamento indevido causadas por situações adversas;
Testes de portabilidade- verificar se é possível a instalação desse software em ambientes operacionais distintos;
Testes de confiabilidade ou disponibilidade- perceber como o software se comporta diante de alguma falha, ele deve se manter funcionando, pelo menos parcialmente e informar o usuário através de mensagens.
Tipos de testes para ambiente:
Testes estáticos: verifica se os diagramas de casos de uso, de classes estão compatíveis com o software desenvolvido;
Testes de aderência de código: é feita a inspeção do código fonte para checar se está dentro dos padrões de organização e melhores práticas;
Testes de configuração: avalia-se a compatibilidade desse sistema com os recursos que se tem de hardware e software;
Testes de navegação: é avaliado a postura do software perante a navegação entre telas, links para outros sistemas, dentre outro;
Testes de instalação: é feita a checagem do instaladore se o sistema funciona após ser instalado em outro computador.
Técnica de teste funcional ou caixa-preta: são efetuados casos de testes em que serão testadas funcionalidades específicas e catalogadas as situações de sucessos e insucessos.
Técnica de teste estrutural ou caixa-branca: este teste é focado na qualidade do código confeccionado, sendo inspecionado se todas as linhas de comando foram executadas pelo menos uma vez. Para isso são testados todos os casos de condicionais e escolhas existentes no código do software.
			
2.1.0. ROTEIRO DE TESTES.
	
	
	O sistema de formatação de textos já está pronto, faltando somente alguns testes para ser liberado para o público, sendo assim, foi percebido que o correto a se fazer seriam testes de diversas situações, então a equipe de engenheiros contratou um programador que não estava presente no desenvolvimento para efetuá-los.
	Na realização dos testes não se tem certeza que o software fará o esperado pelo cliente, sendo possível saber somente testando pois são muitas as combinações possíveis que podem gerar diferentes comportamentos que não eram esperados.
	Para cada caso de teste efetuado será descrito o que será testado, a sua condição inicial, o passo a ser executado, quais os campos preenchidos para o teste e o resultado. Após o teste ser efetuado, o programador mostrará com capturas de tela qual foi o resultado alcançado para provar que os testes foram feitos.
	Sendo assim serão testadas as seguintes situações do sistema de formatação de textos: 
Neste primeiro teste será gerado um artigo completo, com todos os campos preenchidos: Título, título em inglês, um autor cadastrado, resumo, palavras-chave, abstract, Keywords, corpo de texto, notas e referências bibliográficas.
O objetivo é que o texto de entrada seja gerado e dê saída como um artigo formatado e nos padrões ABNT.
O segundo caso de testes segue o mesmo procedimento do primeiro caso de testes exceto que esse artigo será para a submissão e não gerado:
O terceiro caso de uso fará o teste gerando um artigo completo, com todos os campos preenchidos: Título, título em inglês, três autores cadastrados, resumo, palavras-chave, abstract, Keywords, corpo de texto, notas e referências bibliográficas. Sendo assim, quando o artigo for gerado terá que mostrar todos os autores do artigo.
O quarto caso de uso terá todos os campos preenchidos, serão cadastrados três autores com e-mails inválidos.
c
	
O quinto caso de uso o artigo será gerado com todos os campos preenchidos exceto os três autores:
O sexto caso de uso contará com o preenchimento de todos os campos e um autor e logo depois limpado antes de gerar o artigo:
No sétimo caso de teste será cadastrado um autor e no campo chamado de corpo de texto um texto com formatação em negrito, itálico, subscrito e sobrescrito com texto justificado.
O oitavo caso de teste, o artigo precisa ter um autor cadastrado, nenhum campo em branco e tendo no campo chamado corpo de texto uma imagem. O teste foi efetuado e assim constatado que não é possível fazer a inserção de imagens no artigo, ou seja, o campo “corpo de texto” não provê este tipo de funcionalidade.
No nono e último caso de testes, será gerado um artigo completo com um autor cadastrado, e incluindo no campo “notas” o URL de uma imagem e ciar um texto formatado à esquerda e em negrito.
2.1.1. RESULTADO DOS TESTES.
	Em todos os casos de testes efetuados foram gerados os resultados esperados na geração e submissão de artigos, exceto pelo caso de teste de anexo de imagens no campo “corpo de texto”, já que neste caso não foi possível a conclusão do teste por conta deste campo não ter a capacidade de receber imagens.
	Nestes testes recém executados o sistema se saiu bem em relação ao cadastramento de um ou mais autores, sendo que, todos os outros campos também foram preenchidos. 
	Quando o artigo foi gerado, aparecerão os nomes de todos os autores no topo do artigo com uma numeração que dá referência ao final da página em que aparece o restante das informações de determinado autor.
	Sendo reconhecido quando não nenhum autor cadastrado, não é possível gerar o artigo e a falta de e-mail válido também impede que o artigo seja gerado, os dois casos provocam avisos específicos que ajudam o estudante a encontrar e corrigir os erros.
	O sistema teve um ótimo comportamento em relação a formatação de textos que estão situados nos campos de “corpo de texto e notas”, foram testados recursos como, negrito, itálico, subscrito, sobrescrito, e funções que dizem a respeito do alinhamento do texto. 
	E, no último caso de uso, foi gerado com sucesso um artigo completo que incluía no campo “notas” o URL de uma imagem, e algumas alterações de formatação no texto.
	
	
	
	
2.1.2. AVALIAÇÃO HEURÍSTICA.
	 
	Este tipo de avaliação consiste em verificar a usabilidade utilizado para encontrar problemas na interface do sistema de formatação. Este método se baseia em conceitos de usabilidade e pode ser considerado econômico pois é fácil de ser aplicado e de fácil aprendizagem.
	Para efetuar os testes o programador contratado passará por duas etapas, na primeira ele vai verificar o sistema como um todo, tendo uma visão abrangente e na segunda, a análise será voltada para elementos específicos da interface.
	O ideal para a realização deste teste inclui de três a cinco integrantes, o que não acontece agora pois haverá somente um programador para efetuar os testes, sendo assim, nem todos os erros de interface serão perceptíveis, já que outros programadores poderiam encontrar problemas parecidos e distintos.
	Para a inspeção da heurística de usabilidade para projeto de interface serão utilizados dez princípios:
Visibilidade do estado do sistema:
O sistema de formatação de texto cria sempre avisos responsivos sobre as tarefas realizadas, como quando é necessário utilizar uma janela alternativa para efetuar a colagem de imagens ou aviso de erros
Correlação entre o sistema e o mundo real:
O sistema esconde bem a linguagem que está por trás da interface, ou seja, não mostra quaisquer palavras que deveriam ser utilizadas exclusivamente no código fonte, por exemplo, nome das variáveis. Sendo assim, o uso da linguem no programa está adequado e segue um fácil entendimento.
Liberdade e controle do usuário:
O usuário terá como reverter alguns tipos de erros que venha a lhe ocorrer involuntariamente, por exemplo, efetuar a limpeza de todos os campos, desfazer pequenas ações (utilizando o conjunto de teclas de atalho Ctrl+Z), retirar facilmente a formatação (negrito, itálico, subscrito, sobrescrito) e o alinhamento do texto (Alinhamento à esquerda, direita, centralizado e justificado) entre outras. Clicando sobre a função indesejada que já foi aplicada pode-se efetuar a sua retirada.
Consistência e padrões:
O sistema deixa claro o seu texto, não deixando margens para uma interpretação incorreta ou achar que duas opções possam ter a mesma função.
Prevenção de erros:
Sendo mostrados erros no momento em que o campo título está vazio, ou reconhecendo quando o e-mail não é válido, o sistema não deixará o usuário confuso a respeito de que campo precisa ser corrigido para que o artigo seja gerado.
Reconhecimento ao invés de memorização:
Por causa da sua simplicidade o sistema é fácil de ser utilizado, e em caso de dúvida é possível posicionar o cursor em cima da função desejada que aparecerá o nome da função, mas não há nenhum tipo de instruções.
Flexibilidade e eficiência de uso:
Pode-se utilizar algumas teclas de atalho para tornar o processo de gerar o artigo mais ágil. Já foi mencionado anteriormente o recurso de desfazer uma ação, pode-se também copiar e colar (Ctrl+C, Ctrl+V), entre outros.
Projeto estético e minimalista:
Não são mostradas informações irrelevantes em caixas de diálogo ou outras situações.
Suporte para o usuário no reconhecimento,no diagnóstico e na recuperação de erros:
Como já citado anteriormente, o sistema cria um aviso caso o e-mail seja inválido, seria de maior utilidade se o sistema mostrasse um exemplo de qual seria o formato de um e-mail válido, por exemplo, nome@provedor.com.
Ajuda e documentação:
Não há documentação ou instruções disponíveis para a consulta do usuário.
	
2.1.3. TESTE DE USABILIDADE.
	Pode-se dizer que o sistema tem boa usabilidade quando se tem facilidade de aprendizado, facilidade de uso, flexibilidade, produtividade, e a satisfação do usuário.
	O teste usabilidade tem como maior foco encontrar problemas, recolher dados quantitativos e qualitativos, e saber se o usuário está satisfeito em utilizar o software. Os usuários vão testar o software para fazer trabalhos requisitados pelos programadores. Haverá observadores que prestarão atenção no que se passa durante o teste e farão anotações a respeito.
	O objetivo do teste é o descobrimento de falhas no sistema, o teste vai ocorrer na empresa que desenvolveu o software, juntamente com o programador que coordenará o processo de testes, tendo como duração duas seções de uma hora. 
	O teste contará com a participação de cinco estudantes voluntários que não devem conhecer o sistema, farão uso dos computadores dos programadores, com o sistema de formatação de textos previamente instalado e sem nenhum campo estar preenchido.
	As tarefas solicitadas aos voluntários será, efetuar o teste de todos os campos, e logo em seguida, ir alternando os campos em branco, para garantir que o sistema não deixe um artigo ser publicado sem ter todos os dados relevantes.
	Para garantir que os testes foram efetuados, eles terão que fazer uma captura de tela com uma breve descrição do que foi testado. Também é possível habilitar uma gravação da tela e gravação de áudio, sendo assim, possibilita a percepção de reações do usuário ao chegar em determinado campo a ser testado, deste modo pode-se saber se a interface está de acordo com os padrões de usabilidade.
	As instruções serão distribuídas aos cinco participantes, nela haverá todo o roteiro de testes, deste modo os participantes não irão ficar pedindo para esclarecer dúvidas durante as sessões.
	Os estudantes provavelmente já leram alguma espécie de artigo, inclusive para conseguir efetuar o seu próprio artigo, sendo assim, ele sabe a ordem que as informações são dispostas, o que estará no topo (título, título em inglês, autor, resumo e palavras-chave), o que estará no meio (corpo de texto) e o que ficará no rodapé ( notas e referências), sendo assim, o sistema dispõe dos campos na ordem padrão de todos os outros possíveis artigos que o aluno já leu, possibilitando que o aluno saiba, sem conhecer o sistema a ordem que os campos serão dispostos. Isso faz com que o software tenha um ótimo trabalho empírica.
	Algo que os voluntários não gostaram é que na submissão do documento (blind review) não especifica que esta função gera o artigo sem fazer a menção dos autores no artigo.
Mais um ponto negativo é que o sistema não possui nenhuma seção dedicada para a ajuda, que respondam as dúvidas mais frequentes dos usuários, por exemplo, saber para que serve a função de submissão de artigo (blind review), citada anteriormente.
Este modelo de formatação utilizado para padronizar o artigo é o ABNT que é o mais utilizado para efetuar trabalhos acadêmicos como monografias e artigos, mas para o sistema poderia também ser mais flexível e permitir que tivessem um modelo de outros padrões, como o Vancouver que é mais focado na área dos estudos relacionados à saúde (como Enfermagem, Fisioterapia, entre outros).
Apesar do sistema contar com os erros acima mencionados, ainda é possível ser feita a utilização do mesmo, já que não é usual a inserção de imagens no corpo de texto de artigos. Sendo que o sistema conta com uma interface limpa e prática, se torna fácil a usabilidade.
2.1.4. SALA DE TRIAGEM E CADASTRAMENTO.
	
	
	
2.1.5. ESPAÇO DE CONVIVÊNCIA.
	
	
2.1.6. ADMINISTRAÇÃO DO CIDI.
3. LAN
	
	
	
5. CONCLUSÃO
	
	
Este sistema embora que possua falhas esta apto ao uso
6. REFERÊNCIAS