Metodologia de Gestão de projetos baseado em AGIL

47 Deverá também ser criado os Releases Templates de cada Build existente para seu ambiente definido. As convenções/configurações estão definidas no Documento “Padrões de Desenvolvimento” do DSA. Durante a criação da Release Template, as permissões a ela devem ser atribuídas conforme o documento de Permissões no ALM. Figura 11 – Fluxo de uma release Só é possível criar uma Release Template a partir de uma Build existente. 7.1.5.4.7 Reporting Services Reporting Services é um recurso que permite a visualização e criação de relatórios extraindo informações de todas as ferramentas do ALM. Durante a criação de um projeto no TFS, alguns relatórios são criados por padrão e servem como base para estratificar informações estatísticas como “Quantidade de Bugs”, “Builds realizadas”, “Quantidades de Tarefas”, etc.

48 As permissões deverão ser atribuídas aos grupos da equipe no diretório do projeto para que estes possam utilizar estes recursos. As permissões que devem ser atribuídas e os grupos que irão recebe- las estão descritas no documento Permissões no ALM. 7.1.5.4.8 Sharepoint Sharepoint é uma ferramenta para colaboração entre as equipes, disponibilização de artefatos referente aos projetos, entre outros recursos. As permissões para a utilização dessa ferramenta deverão ser atribuídas aos grupos da equipe no portal do projeto para que estes possam utilizar os recursos do portal. As permissões serão concedidas de acordo com o documento Permissões no ALM. 7.1.5.4.9 IIS (Servidor de Aplicação) IIS é o Servidor de aplicação onde fica hospedada um sistema. Este servidor deversá ser configurado em cada ambiente para que aponte para o local onde o Release Management fará o Deploy dos arquivos. 7.1.5.4.10 Ambientes O publicador do ALM é responsável por validar que as Builds, Releases Templates e Servidores de Aplicação (IIS) estejam compatíveis e configuradas de acordo para que seu fluxo funcione de forma rápida e célere. Os objetivos de cada ambiente são:  Ambiente de Desenvolvimento: Onde o desenvolvedor executa alterações e pode visualizar a partir da sua própria branch. Normalmente é para desenvolver e testar uma pequena feature.  Ambiente de Teste: Onde a equipe de qualidade pode testar uma versão completa do sistema.  Ambiente de Homologação: Onde é testado o impacto das modificações a serem feitas em produção e também onde o teste de aceitação é realizado.  Ambiente de Produção: Ambiente onde os usuários finais utilizam o sistema.

49 7.1.5.5 Documentar requisitos de negócio Existem diversos tipos de requisitos que são normalmente classificados em níveis e são derivados do mais alto nível ao mais baixo nível e a partir do problema de negócio é possível identificar os requisitos de negócio. Requisito de negócio é a definição de como o negócio funciona, ela evidencia as restrições existentes para o funcionamento de determinado negócio, podendo abranger qualquer assunto. Além disso, a regra de negócio não depende da existência de um sistema. Os requisitos de negócios deverão ser cadastrados no Team foundation server no formato de Features conforme a Figura 12 – Relação requisitos x work items. Figura 12 – Relação requisitos x work items Requisitos de negócio Feature Requisitos funcionais e User story não funcionais Task Especificações (requisitos detalhados) 7.1.5.6 Elaborar plano de entregas (release) O plano de entregas estabelece a meta da versão, as maiores prioridades do Product Backlog, os principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para entrega a cada Sprint.

50 O plano de release define quando as funcionalidades ou um conjunto delas serão entregues ao cliente. Seu principal objetivo é permitir que o time de desenvolvimento tenha uma visão de quando as entregas serão efetuadas ao cliente. 7.1.6 CONCEPÇÃO DA APLICAÇÃO: SAÍDAS  Epics (lista de funcionalidades);  Plano de release;  Políticas do ALM;  Team collection do projeto;  Portal do sistema;  Portal do projeto.

