The Developer’s Conference

Pessoal,

Gostaria de alertar a comunidade para um grande evento a ser realizado em Goiânia no final do mês de outubro de 2011.
O objetivo desse post é divulgar o evento e também convidar os senhores para minha apresentação no dia 29/10/2011, Sábado. Eu irei falar sobre o Team Foundation Server e especificamente sobre a customização dos templates utilizados pela ferramenta. Esse template pode ser customizado e este será o objetivo da minha apresentação mostrar como a ferramenta é flexível e pode ser utilizada para diversos ambientes de desenvolvimento independente da plataforma utilizada. Não deixe de conferir na trilha .NET a palestra:

14:10 às 15:00 Customizando templates de projetos (MSF, CMMI, Scrum) do Team Fountation Server para adaptação ao processo de desenvolvimento de software.
José Lino Neto (Pensou.NET)

O TDC é um evento muito maior e possui trilhas em diversos segmentos e diferentes plataformas, então não deixe de conferir tudo que o evento vai oferecer e participe.

Esse link é para conferir as trilhas que vão ocorrer:
http://www.thedevelopersconference.com.br/tdc/2011/index.html#goiania

Esse link é para a agenda da trilha de .Net o qual estou envolvido:
http://www.thedevelopersconference.com.br/tdc/2011/goiania/trilha-dot-net#programacao

Lembrando que o TDC é um evento que aconteceu em outras cidades do país e agora chegou em Goiânia, então não fique de fora desse mega evento. Confira esses outros links algumas fotos, vídeos que rolaram em outras cidades:
http://www.thedevelopersconference.com.br/tdc/2011/florianopolis/fotos
http://www.thedevelopersconference.com.br/tdc/2011/saopaulo/videos/

Para fazer sua inscrição acesse esse outro link, no entanto como participante tenho uma entrada para ser presenteada a algum amigo ou cliente, logo me enviem um email até o dia 23 de Outubro que irei sortear entre os interessados. Não percam tempo.

#TDC2011 – Participem!
 The Developers Conference 2011, um evento organizado pela Globalcode

Customizar Work Item Template

