ALM – Quem São os ALM Rangers?

Introdução

O ALM Rangers são um grupo de especialistas que promovem a colaboração entre os grupos de produtos do Visual Studio, o Microsoft Services e a comunidade MVP (Microsoft Most Valuable Professional) publicando as melhores práticas, idéias, ferramentas, indicações de melhorias, ajudando toda a comunidade técnica.

image

Missão do ALM Rangers

Fornecer orientação profissional, experiência prática e soluções preenchendo lacunas para a comunidade ALM.

image

Integrantes do ALM Rangers

Clique aqui para conhecer os integrantes desse incrível time.

Papéis e Responsabilidades do ALM Rangers

O time do ALM Rangers é extremamente organizado, com papéis definidos, processos, responsabilidades e objetivos.

image

Conheça toda a estrutura clicando aqui.

image

image

Soluções, Guias e Ferramentas

Dos diversos trabalhos realizados pelo time, destacamos:

Guia Controle de Versão (Branching e Merging)

Ferramenta de Extração Efetiva de Permissão do Team Foundation Server

Guia – Configurando Códigos para Práticas de DevOps e ALM

Guia de Atualização do Team Foundation Server

Blog e Página

Conheça o Blog do Willy Schaub sobre o ALM Rangers e conheça também a página do Codeplex onde o material do ALM Rangers é divulgado.

ALM – Templates de Processos do Team Foundation Server

Introdução

O Team Foundation Server é uma ferramenta de SDLC (Software Development Life Cycle) utilizada para ajudar no gerenciamento do seu projeto de desenvolvimento de software e é parte integrante da solução de ALM (Application Lifecycle Management) da Microsoft.
Uma de suas diversas características e features é trazer definido alguns Templates de Processos de Desenvolvimento de Software baseados nas práticas de sucesso mais comuns do mercado para serem utilizadas, sendo possível customizá-las conforme sua necessidade.

Dentre os processos estão disponíveis:

– Visual Studio Scrum

– MSF for CMMI

– MSF for Agile

image

Que vem já no TFS e podem ser selecionados ao criar um Projeto.

image

Esses processos passam por atualizações e disponibilização de novas versões, que podem ser acompanhadas conforme a atualização do seu TFS.

Dicas

Para realizar alterações no seu processo, acesse esse link e siga os passos.

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

ALM – Teste Manager – Clonar ou Copiar?

Introdução

A ferramenta Test Manager trás um excelente recurso para facilitar o gerenciamento do seu Plano de Testes, a possibilidade de Clonar ou Copiar seu Caso de Testes, Suíte de Testes, e Plano de Testes, dando velocidade na criação de Casos de Testes.

Importante

– Se você trabalha dentro de uma mesma versão, com iterações ou sprints diferentes, tem todo o sentido você copiar ou adicionar um caso de teste com todos os seus itens atuais (Requisitos, Tasks de Tempo), pois faz parte da mesma versão, assim poupa-se trabalho de reescrever e realizar os links em cima de um requisito, e até criar tarefa, caso o seu processo permita “zerar” uma Tarefa de medição de tempo e reutilizar a mesma na próxima sprint ou Iteração dentro da mesma versão de produto.

– Se você trabalha em um nova versão, e deseja manter links com work items anteriores, inclusive requisitos, mas que não serão alterados, tem todo o sentido você criar uma suite dentro de um plano de testes, realizar um add de caso de teste e copiar esse caso de teste, pois irá gerar um caso de testes com os work items relacionados do antigo, mas que você poderá manter ou remover, sem afetar o origem.

– Se você trabalha em uma nova versão, e deseja apenas manter os passos e descrição do work item, sem o relacionamento com outros work items, tem todo o sentido você clonar o plano de testes diretamente, pois os casos e suites serão clonados, mas não terá link com requisitos anteriores, dando a você a possibilidade de realizar um link que um requisito novo versionado.

Cenários

Abaixo segue exemplo de cenários e qual a melhor forma de utilização:

