Quality Assurance in .NET

[Sidney Lima Filho]

Pessoal,

     estou incubido e ajudar a montar um projeto, aqui na empresa, de Q&A, eu sei que dentro do VSTS tem várias ferramentas para documentar os Test Cases e rodar acoplado com testes unitários inclusive, alguém tem alguma experiência com isso?


Sidney Lima Filho  ---------------------------------------------------------------------
Vivina Softhouse
(0xx21) 7867-2321
55*10*68934
http://www.vivina.com.br
http://twitter.com/sidneyfilho

[Giovanni Bassi]

Sidney,

Não tenho nenhum cliente usando os testes manuais do TFS 2008. No entanto, já andei testando as ferramentas de testes manuais e lab management do TFS 2010, e são uma grande evolução. Acho que vale a pena dar uma olhada.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/17 Sidney Lima Filho <sidney...@vivina.com.br>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Sidney Lima Filho]

GB,  
   eu já andei dando uma olhada sim no MTLM, achei muito interessante inclusive o como ele se integra no TFS, mas uma coisa é fazer testes outra é metodologia de como fazer, afinal o Tester pode testar uma Tela, como testar um WebService e ae começam os problemas pois independente de ferramenta tem que haver uma metodologia de como fazer, padrões de organização dos testes, COMO criar um teste, quais coisas a se pensar ao fazer um teste, etc.

Sidney Lima Filho  ---------------------------------------------------------------------
Vivina Softhouse
(0xx21) 7867-2321
55*10*68934
http://www.vivina.com.br
http://twitter.com/sidneyfilho

2009/12/19 Giovanni Bassi <gig...@giggio.net>

[Giovanni Bassi]

Sidney,

Testes de webservices podem ser feitos de forma automatizada, sem passar pela interface gráfica. Os testes de tela já podem ser automatizado com o VS e TFS + LM 2010.
Quanto à metodologia, sobre como fazer, organização, não acredito que vá encontrar isso pronto. Cada empresa tem uma maneira de trabalhar. Minha sugestão: em vez de tentar pensar tudo antes, vá evoluindo aos poucos, baby steps. Aprenda conforme evolui a idéia. Uma idéia seria primeiro integrar os testes unitários no ciclo de vida do seu desenvolvimento, com integração contínua. Seria o básico. A partir daí você poderia evoluir para testes integrados, testes funcionais, testes de aceitação, etc, mas somente quando o passo anterior estivesse satisfatório o suficiente.
Da mesma forma que não acredito em Big Design Up Front para a arquitetura, análise, documentação de projetos de software, não acredito em BDUF para implantação de uma metodologia, que pode até ser vista como um projeto, mas prefiro ver como algo que não tem fim, e que evolui constantemente.
Quanto a como criar um teste, para isso sim, há literatura. Eu mesmo já escrevi alguns artigos na .Net Mafazine, algumas coisas no blog, já publiquei algumas coisas de TDD, etc... Ainda assim, você vai ter que analisar e ver o que se encaixa melhor no seu cenário.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/12/19 Sidney Lima Filho <sidney...@vivina.com.br>

[Sidney Lima Filho]

Então você concorda comigo, pois eu penso a mesma coisa, na verdade quando eu propuz essa thread era justamente para ver as experiências das pessoas na implantação de algo desse tipo, claro que há diferenças culturais para cada empresa.

 

Com relação aos testes é isso mesmo, também acho que tem literatura de como fazer os testes, eu mesmo já escrevi sobre isso, mas pensei que encontraria alguém que já tivesse passado por isso.

[Eduardo Miranda]

Sidney,

 

Quanto a evoluir a metodologia e o processo gradativamente eu concordo 100% com o Giovanni.

 

