Olá Pessoal!
Em nossa empresa, estamos tendo que pensar num padrão de precodimentos de realização de testes de software. Precisávamos de uma metodologia ou padrão que nos ajudassem a identificar o máximo(se possível TODOS) os erros de sistemas(de desenvolvimento).
Estava dando uma olhada na norma IEEE 829. Elé é tido como referência no mercado? As fábricas de software costumam se basear nesta norma?
Saudações e Obrigado,
Bruno Giminiani
Metodologia você poderia ver a TDD, que é totalmente orientada a testes. A norma será um padrão e vinda do IEEE claro que é referencia forte no mercado (pelo menos ao meu ver).
Dá uma olhada nesses links, pode ajudar a esclarecer um pouco mais sobre a norma:
Além de TDD, seria legal fazer refatoração e usar testes unitários - no começo, parece que só serve pra travar, mas depois de um tempo você vê como é bom usar.
Abraço.
[quote=Giminiani] Olá Pessoal!
Em nossa empresa, estamos tendo que pensar num padrão de precodimentos de realização de testes de software. Precisávamos de uma metodologia ou padrão que nos ajudassem a identificar o máximo(se possível TODOS) os erros de sistemas(de desenvolvimento).
Estava dando uma olhada na norma IEEE 829. Elé é tido como referência no mercado? As fábricas de software costumam se basear nesta norma?
Saudações e Obrigado,
Bruno Giminiani[/quote]
Erros vc sempre vai encontrar. Agora, uma coisa é vc comparar a resposta do software com o que foi especificado para o desenvolvedor, outra coisa é comparar a resposta do software com o que o cliente espera.
Vc pode procurar todos os erros usando metodos formais: ja adianto que é uma forma um tanto cara e demorada.
Vc pode procurar boa parte dos erros trabalhando com metricas do tipo:
- cobertura de código
- ciclos de teste unitario e funcional
- lead time
A verdade é que existem muitas formas de fazer isso e vc deve encontrar a melhor para a sua realidade. Projetar um Device Drive é totalmente diferente de um sistema Web e, ainda assim, existem muitas formas de aplicar TDD ou BDD, por exemplo. Vc vai usar integração continua? Como planeja o ciclo de refactory?
Por exemplo, o IEEE 892 especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento. O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.
Para mim, documentação nesse nivel pode representar “eu vou tirar o meu da reta pois o erro é de fulano”. Boa sorte na sua empreitada
[quote=Giminiani] Olá Pessoal!
Em nossa empresa, estamos tendo que pensar num padrão de precodimentos de realização de testes de software. Precisávamos de uma metodologia ou padrão que nos ajudassem a identificar o máximo(se possível TODOS) os erros de sistemas(de desenvolvimento).
Estava dando uma olhada na norma IEEE 829. Elé é tido como referência no mercado? As fábricas de software costumam se basear nesta norma?
Saudações e Obrigado,
Bruno Giminiani[/quote]
Estou desenvolvendo um projeto para implementação de uma equipe de testes na empresa que trabalho. A empresa é pequena mas será tudo bem organizado. Se quiser posso lhe enviar algum material ou links pra pesquisa.
Ana Paula, poderia me enviar esses materiais ?
Estou comecando com testes, e gostaria de criar toda documentação para nao me perder futuramente.
Obrigado
[quote=juliofreitas]Ana Paula, poderia me enviar esses materiais ?
Estou comecando com testes, e gostaria de criar toda documentação para nao me perder futuramente.
Obrigado[/quote]
Julio
Me parece que essa não é uma boa abordagem. Sugiro que não foque na
documentação como base.
A prática é que deveria ditar quais registros se tornam necessários para
apoiar o trabalho, e não o contrário. Na medida em que vc avançar na prática,
vai conseguir perceber o que é importante e o que é acessório.
Normas de documentação / prescrição de artefatos não dão subsídio para
essa análise crítica. Sem ela, há o perigo real e imediato de querer ficar
"aderente" às “melhores práticas” (note as aspas).
Espero ter ajudado,
Jorge Diz
Obrigado Ana Paula!!!
Certo Jorge. Farei mais a parte prática e futuramente verei o que é necessário documentar.
Abraço!
[quote=peczenyj]
Por exemplo, o IEEE 892 especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento. O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.
Para mim, documentação nesse nivel pode representar “eu vou tirar o meu da reta pois o erro é de fulano”. Boa sorte na sua empreitada[/quote]
+1
A chance desse nível de documentação gerar mais ruído que sinal é grande.
Infelizmente, a política em muitas organizações é gerar ruído para desviar a atenção, e não
apenas em organizações de software. Processos na justiça são um (mau) exemplo.
Quanto mais transparente a organização, mais claros, concisos e desfulanizados
são os registros feitos.
Jorge Diz
[quote=Giminiani] Olá Pessoal!
Estava dando uma olhada na norma IEEE 829. Elé é tido como referência no mercado? As fábricas de software costumam se basear nesta norma?
Saudações e Obrigado,
Bruno Giminiani[/quote]
Bruno:
Sim, é uma referência importante.
E, por favor, não use esse palavrão (f******* de software).
Pode haver crianças acessando o fórum. Troque pelo
eufemismo “pastelaria”, por exemplo.
[]s
Jorge Diz