Usar os mesmos Casos de Testes dentro do mesmo Plano em Suites de Testes Diferentes

Esse cenário você ganha velocidade, pois os Work Items, Links com Requisitos e Tarefas irão se manter, não sendo necessário escrever ou inserir novos dados.

Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, irá refletir no Caso de Teste origem.

image

image

image

Se você alterar o Work Item de qualquer uma das suites, irá refletir no outro Work Item. Veja como exemplo a alteração da prioridade do Work Item da cópia, e refletiu no original, ou seja, perde o histórico.

image

image

Usar os mesmos Casos de Testes de outras Iterações ou Plano de Testes em um Novo Plano ou Iteração

Esse cenário você ganha velocidade, pois os Work Items, Links com Requisitos e Tarefas irão se manter, não sendo necessário escrever ou inserir novos dados.

Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, irá refletir no Caso de Teste origem. Você mantém a relação com o Requisito Primário.

Criar uma suite, pesquisar os Work Items e Adicionar os Casos de Testes.

image

image

Usar os Dados (inclusive links) de um Casos de Testes de outras Iterações ou Plano de Testes em um Novo Plano ou Iteração mas como um Novo Caso de Teste

Esse cenário você ganha velocidade, pois os Work Items, Descrição e Links irão se manter, não sendo necessário escrever ou inserir novos dados.

Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, não irá refletir no Caso de Teste origem. Você mantém ou não a relação com o Requisito Primário.

Criar uma Suite, pesquisar os Work Items e Copiar o Caso de Teste

image

Nesse cenário, você irá Criar um Novo Caso de Teste e ele levará os Work Items do Caso de Testes Original. Nesse caso você poderá alterar o Caso de Testes e remover os Links que não irá alterar o Caso de Teste origem.

image

Veja, foi removido o link Requirement do novo Caso de Teste.

image

E no original ainda mantém.

image

Usar apenas os Dados (Passos e Descrição do Caso de Teste) de um Casos de Testes de outras Iterações ou Plano de Testes em um Novo Plano ou Iteração mas como um Novo Caso de Teste

Esse cenário você ganha velocidade, pois a Descrição e Passos do Teste irá se manter, sendo necessário realizar o link novamente com Tarefas e Requisitos, por exemplo.

Obs.: Se você alterar o Caso de Testes copiado, sendo na descrição ou links, não irá refletir no Caso de Teste origem. Você deve criar uma nova relação com o novo Requisito (nova versão).

image

image

image

Ou seja, você pode usar qualquer técnica, porém precisa se atendar aos detalhes nas alterações e rastreabilidade.

Alan Carlos

Exames Microsoft Online

Artigo Original TechNet, clique aqui.

 

Olá Comunidade TechNet Wiki! Hoje é terça-feira, dia de Artigo Spotlight!

E o artigo destaque vai para:

Como Agendar um Exame – Person VUE
Autor: Alan Nascimento Carlos

Esse artigo explica, passo a passo, como realizar um agendamento de um exame de certificação no novo sistema da Microsoft com a Person VUE.

E o motivo desse destaque é que anunciamos que a partir de hoje (16/12/2014) já é possível realizar os exames da Microsoft de sua casa!

Isso mesmo, a Microsoft lançou na data de hoje a possibilidade de realizar os exames de certificação remotamente. Para saber os detalhes, clique aqui.

Requisitos:

– Conta da Microsoft (Live, Hotmail, etc.);
– Acesso a Internet;
– Webcam;
– Documento oficial com foto (identidade, passaporte, carteira de motorista);
– Adobe Flash Player 10.1;
– Adobe AIR 14.0;
– Internet Explorer 9 ou superior;
– Windows 7, 8 e 8.1 (XP, Mac OSX, Windows Starter não são suportados).

