Agilidade em Testes de Software – O que é ser Ágil? Parte 02 de 03

agile-glossary

Olá Pessoal,

Dando continuidade ao post ALM – Agilidade em Testes de Software – O que é ser Ágil? – Parte 01 de 03 o que acredito ser um bom caminho desse tema as vezes polêmico.

Particularmente e longe da minha crença/opinião estar certa e além disso, amanhã posso tranquilamente mudar minha opinião, mas hoje creio que agilidade está intimamente ligada muito mais aos indivíduos (time, colaboradores, empresa) que fazem a atividade do que apenas no processo em si.

Claro que há processos que inibem você (que acredita que possui um pensamento ágil, assertivo, etc.) de pular partes desse processo devido a regras estabelecidas, mesmo que você entenda que aquela parte do processo é descartável, devido a uma obrigatoriedade legal como uma ISO ou SOX ou até por determinação da própria empresa.

Continuar lendo

ALM – Agilidade em Testes de Software – O que é ser Ágil? Parte 01 de 03

keep-calm-and-love-agil

Resolvi escrever esse post, depois que recebi um contato de uma amiga me pedindo se eu tinha materiais sobre Testes Ágeis. Então para deixar bem organizado, resolvi escrever um Post de 03 partes que, além de ajudar essa amiga, também deixar disponível caso alguém tenha interesse.

Primeiramente, antes de iniciar a leitura, gostaria de deixar claro que acredito particularmente que, todos os métodos, processos e frameworks são funcionais e bons, e tudo é questão de momento, tendências e realidades, conforme as necessidades de cada empresa e time. Que o objetivo desse post é apenas provocar uma reflexão sobre as tendências, se realmente temos o certo e errado dentro de processos e frameworks mundialmente utilizados e que tanto serviram a seus propósitos ao longo dos anos. E não sou um guru de testes ágeis, nem de DevOps, apenas estou expondo um pouco do que já vi e o conhecimento que tenho de ferramentas e processos.

Continuar lendo

ALM – Team Foundation Server Office Integration

Introdução

Esse artigo tem como finalidade auxiliar na instalação do pacote de integração para o Microsoft Office e o Team Foundation Server, substituindo assim, a necessidade da instalação do Team Explorer, quando o objetivo é o uso apenas do Microsoft Office para a conexão com Microsoft Excel com o Team Foundation Server, o uso do Powerpoint para a criação de Storyboards.

Passos

Faça o download do pacote nesse link.

image

Continuar lendo

ALM – Conhecendo um Pouco mais sobre ALM – Post 18 de 100 – Erro ao Carregar um Template de Processo no TFS 2015 – VS402357: You cannot override a Deployment template

Introdução

Esse artigo tem como finalidade auxiliar quando você enfrenta um problema de mensagem VS402357 ao carregar um Process Template no seu Team Foundation Server.

Cuidados no Carregar um Process Template

Sempre temos que cuidar ao usar um Process Template customizado, principalmente quando realizamos atualizações do Team Foundation Server. Sempre que você for realizar uma atualização em seu Servidor TFS, deixe seu ultimo Process Template carregado em alguma Collection, pois todas as alterações que o TFS fizer, seu Process Template também será beneficiado, facilitando assim a gestão.

Mensagem de Exceção

Ao tentar carregar um Process Template, a seguinte mensagem poderá aparecer para você:

Exception Message: The remote server returned an error: (400) Bad Request. Response Status Message: VS402357: You cannot override a Deployment template of type…

image

image

Causa

Isso ocorre normalmente quando você tenta carregar um Process Template de versionamento anterior do Team Foundation Server para um Team Foundation Server atualizado.

Como Corrigir

O correto é refazer seu process template baseando-se na versão atual disponível no TFS, com a SCRUM ou CMMI, conforme seu tipo de Process Template, e não utilizar seu Process Template da versão anterior do TFS. Por isso o ideal é que se cuide para que você possua um Process Template customizado atual carregado no seu TFS, assim o mesmo estará versionado corretamente como exige o TFS.

Sendo assim você tem duas formas de solucionar o incidente:

1. – Realizar o download de sua ultima versão de Process Template disponivel no TFS, realizar as alterações necessárias, renomear o mesmo e realizar o Upload.

2. – Caso você não possua um Process Template atualizado, faça o download do Process Template padrão disponivel no TFS, em seguida faça todas as edições necessárias, versionamentos, renomeie o Process Template e pronto.

image

image

image

Observe o ID de versionamento do mesmo:

image

Pronto, depois é só realizar o upload novamente.

Maiores Informações

https://www.visualstudio.com/en-us/news/tfs2015-vs.aspx#proctemp

Conhecendo um Pouco mais sobre ALM – Post 11 de 100 – Process Template – Customizando seu Painel de Backlog – Adicionando Change Request

Introdução

Esse artigo tem como finalidade, explicar como você pode customizar seu Painel de Backlog, inserindo item na caixa de seleção suspensa, além do padrão como a opção de selecionar Feature ou Change Request para uma nova criação.