51 8 FASE DE CONSTRUÇÃO Esta fase está essencialmente relacionada à codificação e teste do sistema ou componente, ao final deve-se ter um sistema de software em funcionamento e a documentação associada pronta para ser liberada para os usuários (SENE, 2011). É na fase de construção que a maior parte de codificação ocorre. É prevista para ocorrer de forma iterativa e incremental, de acordo com o plano de releases criado na atividade Elaborar plano de entregas (release). As iterações são um time box4 de aproximadamente 2 a 4 semanas. Se todas as funcionalidades demandarem esforço inferior a 4 semanas, sugere-se a utilização de apenas uma iteração. Caso a duração seja superior, a construção deve considerar múltiplas iterações, com a priorização do que deve ser implementado na iteração ocorrendo no início da mesma, conforme fluxo a ser apresentado na próxima seção. Esta fase é composta pelos seguintes processos e subprocessos: 1.1. Desenvolvimento da aplicação 1.1.1. Planejar iteração 1.1.2. Executar iteração 1.1.2.1. Construção e testes unitários 1.1.2.2. Planejar testes 1.1.2.3. Executar testes 1.1.2.4. Gestão do conhecimento 8.1 Desenvolvimento da aplicação O processo de Desenvolvimento da aplicação é responsável por organizar as iterações e executar a construção da melhoria. A parte mais relevante deste processo ocorre dentro da iteração onde estão a maior parte das atividades executadas. Iterações são eventos com duração fixa onde o time busca 4 Termo utilizado em métodos ágeis que representa o prazo inflexível de tempo alocado para uma tarefa específica.

52 sempre atingir a meta que foi estabelecida. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a iteração (SCHWABER, 2009). As iterações consistem na reunião de planejamento, o trabalho de desenvolvimento e a revisão da iteração. A retrospectiva da iteração é opcional para as equipes e ocorre dentro da fase de monitoramento e controle. As iterações deverão ocorrer uma após a outra, sem intervalos entre elas.

Figura 13 – Diagrama de do processo Desenvolvimento da aplicação

53

Atividades do processo Desenvolvimento da Coordenador aplicação Assessoria da CTI Levantar requisitos Registrar user stories no product backlog Planejar iteração Executar iteração Gerar build stable

C/I A/R I I I A/R R R/A C C C A/R R A/R C Diretor do DSA Assessora DSA RR Gerente de sistemas Controller Arquiteto de sistemas Analista de sistemas Desenvolvedor Gerente de qualidade Analista de qualidade Técnico de qualidade Cliente 54

55 8.1.1 DESENVOLVIMENTO DA APLICAÇÃO: ENTRADAS  Requisitos de negócio  Plano de release 8.1.2 DESENVOLVIMENTO DA APLICAÇÃO: ATIVIDADES 8.1.2.1 Levantar requisitos É essencial que os requisitos sejam completos, claros, corretos e consistentes, porque eles servem como pilares da solução para as necessidades do negócio (Guia BABOK®, 2011). Podem ser utilizadas diversas técnicas durante a execução desta atividade, porém a mais amplamente aceita pelos os clientes do DSA é para levantamento de requisitos é a aplicação de entrevistas e questionários. Durante a atividade de levantamento de requisitos é essencial que os critérios de aceitação sejam especificados junto ao cliente, pois é por meio destes que os testes serão executados e as funcionalidades serão validadas pelo cliente. Todos os documentos gerados no levantamento de requisitos, tais como atas, caso de uso, modelos dentre outros, deverão ser armazenados na pasta Shared documents, que está localizada dentro do portal do sistema, na subpasta 8.1.2.2 Registrar user stories no Product Backlog O product backlog pode ser formado por diversos itens, como requisitos funcionais, requisitos não- funcionais, correções ou outros itens que agregam valor ao produto (WEISS, 2013), porém para esta metodologia o item a ser utilizado será a User Story5 quando se tratar de um requisito. As user stories podem ser cadastradas utilizado o Team web access. As informações obrigatórias no cadastro de uma user storie são: 5 A user story (história de usuário), é uma descrição concisa de uma necessidade do usuário do produto (ou seja, de um “requisito”) sob o ponto de vista desse usuário. A User Story busca descrever essa necessidade de uma forma simples e leve.