Quanto a implementar testes unitários antes de qualquer outro tipo de teste, não acho que isto seja uma premissa. Estas práticas (unit tests e "testes de produto", ou todos os outros testes necessários para garantir a qualidaade do produto) podem ser complementares, mas definitivamente não são pré-requisitos. No seu caso vc já tem o apoio necessário para implementar uma área de QA. Vá em frente, busque os resultados mais rápido possível (conhecidos como "low hanging fruits") e mostre o quão importante é manter e crescer esta área.

 

Também te sugiro a NÃO estudar material sobre testes unitários para tentar depois transpor este conhecimento para outros testes. É lógico que é tudo teste e existe sim uma zona de interseção, mas por outro lado o contexto é diferente e nem todas a práticas que se aplicam a um contexto podem/devem ser utilizadas em outro. Portanto, acredito que é muito mais eficiente vc buscar informação/conhecimento específico da disciplina de testes. InfoQ tem alguns artigos, existem livros sobre o assunto, como o How we test at Microsoft e muitos outros.

 

Em termos práticos:

 

Evite o modelo clássico de tests scripts. Tanto no modelo "super-produtivo", usando ferramentas de gravação de testes, como na mais "refinada", com testers escrevendo-os manualmente. O custo de manutenção de testes é igual ou maior que o de código. Pense sempre em manutenibilidade.

 

O objetivo da área de testes é definir o nível de qualidade desejado para o produto (junto com os stakeholders) e medir e divulgar a qualidade real do produto ao longo do projeto. O objetivo não é: Achar o máximo de bugs, atrasar o lançamento do produto, irritar os desenvolvedores com bugs de corner case cenários :)

 

Divulge a sua área para a empresa e mostre que o seu objetivo é elevar a qualidade do produto E mantenha um bom relacionamento com desenvolvimento e todas as outras áreas envolvidas e impactadas pela sua (acredite vc vai impactar/incomodar muita gente).

 

Tem muito mais, mas chega, por agora. :)

[Sidney Lima Filho]

Eduardo,

 

   quanto a essas premissas que expos concordo plenamente, tanto que não busco uma metodologia de test script, mas por experiências de como funciona esse cenário de qualidade. Cenário de qualidade é exatamente o que falou, buscar atingir/cobrir as necessidades dos clientes e não achar bugs.

 

Eu também não estou preocupado em descobrir as melhores práticas de criar testes, nesse momento. Pois preciso antes fundamentar o como será essa área, aqui o desenvolvimento nem tem unit test, e se falar de DDD, vão me perguntar se podem jogar de mago. rsrsrs

 

Como qualidade é algo subjetivo, e metodologia de garantir a subjetividade é algo complexo e por isso não há formula mágica, gostei da idéia de low hanging fruits, aqui será muito útil.

Sidney Lima Filho  ---------------------------------------------------------------------
Vivina Softhouse
(0xx21) 7867-2321
55*10*68934
http://www.vivina.com.br
http://twitter.com/sidneyfilho

2009/12/21 Eduardo Miranda <dud...@gmail.com>

[Eduardo Miranda]

Pois preciso antes fundamentar o como será essa área, aqui o desenvolvimento nem tem unit test, e se falar de DDD, vão me perguntar se podem jogar de mago

 

Por isto que eu disse que colocar os unit tests como pré-requisito para outros testes seria um bom caminho para a curta existência desta nova área.

 

O que vc achar mais fácil? Convencer os desenvolvedores que eles precisam começar a fazer testes unitários, ensinar tudo o que é necessário e começar a conseguir resultados? Ou motivar um time novo a a testar a aplicação?

 

Quando ficar claro que existe um problema de qualidade, o time de desenvolvimento irá buscar maneiras de resolver isto e testes unitários podem ser uma das soluções.

 

Esqueci alguns pré-requisitos basais para vc sequer começar a testar:

 

- Um bom software de issue management

- Build automatizado

- Um processo formalizado de instalação (pode ser um instalador ou um manual, mas é necessário)

 

Sem isto vc vai perder muito tempo até começar a ser ouvido pelos desenvolvedores.

2009/12/22 Sidney Lima Filho <sidney...@vivina.com.br>