Acesse ainda hoje o site e agende seu exame, se precisa estudar, acesse o site do MVA (Microsoft Virtual Academy), Portal do TechNet Wiki e Microsoft Curah! que possuem material de qualidade para ajudar você a fazer parte desse time! Se ainda tem dúvidas, acesse esse link aqui e veja os benefícios de ser um profissional certificado.

Até a próxima!

Alan Carlos
TechNet Wiki Ninja

ALM – Testes – Abordagens de Testes de Software

Introdução

Atualmente em desenvolvimento de software, possuimos diversas abordagens de processos, conforme a realidade da empresa, funcionários e necessidades. Sendo que cada modelo se adequa ao negócio, ficando a cargo dos envolvidos entenderem se há necessidade de mudanças ou não, conforme seus projetos, planejamentos e cenários.

Nesse artigo são destacados algumas das diversas abordagens, na parte de Testes de Software, para conhecermos e entendermos um pouco mais de cada uma. Cada abordagem aqui possui seu valor e objetivo, conforme a realidade da empresa que a utiliza.

Abordagens de Testes

Testes Analíticos

Características

– Testes são uma atividade técnica e rigorosa;

– Testes são um branch da ciência da computação e matemática;

– Software é um artefato lógico;

– Teste é uma ciência baseada em Computação e Matemática: Objetivo, rigoroso e compreensivo;

– Técnicas de testes devem ser objetivas: apenas uma resposta certa;

– Teste é uma atividade técnica;

Empresas que utilizam

– Indústrias de Telecom;

– Sistemas Críticos (Aviões, Navios, Medicina);

Instituições Divulgadoras

– Academias

Técnicas de Testes

Testes de Caixa Branca;

– Testes estruturais;

– Testes de cobertura de código.

Testes Convencionais

Características

– Testes gerenciados: Previsível, repetível, planejado;

– Testes valida o produto;

– Testes medem o progresso do desenvolvimento;

Empresas que utilizam

– Enterprise IT;

– Desenvolvimento para Governo.

Instituições Divulgadoras

– IEEE Standards Boards

– Instituições certificadoras de Teste: ISTQB, ALATS, entre outras.

Técnicas de Testes

– Matriz de Rastreabilidade (Identifica se todos os requisitos foram testados);

– V-Model

image

Testes Baseados em Quality Assurance

Características

– Disciplinado;

– Testes determina se o processo de desenvolvimento está sendo seguido;

– Cada bug é um problema de processo;

– Testadores devem proteger os usuários dos software ruins;

– O software não está pronto até que o QA (Controle de Qualidade de Software) concorde;

– Testes é o ponto de partida para a Melhoria do Processo;

Empresas que utilizam

– Organizações sob leis e obrigatoriedades

Instituições Divulgadoras

– American Society for Quality (ASQ);

– Software Engineering Institute (CMM);

– International Standards Organization (ISO);

Técnicas de Testes

– Testes baseados em processos;

– Suites de Testes definidas conforme as normas instituidas;

– Validação por um time de QA que identifica se os processos foram finalizados;

Testes Dirigidos ao Contexto

Características

– Teste deve encontrar bugs;

– Teste provê informações para o projeto;

– Teste é uma atividade mental que requer habilidade;

– Teste é multidisciplinar;

– O valor de qualquer prática depende de seu contexto;

– . Existem boas práticas em determinado contexto, mas não existem melhores práticas;

– As pessoas, trabalhando em conjunto, são a parte mais importante do contexto de qualquer projeto;

– Projetos se desdobram ao longo do tempo de maneiras normalmente imprevisíveis;

– O produto é uma solução. Se o problema não foi resolvido, então o produto não funciona;

– O bom teste de software é um processo intelectual desafiador;

– Somente por meio de julgamento e habilidade, realizados cooperativamente ao longo de todo projeto, somos capazes de fazer as coisas certas nos momentos certos para testar nossos produtos de forma efetiva.

Empresas que utilizam

– Software Comerciais;

– Market-driven Software (Software dirigido ao Mercado)

Instituições Divulgadoras

– LAWST Workshops;