56 Figura 14 – Cadastro de user story no team web access  Título: Breve descrição do que a história irá entregar.  Details: Forneça detalhes suficientes para fazer a estimativa do trabalho necessário para implementar a história. Foque no objetivo do recurso, no que os usuários desejam fazer e por quê. Não descreva como o recurso deve ser desenvolvido. Forneça detalhes suficientes para que sua equipe possa escrever tarefas e casos de teste para implementar o item. Veja um exemplo dos detalhes de uma user story na Figura 15 – Formato dos detalhes de uma user story  Assigned to: O proprietário da user story. De forma simplista, é o usuário ou o interessado em um funcionalidade.  State: Quando o item de trabalho é criado, o status assume por padrão o valor New. Conforme o trabalho progride, atualize-o para refletir o estado atual.  Story points: Estimativa da quantidade de trabalho necessária para concluir uma user story usando qualquer unidade de medida que sua equipe preferir.

57  Area: Escolha o caminho de área associado ao produto ou à equipe, ou deixe em branco até ser atribuído durante uma reunião de planejamento.  Iteration: Iteração em que o trabalho deve ser concluído, ou deixe em branco e atribua posteriormente, durante uma reunião de planejamento. Figura 15 – Formato dos detalhes de uma user story Fonte: Adaptada de (WEISS, 2013) Após registrar as user stories no Product backlog o fluxo deve ser direcionado para o processo Planejar iteração. 8.1.2.3 Planejar iteração O processo de Planejar iteração é uma reunião na qual estão presentes o cliente, o e todo o time6 de desenvolvimento, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente (Sprint Planning Meeting, 2013). O objetivo da primeira parte da reunião é entender o que cada user story representa e em seguida selecionar quais serão desenvolvidas dando origem ao backlog da iteração. Coletivamente, o time e o cliente definem um objetivo para o iteração, que é uma breve descrição daquilo que se tentará alcançar. 6 No scrum um time é composto por três papéis: Scrum máster, product owner e a equipe

58 Na segunda parte da reunião de planejamento da iteração, a equipe7 se encontra separadamente, sem o cliente, para conversar sobre como será desenvolvida cada user story e o quanto eles podem se comprometer a fazer na iteração que será iniciada. Em alguns casos, haverá negociação com o cliente, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer. 7 A equipe scrum é que desenvolve e testa o produto.

Figura 16 – Diagrama do processo planejar iteração Tabela 3 – Matriz de responsabilidade planejar iteração

59

Atividades do processo Gerenciamento da Coordenador demanda Assessoria da CTI Explicar user stories ao time Selecionar itens do backlog para iteração Decompor user stories em tasks Estimar prazos para as tasks Distribuir tasks

RR Diretor do DSA RR Assessora DSA I C C R/C Gerente de sistemas A/R Controller Arquiteto de sistemas A/R Analista de sistemas A/R Desenvolvedor Gerente de qualidade CC Analista de qualidade Técnico de qualidade Cliente 60