image

Requisitos

Visual Studio;

Permissão Project Admins no Team Foundation Server;

Visual Studio Team Foundation Server Power Tools;

Passos

Para customizar seu Backlog, você deverá editar o arquivo categories.xml de seu Template de Processo.

– Exporte o arquivo Categories.XML

Para isso, exporte o mesmo com o seguinte comando:

witadmin exportcategories /collection:http://servidortfs:8080/tfs/Collection /p:”teamproject” /f:”C:\WIT\Update4\Categories.xml”

image

– Edite o arquivo Categories.XML colocando o item adicional, no nosso caso “Change Request”.

image

image

Salve o arquivo.

– Importe o arquivo Categories.XML para seu Projeto novamente.

Para isso, impornte o mesmo com o seguinte comando:

witadmin importcategories /collection:http://servidortfs:8080/tfs/Collection /p:”teamproject” /f:”C:\WIT\Update4\Categories.xml”

image

Depois vá no Portal do TFS e tente abrir o Backlog. Observe que aparecerá o aviso TF400917: The current configuration is not valid for this feature. This feature cannot be used until you correct the configuration.

E nos detalhes, irá informar que o objeto não possui o elemento Microsoft.VSTS.Common.StackRank configurado.

image

Para resolver essa questão, abra a partir do seu Visual Studio o Work Item Change Request do Projeto em questão.

image

image

image

Coloque os valores:

Name:Stack Rank

Type: Double

Reference Name: Microsoft.VSTS.Common.StackRank

Help Text: Work first on item with lower-valued stack rank. Set in triage

Reportable: None

Em seguida clique em OK.

image

Depois salve o Work Item e pronto. Abra novamente a Web.

image

Maiores Informações

https://msdn.microsoft.com/en-us/library/ms243782.aspx

Conhecendo um Pouco mais sobre ALM – Post 10 de 100 – Process Template – Automatizando Preenchimento de Campos dos Work Items

Introdução

Esse artigo tem como finalidade demonstrar como automatizar preenchimento de campos de Work Items do Team Foundation Server, para que ao se mudar determinado estado de um Work Item, um determinado campo seja automaticamente preenchido facilitando o fluxo de trabalho dos times. Ou seja, customizar Fluxos de Processos (Workflow) conforme sua necessidade. Por exemplo, um campo de Horas Restantes (Remaining Work) de um Work Item, ser preenchido automaticamente, quando um estado é alterado pelo time.

Requisitos

Visual Studio Team Foundation Server Power Tools

Você pode realizar a edição diretamente no Servidor do Team Foundation Server (apenas aconselho em um Projeto de Homologação) ou em um arquivo de um processo salvo, para depois carregá-lo no TFS.

Exemplo de Customização de Workflow

Exemplo: Quando o campo “Reason” de um Work Item “Task” é alterado para um estado definido por você (por exemplo: Complete and Does Not Require Review/Test), o campo Remaining Work deve ser automaticamente preenchido com 0, pois, significa que o tempo restante de uma tarefa com a Reason alterada foi concluído.

Para isso, siga os passos:

Passo 1 – Escolhendo o local de alteração do Work Item (Arquivo ou Servidor)

Editando a partir de um Process Template customizado

– Faça o download do Process Template que você deseja alterar, por exemplo:

Do seu Visual Studio, vá em Settings, Team Project Collection e Process Template Manager.

 

image

image

Faça o download do seu processo e salve em um diretório.

image

Depois, abra o diretório salvo, e altere o nome dele.

image

image

Depois abra o XML Process Template e altere o nome do processo dentro do XML.

image

image

image

Salve o arquivo. Isso permitirá que você possa fazer o Upload desse Process Template sem conflitar com o Process Template padrão do TFS que possui o mesmo nome.

– Abra seu Visual Studio (depois de instalada a ferramenta Power Tools), vá em Tools –> Processor Editor –> Work Item Types –> Open Wit for File

image

Vá no seu Process Template editado e procure o Work Item (XML) que você deseja editar, no caso é a Tarefa (Task), então você deverá ir no diretório \WorkItem Tracking\TypeDefinitions

image

Editando a partir de um Process Template de Um Projeto Carregado

Você pode também editar diretamente no Projeto em funcionamento (aconselho a fazer em homologação). Para isso, vá em Tools –> Processor Editor –> Work Item Types –> Open Wit for Server

image

Escolha o Work Item Task.

image

Passo 2 – Editando o Workflow

No nosso exemplo, iremos preencher automaticamente o campo Remaining Work, então para podermos manipular ele, temos que identificar qual é seu Referency Name, para que no Workflow, utilizemos o mesmo para inserir dados no campo. Para isso, com o Work Item aberto, vá em “Fields” e procure o campo Remaining Work e dê um duplo clique nele.

image

