PODER JUDICIÁRIO JUSTIÇA DO TRABALHO DA 4a REGIÃO

PROCESSO DE TESTE DESENVOLVIMENTO

DESENHO DO PROCESSO

DEFINIÇÕES

DESCRIÇÃO DAS FASES

DESENHO DO PROCESSO

DEFINIÇÕES

PAPÉIS

Desenvolvedor As mesmas atribuições do Processo de Desenvolvimento mais as que seguem: Responsável pela documentação das Estórias de Usuário e detalhamento das mesmas em Cenários de Teste a partir dos requisitos levantados com o Gestor do Produto. Executor dos Cenários de Teste, abertura de defeitos encontrados e geração do Relatório de Teste. Sugere-se que o membro da equipe com a atribuição de testador NÃO seja o mesmo que escreveu as Estórias de Usuário/Cenários de Teste. O membro da equipe que realizar os testes NÃO DEVE ser o mesmo que desenvolveu/implementou/codificou os requisitos documentados nas Estórias de Usuário. Para incentivar a integração entre as equipes de desenvolvimento, seria interessante que o Testador pudesse ser um membro de equipe diferente do responsável pelo desenvolvimento.

Gestor do Produto

Responsável pela centralização dos requisitos do projeto, priorização do backlog, aceite da(s) entrega(s), validação das Estórias de Usuários/Cenários de Teste e homologação do sistema/demanda.

DOCUMENTOS

Estória de Usuário Modelo para registro de requisito na forma de estória de usuário. O modelo definido no Processo de Desenvolvimento de Software do TRT4 é o seguinte: ID: <id> TÍTULO: <título da estória> AUTOR: <autor da estória> COMO: <papel> EU QUERO: <fazer alguma coisa> PARA: <objetivo> OBSERVAÇÕES: <observações gerais>