61 8.1.2.3.1 Planejar iteração: Entradas  Capacidade do time: É um valor que representa a capacidade produtiva ou velocidade de um time. É o mesmo que definir quantas histórias um time consegue entregar numa iteração, baseando-se no histórico do time.  Backlog do produto priorizado: Backlog ordenado com as user story de maior valor para o negócio em primeiro lugar da lista. Para que o product backlog já esteja priorizado é necessário executar regularmente o processo Backlog Grooming.  Incremento do produto recente: Conjunto de funcionalidades potencialmente entregável que foram desenvolvidas durante uma iteração. Incremento de produto 8.1.2.3.2 Planejar iteração: Atividades 8.1.2.3.2.1 Explicar user stories ao time Esta atividade deve ser executada preferencialmente pelo cliente, porém existem projetos nos quais o cliente não se envolve com o processo de desenvolvimento. Nesses casos deverá ser elencado uma pessoa para representar o cliente durante as reuniões. O cliente ou seu representante não precisa descrever todos os itens que estão no product backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para a próxima reunião de planejamento da iteração. Nota: Para se executar esta atividade é necessário que o product backlog já esteja priorizado. Esta priorização é feita na atividade de Backlog Grooming fase de

62 Monitoramento e controle. 8.1.2.3.2.2 Selecionar itens do product backlog Depois de entender e estimar a complexidade dos itens de backlog o time de desenvolvimento seleciona, respeitando a prioridade, os itens que acredita que consegue entregar na iteração e acorda estes com o cliente, formando assim o backlog da iteração. Para executar esta atividade é necessário que o backlog já esteja priorizado. Esta atividade é feita regularmente no Backlog Grooming. 8.1.2.3.2.3 Decompor user stories em tasks O time de desenvolvimento discute como entregar cada um dos itens selecionados e quais são as tarefas (tasks) que precisam ser feitas. São discutidos todos os tipos de atividades que podem ser necessárias, podendo ser dos seguintes tipos:  Desenvolvimento  Deploy  Desenho  Documentação  Levantamento de requisitos  Teste 8.1.2.3.2.4 Estimar prazos para as tasks As tarefas deverão ser estimadas em horas e os responsáveis pelas atividades devem informar quanto tempo será necessário para executar a atividade. É importante que os prazos inseridos nas tarefas sejam realistas, pois será por meio deles que a equipe poderá acompanhar se a meta da iteração será alcançada dentro do prazo acordado. 8.1.2.3.2.5 Distribuir tasks As tarefas devem ser distribuídas para os responsáveis pela execução Para isso basta assinar a tarefa com o nome de quem a executará. Para fazer a distribuição das tarefas siga os passos abaixo: 1. Entre no Team Foundation Server (TFS) por meio de um navegador;

63 2. Procure pelo projeto desejado; 3. Clique na aba Work; 4. Clique em backlog; 5. Escolha a iteração atual; Visualize os detalhes de cada tarefa e no campo Assigned to atribua o nome de quem executará a tarefa. Faça isso para todas as tarefas de todas as histórias. 8.1.2.3.3 Planejar iteração: Saídas  Backlog da iteração: Os itens selecionados do backlog do produtos mais as tarefas necessárias para transformá-los em incremento de software pronto e potencialmente utilizável é. Após a execução do fluxo planejar iteração deve ser direcionado para o fluxo executar iteração.

64 8.1.2.4 Executar iteração O processo de executar iteração é onde os desenvolvedores e testadores trabalham com mais intensidade, é basicamente a codificação e teste ocorrem de forma a concluir os itens do backlog da iteração. O processo de Executar iteração pressupõe que o desenvolvimento da aplicação e os testes sejam realizados em paralelo ao longo de todo o processo de desenvolvimento conforme explica (BASTOS, RIOS, et al., 2007).

Figura 17 – Diagrama Executar iteração Tabela 4 – Matriz de responsabilidade Executar iteração

65

Atividades do processo Executar Iteração Coordenador Assessoria da CTI Construção e testes unitários Planejar testes Lançar versão beta Executar testes de sistema Gestão do conhecimento Lançar versão RC

A/R Ck A R R R/A I CC R/A Diretor do DSA Assessora DSA C R/A R/A Gerente de sistemas Controller I Arquiteto de sistemas Analista de sistemas Desenvolvedor Gerente de qualidade Analista de qualidade Técnico de qualidade Cliente 66