Em um post anterior ( http://wp.me/pOqhK-2I2 ) comentei sobre o uso do TFS Power Tools. Essa ferramenta dentre suas várias utilidades tem uma interface para customização de um arquivo XML o qual é utilizado pelo servidor TFS para o template dos work itens utilizados no controle de atividades de uma equipe.

A instalação padrão do TFS vem com dois templates: MSF Agile e CMMI. O guia de ambos podem ser encontrados em:

MSF for Agile Software Development Process Guidance

MSF for CMMI Process Improvement Guidance

Veja o fluxo de ambos em:

http://msmvps.com/blogs/vstsblog/archive/2009/01/09/workflows-of-msf-agile-and-cmmi-process-templates-for-tfs.aspx

Outro processo agora oficial da Microsoft e não da comunidade como versão anteriores do TFS é o template para SCRUM. O mesmo pode ser baixado pelo link a seguir:

http://visualstudiogallery.msdn.microsoft.com/59ac03e3-df99-4776-be39-1917cbfc5d8e

No entanto o TFS é uma ferramenta e as ferramentas devem se adaptar ao processo da organização e não o contrário. Termos, o fluxo da atividade e o padrão de um novo projeto devem seguir o padrão e processo da organização.

Como então personalizar um desses templates ou então criar um novo para atender a essa adaptação ao processo?

Customizar o template. Podemos fazer isso manualmente editando o arquivo xml (grande esforço) ou visualmente através TFS Power Tools instalado.

Capturar
Imagem 01: Interface do TFS power tools para edição do processo.

Podemos ainda customizar os campos que existem em uma atividade. O exemplo a seguir mostra criando um novo campo em um item de bug. Estou por exemplo criando um campo que é o número de chamado utilizado pela equipe do suporte.

Capturar
Imagem 02: Novo Campo Número Chamado.

Podemos também personalizar o desing dos itens de tarefa.

Capturar
Imagem 03: Layout do work item com o recem criado campo e também a tradução do nome da tarefa:

Outra capacidade é mudar a estrutura dos diretórios e bibliotecas a serem criadas no projeto de Sharepoint criado.

Capturar
Imagem 04: Bibliotecas e Diretórios para o Sharepoint

A essa estrutura do Sharepoint podemos anexar documentos de texto, planilhas, apresentações e qualquer tipo de documento de exemplo ou templates a serem utilizados no projeto. Ou seja, da mesma forma que mudamos a estrutura e nomes de diretórios podemos colocar arquivos no interior desses diretórios.

Podemos controlar os relatórios padrões a serem criados no início de um projeto.

Capturar
Imagem 05: Relatórios

Outra várias opções estão disponíveis como o processo a ser utilizado na Build, configuração de grupos e permissões e também integração com os campos do MS Project.

Depois de terminado podemos importar o nosso novo template ao servidor e criar um novo projeto de acordo com as nossas recém-personalizações.

Capturar
Imagem 06: Novo modelo processo.

Novo work item no visual studio e também no team web acess

CapturarCapturar
Imagem 07: Novo Work Item no Visual Studio e Team Web Acess

Capturar
Imagem 08: Sharepoint e a estrutura de acordo com o template

Espero que esses exemplo inspirem a personalização da ferramenta e adaptação ao processo de cada organização.

Espero o feedback dos leitores.

Abraço

Lino

Execução de testes manuais com o Test Manager 2010.

Durante o ciclo de vida de desenvolvimento de uma aplicação deparamos com a fase de testes. Um teste a ser realizado pelos analistas é o Teste Manual.

O teste manual é elaborado a partir do roteiro de testes. Artefato produzido a partir do caso de uso e tem como objetivo validar o fluxo princial e os fluxos alternativos do caso de uso.

Durante a execução do teste manual evidências precisam ser geradas em casos de sucesso e também durante as falhas para auxiliar o desenvolvedor na correção do erro.

O Test Manager 2010 é um produto inovador presente nas versões Ultimate do Visual Studio 2010 e na versão Test Professional 2010. Com uma interface rica e bem elaborada centraliza as atividades dos analistas de testes em uma ferramenta poderosa e cheia de recursos.

Vamos a alguns exemplos:

1- Elaboração do Test Case (Work Item do TFS)  com os passos a serem validados durante o teste manual. Observem o resultado esperado que irá servir de informação ao analista durante a execução do teste manual:

Capturar

2- Execução do teste manual com o analista tendo do lado esquerdo o test manager em formato reduzido para validar os passos criados anteriormente e a aplicação a direita. Os passos realizados durante a execução do teste podem ser gravados e com isso depois serem reproduzidos ou utilizados para geração de código para automação de testes.

Capturar

Vamos a imagem anteior:

  • Onde temos um check verde sinalizado como aprovado. O mesmo foi marcado como tal manualmente pelo analista de teste conforme o passo era satisfatório.
  • Observe o arquivo *.png anexo ao roteiro. O mesmo é o resultado de uma captura da tela feita pela própria ferramenta da aplicação para uso como evidência.
  • Uma nota com comentários foi colocada para exemplo de mensagens que podem ser criadas pelos analistas de teste.
  • Caso algum erro fosse encontrado pela própria ferramanta poderiamos criar um work item no TFS de Bug para o desenvolvedor responsável e todas as evidências coletadas e os passos com sucesso e erros seriam anexados ao novo work item para o desenvolvedor receber o maior número de informações para analisar e corrigir o erro.
  • Um arquivo de log com as configurações de máquina, sobre o sitema operacional, browser e etc onde o teste foi executado é anexado para informar o ambiente de teste.

3 – Abaixo a demonstração do relatório sobre a execução deste teste manual. E o anexo aberto com a evidência da imagem. Dentre os anexos temos um xml com as informações sobre a máquina.

Capturar

4 – Outro ponto interessante é que o teste manual pode ser executado novamente e esse histórico das execuções e resultados ficam armazenados.

Capturar

6 – Os passos que gravamos durante a execução do teste manual podemos utilizar ele como base para criação de Coded UI Tests no Visual Studio.

Capturar

Capturar

7- Alguns trechos de código gerado para automação do teste:

Método de teste:

[TestMethod]
public void CodedUITestMethod1()
{
this.UIMap.DigitarNome();
this.UIMap.DigitarEmail();
this.UIMap.Digitaremailformatoerrado();
this.UIMap.FinalizarTeste();
}

Código que automatiza a digitação do texto no campo de Email:

public void DigitarEmail()
{
HtmlEdit uIEmailEdit = this.UICreateInternetExplorWindow.UICreateDocument.UIEmailEdit;
// Type 'contato@joselino.net' in 'Email' text box
uIEmailEdit.Text = this.DigitarEmailParams.UIEmailEditText;
}

Field com o valor a ser inserido:

[GeneratedCode("Coded UITest Builder", "10.0.40219.1")]
public class DigitarEmailParams
{
#region Fields
///
<summary> /// Type 'contato@joselino.net' in 'Email' text box
/// </summary>
public string UIEmailEditText = "contato@joselino.net";
#endregion
}

Resumindo:
Criamos um item de tarefa que possui os passos a serem executados durante os testes manuais.

Com o Test Manager fomos testando os passos e validando se foram aprovados ou não e gerando evidências como imagens, informações sobre a máquina que executou o teste e mais comentários livres para os analistas de teste.

Temos um histórico sobre a execução do teste manual.

Automatizamos o teste manual reproduzindo os passos que o analista fez manualmente e geramos código desses passos para modificações e reproduções dos testes durante a build por exemplo.

É isso aí pessoal vamos aos testes!

Lino

Team Foundation Server Power Tools–Windows Shell Extensions

Para quem está trabalhando com o TFS para controlar outros códigos fontes legados fica a dica para quem quiser utilizar o próprio Windows Explorer para controlar versão.

Sem a necessidade do Team Explorer do Visual Studio ou Team Explorer EveryWhere que roda no Eclipse:

O mesmo foi desenvolvido pelo próprio time de TFS da Microsoft e pode ser baixado em: http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx

Abaixo a imagem 01 mostrando controlando a versão pelo Windows Explorer:

imagem07
Imagem 01: Controle de versão pelo Windows Explorer. Saudades do SVN?

OBS: Team Foundation Server Power Tools possui diversas outras funcionalidades que ajudam bastante, vale a pena conferir, essa dica é apenas uma de suas opções. Aos poucos vamos falando de outras coisas.

Lino

Validar Arquitetura com MSBuild–TFS 2010

Conhecem o Layer Diagram?

imagem02
imagem 01: Criação de um novo diagrama de camadas.

Então sabem que ele valida sua arquitetura de acordo com o código fonte.

imagem01
imagem 02: Validação de arquitetura com o layer diagram.

E se o desenvolvedor comete algum erro que quebra a arquitetura, por falta de atenção, falta de experiência ou falta de conhecimento do uso da arquiteutra do projeto? Como se validar isso? O layer diagram pode ajudar bastante.

E que tal automatizar essa validação durante a build?

1- Habilite nas propriedade do projeto de arquitetura onde estão seus diagramas para o mesmo validar a arquitetura:

imagem03
imagem 03: Habilitar validação.

2- Depois nas configurações de sua Build no TFS é necessário adicionar o argumento a seguir para o MSBuild: /p:ValidateArchitectureOnBuild=true

imagem 04
imagem 04: argumento MSBuild.

Pronto.

Quando a próxima build for colocada para ser executada, seja manual, integração continua, Gated checkin ou agendada, a arquitetura vai ser validada e caso haja alguma falha de dependência vai gerar erro na build e um item de bug.

Na imagem 02 temos um arquitetura de exemplo em com a view chamando o négocio que chama a persistência, vamos intencionalmente fazer a view chamar a persistência, ou seja cometer um erro e gerar um erro de validação. A imagem 05 a seguir mostra o erro durante a validação:

imagem04
imagem 05: Validação com erro causado intencionalmente.

E agora os resultados da build mostrando os mesmos erros acima, mas agora sendo sinalizados duarante a execução de uma Build:

imagem06

Isso aí…

Comentem…

Lino