Cenário de Teste Detalhamento da Estória de Usuário em formato de cenários de teste executáveis por uma ferramenta de testes automatizados. Sugestão usar o BDD (Behavior Driven Development) e o padrão já definido pelo Demoiselle Behave (http://dbehave.com/). Exemplo de cenário de teste do Demoiselle Behave: Cenário: Acessar o sistema com usuário demoiselle e senha behave Dado que estou na página "Login" Quando informo "demoiselle" no campo "Usuário:" E informo "behave" no campo "Senha:" Quando clico em "Entrar" Então será exibido "Seja bem vindo" Exemplo de frases pré-definidas pelo framework para escrita de cenários de teste:

● [Dado que | Quando | Então] vou para a tela "<título da tela>"

● [Dado que | Quando | Então] estou na tela "<título da tela>"

● [Quando | Então] clico em "<nome do elemento>" referente a "<lista de parâmetros>"

● [Quando | Então] clico em "<texto do botão/link>" ● [Quando | Então] seleciono a opção "<texto da

opção>" ● [Quando | Então] seleciono a opção de índice

"<indice>" no campo "<nome do elemento>" ● [Quando | Então] seleciono a opção "<nome do

elemento>" referente a "<lista de parametros>" ● [Quando | Então] seleciono a opção de valor

"<valor>" no campo "<nome do elemento>" ● [Dado que | Quando | Então] informo "<valor>" no

campo "<nome do campo>" ● [Quando] limpo o valor do campo "<nome do

campo>" ● [Quando] não informo valor para o campo "<nome

do campo>" ● [Dado que | Quando] informo "<tabela de

exemplos>" ● [Quando] informo os campos "<tabela de

exemplos>" ● [Então] será exibido "<texto>" ● [Então] será exibido na "<nome do elemento>" o

valor "<valor>" ● [Então] será exibido o valor "<texto>" em "<nome

do elemento>" referente a "<lista de parâmetros>"

Plano de Teste Definições do que será coberto pelo teste (quais estórias de usuário e destas quais cenários de teste), do que não será coberto pelo teste, orientações gerais para o teste. No Testlink temos apenas um campo para o nome do Plano de Teste e um campo “rich text” de descrição. É desejável um modelo básico e nomenclatura padrão para esse artefato

Defeitos / Sugestão de Melhoria

Cenários de Teste que falharem deverão ter um ou mais defeitos abertos para correção. Ciclo de vida do defeito sugerido ao final deste documento.

Relatório de Teste Deve conter os detalhes da execução dos testes e defeitos encontrados. Usar o padrão da ferramenta adotada para gestão do testes.

Estimativa de Teste Orientação para estimar cada estória de usuário e cenários de teste. Planning Poker.

Métricas de Teste Ao final do projeto devem ser coletadas para medir a eficiência do teste realizado.

FERRAMENTAS UTILIZADAS

Testlink Gestão de teste (Estória/Cenário de Teste, Plano de Teste, Relatórios).

GIT

Ferramenta utilizada para armazenar e versionar os artefatos produzidos pelo processo de teste como projetos de automação por exemplo.

Assyst Gestão de defeitos. Caso seja escolhido o Testlink, o ideal seria que a ferramenta de gestão de defeitos tenha uma integração mínima com a ferramenta.

DESCRIÇÃO DAS FASES As fases abaixo descritas são as mesmas do documento do Processo Desenvolvimento Software V 2.0. Os textos destacados em AZUL são as considerações do Grupo de Testes para melhoria do processo levando em consideração as atividades relacionadas a prática de Teste de Software. Fase 1 - Definir Escopo do Produto

1. Levantar Necessidades Obter os requisitos necessários junto aos usuários indicados, incluindo o Gestor do Produto e identificar testes não funcionais (usabilidade, desempenho, disponibilidade, segurança, legal e outros).

2. Criar Backlog Registrar requisitos na forma de estórias de usuário. Equipe, após reuniões com Gestor do Produto para levantamento de requisitos, escreve-os no formato de Estórias de Usuário que serão detalhadas em Cenários de Teste na Fase 2 - Planejar Sprint.

3. Estimar Complexidade Estimar o esforço necessário para implementação de cada estória do backlog. A estimativa de complexidade inclui a escrita dos cenários baseados nas estórias adicionadas na etapa anterior. Esses cenários podem servir de base para a estimativa da complexidade. A estimativa deve incluir também o desenvolvimento dos testes unitários.

4. Levantar Requisitos Não Funcionais Identificar os requisitos ao desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas na implementação do produto. Detalhar a necessidade dos testes não funcionais.

5. Aprovar Backlog Estimado Obter aprovação do backlog junto ao Gestor do Produto. As estórias de usuário e os cenários de teste também são aprovados.

6. Atualizar Plano de Projeto

Revisar Plano de Projeto a fim de identificar mudanças necessárias em cronograma, escopo, riscos, arquitetura, requisitos de segurança, volume de usuários e dados para gestão de capacidade etc. Preencher o formulário “Registro de Mudanças”, pertencente ao processo de gerenciamento de projetos, para comunicar a mudança no projeto. Iniciar a elaboração do Plano de Teste e adicionar as atividades de teste no Cronograma. Fase 2 - Planejar Sprint

7. Selecionar Estórias de Usuário Selecionar e detalhar junto ao Gestor de Produto as estórias de usuário que serão implementadas na Sprint. As atividades de teste serão executadas em paralelo à seleção das Estórias de Usuário na tarefa “Projetar Testes”.

8. Projetar Testes O projeto de teste visa definir as condições necessárias para a realização dos testes em um contexto específico, identificando pontos de observação e de controle. Essas informações devem ser registradas nos cenários de testes. Sendo assim, nessa atividade são refinados e/ou incrementados os cenários de testes produzidos anteriormente, quando da análise dos requisitos. Além disso, também são projetados e elaborados os roteiros de testes automáticos a serem utilizados para o desenvolvimento de cada funcionalidade. Os cenários de testes devem obedecer o planejamento feito no plano de testes, já os roteiros de testes automáticos devem ser desenvolvidos de acordo com as especificações dos cenários. Para ambos os documentos, o desenvolvedor (atuando no papel de testador) deve estar preocupado em escrever tanto os fluxos normais de execução, quanto os fluxos de exceção, por mais improvável que possa parecer uma determinada situação.

9. Atualizar Cronograma de Projeto Revisar cronograma do projeto a partir das estórias de usuários selecionadas para a sprint que se inicia. As atividades de teste devem aparecer no cronograma como, por exemplo, a elaboração dos cenários de teste.

10.Registrar Atividades da Sprint Registrar as atividades necessárias para implementação das estórias de usuário, sendo no mínimo uma atividade para cada estória

Além das atividades de desenvolvimento as atividades de teste devem ser registradas. Nesse caso deve-se usar o Plano de Teste para incluir as Estórias de Usuário e os Cenários de Teste a serem testados na sprint. Fase 3 - Implementar Backlog da Sprint

11.Designar Responsável Designar responsável pela implementação de cada uma das atividades da Sprint, incluindo responsável por atualização/execução dos casos de teste.

12. Implementar Criar estrutura de dados, criar interfaces, codificar e testar (teste unitário) as funcionalidades que atendam às estórias selecionadas para a Sprint versionando os artefatos gerados. Registrar a conclusão da implementação. A implementação deve incluir os testes unitários. Erros nos testes unitários não precisam ser registrados na ferramenta de bug tracking.

13.Automatizar Testes Preparar os cenários de teste para execução automática usando a tecnologia sugerida para automação de testes (demoiselle behave).

14.Executar Testes Disparar os testes automáticos para os cenários das Estórias de Usuário selecionadas para a Sprint e rodar os demais testes que não puderam ser automatizados de forma manual. Caso ocorram erros, estes devem ser registrados na ferramenta de bug tracking e seguir o ciclo de vida do defeito documentado em anexo neste documento. Esses defeitos são registrados com tipo “DESENVOLVIMENTO”. Quando os erros críticos forem eliminados passa-se para a fase seguinte de integração. Gerar o relatório de testes através da ferramenta de gestão de testes com os problemas encontrados.

15. Integrar Reunir os códigos das funcionalidades implementadas, bem como scripts de criação / atualização da estrutura de dados. Tarefa de responsabilidade do desenvolvedor que deverá preparar o ambiente para o teste de integração.

16.Disponibilizar Ambiente de Homologação

Disponibilizar ambiente de homologação para que o teste integrado possa ser realizado, assim como o Gestor de Produto possa validar o pacote de software entregue. Além do Ambiente de Homologação, idealmente, deveríamos ter um Ambiente de Teste para execução dos testes manuais e automatizados. Fase 4 - Finalizar Sprint

17.Testar (teste integrado) Realizar o teste integrado das funcionalidades implementadas, a fim de verificar o funcionamento esperado do pacote de software. Diferentemente da tarefa “Executar Testes” em que os testes eram específicos para os cenários das Estórias de Usuário, o teste integrado irá testar o conjunto de Estórias de Usuário planejados para a Sprint. Caso ocorram erros, estes devem ser registrados na ferramenta de bug tracking e seguir o ciclo de vida do defeito documentado em anexo neste documento. Esses defeitos são registrados com o tipo “INTEGRAÇÃO”. Quando os erros críticos forem eliminados passa-se para a fase seguinte de validação. Caso não se tenha tempo hábil para eliminar os erros críticos que impossibilitam a validação pelo Gestor do Produto a sprint não poderá ser validada. Gerar o relatório de testes através da ferramenta de gestão de testes com os problemas encontrados.

18.Validar Pacote de Software Comunicar o Gestor do Produto sobre a disponibilização do ambiente de homologação, solicitando a devida validação e retorno. A validação do Pacote de Software deve ser feita em uma reunião de revisão com o Gestor do Produto, o cliente e outras partes interessadas para apresentar a versão do produto desenvolvida até o momento, avaliar como transcorreram os trabalhos, discutir pendências e validar o grau de satisfação do cliente com o projeto. As informações dadas pelo cliente (elogios, sugestões, críticas, etc.) devem ser documentadas e discutidas posteriormente com a equipe de desenvolvimento. O Gestor irá cadastrar os problemas encontrados na mesma ferramenta de bug tracking do desenvolvimento com os seguintes tipos possíveis: “MELHORIA” ou defeito de “HOMOLOGAÇÃO”. Além disso, os ajustes identificados durante as revisões devem ser incluídos no backlog do produto, para ser tratado, preferencialmente, na sprint seguinte.

19.Realizar Reunião de Retrospectiva Realizar reunião para revisão da Sprint concluída, a fim de identificar impedimentos ocorridos e acompanhar o andamento do projeto em relação ao previsto.

Levar para a reunião as métricas de testes da Sprint. Na última Sprint do projeto deve-se trazer as métricas consolidadas de todo o projeto.

20.Atualizar Backlog Atualizar requisitos na forma de estórias de usuário, a partir dos problemas identificados na reunião de retrospectiva. Estimar o esforço necessário para implementação de estórias criadas ou atualizadas. Da mesma forma os cenários de teste das estórias devem ser revistos e identificar quais foram testados. Nessa etapa, deve-se também registrar quais estórias de usuários foram implementadas na sprint. Atualizar o Plano e Métricas de Teste. Fase 5 - Implantar

21.Consolidar Ambiente de Homologação Consolidar as funcionalidades implementadas em todas as sprints do projeto em ambiente integrado de homologação para que o Gestor de Produto possa realizar a validação. Realizar smoke tests para garantir que o ambiente está funcional.

22.Validar Produto Comunicar o Gestor do Produto sobre a disponibilização do ambiente de homologação, solicitando a devida validação e retorno. Tarefa semelhante a de “Validar Pacote de Software” só que nesta etapa do projeto serão testados de forma integrada todos os pacotes de software desenvolvidos nas sprints. A homologação é a comprovação, pelo cliente e demais partes interessadas, de que o produto resultante do projeto de software atende aos critérios de aceite previamente estabelecidos com o cliente. Inclui elementos de verificação e de validação do produto todo ou de partes do produto selecionadas em comum acordo com o cliente e tem como meta principal a obtenção do aceite do produto. Tal atividade só deve começar depois que todos os outros testes forem executados, e os erros encontrados forem corrigidos ou aceitos. A homologação é considerada "finalizada com sucesso" quando o software funcionar da forma esperada pelo cliente no ambiente proposto. Desta forma, os objetivos desta atividade são:

● Atestar que o software funciona da forma esperada pelo cliente no ambiente proposto;

● Identificar oportunidades de correção e aplicar os ajustes correlatos à aplicação; ● Obter o aceite do produto de software pelo cliente; ● Registrar sugestões para as próximas versões da aplicação

O Gestor irá cadastrar os problemas encontrados na mesma ferramenta de bug tracking do desenvolvimento com os seguintes tipos possíveis: “MELHORIA” ou defeito de “IMPLANTAÇÃO”. Avaliar os problemas encontrados e decidir se o produto pode ir para Produção ou não. Atualizar o Plano de Teste e métricas de testes.

23.Repassar para Operação Treinar equipe de atendimento a usuários e, quando for o caso, os principais envolvidos. Atividades de teste não se aplicam.

24.Divulgar Divulgar o produto e a data de entrada em produção aos interessados e ao Comitê Gestor de TIC. Dependendo do caso, a divulgação final poderá ser realizada pela Secretaria de Comunicação Social ou pela área de negócio envolvida (Presidência, Corregedoria, entre outras). Atividades de teste não se aplicam.

25.Liberar em Produção Disponibilizar no ambiente de produção o produto homologado. Executar um smoke test antes da liberação para os usuários para garantir que o software passe nos testes básicos.

ANEXO: FURPS Para o futuro… Sugestão de metodologia Teste de Qualidade baseado no FURPS (Functionality, Usability, Reliability, Performance, Supportability), que consiste nas seguintes categorias: Funcionalidade Teste funcional. Concentra-se na validação das funções do elemento a ser testado. Esse teste é realizado em diferentes estágios, como unidade, interação ou sistema. Teste de regressão. Verifica se as partes do software não afetadas por uma alteração continuam operando conforme o que foi especificado. Teste de volume. Submete a aplicação a ser testada a grandes quantidades de dados para determinar se os limites que causam a falha foram alcançados. Teste de segurança. Destinado a garantir que o objetivo do teste e os dados possam ser acessados apenas por determinados atores. Esse teste é implementado e executado em vários objetos de teste (verificar com o Grupo de Segurança). Usabilidade Teste de interface. Verifica a interação do usuário em relação ao aplicativo, garantindo acesso e navegação apropriados através das funções do aplicativo. Neste teste também se examina se os objetos na interface funcionam de acordo com o especificado. Teste de usabilidade. Enfatiza a facilidade de uso da aplicação por seus clientes ou usuários. As aplicações devem ser suficientemente amigáveis para atingir os objetivos do negócio. Confiabilidade Teste de integridade. Destinado a avaliar a robustez do objetivo do teste e a compatibilidade técnica em relação à linguagem, sintaxe e utilização de recursos, é implementado e executado em vários objetivos do teste, como unidades e unidades integradas. Teste de estrutura. Destinado a avaliar a adequação do objetivo em relação ao seu design e a sua formação, este teste, em geral, é realizado em aplicativos habilitados para a Web, garantindo que todos os links estejam conectados, que o conteúdo apropriado seja exibido e que não haja conteúdo órfão. Teste de estresse. Tipo de teste de confiabilidade destinado a avaliar como o sistema responde em condições anormais. O estresse no sistema pode abranger cargas de trabalho

extremas, memória insuficiente, hardware e serviços indisponíveis ou recursos compartilhados limitados. Este teste costuma ser executado para se compreender melhor como e em quais áreas o sistema será dividido, para que os planos de contingência e a manutenção de atualização possam ser planejados e orçados com bastante antecedência. Smoke test. O smoke test exercita o sistema numa única passagem, em geral utilizando script de execução automática, e não deve ser exaustivo, mas capaz de expor os maiores problemas. O smoke test é executado após a construção de cada nova versão. Desempenho Teste de avaliação de desempenho ou benchmark. Compara o desempenho de um objetivo do teste a um sistema e a uma carga de trabalho de referência conhecidos. Teste de contenção. Verifica se a aplicação pode lidar de maneira aceitável com as demandas de vários atores no mesmo recurso (registro de dados, memória etc.). Teste de carga. Usado para validar e avaliar a aceitabilidade dos limites operacionais de um sistema de acordo com cargas de trabalho variáveis, ao passo que o sistema em teste permanece constante. Em geral, as medições são tomadas com base na taxa de transferência de dados da carga de trabalho e no tempo de resposta da transação alinhado. Perfil de desempenho. Teste no qual o perfil de andamento é monitorado a fim de identificar e tratar gargalos de desempenho e processos ineficientes. Suportabilidade Teste de configuração. Assegura que o objetivo do teste funcione conforme o esperado em diferentes configurações de hardware e/ou software. Este teste também pode ser implementado como um teste de desempenho do sistema. Teste de instalação. Garante que o objetivo do teste seja instalado conforme o esperado em diferentes configurações de hardware e/ou software e sob diferentes condições. Este teste é implementado e executado em aplicativos e sistemas.

ANEXO: CICLO DE VIDA DO DEFEITO Os defeitos encontrados durante a tarefa “Executar Testes” durante a implementação da Sprint são do tipo “IMPLEMENTAÇÃO”. Os defeitos abertos na tarefa “Testar (teste integrado)” são do tipo “INTEGRAÇÃO” e os defeitos na tarefa “Validar Pacote de Software” são do tipo “HOMOLOGAÇÃO”. Essa tipagem é importante para a coleta das métricas de teste descritas a seguir. A ferramenta de bug tracking também pode aceitar sugestões ou melhorias que poderão gerar/atualizar as estórias/cenários a serem tratados nas sprints seguintes.

ANEXO: Modelo para descrever requisito não funcional Identificador RNF001 Categoria Usabilidade

Nome Uso de Design responsivo nas interfaces gráficas

Data 11/09/2017 Autor L.F.Estivalet

Versão 1 Prioridade Importante

Descrição O sistema de Audiências será construído para rodar em ambiente web. Deverá possui um design responsivo (https://en.wikipedia.org/wiki/Responsive_web_design). A interface do sistema deverá se comportar adequadamente independente do front-end que será utilizado para acesso – Browser, Smartphone ou Tablet.

ANEXO: SUGESTÃO DE MÉTRICAS DE TESTE

1) PERD – Projetos com Eficiência na Remoção de Defeitos Descrição: Percentual de projetos com todos os Erros de Desenvolvimento removidos antes da entrega do produto

Nome Unidade Fórmula

TDR Erro de Desenvolvimento

Quantidade total de Erros de Desenvolvimento removidos em cada projeto considerando a última entrega da sprint.

TD Erro de Desenvolvimento

Quantidade total de Erros de Desenvolvimento em cada projeto.

ERD % (TDR / TD) * 100

PDR Projeto Quantidade total de projetos elegíveis com 100% ERD.

PDT Projeto Quantidade total de projetos elegíveis.

PERD % (PDR / PDT) * 100

2) DDH – Densidade de Defeitos na Homologação

Nome Unidade Fórmula

TH Erro de Homologação

Total de Erros de Homologação detectados.

PF PF Tamanho funcional do projeto estimado/realizado em Ponto por Função.

DDH Erro de Homologação/PF

DDH = TH / PF

3) EDD – Eficiência na Detecção de Defeitos

Nome Unidade Fórmula

TD Erro de Desenvolvimento

Erro

TH Erro de Homologação

Total de Erros de Homologação detectados

EDD % EDD = [TD / (TD + TH)] * 100