67 8.1.2.4.1 Executar iteração: Entradas  Tasks 8.1.2.4.2 Executar iteração: Atividades 8.1.2.4.2.1 Construção e testes unitários A contrução e testes unitários é uma atividade exclusiva da equipe de desenvolvimento. O desenvolvedor escreve o código necessário e faz alguns testes preliminares, utilizando a análise de código e ferramentas de teste de unidade estáticos.

Figura 18 – Diagrama do processo Construção e testes unitários

68

Tabela 5 – Matriz de responsabilidade Construção e testes unitáriosCoordenador Assessoria da CTI Atividades do processo Construção e testes unitários Puxar Task Codificar Incremento Realizar Check in Gerar build alpha Testes Unitários automatizados Marcar user stories como resolved

69Diretor do DSA Assessora DSA A/RGerente de sistemas A/RController A/RArquiteto de sistemas A/R IAnalista de sistemas A/RDesenvolvedor A/RGerente de qualidade Analista de qualidade Técnico de qualidade Cliente

70 8.1.2.4.2.1.1 CONSTRUÇÃO E TESTES UNITÁRIOS: ENTRADAS  Task  Padrões de desenvolvimento DSA 8.1.2.4.2.1.2 CONSTRUÇÃO E TESTES UNITÁRIOS: ATIVIDADES 8.1.2.4.2.1.2.1 Puxar task Nesta atividade o desenvolvedor utiliza a própria IDE de desenvolvimento para iniciar a execução de seu trabalho. O principal objetivo desta atividade é marcar a task com o status Active. Para isso o desenvolvedor deverá procurar a task utilizando a ferramenta Team Explorer localizada em View  Team explorer. Em seguida procure pela opção Work Items e na seção Queries procure pela query My tasks. Visualize os detalhes na task que deseja iniciar o trabalho e em seguida altere seu status para Active, salve e inicie o trabalho. Caso o desenvolvedor possua o Visual Studio Premium ou superior é possível utilizar a opção my work dentro do team explorer para dar andamento nas tasks ou outros tipos de work items que estejam assinador para ele. 8.1.2.4.2.1.2.2 Codificar incremento Nesta etapa o desenvolvedor começa a codificar de acordo com as normas estabelecidas no documento “Padrões de desenvolvimento” localizado em: Padrões de Desenvolvimento. Para todos os novos projetos ou onde for possível, deve-se criar os testes unitários que será utilizado para validar o código. Durante este desenvolvimento, qualquer mudança referente a arquitetura do sistema deve ser acordado com o arquiteto da equipe. 8.1.2.4.2.1.2.3 Realizar check in Realizar check in é o processo de envio do código realizado localmente na estação de trabalho do desenvolvedor para o TFS.

71 Para executar esta ação no Visual Studio, abra a Solution Explorer (Menu View  Solution Explorer) e clique com o botão direito no item cujo seus respectivos itens abaixo na hierarquia será enviado e clicar em Source Control  Check In. Irá então abrir o “Team Explorer” na área de “Pending Changes”, nesta deve-se informar em Comment as informações sobre o que representa estas alterações e em Related Work Items deve-se adicionar os work items que estão relacionados a estas alterações. Após isto é somente clicar em Check In para que as informações sejam enviadas para o servidor. Todos os check in devem obrigatoriamente possuir um comentário e um work item vinculado definido pela política do projeto. Ao realizar o check in, é gerada uma Build do tipo Alpha e realizado automaticamente o deploy pela ferramenta “Release Management”. A Build Alpha está ligada a uma branch de desenvolvimento (Dev) o que significa que esta build é para ser validada e testada somente naquela feature que originou a Branch. 8.1.2.4.2.1.2.4 Testes Unitários Automatizados Os testes unitários consistem em validar dados válidos e inválidos via I/O (entrada/saída) sendo aplicado por desenvolvedores ou analistas de teste. Uma unidade é a menor parte testável de um programa de computador. Esses testes devem ser executados automaticamente em cada build criada, o que permite verificar a cobertura de código, quantidade de testes falhos e teste de impacto. 8.1.2.4.2.1.2.5 Marcar User Story como Resolved O status da user story é marcado como resolved quando seu código já está completo, ou seja, quando todas as tarefas de desenvolvimento já foram concluídas, e nenhum defeito foi encontrado nos testes unitários, conforme pode ser visto na Figura 19 – Diagrama de status da user story.

