Post

1 Star2 Stars3 Stars4 Stars5 Stars

By Luiz Gustavo Schroeder Vieira Eu costumo sempre dizer que o radicalismo é sempre burro. Para se trabalhar com qualquer coisa, é sempre bom ter bom senso, principalmente na nossa área onde a oferta de aplicações para dar suporte ao desenvolvimento é sempre grande.O motivo pelo qual eu sempre bato de frente com os scrumaníacos é justamente pelo fato desse tipo de metodologia ser tão bom, que acabam achando que é a solução para todos os problemas, mas não é esse o foco da discussão.Hoje estou fazendo um trabalho de consultoria e fábrica de software num órgão público e devo elogiar a equipe deste órgão e da fábrica pois todos estão dispostos a fazer um bom trabalho, independente dos objetivos e interesses.O foco da questão é a estrutura de suporte dada aos Testes, achei bastante interessante a forma como chegamos ao resultado dessa consultoria. Basicamente eles possuem uma estrutura bastante organizada, baseada no Enterprise Architect. As fases de projeto são divididas em Concepção, Elaboração, Construção, Homologação e Implantação. Sendo que cada fase possui suas respectivas etapas, podendo citar: modelagem de casos de uso, plano de testes, diagramas de sequencia, diagramas de colaboração, protótipos de tela e afins.Dificilmente chego numa empresa e digo o que eles devem fazer. Eu apresento as sugestões e juntos, chegamos ao resultado mais apropriado. Toda proposta é acompanhada de um: “está OK para vocês trabalharem dessa forma?” O mais interessante é que às vezes o cliente se empolga com a solução/proposta e eu tenho a preocupação de entrar no detalhe, mostrar como vai ser trabalhar de tal forma no dia-dia. Faço isso pois às vezes eles confundem o “simples” com o “fácil”, e são abordagens COMPLETAMENTE diferentes. Por exemplo: em testes de regressão, para um sistema em funcionamento e homologado pelo cliente, criar um caso de teste baseado no sistema em funcionamento parece simples, mas ao se deparar com a quantidade de regras de negócio, requisitos funcionais e de interface, o cliente toma um “susto” com tal complexidade e solicita uma nova sugestão.No caso desse órgão, utilizamos o Enterprise Architect para centralizar as informações referentes aos requisitos (ele é realmente muito completo nesse sentido), um repositório conjunto para formalização das atas de reunião (pois as entregas da fábrica devem estar alinhadas com o edital), uma planilha volátil com o checklist padrão e específico de cada caso de uso, o Testlink para formalização do repositório dos checklists e cenários, versionamento e execução dos testes e um servidor de integração contínua com Hudson e Maven.Final do ano iremos confirmar o sucesso desse processo e farei um novo post relatando as alterações e ajustes no decorrer do processo.

Source: http://www.testavo.com.br/2012/09/a-importancia-de-uma-estrutura-de.html

Você também pode querer ler

Comments are off for this post.