Ministério da Educação
Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital
Programa de Residência em Tecnologia da Informação
Definindo um Processo de Testes Aplicado ao Contexto do Tribunal de Contas do Estado do
Rio Grande do Norte
Rebecca Betwel Santos Oliveira
Natal-RN Junho de 2019
Processo de testes aplicado ao contexto do Tribunal de Contas do Estado do Rio Grande do Norte
Trabalho de conclusão de curso apresentado ao Programa de Residência em Tecnologia da Informação da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Especialista Residente em Tecnologia da Informação .
Linha de pesquisa:
Testes de Software
Orientadora
Profa. Dra. Roberta de Souza Coelho
Programa de Residência em Tecnologia da Informação IMD – Instituto Metrópole Digital
UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN Agosto de 2019
Trabalho de Conclusão de Curso sob o título Processo de testes aplicado ao contexto do Tribunal de Contas do Estado do Rio Grande do Norte apresentado por Rebecca Betwel Santos Oliveira e aceita o Programa de Residência em Tecnologia da Informação (TI) com atuação junto ao Tribunal de Contas do Estado (TCE/RN) da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Profa. Dra. Roberta de Souza Coelho Presidente
DIMAp – Departamento de Informática e Matemática Aplicada UFRN – Universidade Federal do Rio Grande do Norte
Uirá Kulesza Examinador
DIMAp – Departamento de Informática e Matemática Aplicada UFRN – Universidade Federal do Rio Grande do Norte
Vinícius José Miranda Toscano de Brito Filho Examinador
Diretoria de Informática
Tribunal de Contas do estado do Rio Grande do Norte
Natal-RN, 11 de Agosto de 2019.
Agradecimentos
Agradeço primeiramente aos que me apoiaram nessa jornada e entenderam minha ausência nos momentos necessários, meu esposo Marco Olimpio, que além de apoio co- laborou com o projeto de forma direta e indireta com dicas e sugestões, meu filho Mark Betwel e minha filha Lissa Betwel que ainda amamentando me acompanhou durante as aulas da residência. E a minha mãe (in memorian) que sempre me incentivou a seguir meus sonhos e nunca parar de estudar.
Também agradeço a minha orientadora por toda paciência e ensinamentos passados, toda atenção e motivação que sempre me inspiraram para realizar um trabalho melhor.
Agradeço também ao meu Diretor Vinícius José Miranda Toscano de Brito Filho que me deu a oportunidade de implementar o presente projeto.
Também agradeço aos dois colaboradores Carlos Eduardo Azevedo dos Santos e Jeck- son Victor de Oliveira por todo apoio ao longo da implantação do presente projeto.
Agradeço finalmente ao órgão que trabalho pela oportunidade de realizar mais um curso para meu aperfeiçoamento profissional, demostrando mais um vez o interesse na qualificação dos profissionais que atuam no TCE-RN.
Albert Einstein
Processo de testes aplicado ao contexto do Tribunal de Contas do Estado do Rio Grande do Norte
Autor: Rebecca Betwel Santos Oliveira Orientador: Professora Dra. Roberta Coelho
Resumo
O presente trabalho objetiva descrever a adoção de um processo de testes de software a um ambiente de desenvolvimento previamente sem nenhum processo definido de teste ou qualidade.
A metodologia utilizada foi de pesquisa exploratória, tendo sido feita levantamento bibliográfico de diversos autores como (SOMMERVILLE, 2011) e(HUMBLE; FARLEY, 2010) que tratavam da relação processo de testes e processo de desenvolvimento de forma ampla, sendo o primeiro uma abordagem que integrava os processos de desenvolvimento e testes e o segundo levando em consideração ao processo como todo, desde a concepção até a integração continua e também abordando softwares em outras fases do ciclo de vida do software. Outros autores foram pesquisados também como ferramenta de auxilio para ela- boração dos templates utilizados dos testwares criados como (FUNPAR, 2001c), (FUNPAR, 2001a) e (FUNPAR, 2001b) alem de artigos na área como (SOUZA; GASPAROTTO, 2013), (STELLMAN; GREENE, 2011), (BLANCO, 2012), (IEEE, 1990), (ISTQB, 2018) . Durante a execução do projeto aqui apresentadofoi elaborado um processo de teste que se encaixa- se na nova proposta de desenvolvimento de sistemas da Diretoria de Informática (DIN) associado a um conjunto de boas práticas e equipes treinadas para realizar as atividades do processo. Atualmente o projeto apresentado encontra-se funcional e aplicado dentro da DIN-TCE-RN.
Palavras-chave: Processo de Testes, Plano de Testes, Casos de Testes, Integração contínua, automatização de testes.
Contas do Estado do Rio Grande do Norte
Author: Rebecca Betwel Santos Oliveira Supervisor: Prof. Dra. Roberta de Souza Coelho
Abstract
The present work aims to describe the introduction of a software testing process into a development environmentwithout any kind of previous test or testing process, or any quality goals, or development process.
The methodology used was exploratory research, having been made bibliographic survey of several authors as (SOMMERVILLE, 2011) e (HUMBLE; FARLEY, 2010) that deal with the relationship between testing process and development process broadly, the first being an approach that integrated the development and testing processes and the second taking into account the whole process from conception to continuous integration and also addressing software in other phases of the software life cycle. Other authors were also researched as an aid tool for the elaboration of the used templates of the software created as(FUNPAR, 2001c), (FUNPAR, 2001a) and (FUNPAR, 2001b) besides articles like (SOUZA;
GASPAROTTO, 2013), (STELLMAN; GREENE, 2011), (BLANCO, 2012), (IEEE, 1990), (ISTQB, 2018) . During the execution of the project presented here, a test process was elaborated that fits in with the new proposal for the development of systems of the Informatics Directorate (DIN) associated with a set of good practices and teams trained to carry out the activities of the process. Currently the project presented is functional and applied within DIN-TCE-RN.
Keywords: Test process, test plan, test case, continuous integration, test automation
Lista de figuras
1 Detalhamento do modelo. Fonte: (ISO/IEC/IEEE29119, 2013) . . . p. 20 2 Detalhamento do modelo. Fonte: (TCE-RN, 2019) . . . p. 22 3 Lista de APIs dentro do repositório GitLab . . . p. 25
CI: Continuos Integration
DIN: Diretoria de informática do TCE-RN
FUNPAR: Fundação da Universidade Federal do Paraná IMD: Instituto Metrópole Digital
TCE-RN: Tribunal de Contas do Estado do Rio Grande do Norte
Sumário
1 Introdução p. 12
1.1 Contextualização . . . p. 13 1.1.1 Sistemas Legados . . . p. 13 1.1.2 Projetos . . . p. 14 1.2 Problema . . . p. 14 1.3 Estado da Arte . . . p. 15 1.4 Solução . . . p. 16
2 Processo de teste p. 18
2.1 Fases do processo de testes e tarefas de teste . . . p. 19
3 Projetos piloto p. 24
4 Considerações finais p. 26
4.1 Trabalhos futuros . . . p. 26
Referências p. 27
Apêndice A -- Guia de Testes p. 29
Apêndice B -- Plano de Testes p. 61
Apêndice C -- Caso de Testes p. 71
Apêndice D -- Relatório de testes de fluxo p. 78
Apêndice F -- Relatório de validação da sprint p. 99
12
1 Introdução
De acordo com (SOMMERVILLE, 2011) validação de requisitos checa se estes realmente definem o sistema que o usuário deseja. Com esse motivador inicial de validar se o que foi requisitado está sendo entregue, podem ser usadas algumas técnicas como: revisão de requisitos, prototipação e geração de casos de teste. Essas três técnicas podem ser utilizadas para validar um requisito e por consequência auxiliar a equipe a compreender melhor o que aquele requisito representa em termos de desenvolvimento. Como os casos de testes e devem chegar o código a partir deste requisito, logo o processo de validação permeia todo o processo de desenvolvimento.
(SOMMERVILLE, 2011) chama de processo de verificar e validar (V&V) e este destina-se a mostrar que um sistema está em conformidade com sua especificação e que a engenharia de requisitos de encarrega de detalhar, e são os testes que fazem este papel de verificação e validação do sistema ao que foi especificado. Logo os testes são aliados da qualidade, sendo os mesmos capazes dentro de um contexto controlado, afirmar que o entregue e o especificado é equivalente. Também seguindo a mesma ideia (PRESSMAN; MAXIM, 2016) ,
“teste de software é um elemento crítico da garantia de qualidade de software e representa a revisão final da especificação, projeto e geração de código”. Logo é necessário criar testes de software, porém não de qualquer forma ou jeito, deve-se existir um planejamento para o mesmo, um processo próprio com etapas claras e bem definidas, um processo de testes.
Segundo (PRESSMAN; MAXIM, 2016) o objetivo dos testes é encontrar o maior número possível de erros com esforço controlado aplicado durante um intervalo de tempo previsto, por este motivo deve-se existir um mínimo de documentação e planejamento para a testes dentro do processo de desenvolvimento de um software e, muitas vezes, é necessário um controle e acompanhamento dos testes, avaliando sempre o retorno destes para o projeto de software, haja vista que testar todo o sistema é inviável por demandar alto custo de tempo, recursos humanos e computacional, planejar e definir objetivos claros para os testes é essencial para o sucesso do software e sua boa aceitação, além disso entregar software de qualidade é estar de acordo com as especificidades do cliente, conforme a série
de normas ((ISO), 2005), também conhecida como SQuaRE (Sysem and Software Quality Requirements and Evaluation) .
1.1 Contextualização
O Tribunal de Contas do Estado do Rio Grande do Norte, através de sua Diretoria de Informática, está criando um conjunto de guias e definições de processos internos para o desenvolvimento de software, neste sentido e alinhando os interesses do TCE-RN as inovações pretendidas na parceria com o IMD-UFRN, foram designados alguns projetos visando a melhoria interna de processos e aumento da qualidade dos produtos entregues aos usuários de sistemas do TCE-RN, onde estão inclusos Ministério Público, Polícia Federal entre outros órgãos das diversas esferas governamentais.
No contexto inicial ao projeto, não havia um processo de teste definido dentro da diretoria, cada equipe de projetos desenvolvia seu próprio processo interno e fazia de forma exploratória sem registros seus testes e avaliações das entregas a serem feitas. O mesmo acontecia aos projetos legados, os mesmos recebiam solicitações de melhorias e correção, iam para a equipe de operação, que realizava a correção pontual e não era feito analise de impacto da correção nos demais sistemas que consumiam as informações ou sistemas corrigidos.
O presente projeto visa melhorar a qualidade dos produtos de software entregues aos seus usuários finais, criando um processo de testes inserido no processo de desenvolvimento e alinhado com os demais projetos de melhoria da diretoria.
1.1.1 Sistemas Legados
Conforme (HUMBLE; FARLEY, 2010) em cada uma das etapas do ciclo de vida do software deve ser analisado como serão aplicados os esforços de realização de testes, quando se inicia um processo de testes e verificação em produtos já existentes deve-se levar em consideração diversos pontos, como: possibilidade de automatização dos testes, o custo dessa automatização, etapa do ciclo de vida do software, tipo de tecnologia utilizada no desenvolvimento, capacidade da equipe de testes (recursos humanos e computacionais envolvidos) dentre outros critérios. O autor afirma que o esforços em sistemas legados deve ser ponderados, e feita de forma clara apenas testes no que está sendo corrigido ou modificado, porém também é categórico em afirmar que quando há consumo de recursos de sistemas legados por projetos novos, o mesmo deve ser analisado a viabilidade de testes
14
do que será consumido nos novos projetos.
Dentre os projetos do TCE-RN muitos deles encontram-se como sistemas legados, sistemas já consolidados que possuem correções periódicas e diversas modificações solici- tadas pelas demais diretorias do tribunal, por este motivo a análise de como lidar com qualidade e testes em sistemas legados é necessária para o projeto de testes.
1.1.2 Projetos
Um dos maiores esforços da DIN é a entrega de novos sistemas que podem ser novos módulos de sistemas já existentes, ou novas demandas sejam elas legais ou por necessida- des de atualização tecnológica ou por serem grandes demais para pequenas correções ou modificações.
(HUMBLE; FARLEY, 2010) cita a importância do investimento do processo de testes em projetos novos e a importância dos testes, em especial dos testes unitários, para a criação de etapas de verificação dentro da integração contínua.
Neste cenário é justificado o investimento em testes e em um processo para padroni- zação de testes dentro de projetos e sistemas em geral dentro do TCE-RN.
1.2 Problema
Criar um processo de testes não é algo trivial, principalmente quando não há cultura de testes em um ambiente de desenvolvimento, conforme (ISTQB, 2018) é necessário ter etapas bem definidas e processos claros e é vital para o desenvolvimento que os testes sejam feitos, verificados e melhorados ao longo do ciclo de vida do software. E (HUMBLE;
FARLEY, 2010) afirma que é importante também planejar os tipos de testes, estudar as ferramentas a serem adotadas, criar guias e criar uma cultura de testes dentro do ambiente de desenvolvimento de uma forma geral.
De uma maneira geral o (ISTQB, 2018) descreve um processo cíclico de testes reco- mendado para as atividades de teste, o mesmo possui as etapas de : planejamento, análise, modelagem, implementação, execução, relatório (registro) e controle e atualização de tes- tes. Cada uma dessas etapas possuem atividades e responsabilidades claras a serem feitas, mas a descrição das mesmas serão apresentadas no tópico 1.3.
A problemática que envolve os diversos estágios de desenvolvimento no TCE-RN en- globam, sistemas legados de alta demanda de correção e melhoria, projetos em tecnologias
diferentes, e metodologias diversas de desenvolvimento a depender dos seus gerentes de projetos (líderes) e expertise da equipe no geral. Com isso tinha-se um ambiente heterogê- neo quanto a práticas e processos dentro de cada um dos diversos produtos desenvolvidos ou a desenvolver.
O primeiro levantamento seria analisar o catálogo de produtos da diretoria, avaliar quais produtos e tecnologias a serem utilizadas e adequar um processo e conjunto de templates de artefatos de testes que seria necessário e adequá-los ao novo processo de desenvolvimento proposto por outros membros da equipe técnica da DIN no TCE-RN.
O fato de não existir um processo prévio de testes nos impede de fazer compara- ção entre processos, porém facilita na aplicação de um novo processo, já que existe a oportunidade de inserir no
1.3 Estado da Arte
Os termos QA(Quality Assurance) e QC (Quality Control) polularizaram-se nos últi- mos anos como termos relacionados a área de Qualidade de Software, sendo estes muitas vezes confundidos com a os termos dos profissionais na área de testes de software. Im- portante frisar que existem diferenças entre qualidade e teste de software. A ((ISO), 2005) define que qualidade está relacionada ao processo de produzir algo, logo está relacionada a definição clara e objetiva de passos a serem realizados para obter um produto dito de qualidade, e se existe qualidade no processo o produto produzido naturalmente terá quali- dade. Sendo objetiva também a ISO afirma que esse processo deve conter diversas etapas que verifiquem que o que está sendo feito corresponde ao que foi requerido.
Já (SOMMERVILLE, 2011) fala de processos de Validação e Verificação, chamados por ele de V&V, ou seja dentro do processo de software existem etapas que verificam o que está sendo feito e outras que validam, o (ISTQB, 2018) afirma que assim como o desenvol- vimento de software pode ter diversos processos possíveis para realiza-lo o mesmo ocorre quando se trata de processos de teste, dentro dos possíveis processos o mais importante é sempre adequar o processo de teste a cultura da empresa e alinha-lo ao processo de desenvolvimento, o Instituto também define que apesar de muitos processos assim como nos processo de desenvolvimento existem etapas e atividades que são gerais independente de tipo de processo escolhido a ser adotado e assim como (SOMMERVILLE, 2011) e (PRES- SMAN; MAXIM, 2016) defendem que deve-se adequar o processo de desenvolvimento ao contexto (empresa/organização) inserido para testes se aplica a mesma ideia.
16
Dentro do processo de testes é importante definir suas atividades, diferenciar seus produtos de trabalho e manter a rastreabilidade entre a base de testes e os produtos de trabalho de teste, como explica (ISTQB, 2018).
1.4 Solução
A presente solução é implementar um processo de teste de software que se adapte a cultura de desenvolvimento do TCE-RN alinhando o processo de teste as demais áreas como projetos de desenvolvimento de software, sustentação de software, CI, banco de dados e infra estrutura.
Primeiramente fazer um levantamento bibliográfico, com isso foi observado que exis- tem algumas diferenças em como os processo de teste são apresentados como (ISTQB, 2018) afirma que não existe um processo universal, mas sim um conjunto de atividades de teste sem as quais os objetivos de teste não serão possíveis, e lista que existem diver- sos fatores que influenciam no processo de testes de uma organização, como: Modelo de ciclo de vida de desenvolvimento e metodologias de projeto utilizados, níveis de testes e tipos de testes considerados, risco de produto e projeto, domínio de negócio, restrições operacionais, políticas e práticas organizacionais e normas internas e externas necessárias.
Além disso fazer o levantamento de outros processos de testes aplicados a contextos do serviço público foram feitos, e foi encontrado o material disponível da FUNPAR, este foi utilizado como base inicial para os templates elaborados dos artefatos de teste como plano de aceitação, plano de testes, caso de teste e foram retirados alguns conceitos também dos documentos estudados como (FUNPAR, 2001c),(FUNPAR, 2001a) e (FUNPAR, 2001b).
Levantar o conjunto de artefatos mínimos para viabilizar os testes, estudar possíveis ferramentas, elaborar plano de treinamento de equipe, assim como elaboração de guias que deem suporte ao processo de software foram ações que fizeram parte da presente proposta.
Foi levado em consideração o tipo de desenvolvimento, as linguagens de programação que eram utilizadas nos diversos projetos. Como parte do que foi elaborado, um conjunto de testwares1 foi elaborado para dar suporte ao processo proposto, que será detalhado no tópico de desenvolvimento a seguir, e em cima desse modelo proposto de processo foram feitos alguns projetos piloto para validar o processo, que atualmente está implementado e integrado ao processo de desenvolvimento na DIN.
1Conjunto de artefatos de teste, como: planos de teste, casos de teste, procedimento de testes, scripts de testes automatizados, ou seja, todos os artefatos de testes produzido
Os objetivos de teste do processo proposto incluem:
• Avaliar os produtos de trabalho: código, requisitos, regras de negócio e qualquer documentação que forneça informações sobre os requisitos do sistema solicitado
• Verificar se todos os requisitos especificados foram atendidos: em projetos
• Validar se o objeto de teste2 está completo
• Reduzir defeitos
• Encontrar falhas
• Fornecer informações necessárias para tomada de decisão: tornando essencial o re- gistro do que se é feito no processo de testes para dar suporte a tomadas de decisão da organização quanto ao sistema e até os próprios testes
• Reduzir nível de risco de qualidade de software inadequada (por exemplo, falhas não detectadas anteriormente que podem ocorrer em produção)
• Cumprir com requisitos ou normas legais ou regulamentares3
• Verificar se cada função ou componente está funcionando como esperado, através de testes unitários
• Verificar se a integração das funcionalidades estão funcionando como esperado, atra- vés de testes de integração
• Aferir cada entrega se o que foi especificado está sendo entregue, através de um conjunto de testes de aceitação
2todo artefato de software que está sendo verificado e testado
3No contexto do TCE-RN é essencial que os sistemas reproduzam com fidelidade o que é requisitado por leis e regulamentos, por se tratar de um órgão público que faz fiscalização e auditoria de contas públicas e o mesmo possuir grande impacto no cenário político e econômico da região
18
2 Processo de teste
Como mencionado no tópico anterior, a solução para implantação foi desenvolvida com base no levantamento feito, o ISTQB no seu syllabus (ISTQB, 2018) fala dos fatores contextuais que influenciam o processo de testes de uma organização e elenca-os, dentre os quais temos:
• Modelo de ciclo de vida de desenvolvimento e metodologias de projeto utilizados;
• Níveis de teste e tipos de teste considerados;
• Restrições operacionais: conhecer os limites em relação a recursos e orçamento é necessário já que o TCE-RN conta com a colaboração de servidores, terceirizados e estagiários;
• Políticas e práticas organizacionais
• Normas internas e externas necessárias
O mesmo guia também elenca os aspectos gerais que devem ser levados em conside- ração em um processo de teste que concordam com as diretrizes de (ISO/IEC/IEEE29119, 2013) são eles:
• Atividades e tarefas de teste
• Produtos de trabalho de teste
• Rastreabilidade entre a base de teste e os produtos de trabalho de teste
Alinhado ao (TCE-RN, 2019) o que é equipe de testes, testadores e analista de testes e qualidade, com as seguintes responsabilidades e atribuições:
• Equipe de Testes: Equipe formada pela equipe de testadores e Analista de teste e qualidade.
• Analista de testes e qualidade: responsável por validar os incrementos de soft- ware e avaliar a qualidade dos artefatos entregues: definir estratégias de testes, definir ferramentas, metodologias e procedimentos de testes a serem adotados, ava- liar resultados e reportar erros e não conformidades, assegurar alinhamento entre os testwares e o PRODEV-TCE/RN1, liberar release para homologação;
• Testador:responsável pela execução de testes manuais e automatizados, implemen- tação de scripts de testes e código de testes, elaborar relatórios, apontar inconformi- dades durante a execução dos testes ao analista de teste e qualidade para avaliação, analisar erros de execução, registrar resultados obtidos pelos testes, contribuir sem- pre que oportunamente ao processo de teste, devido sua dinamicidade evolutiva, difundir a importancia de testes no processo de desenvolvimento.
Um ponto importante é a definição dos artefatos a serem usados como guias, os cha- mados templates, para o presente processo foram desenvolvidos os seguintes artefatos:
• Plano de Teste: documento com visão estratégica e gerencial de como os testes serão executados no projeto, dentro de uma definição de escopo, recursos, prazos, pode ser visto no Apêndice B;
• Caso de Testes: documento que defini um caso de teste a partir de um caso de uso, associado a regras de negócio, elaborado na fase de análise, ver Apêndice A, e o caso de teste está descrito no Apêndice C modelo engloba como deverá ser descrito dentro das features cucumber em ferramenta específica citada no Guia.
• Relatórios de testes: Apêndices F, E e D, são o produto entregável para a próxima etapa do processo de desenvolvimento descrito no (TCE-RN, 2019).
Sobre as atividades do processo a próxima seção irá descrever as mesmas dentro de cada uma das etapas.
2.1 Fases do processo de testes e tarefas de teste
• Planejamento de teste
1fonte: (TCE-RN, 2019) É o processo de desenvolvimento recentemente desenvolvido para a Diretoria de Informática do TCE-RN, projeto que foi liderado por André Gustavo, servidor da casa, em parceria com demais analistas de controle externo e direção
20
• Análise e modelagem de teste
• Implementação de testes automatizados e manuais
• Execução de testes
• Conclusão do teste
• Monitoramento e Controle
Definir uma base de teste2 é um passo importante no processo e depende diretamente do processo de desenvolvimento, uma base de testes pode incluir por exemplo uma lista de requisitos, diagramas, e artefatos de software que ajudam a descrever as funcionalidades.
Após definida a base de testes deve ser avaliado quais produtos de trabalho de teste serão elaborados, como por exemplo: plano de testes, plano de aceitação, casos de testes,scripts de teste, roteiro de teste, relatório de teste.
De acordo com (ISO/IEC/IEEE29119, 2013) existe um processo genérico de teste de soft- ware que pode ser aplicado a qualquer modelo de ciclo de vida em qualquer organização, e o processo proposto se baseia nas diretrizes do modelo genérico, nas diretrizes de (ISTQB, 2018), conforme figura 1.
Figura 1: Detalhamento do modelo. Fonte: (ISO/IEC/IEEE29119, 2013)
2quaisquer produtos de trabalho que podem ser utilizados como base de informações para os testes, exemplo: Processo de negócio, requisitos de usuário ou de negócio, casos de uso, documentação do sistema, procedimentos de instalação, metas de desempenho, normas o regulamentos de segurança. Em resumo qualquer produto de trabalho que possa dar informação para que os testes sejam viabilizados e que facilitem o entendimento do que foi requisitado
Como podemos observar na figura 1 o processo de testes dividi-se em: Processo de teste organizacional, conforme (LERCHE-JENSEN, 2019) o processo de teste organizacional diz respeito ao desenvolvimento, monitoramento, manutenção organizacional das especi- ficações de teste, como políticas de testes, estratégias de teste, ou seja o nível estratégico dos testes.
No que se refere ao nível estratégico do processo de testes, o processo proposto pro- duziu um guia (TESTES, 2019), o mesmo define as diretrizes e fornece orientações sobre o que foi definido a nível organizacional alinhados com os demais processos estratégicos da diretoria. Inclusive a elaboração e manutenção de templates que deem suporte ao ní- vel gerencial, está ligado ao nível estratégico. Neste caso o guia servirá de base para o planejamento dos testes e orientação para testadores e desenvolvedores
No nível gerencial, diz respeito a criação do plano de testes, dentro desta fase está o planejamento de teste, gestão, controle e monitoramento do processo, e a conclusão dos testes.
Na fase de gerencimento é desenvolvido um plano de testes, pelo analista de teste e líder de projeto, ambas atribuições foram descritas no (TCE-RN, 2019), onde são feitas as análises mínimas para a execução do projeto. Como mostra a figura 2 retirada do (TCE- RN, 2019) a sprint de validação "Preparar testes de aceitação", incluem as atividades de planejamento e análise do que poderá ser feito. De acordo com o PRODEV, (TCE-RN, 2019)
Procedimentos:
• Identificar os tipos de testes a serem executados na sprint (manuais, au- tomatizados, guiados por ferramentas);
• Elaborar os casos de teste dos itens desenvolvidos na sprint e, caso ne- cessário, elaborar mais de um caso de teste para o mesmo caso de uso;
• Definir a forma de execução (serial ou paralela) e identificar os cenários possíveis para o caso de uso e seus exemplos assim como os comporta- mentos esperados para cada tipo de entrada;
• Elaborar as features de testes, dentro do caso de teste, com os respectivos exemplos de execução.
Dentro dos procedimentos acima descritos existe um conjunto de atividades associa- das, como:
22
Identificar os tipos de testes a serem executados na sprint, envolve as seguintes etapas:
1. Planejar o trabalho de teste: Verificar documentação disponível, analisar quais são os possíveis testes dentro do que foi entregue, manuais ou automatizados, mensurar o tempo necessário para as etapas posteriores;
2. Análise: definir as estratégias e objetivos de testes, dentro dos objetivos da sprint entregue, APIs e fluxos de sistema;
3. Modelar: casos de testes, criar tabelas de decisão utilizando métodos como: valor limite3 e classes de equivalência4
Além do procedimento acima descrito existe na etapa de gerenciamento, conforme modelo proposto por (ISO/IEC/IEEE29119, 2013), existe o controle e monitoramento das tarefas, o mesmo é feito via ferramentas como: GitLab5, onde é genrenciado o conjunto detestwares desenvolvidos durante o processo; o Redmine 6 para gerenciamento das ati- vidades como descrito em Apêndice A, os principais testwares que utilizamos foram:
Figura 2: Detalhamento do modelo.Fonte: (TCE-RN, 2019)
• Plano de testes, que pode ser visto em: Apêndice B
• Caso de Testes, que pode ser visto em: Apêndice C
• Sprint de Validação, que pode ser visto em: Apêndice F
3Análise do valor limite é uma técnica de teste de software utilizada para verificar os limites do domínio de entrada, complementar a classes de equivalência
4Em testes de software, consiste em um método que particiona o conjunto de entradas e saídas em número finito, este método é complementar ao de valor limite e é utilizado para escolher os candidatos de elementos a serem testados
5GitLab é uma ferramenta web-based DevOps lifecycle que prover um gerenciamento de repositório git, foi a ferramenta adotada pela gerencia de configuração da DIN-TCE-RN
6Como informado em (LANG, 2019) este é uma ferramenta de gerenciamento online de projetos
• Relatório de Testes como: Apêndice D e Apêndice E
Os documentos acima descritos foram desenvolvidos ao longo do presente projeto, sendo estes de fundamental importância para a construção e implantação do processo aqui proposto, no próximo capitulo serão abordadas as experiências, andamentos da aplicaçao do processo proposto.
24
3 Projetos piloto
Agora que o processo foi descrito, seus principais artefatos foram elaborados, deve-se verificar e aplicação do processo dentro do contexto proposto. Para isso foi montado um plano de ação, incluindo projetos e sistemas legados. A estratégia montada para preparar a equipe envolvia:
1. Leitura do Guia (Apêndice A)
2. Leitura e entendimento dos Relatórios descritos em: Apêndices D, E, F 3. Leitura e entendimento dos demais testwares como: Apêndices B, C 4. Estudar sobre Git e principais comandos
5. Entender o que é o Gherkin1, 6. Curso de Katalon Studio 2
Ao longo dos quatro meses de implantação do processo, foi determinado o período de treinamento seria de 100 horas. Incluindo os estudos necessários e a elaboração de testes usando a prinicpal ferramenta de testes o Katalon Studio3. Estes testes de treinamento englobariam sistemas já em uso, os sistemas legados, para não impactar nos sistemas em desenvolvimento, e ao mesmo tempo, podendo adicionar aos sistemas legados algum tipo de teste, o escopo para cada sistema legado foi avaliado e os mesmos eram priorizados pela diretoria e alinhados com os projetos vigentes. As APIs foram em particular o objeto de teste de maior foco, haja vista que o consumo de microserviços e a arquitetura consolidada dos novos sistemas dependeriam de APIs que estivessem em pleno funcionamento.
Esses testes iniciais foram importantes para consolidar o conhecimento sobre as ferra- mentas, e aproveitando, levantando alguns pontos de sistemas em uso Por isso o primeiro
1Linguagem ubígua que utiliza um conjunto de palavras reservadas que fornecem uma estrutura que resulta em uma especificação executável.
2https://www.udemy.com/katalon-studio-step-by-step-for-beginners
3https://www.katalon.com/
passo era para cada novo membro da equipe uma API dentro da lista de APIs, ver figura 3.
Figura 3: Lista de APIs dentro do repositório GitLab
Então a primeira rodada de testes iniciais foram feitos em cima de APIs, dentro do contexto de legados.
Após o domínio inicial das ferramentas, templates e demais guias adotados, a atuação de projetos deu-se início em dois projetos com os projetos Comunicação Eletrônica 2.0 e Siai DP, com a primeira equipe de testes formada pelos testadores Carlos Eduardo e Jeckson Victor, além da Analista Rebecca Betwel, autora da presente proposta.
Então aos poucos os ambientes foram sendo preparados conforme a gerencia de confi- guração definiu, como o processo era novo e todos estavam integrando o processo estavam se adaptando ao novo modo de desenvolvimento e processos, foi necessário um conjunto de reuniões entre equipe de Teste, gerente de configuração na figura do servidor Analista de Controle Externo Marco Olimpio. Outro ponto importante a levantar foi o conjunto de metas da Diretoria, Vinícius Toscano, que deu suporte para criação de uma equipe de Qualidade e Testes e formação de profissionais para atender as demandas da diretoria.
Os primeiros relatórios entregues aos respectivos líderes dos projetos citados acima, algumas coisas como: melhorias dos relatórios e alterações pontuais nas descrições de alguns tipos de bugs.
26
4 Considerações finais
O presente projeto foi uma iniciativa que partiu da nova gestão da diretoria, dando início a um novo ciclo de desenvolvimento com foco em entrega com qualidade, cuidado ao que está sendo entregue através de um processo definido e um conjunto de ações para atingir o objetivo de qualidade.
O presente projeto teve mudança de escopo ao longo da sua execução, pois inicialmente seria apenas a elaboração de templates de artefatos de testes,testwares para integrar ao processo de desenvolvimento. Com a mudança de gestão o escopo do projeto se extendeu e foi criado um processo de testes relacionado, com equipe de testadores e o papel de analista de qualidade e testes foi estabelecido.
O projeto teve seu maior impacto na diretoria de informática e na melhoria dos processos internos, pois pela primeira vez, os processos estão definidos e sendo executados, isso incluindo processo de desenvolvimento e processo de testes integrado.
4.1 Trabalhos futuros
Um dos pontos interessantes de uma nova abordagem é melhorar a anterior, porém a presente proposta não tinha referencias antigas, logo um dos principais objetivos em trabalhos futuros relacionados é melhoria do processo, fazendo ajustes necessários com o tempo.
Melhoria dos testwares entregues, principalmente o plano de testes que foi o primeiro documento elaborado pelo projeto atual.
Criar novos guias das ferramentas escolhidas pela equipe e criar semanas de treina- mento.
Referências
BLANCO, M. Z. Documentação de teste baseado na Norma IEEE 829 - estudo de caso: Sistema de apoio a tomada de decisão. 2012. Disponível em:
<revistatis.dc.ufscar.br/index.php/revista/article/download/18/22>. Acesso em: 19 dez.
2018.
FUNPAR, F. D. U. F. D. P.Artefato: Plano de aceitação do produto. março 2001.
Disponível em: <http://www.funpar.ufpr.br:8080/rup/process/artifact/ar_acpl.htm>.
Acesso em: 23 set. 2018.
FUNPAR, F. D. U. F. D. P. Artefato Plano de testes. 2001. Disponível em:
<http://www.funpar.ufpr.br:8080/rup/process/artifact/ar_tstpl.htm>. Acesso em: 23 set. 2018.
FUNPAR, F. D. U. F. D. P. Conceitos: Estágio de Teste. 2001. Disponível em:
<http://www.funpar.ufpr.br:8080/rup/process/workflow/test/co_stage.htm>. Acesso em: 31 ago. 2018.
HUMBLE, J.; FARLEY, D. Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Addison-Wesley, 2010. (A Martin Fowler Signature Book). ISBN 9780321601919. Disponível em: <Disponível em:
<https://books.google.com.br/books?id=9CAxmQEACAAJ>>.
IEEE, C. S. IEEE Standard Glossary of Software Engineering Terminology.
IEEE, 1990. (IEEE Std). ISBN 9781559370677. Disponível em: <Disponível em:
<https://books.google.com.br/books?id=qGR_PgAACAAJ>>.
(ISO), I. O. for S. ISO/IEC 25000:2005, Software Engineering - Software Product Quality Requirements and Evaluation (SQuaRE). 2005.
ISO/IEC/IEEE29119, I. S. f. S. T. ISO/IEC/IEEE29119: 2013(E): Software and Systems Engineering Software Testing Part 2:Test Processes. [s.n.], 2013. Disponível em:
<http://www.softwaretestingstandard.org/part2.php>.
ISTQB, I. S. T. Q. B. Certified Tester: Foundation Level Syllabus. 2018. Disponível em: <https://www.bstqb.org.br/uploads/syllabus/syllabus_ctfl_2018br.pdf>.
Acesso em Junho 01, 2019.
LANG, J.-P.Redmine. jul. 2019. Julho., 2019. Disponível em: <https://www.redmine.
org/>. Acesso em Julho, 17, 2019.
LERCHE-JENSEN, S. Test Process Advanced (ITPA). maio 2019. Abril., 2019.
Disponível em: <https://www.scrum.as/academy.php?show=3&chapter=2>. Acesso em Julho, 17, 2019.
28
PRESSMAN, R.; MAXIM, B.Engenharia de Software. 8. ed. [S.l.]: Editora Bookman, 2016. ISBN 9788580555349.
SOMMERVILLE, I. Engenharia de software. Pearson Bra- sil, 2011. ISBN 9788579361081. Disponível em: <Disponível em:
<https://books.google.com.br/books?id=H4u5ygAACAAJ>>.
SOUZA, K. P.; GASPAROTTO, A. M. S. A importância da atividade de teste no desenvolvimento de software. In:XXXIII ENEGEP - Encontro Nacional de Engenharia de Produção. (DISC, Salvador, Brasil, Outubro 2013). [S.l.]: ABEPRO, 2013.
STELLMAN, A.; GREENE, J. USE A CABEÇA! PMP. [S.l.]: Rio de Janeiro: Alta Books, 2011.
TCE-RN. Modelo de processo de gestão e desenvolvimento de software do TCE/RN:
Guia de Referência v.1.0. jul. 2019. Julho., 2019. Disponível em: <http://www.tce.rn.
gov.br/docs/prodev_tce-rn_v1.0.pdf>. Acesso em Julho, 17, 2019.
TESTES, G. de.Guia de boas práticas para Softwares Testáveis. jul. 2019. Abril., 2019.
Disponível em: <https://www.scrum.as/academy.php?show=3&chapter=2>. Acesso em Julho, 17, 2019.
APÊNDICE A -- Guia de Testes
PROTESTE - Guia de Testes
Guia para testadores e desenvolvedores, conjunto de diretrizes gerais sobre conceitos e estratégias a
serem utilizadas pelas equipes da DIN
Versão 1.0
Natal 2019
30
Guia de Teste 2
Sumário
1. Introdução ... 5 1.1 Escopo ... 5 2. Diferença entre teste e qualidade ... 5 3. O que é teste de software ... 8 3.1 Objetivos de testes ... 8 3.2 Erros, defeitos e falhas ... 10 4. O que é um software testável ... 10 4.1 Princípios de testes ... 12 4.2 - Padronização de códigos ... 13 4.2.1 - Padronização de identificadores em código ... 13 5. O que é teste unitário ... 14 5.1 - Base de testes ... 14 5.2 - Objetos de teste ... 14 5.3 - Defeitos típicos e falhas ... 15 6. O que é teste de integração ... 15 6.1 - Base de testes de integração ... 16 6.2 - Objetos de testes de integração... 16 6.3 - Defeitos típicos e falhas ... 16 7. O que é teste de sistema ... 17 7.1 - Base de testes ... 17 7.2 - Objetos de testes ... 17 8. O que é teste de Aceitação ... 18 8.1 - Objetivos da fase de testes de aceite ... 19 8.1.1 - Teste de Aceite do Usuário (UAT) ... 19 8.1.2 - Teste de aceite contratual e regulatório ... 20 8.2 - Os objetos a serem testados na fase de aceite são: ... 20 8.3 - Abordagens a serem adotadas para testes de aceitação no processo DIN DEV ... 20 9. Processo de Testes ... 21 9.1 - Fase de planejamento ... 24
31
Guia de Teste 3 DIRETORIA DE INFORMÁTICA - DIN
9.2 - Análise do teste ... 25 9.3 – Modelagem do teste... 26 9.4 – implementação do teste ... 26 9.5 – Execução do teste ... 27 9.6 – Conclusão do teste ... 27 9.7 – Correção e monitoramento de testes ... 27
32
Guia de Teste 4
Histórico de revisões
Data Versão Descrição Autor
02/08/2019 1.0 Elaboração do guia Rebecca
Betwel
33
Guia de Teste 5 DIRETORIA DE INFORMÁTICA - DIN
1. Introdução
O Tribunal de Contas do Estado do Rio Grande do Norte, através da sua Diretoria de Informática, criou um conjunto de guias e processos de software para alinhar e nortear todo desenvolvimento de sistemas que estão em seu catálogo de serviços e sistemas oferecidos para a comunidade interna e externa ao TCE-RN, por este motivo o presente guia é uma das partes integrantes de todo o processo de desenvolvimento com o foco nas áreas de testes e qualidade de software.
O presente guia faz parte do conjunto de documentos produzidos para dar suporte aos processos de desenvolvimento e testes da DIN-TCE-RN. O qual tem como objetivo geral nivelar os conceitos básicos sobre testes e qualidade, fornecer as orientações sobre as estratégias de testes adotados pelo processo de testes da DIN e fornecer orientações básicas para os desenvolvedores realizarem os seus testes unitários e que tenham em mente o desenvolvimento de softwares testáveis, sempre pensando na viabilidade dos testes utilizando princípios básicos de boas práticas de programação.
1.1 Escopo
Considerando as boas práticas pregadas em autores como SOMMERVILLE, PRESSMAN, WHITTAKER (How Google Tests Softwares) e outros autores, este guia é uma visão geral do processo de testes, desde escolha de estratégias aplicáveis ao relatórios de testes, banco de bugs e coleta de informações a partir dos testes e de como aplicá-los dentro do processo de desenvolvimento de software da DIN-TCE-RN, sendo o mesmo um guia essencial para qualquer membro da equipe de testes e qualidade de software, e uma referência para as equipes de projeto, desenvolvimento, sustentação e operação dentro da DIN-TCE-RN, serão abordados os seguintes assuntos: Testes, Qualidade, Processos de testes, tipos de testes, categorias de testes, fases de testes.
2. Diferença entre teste e qualidade
Uma dúvida constante é a definição entre teste e qualidade, pois existem diferenças entre essas duas definições. Em um processo de desenvolvimento de software assim como qualquer processo de desenvolvimento de produtos, investe-se muito no processo de desenvolvimento e o resultado pode não sair como esperado, como apresentado na figura 1, não há teste para avaliar como todo a especificidade de um produto, sempre existirá a necessidade de avaliação da qualidade e, como afirma WHITAKER (2012), qualidade é uma responsabilidade de todos no processo: desenvolvedores, gerentes, arquitetos e testadores. A qualidade vai além dos testes e teste é parte integrante do processo de construção, não deve ser feito apenas para garantir qualidade ao final. Os testes são aliados da qualidade, porém os aspectos de qualidade ultrapassam o escopo de testes e levam em consideração questões de subjetividade e entendimento de necessidades dos usuários finais e desejos de clientes, porém um com ponto forte para qualquer software é
34
Guia de Teste 6 o processo de verificação e validação dos requisitos assim como tratamentos de erros e falhas de sistema de forma aceitável para o cliente.
Figura 1 - COELHO(2018)
Outra questão é avaliar apenas no final do processo, pode gerar alto custo para correção ou melhorias ou ajustes que deveriam ter sido feitos em fases anteriores, então avaliar e verificar a qualidade durante todo o processo diminui as chances do produto final sair diferente do esperado, alinhando a expectativa à realidade, requisitos ao produto final.
Expectativa Realidade
Figura 2 – Desejado pelo cliente Figura 3 – entrega ao cliente
O processo de testes e avaliação de qualidade nas metodologias mais antigas e até mesmo no modo de trabalho de muitas empresas, inclusive atuais, se dava apenas ao
35
Guia de Teste 7 DIRETORIA DE INFORMÁTICA - DIN
final de uma release ou na entrega de produto, funcionava como uma “última barreira”, apenas verificado na etapa final, Figura 4.
Figura 4 - COELHO (2018). Modelo tradicional.
Outra importância para o processo de teste e qualidade ser uma responsabilidade de todos é que uma vez os testes dos desenvolvedores terem sucesso, a equipe de qualidade e testes pode partir para testes mais rigorosos.
Figura 5 - Teste de impacto em acidentes frontais, certificado por instituição credenciada de qualidade e testes automobilísticos.
Logo a equipe de qualidade e testes deverá ter seu escopo voltado aos testes de aceitação do produto final. Conforme Sommerville (2011), Figura 6 propõe uma abordagem de testes iniciando na fase de especificação de requisitos e em paralelo ao processo de desenvolvimento.
36
Guia de Teste 8
Figura 6 - Sommerville (2011), adaptado pelo autor do presente guia.
A proposta apresentada por Sommerville pode ser adaptada aos processos ágeis e as necessidades de diversas organizações e metodologias de desenvolvimento.
Definindo os escopos de atuação dos testes pelas equipes de desenvolvimento e de teste, temos um conjunto de responsabilidades por parte de cada uma das equipes dentro do ciclo de vida do software.
3. O que é teste de software
Agora que a diferença entre Qualidade e Teste está estabelecida com seus conceitos mais claros, torna-se necessário descrever melhor o que é teste de software e seus objetivos.
É comum o pensamento que testes são apenas a execução de testes, ou seja, executar o software e verificar resultados, conforme afirma ISTQB (2018, p.13) no seu guia padrão para profissionais de testes de software:
Um equívoco comum do teste é que ele consiste apenas em executar testes, ou seja, executar o software e verificar os resultados. Conforme descrito na seção 1.4, o teste de software é um processo que inclui muitas atividades diferentes, e a execução do teste (incluindo a verificação dos resultados) é apenas uma dessas atividades. O processo de teste também inclui atividades como planejamento de teste, análise, modelagem e implementação do testes, relatórios de progresso e resultados de testes e avaliação da qualidade de um objeto de teste.
Outro ponto importante é que testes não se concentra inteiramente na verificação de requisitos, estórias de usuários ou outras especificações. Testes também englobam verificação código-fonte, revisão de produto de trabalho, documentação e requisitos de sistemas.
3.1 Objetivos de testes
Os objetivos do teste incluem:
Avaliar os produtos de trabalho, como requisitos, estórias de usuários, modelagem e código.
37
Guia de Teste 9 DIRETORIA DE INFORMÁTICA - DIN
Verificar se todos os requisitos especificados foram atendidos.
Validar se o objeto de teste está completo e funciona como os usuários e outras partes interessadas esperam.
Evitar defeitos.
Encontrar falhas e defeitos.
Fornecer informações suficientes às partes interessadas para permitir que elas tomem decisões, especialmente em relação ao nível de qualidade do objeto de teste.
Reduzir o nível de risco de qualidade de software inadequada (p.e., falhas não detectadas anteriormente que ocorrem em produção).
Cumprir com requisitos ou normas legais ou regulamentares, e/ou verificar o cumprimento do objeto de teste com tais requisitos e normas.
Testes unitários, verificar se cada função ou componente está funcionando como esperado.
Testes de integração, verificar se a integração das funcionalidades está funcionando como esperado.
Testes de Aceite, para aferir se o que foi especificado foi entregue.
No geral podem-se organizar os testes por: modo de execução (manual ou automatizado), método (caixa preta, caixa branca ou caixa cinza), estágio (unitário, integração, sistema e aceitação) e categoria (ver tabela 1).
Nos próximos tópicos serão abordados outros aspectos de testes, porém temos diversos tipos de testes possíveis e diversas formas de executá-los, alguns desses testes podem ser executados de uma mesma maneira com mais de um objetivos, modos de execução e com outras características como testes estáticos e testes dinâmicos, a seguir uma tabela 1 com alguns dos tipos de testes mais conhecidos por categorias.
Teste Descrição
Teste de Estresse Avalia o desempenho do sistema com o volume de acesso/transações acima da média esperada e em condições extremas de uso.
Teste de Performance ou Desempenho
Avalia se o sistema atende os requisitos de performance(proficiência) com o volume de acesso/transações dentro do esperado. Verifica se o tempo de resposta da aplicação está conforme esperado
Teste de Contenção Avalia se o sistema retorna a um status operacional após uma falha
Teste de Segurança Avalia o nível de segurança do sistema quanto a perfis de acesso, permissões de uso e tags html nos campos, inclusive SQL Injections
Teste de Regressão Avalia se funcionalidade que estava funcionando ainda funciona após uma modificação no sistema. Todo sistema é novamente verificado neste teste. Exemplo: um conjunto de testes unitários
Teste de Funcionalidade Avalia se o sistema funciona conforme descrito nos requisitos
Teste de Usabilidade Verifica se a navegabilidade, objetivos e padrões de tela estão conforme especificado e se atendem da melhor forma ao usuário
Teste de Volume Avalia o comportamento do sistema com grande quantidade de dados
Teste de Acessibilidade Avalia se a aplicação está navegável para um usuário com algum tipo de deficiência visual Testes de Estrutura Avalia se a codificação foi feita corretamente e se todos os métodos são utilizados
Teste de Carga Avalia o funcionamento da aplicação com a utilização de uma grande Teste de Instalação Testar se a instalação da aplicação obteve sucesso
38
Guia de Teste 10
Teste de configuração Avalia se a aplicação funciona corretamente em ambientes diferentes de hardware ou software
Tabela 1: Categorias de testes
A criação de teste deve ser feita com planejamento adequado, escolhendo as melhores estratégias de aplicação de testes nos softwares sempre avaliando os estágios de desenvolvimento, tipos de tecnologias, e outros fatores que influenciam no processo de testes.
Como benefícios dos testes ao custo de desenvolvimento podemos citar que:
identificação de falhas e erros no início do desenvolvimento diminui o impacto do mesmo no projeto; ter testadores trabalhando em conjunto com equipe projetos pode aumentar o entendimento dos requisitos e como cada parte pode ser projetada; aumento de entendimento e colaboração entre testadores e desenvolvedores diminuem riscos de defeitos no código e nos testes; validar e verificar os softwares antes de liberar para uso do usuário aumenta a probabilidade de atendimento das necessidades das partes interessadas e satisfação em relação aos requisitos e expectativas do produto.
3.2 Erros, defeitos e falhas
Erro é uma consequência de uma ação inesperada, é inserido no software por ação externa (humana, atualização de ambientes, navegadores ou qualquer fator externo), por diversos motivos, incluindo má especificação de casos de uso, documentação fraca, desatenção do programador, falta de clareza pelo engenheiro de software na hora de especificar, inexperiência do programador entre outros motivos possíveis. Esses erros podem ocorrer em diversas fases do processo de desenvolvimento, erros podem ser inseridos no momento da especificação, no momento da modelagem e projeto de software assim como na codificação. O erro cria um defeito, que é o resultado de um erro inserido no código que pode gerar uma anomalia de funcionamento, um erro pode produzir mais de um defeito. A falha é a execução do defeito, e a execução do mesmo defeito pode gerar diversas falhas.
Em resumo podemos dizer que:
Erro: é introduzido no software por ação externa e produz um resultado incorreto.
Defeito: é o resultado da inserção do erro no código que gera uma anomalia de funcionamento, um erro pode criar mais de um defeito, dependendo do impacto e propagação do erro dentro de um código.
Falha: é o resultado da execução de um defeito, um defeito podem gerar diversas falhas.
4. O que é um software testável
Segundo (ZADROSNY,2006) e (PRESSMAN,2002), as seguintes características levam a um software testável e devem ser levadas em conta quando ele é construído:
39
Guia de Teste 11 DIRETORIA DE INFORMÁTICA - DIN
Operabilidade: o software deve ser projetado e implementado com qualidade.
"Quanto melhor funciona, mais eficientemente pode ser usado e testado".
Observabilidade: variáveis devem ser visíveis ou consultáveis durante a execução. "O que você vê é o que você testa."
Controlabilidade: variáveis devem poder ser controladas diretamente pelo engenheiro de teste. "Quanto mais você pode controlar o software, mais o teste pode ser automatizado e otimizado".
Decomponibilidade: módulos independentes podem ser testados independentemente. "Controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagem mais racionalmente".
Simplicidade: o conjunto de características deve ser o mínimo necessário para atender os requisitos. "Quanto menos há a testar, mais rapidamente podemos testá-lo".
Estabilidade: o software se recupera bem de falhas. "Quanto menos modificações, menos interrupções no teste".
Compreensibilidade: a documentação técnica é acessível instantaneamente, bem organizada, específica, detalhada e precisa."Quanto mais documentação temos, mais racionalmente vamos testar".
É importante mencionar que softwares são testáveis, porém quando se cria software pensando em como será testado o processo de testes se torna menos custoso, o desenvolvedor consegue mitigar erros em tempo de desenvolvimento, haja vista que o desenvolvedor preocupa-se com o que está sendo feito pois será avaliado por outra equipe. Com isso a probabilidade dos riscos de defeitos e falhas diminui.
Pelas razões já mencionadas acima os testes devem ocorrer desde o começo do projeto.
A testabilidade pode ser incorporada nos vários estágios do desenvolvimento de software como:
Fase de especificação: Durante o processo de revisão especificação, a equipe de testes deve ser questionada quanto ao seu entendimento aos requisitos, afinal elaborar testes sobre um conjunto de requisitos não claros, ou, que existam dúvidas sobre sua execução é uma tarefa complicada e algumas vezes impossível dependendo do escopo do projeto.
Fase de detalhamento do projeto: os testes nessa fase estabelecem com clareza os conjuntos de entradas e saídas esperadas, facilitando a montagem de cenários de testes pela equipe de testes, e para a equipe de desenvolvimento esclarecer o que deve ser tratado.
Fase de codificação: nesta fase, a responsabilidade dos testes é da equipe de desenvolvimento, cabendo aos desenvolvedores criar os testes unitários e integração das funcionalidades geradas. Esta fase é essencial, é onde essencialmente os erros são inseridos no código.
40
Guia de Teste 12 Fase de testes: Nesta fase os critérios de aceite, requisitos funcionais e não funcionais serão validados e verificados pela equipe de teste. Onde serão verificados os testes criados nas fases anteriores (controle e garantia) e validação dos critérios de aceitação com base em scripts de testes e planos de testes pertinentes desta fase.
Criar softwares testáveis é responsabilidade de TODOS, garantir a qualidade do produto que está sendo entregue também é responsabilidade de TODOS.
Para facilitar a criação de softwares testáveis, precisamos definir alguns padrões para desenvolvimento dentro da DIN-TCE-RN.
Em cada uma das seções posteriores sobre os estágios de testes são mencionados critérios mínimos para aplicação de testes. A definição de software testável e os aspectos que serão considerados como objetos de testes conforme padronização do processo de desenvolvimento DINDEV [TODO - link com o projeto DINDEV desenvolvido pelo servidor André Gustavo].
4.1 Princípios de testes
De acordo com ISTQB (2018) existem alguns princípios que devem ser levados em consideração, quando se testa. São eles:
Testes mostram a presença de defeitos, não a sua ausência
O teste reduz a probabilidade de defeitos não descobertos permanecerem no software, mas, mesmo se nenhum defeito for encontrado, o teste não é a prova de correção. Isso quer dizer, que teste não consegue abranger todas as possibilidades, e que não podem garantir ausência de falhas, porém podem e irão mostrar defeitos e falhas.
Testes exaustivos são impossíveis
Testar tudo, todas as combinações possíveis de entrada e todas as pré- condições não é viável, exceto em casos triviais. Ao invés disso utilizar-se de técnicas de teste e priorização é recomendado para otimizar o custo de realização de testes.
O teste inicial economiza tempo e dinheiro
Antecipar defeitos de especificação de requisitos diminuem seu custo e impacto na aplicação, utilizam-se normalmente técnicas, recomenda-se a leitura do tópico 3.1 do ISTQB (2018), sobre testes estáticos.
Defeitos se agrupam
Um pequeno número de módulos geralmente contém a maioria dos defeitos descobertos durante o teste de pré-lançamento ou é responsável pela maioria das falhas operacionais. Observar quais os módulos é os potenciais
41
Guia de Teste 13 DIRETORIA DE INFORMÁTICA - DIN
agrupadores de erros é essencial para otimizar os esforços em desenvolvimento dos testes.
Cuidado com o paradoxo do pesticida
Testes repetitivos não mostrarão novos defeitos, para detectá-los é necessária a constante atualização dos testes em conformidade aos requisitos e expectativas alterados. Alguns casos esse efeito é benéfico, como os casos dos testes de regressão, onde o número de defeitos é relativamente baixo e auxiliam na detecção dos testes que precisam ser atualizados, falhas que surgiram com as modificações de requisitos e implementações que impactaram no sistema entre outros.
O teste depende do contexto
Os testes devem ser planejados de acordo com o contexto em que estão incluídos, testes em dispositivos mobiles com metodologia ágil é testado de forma diferente do teste em um ambiente desktop em um projeto de ciclo de vida sequencial.
Ausência de erros é uma ilusão
Existe uma expectativa errada sobre a equipe de testes, como mencionado anteriormente, testes afirmam a existência de falhas, porém NÃO GARANTEM a falta de falhas ou defeitos. Esperar que a equipe de testes valide todas as condições é impossível pois Testes exaustivos são impossíveis, logo mesmo que se teste, e crie-se toda uma suíte de testes, ainda é possível que o resultado final não atenda as expectativas do cliente.
Teste é responsabilidade de todos
Este princípio é uma das premissas para que a qualidade seja alcançável é necessário que todos estejam envolvidos no processo. Lembrando que a qualidade é o que se deseja em relação ao que se é entregue, e teste é uma ferramenta de aferição da qualidade.
4.2 - Padronização de códigos
Com base nos conceitos anteriores, é necessário criar um mecanismo que viabilizem criação dos testes, em testes automatizados é essencial à criação de padrões para que se viabilize a elaboração dos mesmos, e viabilização dessa abordagem.
4.2.1 - Padronização de identificadores em código
Os identificadores seguirão o padrão já estabelecido pela equipe de Banco de Dados para facilitar a adoção do mesmo nos processos de desenvolvimento, e por ser um padrão já conhecido e difundido por todos.
A padronização utiliza de estrutura :
[TIPO]_[API]_<NomeDoElemento>_[Numeracao]
42
Guia de Teste 14 Onde:
[TIPO] : é o tipo de elemento, exemplo: Input_CommonApi_Beneficiario [API]: é inserido caso o elemento venha de alguma biblioteca ou api externa.
<NomeElemento>: é o nome do elemento, se o label é Nome do Agente, o id deve ser NomeAgente
[Numeracao]: Opcional, quando for uma variável de uma lista, ou array.
E é importante que os desenvolvedores tenham em mente que seus códigos são objetos de teste, e com essa linha sempre avaliar se o código produzido segue as boas práticas e as recomendações descritas neste guia e em demais guias utilizados como padrão por esta diretoria.
5. O que é teste unitário
Testes unitários são testes que avaliam a função atômica, ou seja, a menor parte do software que está sendo testada pode ser uma função ou de um componente. Os objetivos deste tipo de teste incluem:
Reduzir riscos;
Verificar os comportamentos funcionais e não funcional do componente ao projetado e especificado;
Construir a confiança na qualidade do componente;
Encontrar defeitos no componente;
Evitar que os defeitos espalhem para níveis mais altos de teste.
Em processos como o utilizado na DIN DEV automatizar testes de componentes é essencial para viabilizar os testes de regressão dos componentes já criados, pois cria confiança de que as alterações não impactaram os componentes já existentes.
5.1 - Base de testes
Produto que podem ser utilizados como base de teste para testes de componentes, inclui:
Projeto detalhado
Código;
Modelo de Dados
Especificação de componentes;
5.2 - Objetos de teste
Os objetos de testes típicos para componentes, unitários incluem:
43
Guia de Teste 15 DIRETORIA DE INFORMÁTICA - DIN
Componentes, unidades ou módulos;
Estruturas de códigos e dados
Classes
Módulos de banco de dados
5.3 - Defeitos típicos e falhas
Exemplos de defeitos e falhas típicas para esta fase de testes:
Funcionalidade incorreta (não funcionam como está definido na documentação);
Problemas no fluxo de dados
Código e lógica incorretos
Os defeitos geralmente são corrigidos assim que são encontrados, geralmente sem gerenciamento formal dos defeitos. Haja vista que os testes de componentes em sua essência devem ser criados e executados pelos próprios desenvolvedores, e os mesmos sendo automatizados farão parte do conjunto de testes que irão compor os testes de aceite do produto.
6. O que é teste de integração
O teste de integração se concentra nas interações entre componentes ou sistemas. No contexto do desenvolvimento da DIN-TCE-RN essas interações têm foco em micro serviços disponível pelas APIs (Application Programming Interface). Logo testar as interações entre essas interfaces é essencial para o bom funcionamento como todo do ecossistema criado nesta arquitetura de sistemas.
No que se trata de testes de APIs o processo aqui apresentado utiliza algumas ferramentas e frameworks de testes, como xUnit, Katalon Studio e Postman. Sendo destas o Katalon Studio a ferramenta principal da equipe de testes para validação das APIs entregues pelas equipes de desenvolvimento. Para isso existe um guia próprio para testes de APIs e Testes com o Katalon Studio.
Os objetivos dos testes de integração podem incluir:
Reduzir riscos;
Verificar se os comportamentos funcionais e não funcionais das interfaces estão projetados e especificados;
Construir confiança na qualidade das interfaces;
Encontrar defeitos (que podem estar nas próprias interfaces ou nos componentes ou sistemas);
Evitar que os defeitos espalhem para níveis mais altos de testes.
Assim como nos testes de componentes, em alguns casos, o teste de regressão de integração automatizada garante que as alterações não interromperam as interfaces, os componentes ou sistemas existentes.
44