72 Figura 19 – Diagrama de status da user story Fonte: (MSDN, 2013) 8.1.2.4.2.1.3 CONSTRUÇÃO E TESTES UNITÁRIOS: SAÍDAS  User story construída

73 8.1.2.4.2.2 Planejar testes Cada cenário será representado por um conjunto de casos de teste a ser validado por uma lista de procedimentos, incorporados numa suíte de testes que posteriormente será executada. Os casos de testes estabelecem quais informações serão empregadas durante os testes desses cenários, quais os resultados esperados e a massa crítica de testes necessária para validar todos os requisitos de software. O plano de caso de teste é o documento que registra todo o planejamento dos testes dos requisitos estabelecidos durante o ciclo de desenvolvimento do software. Esse documento determina o que será testado, e seu principal objetivo consiste em identificar o maior número de cenários e variações de determinado requisito de software (BASTOS, RIOS, et al., 2007).

Figura 20 – Diagrama do processo Planejar testes

74

Tabela 6 – Matriz de responsabilidade Planejar testes Coordenador Assessoria da CTI Atividades do processo Planejar testes Diretor do DSA Receber task Organizar suítes de teste Elaborar / resetar casos de teste Reconhecer defeito(s) Corrigir defeito Agendar correção Encerrar o Bug Solicitar teste

C Assessora DSA R Gerente de sistemas Controller A/R Arquiteto de sistemas R Analista de sistemas Desenvolvedor R Gerente de qualidade A/R Analista de qualidade A/R Técnico de qualidade Cliente R R A/R 75

76 8.1.2.4.2.2.1 PLANEJAR TESTES: ENTRADAS  Task de teste  Critérios de aceitação 8.1.2.4.2.2.2 PLANEJAR TESTES: ATIVIDADES 8.1.2.4.2.2.2.1 Receber task Antes de começar a realizar o planejamento dos testes é necessário que uma task já esteja cadastrada na user story a ser testada. A task para planejar os testes deverá ser escrita durante o processo de Planejar iteração, onde são definidos quais tarefas são necessárias para a entrega daquele pacote, no caso a user story. Para receber a task de teste siga os passos abaixo: 1. Abra o Microsoft Test Manager; 2. Selecione o projeto desejado; 3. Selecione o plano de teste 4. Clique na aba Track; 5. Abra a pasta Shared queries; 6. Abra a pasta Consutlas equipe de qualidade; 7. Execute a query Minhas tarefas; 8. Visualize os detalhes da task e altere o status para Active 9. Clique em salvar 8.1.2.4.2.2.2.2 Organizar suítes de teste E recomendável que as as suítes de teste sejam organizadas utilizando o mesmo formato que a arquitetura do software foi organizada. Os casos de teste devem estar organizados dentro de um dos seguintes tipos de suítes de teste:  Suite de teste baseado em requisitos – Inclui qualquer caso de teste que esteja linkado à uma user story. O mais indicado é que todas as suítes de testes sejam linkadas à algum requisitos que estão sendo implementados na iteração. Desta forma, é possível criar e