– Los Altos Workshop on Software Testing;

– StarEast/StarWest

Técnicas de Testes

– Testes Exploratórios (Exploratory Testing);

– Execução e Design feitos de forma concorrente;

– Aprendizado Rápido (Rapid learning);

– Execução baseada em Missão e Estratégias;

– Difícil Gerenciamento;

– Preparado para mudanças. Adapta o planejamento dos testes baseado nos resultados;

– Efetividade das estratégias são verificadas colocando-as em prática;

– Pesquisas de testes requerem estudos empíricos e psicológicos

– Foco na habilidade ao invés da prática/método;

Testes Ágeis

Características

– Testes mostram que uma história está completa;

– Testes devem ser automatizados;

– Desenvolvedores devem fornecer frameworks para automação dos testes

Empresas que utilizam

– Consultorias

Instituições Divulgadoras

– Agile Workshops

Técnicas de Testes

– Testes Unitários;

– Test-Driven Development (TDD);

Ferramentas para Testes de Software

A Microsoft disponibiliza atualmente uma solução completa para auxiliar os times de testes das empresas, independente da abordagem utilizada. O Visual Studio ALM, permite que suas soluções se adequem a necessidade do cliente, não sendo necessario o cliente se adaptar a ferramenta.

Desde Templates de Processos prontos como SCRUM, CMMI, até a possibilidade de customizações fáceis nos processos para atender o fluxo de trabalho do cliente.

Destaque para as ferramentas de Testes de Software como:

Microsoft Test Manager: Solução de gerenciamento de Testes de Software, com gestão de Casos de Testes, Record & Play, coleta automática de informação de ambiente, entre outras características.

Microsoft Azure: O Azure integra-se com as tecnologias locais da Microsoft, de modo que você pode tirar vantagem completa do seu conhecimento, habilidades e investimentos existentes da Microsoft, e usar um desenvolvimento comum e uma estrutura de teste que abrange desde o datacenter até a nuvem. Tudo no Azure pode ser totalmente automatizado, então você pode realizar spin up e desmontar ambientes virtuais com um pressionamento de tecla. E graças à funcionalidade de escala do Azure, é possível fornecer capacidade adicional sob demanda e com custo reduzido, para projetos de curto prazo e iniciativas com prazo maior

App Insights: É uma ferramenta de análise de aplicações Web e Móveis que tem como objetivo ajudar o desenvolvedor a monitorar suas aplicações, independente de onde estejam instaladas, como celulares, tablets, televisores, servidores, em qualquer parte do mundo. Com essa poderosa ferramenta, você poderá avaliar como seu aplicativo está se comportando nos tablets espalhados pelo mundo, quais as funcionalidades mais usadas, quais as funcionalidades menos usadas, quais os navegadores mais utilizados para acessarem sua aplicação, entre outros recursos.

ALM – Fluxos de Processos do Team Foundantion Server – CMMI – Escalando uma Solicitação de Mudança

Introdução

Imagine um cenário onde um stakeholder solicitou uma mudança (Change Request), porém essa solicitação de mudança não recebeu a devida atenção que merece. Você precisa escalar a solicitação de mudança. Como proceder?

image

Fluxo de Trabalho

Crie um item de trabalho do tipo Issue.

image

image

Vincular como Relacionado essa Issue na Change Request.

image

Escale essa Issue para colocar a solicitação de mudança de volta no caminho certo.

image

ALM – Criando um Requisito de Desenvolvimento de Software no TFS

Introdução

No contexto de construção de uma aplicação, requisitos são a expressão do que a aplicação deve fazer e o que é esperado dela em momento de execução. Um requisito pode ser entendido como a descrição do comportamento de um sistema, por exemplo, em uma aplicação de comércio eletrônico teríamos um requisito definido “durante a visita de um usuário ao site, o site deve apresentar uma série de sugestões de produtos em conformidade com comportamento de compra do mesmo”.

Gerenciamento de Requisito