Irá abrir uma janela com informações de definição do campo, observe que o nome de referência é “Microsoft.VSTS.Scheduling.RemainingWork”, ok, guarde esse dado.

image

Ainda dentro do Work Item Task, vá em Workflow, onde efetivamente é o local que desejamos mudar e procure na diagramação, onde está o fluxo de mudança (transição) do campo Reason.

image

Observe que o local no campo de transição, ao expandi-lo você verá as diversas transições disponíveis em Reason, e logo abaixo em Actions qual ação ele irá tomar em quais campos. Justamente nessa seção Actions, iremos inserir um novo campo para que o Workflow tome uma ação, quando alterado a Reason do Work Item. No nosso caso, queremos que ação executada de forma automática, seja a inserção de um dado no campo Remaining Work.

Então iremos inserir um novo campo (Field) em Actions, nessa caixa de Transição. Para isso, clique duas vezes na caixa de transição.

image

Vá na aba Fields, e clique em New.

image

Agora procure o campo Remaining Work da Tarefa em questão, como vimos o nome de referência é outro, Microsoft.VSTS.Scheduling.RemainingWork. Procure o mesmo e insira-o.

image

image

Agora iremos inserir uma Regra (Rules) nesse campo inserido. Para isso, ainda em Fields, clique Microsoft.VSTS.Scheduling.RemainingWork e clique em Edit.

image

Vá na aba Rules e clique em New:

image

Em seguida seleciona o tipo COPY, pois iremos pedir ao Workflow que copie um valor (sobrescrevendo) no campo Remaining Work quando alterarem a Reason da Task.

image

No caso, escolho de From: Value o Value 0, pois quero que quando uma Task esteja com sua razão alterada conforme a definição minha, o valor de tempo restante seja igual à 0, para que minha Task esteja preenchida corretamente e facilite a vida do time com processos morosos.

image

Pronto, salvo as alterações e realizo os testes.

Testando

Caso você tenha editado no arquivo, você deverá carregar seu Process Template e criar um novo projeto, ou sobrescrever (importar) seu Work Item para um Projeto em andamento (homologação) para testar.

Caso você tenha editado diretamente em um projeto de homologação, poderá validar na hora.

Veja o teste abaixo:

Criei uma Tarefa com as horas.

image

image

Assim que alterei sua Reason (seja por alteração automatico do estado para Closed) que alterou a Reason, meu Remaining Work ficou com o valor 0.

image

Maiores Informações

https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f

https://msdn.microsoft.com/en-us/library/ms243782.aspx

ALM – Conhecendo um Pouco mais sobre ALM – Post 03 de 100 – Estratégias de Branchs (TFVC)

Introdução

Esse artigo tem como finalidade auxiliar na estratégias de branchs no desenvolvimento de seus aplicativos.

Vocabulário

Development Branch: Alterações para a próxima versão.

Forward Integrate: Merge do “parent” das branches “childs”

Hotfix: Uma mudança para corrigir uma falha específica de cliente ou serviço

Main Branch: Junção das branches de de desenvolvimento e de release. Representa um estado estável do produto.

Release Branch: Uma ramificação de código isolada para preparação de uma nova liberação. Depois de liberada, torna-se apenas leitura para não ser mais alterada e representar o código final da Release em seu processo.

Release Vehicle: É a release que chega ao seu cliente.

Reverse Integrate (RI): Merge feito Child –> Parent

Service Pack (SP): Conjunto de hotfix e funcionalidades para aplicar em um produto de release anterior.

Estratégias de Branchs

O time de ALM (Rangers) criou um guia detalhado orientando em como realizar suas estratégias de Branchs como por exemplo:

Main Only – Sem branchs

image

Release Isolation – Branch simples

Essa estratégia de isolamento da main, permite o gerenciamento de Releases simultâneas.

image

Development Isolation – Desenvolvimento isolado da Main (depois feito o merge)

Essa estratégia de isolamento introduz um ou mais ramos de desenvolvimento da Main, o que possibilita o desenvolvimento simultâneo da próxima release, experimentos, ou correções de bugs em desenvolvimento isolado da branch principal.

image

Development and Release isolation – Desenvolvimento e Release isolados da Main (depois feito o merge)

Essa estratégia permite a união das estratégias de Release e Desenvolvimento, isolando cada um da Main.

image

Servicing and Release Isolation – Manutenção e Releases isolados

A estratégia de Manutenção e Release introduz ramos (branches) de manutenção, o que permite a manutenção simultânea e gerenciamento de correções de bugs e service packs.

image

Servicing, Hotfix and Release Isolation – Manutenção e Releases isolados com controle de Hotfixes

image

Feature Isolation – Branching de Feature

A estratégia de isolamento de Feature introduz um ou mais branches da main, permitindo o desenvolvimento simultâneo de recursos claramente definidos para o próximo lançamento.

image

Veja nos detalhes do Guia do ALM Rangers como utilizar cada estratégia, ou adequar a sua realidade de controle.

image