77 executar casos de testes que verificam se a aplicação está entregando o que foi prometida na funcionalidade.  Suite baseada em consultas – Permite que seja especificada um conjunto de work items baseados em uma consulta. Por exemplo, é possível querer incluir todos os casos de teste com prioridade de nível 1, mesmo se estes requisitos já foram concluídos em outras iterações. Ajuda a garantir que funcionalidades críticas que já foram implementadas não foram impactadas pelas novas alterações (teste de regressão).  Suite de teste estática – Trata-se de uma lista de casos de teste que podem ser adicionadas manualmente na suíte. Uma suíte de teste estática também pode ser usada como um contêiner para outras suítes de teste, fornecendo uma estrutura hierárquica para organização dos testes. Sempre que possível, utilize a suite de teste baseada em requisitos. 8.1.2.4.2.2.2.3 Elaborar / resetar casos de teste Na ferramenta Microsoft Test Manager ao clicar na aba Plan  Conteúdo, é possível e organizar os casos de teste que compõem o Plano de teste. Um caso de teste é um conjunto de interações com uma aplicação de software que são projetados para validar a funcionalidade ou o comportamento do aplicativo. Por exemplo, pode existir um caso de teste que confirme que um novo usuário pode criar uma conta dentro de sua aplicação. 8.1.2.4.2.2.2.4 Solicitar teste Após a criação do planejamento de teste por meio de suítes de teste e casos de teste, o analista de qualidade deve solicitar a execução desses testes. Para isso deverá ser aberta uma task de teste. A abertura da task de teste deverá obrigatoriamente conter os seguintes campos: 1. Título: Nome da tarefa com título intuitivo como: “Testar user story” 2. Assigned to: Responsável por executar os testes; 3. Activity: Deverá ser escolhida a atividade “testing” 4. Details: Descrição de quais casos de testes deverão ser testados. Após a execução da atividade solicitar teste, deve ser direcionado a execução do Processo Executar Testes.

78 8.1.2.4.2.2.2.5 Reconhecer defeito(s) Depois de detectado o defeito, o analista de teste em conjunto com o analista de sistemas devem verificar e decidir se ele é válido ou não, e analisar sua criticidade. Um defeito que impacta na release atual deveser corrigido o mais rápido possível, caso contrário sua correção deve ser definida em qual release esta correção deve ser entregue. Se o defeito reportado pelos técnicos de qualidade não for válido o fluxo deve ser direcionado para atividade Encerrar o Bug. 8.1.2.4.2.2.2.6 Corrigir defeito Após o defeito ser reconhecido como válido e também como um defeito crítico, ou seja, um defeito que irá impactar a release a ser lançada, é necessário realizar a correção deste. 8.1.2.4.2.2.2.7 Agendar correção Um defeito reconhecido como válido mas não considerado urgente pode ser agendado para ser corrigido em uma outra iteração. Para isso deve ser iniciado a execução do processo Desenvolvimento da aplicação. 8.1.2.4.2.2.2.8 Encerrar o Bug Caso o analista de teste e o analista de sistema identifiquem que o defeito não é válido, o bug deverá ser encerrado. O status o bug deverá constar como closed e o campo Reason deverá estar marcado como verified, como pode ser observado na Figura 21 – Transição de status dos bugs no MSF. Para alterar o status do bug siga os passos abaixo: 1. Acesse o team projeto na ferramenta Team Fondation Web Access; 2. Escolha o projeto desejado; 3. Clique me work; 4. Clique em queries; 5. Procure o bug utilizando uma das queries já cadastradas; 6. Visualize os detalhes dos bugs; 7. Altere o campo State para Closed; 8. Clique em salvar no ícone semelhante a um disquete.

79 O framework da Microsoft MSF não trata dos bugs juntos ao backlog do produto, sendo tratado em um processo chamado Bug triage, por isso há necessidade de consutlar os bugs por meio de uma consulta. Os bugs possuem status diferente das user stories e das tasks, seguindo o fluxo mostrado na Figura 21 – Transição de status dos bugs no MSF. 8.1.2.4.2.2.3 PLANEJAR TESTES: SAÍDAS  Casos de teste  Bug encerrado