O gerenciamento de requisitos é a prática de documentar e manter a rastreabilidade dos requisitos ao longo do ciclo de vida da aplicação. Dentro do gerenciamento de requisitos temos algumas ações:

– Documentar os requisitos funcionais e não-funcionais;

– Identificar se os requisitos estão aderentes com as necessidades de negócio;

– Priorizar os requisitos;

– Selecionar os requisitos que serão implementados no projeto ou em fase específica;

–  Identificar a dependência entre os requisitos;

– Mapear os requisitos com a arquitetura;

– Mapear os requisitos com as funcionalidades da aplicação;

– Verificar se os requisitos foram atendidos e estão em conformidade com as necessidades dos usuários.

O que é um Work Item Requirement no TFS?

Esse Work Item pode ser utilizado para representar as funcionalidades do software. Podem representar um Use Case, um requisito funcional, requisito não funcional, um item do Cenário, etc. Embora o nome do Work Item seja Requirement, este Work Item não é utilizado para representar apenas requisitos.

Segundo MSF CMMI: Representa a descrição do que sua aplicação deveria ou deve fazer para resolver o problema ou necessidade do cliente. (Fonte: http://msdn.microsoft.com/en-us/library/bb668962.aspx)

Criando um Requisito no Team Foundation Server

image

Tipos de Requisitos:

Feature: Será utilizado para agrupar Tasks que implementarão uma nova característica no produto;

Functional: Será utilizado para agrupar Tasks que implementarão uma funcionalidade no produto;

Interface: Será utilizado para agrupar Tasks que implementarão a criação ou alteração de interface;

Operational: Especificação de características relacionadas com o processamento do software, tais como: volume, frequência, disponibilidade, performance, localização física, etc;

Quality of Service: Para uma aplicação, oferecer seus serviços com qualidade significa atender as expectativas do usuário em termos do tempo de resposta e da qualidade, muitas vezes subjetiva, do serviço que esta sendo provido, ou seja, processamento completo de um documento, recebendo uma integração sem interrupção devido a uma falha na comunicação ou erro no arquivo. Fonte: (https://www.rnp.br/noticias/2003/not-031017b-coord.html). Representa uma exigência restritiva como o sistema deve trabalhar. (http://msdn.microsoft.com/en-us/library/bb668962.aspx)

Safety: Segurança. Este tipo é aplicável como um requisito não-funcional à ações feitas para evitar perdas de dados em caso de algum acidente;

Scenario: Representa uma simples interação com o usuário através do software. Pode representar um Use Case;

Security: Representa a segurança do software, como controle de acesso via senhas, permissões de usuários, acesso restrito a módulos avançados do software, etc.

Associações no Requisito:

Um requisito deve agrupar:

– Tarefas de Desenvolvimento (que irão refletir em tempo, o custo de um requisito)

– Tarefas de Testes (que irão refletir em tempo, o custo de um requisito)

– Casos de Testes (que irão refletir em qualidade um requisito)

Vá em My Work –> Available Work Items –> New –> Requirement

image

Para escrever o título do Requisito, você poderá usar diversas formas e técnicas, conforme sua abordagem de desenvolvimento, um exemplo seria:

image

Caso tenha dúvidas, acesse os links abaixo:

http://msdn.microsoft.com/en-us/library/bb668962.aspx

http://msdn.microsoft.com/en-us/library/dd997574.aspx

Guia de Gerenciamento de Requisitos ALM Rangers

Defina o título, tipo do requisito, descrição, telas de protótipo, triagem, e os demais campos conforme sua necessidade.

image

Esse requisito deverá conter:

– Tarefas de Desenvolvimento e Testes, inclusive com os tempos estimados com Child.

image

image

– Test Case como Tested By, para o vinculo dos BUGS em aberto.

image

Depois, quando as tarefas estiverem sendo executadas e os tempos alterados, você poderá acompanhar nos relatórios de requisitos. Veja um exemplo abaixo:

image

image