80 Figura 21 – Transição de status dos bugs no MSF 8.1.2.4.2.3 Lançar versão BETA A versão beta é lançada após todos os itens previstos na iteração terem sido desenvolvidos e seus testes planejados. Se algum teste unitário for reprovado a versão beta não poderá ser lançada até que todos os defeitos primários tenham sido corrigidos. Para lançar a versão Beta, deve-se fazer um merge da(s) branch(s) de desenvolvimento para a branch MAIN (ambiente de teste), efetuar o check in e então gerar uma build Beta. Para saber mais sobre o que cada versão represenda no fluxo do ALM veja a Figura 22 – Ciclo de vida das releases.

81 Figura 22 – Ciclo de vida das releases Alpha- Versão em construção ainda não disponível para uso Beta - Primeira versão disponibilizada para a equipe de qualidade ou alguns usuários. Release candidate (RC) - O mais próximo da versão final, pois a maioria dos defeitos já foi corrigda Stable - Versão final que vai para o ambiente de produção Fonte: Adaptado de (CAMARGO, 2009) 8.1.2.4.2.4 Executar testes de sistema O responsável pelos testes deve utilizar a ferramenta Test Professional Manager para gerenciar e executar um conjunto de casos de teste manuais, na intenção de encontrar a maior quantidade possíveis de defeitos no software e registrar os bugs para a equipe de desenvolvimento. Embora o ciclo de vida de teste seja totalmente independente do ciclo de vida de desenvolvimento, os testes só poderão ser executados após a conclusão dos produtos do ciclo de vida de desenvolvimento (BASTOS, RIOS, et al., 2007). Os bugs gerados neste processo contêm diversas informações para o desenvolvedor, incluindo um vídeo do test case executado pelo responsável dos testes (screenshots), log de eventos a partir do momento que o teste iniciou. As atividades do ciclo de vida de testes devem ser executadas por um grupo formalmente definido para a realização dos testes, para que sejam bem realizadas.

Figura 23 – Diagrama Executar testes de sistema

82

Tabela 7 – Matriz de responsabilidade Executar testes de sistemaCoordenador Assessoria da CTI Atividades do processo Executar Testes Receber task Procurar defeito(s) Reprovar caso de teste Relatar defeito(s) Encerrar task

83Diretor do DSA Assessora DSA R/A Gerente de sistemas R/A Controller I R/A Arquiteto de sistemas I I R/A Analista de sistemas R/A Desenvolvedor Gerente de qualidade Analista de qualidade Técnico de qualidade Cliente

84 8.1.2.4.2.4.1 EXECUTAR TESTES DE SISTEMA: ENTRADAS  Casos de teste  Task de teste 8.1.2.4.2.4.2 EXECUTAR TESTES DE SISTEMA: ATIVIDADES 8.1.2.4.2.4.2.1 Receber task Antes dos testes serem executados é necessário que uma task seja aberta, como forma de registro da solicitação da execução dos testes. Quem registra essa task é o analista de teste e quem recebe a task é o técnico de teste. Nesta task de teste deverá conter quais casos de testes deverão ser testados. Para que o técnico de teste acesse a task deve ser verificado os passos abaixo: 1. Abra o Microsoft Test Manager e selecione a aba Track; 2. Abra a pasta My queries e realize a consulta; 3. Localize a Task desejada e visualize os detalhes 4. Mude o status da task para active. 8.1.2.4.2.4.2.2 Procurar defeitos Nesta atividade o técnico de teste irá procurar defeitos nas features implementadas por meio de heurística, ou seja, tenta identificar defeitos no software por meio da análise e interpretação de um conjunto de princípios. Para executar os testes é necessário abrir a ferramenta test run executando as seguintes instruções abaixo: 1. Abra o Microsoft Test Manager; 2. Escolha o projeto desejado; 3. Escolha o plano de teste desejado; 4. Selecione qual caso de teste será testado de acordo com a task aberta pelo analista de teste; 5. Clique em run e o test runner será aberto; 6. Realize os testes de acordo com o que foi planejado. Se precisar interromper a execução do teste, pause o teste, pois qualquer ação que não faça parte do fluxo básico será capturada pela ferramenta.