Verificação e validação nos modelos de melhoria de processo

28 02 2014

Em setembro do ano passado, “nasceu” um filho querido, metaforicamente falando. Meu artigo de conclusão da pós em Qualidade e engenharia de software foi publicado em uma revista nacional, a Engenharia de software, da Devmedia.

Este artigo apresenta a análise dos processos de verificação e validação, realizada numa instituição de pesquisa, desenvolvimento e inovação da região de Florianópolis, utilizando-se o mapeamento proposto pelo modelo de referência de processo de verificação e validação alinhado ao CMMI, MPS.BR e à norma ISO/IEC 15504. O resultado dessa análise é apresentado e melhorias no processo são propostas para implementação de V&V (verificação e validação) na instituição. Este artigo visa auxiliar as empresas a analisarem seus processos com vista a melhorias das práticas de verificação e validação que estejam em consonância com as normas e modelos de melhoria atualmente exigidos pelo mercado (CMMI, MPS.BR e à norma ISO/IEC 15504).

Mas por que eu o chamo de filho? Porque levei 9 meses para deixá-lo maduro o suficiente para que fosse publicado. O assunto abordado tem pouca aplicação no mercado, apenas empresas que buscam ou já possuem certificação realizam esses processos e por isso é um tema pouco discutido, se compararmos com testes de sistema (exploratórios ou automatizados). Mas nem por isso são de menor importância. Eu, particularmente, já peguei vários casos de uso mal escritos, sem regras de negócio, só com regras de tela. Na hora de testar você acaba levantando tantas perguntas que o analista se vê obrigado a refazer o caso de uso (retrabalho 1) e sobra pro desenvolvedor fazê-lo novamente (retrabalho 2). Esse é só um exemplo curto onde se vê que há 2 retrabalhos, que poderiam ter sido evitados caso houvesse uma etapa de revisão entre a especificação e o desenvolvimento. E todo mundo já sabe, quanto mais retrabalho, maior vai ficando o custo do projeto.

Quer saber mais? Acesse: http://www.devmedia.com.br/vv-nos-modelos-cmmi-mps-br-e-iso-iec/28937#ixzz2ue7MnTEA

Até mais! Vejo você no TDCFloripa 2014!

Já adiantando o próximo post: Submissão de Palestras TDC2014 Florianópolis





2011 chegou!

5 02 2011

O ano passou rápido demais e 2011 está chegando na mesma velocidade. Janeiro acabou, as férias acabaram e o mundo parece voltar a girar a mil por hora novamente. O tempo agora é artigo de luxo para alguns. Eu mesma queria ter um dia com mais de 24 horas para poder fazer tudo que preciso. Junto com as horas a mais preciso de energia também, ninguém é de ferro.

Mas 2010 acabou e minha retrospectiva é muito boa: novo emprego, novos projetos, desenvolvimento profissional em foco, novas oportunidades bateram a minha porta e foram todas muito bem-vindas. Só faltou tempo para este blog :). Mas isso vai mudar!!! Siiiiiim, quero muito e vou arrumar tempo pra tratar ele com carinho e aos pouquinhos vou compartilhar minhas impressões sobre qualidade de software novamente por aqui.

Por enquanto passei por aqui pra dizer que estou viva e antenada nos outros blogs sobre qualidade (olhe os links ao lado).

Até mais e um ótimo 2011!





Fundamentos do Teste de Software

28 09 2009

Há algum tempo venho pensando em escrever algo mais fundamentado aqui no blog. Hoje parei pra pensar, arrumei um tempo e resolvi falar sobre o capítulo 1 do Foundation Level Syllabus, material base pra certificação do ISTQB e BSTQB. É quase um resumão, às vezes com algumas considerações minhas imbutidas conforme minha experiência na área.

Este capítulo fala sobre os Fundamentos do Teste de Software.

Erro ao tentar finalizar uma transação importante!

Erro ao tentar finalizar uma transação importante!

Muitas pessoas devem se perguntar por que se faz necessário testes em software. Ora, devemos levar em consideração o contexto de cada software em desenvolvimento. Atualmente todos temos acesso a diferentes softwares diariamente. Em menor ou maior grau de dificuldade de uso, como por exemplo, aplicações bancárias, sejam elas acessadas pela web, celular ou caixa eletrônico. Você poderia imaginar o desastre se essas aplicações não fossem muito bem testadas? Você se sentiria seguro em realizar uma transação pela web? Bom, eu com certeza não. Outra aplicação que nos serve como exemplo, é o nosso querido Gmail. Bom, eu não vivo mais sem ele, e diferentemente do sistema bancário, eu não me preocupo muito em perder informações ali contidas (minha opinião tá, tem gente que tem muita coisa armazenada ali!!). Uma outra aplicação que considero importante de ser testada, são os sistemas de lojas e supermercados. Até hoje eu tenho o hábito de verificar os valores dos itens que estou comprando, porque não me sinto segura no sistema de barramento x valor do produto. Enfim, ema ema ema, cada um com seus problemas!! Esses exemplos servem pra mostrar que softwares que não funcionam corretamente podem trazer diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam.

Algumas causas dos problemas de software podem ser causadas por erros (enganos) humanos. O erro gera um defeito (bug) no software. E esse bug, gera uma falha no sistema. É atrás dessa falha que os testadores correm atrás (imaginei uma corrida de cachorros, onde eles correm em busca de um coelho, ou A recompensa).

Testadores atrás de um bug

Testadores atrás de um bug

Falhas podem ocorrer também, por eventos externos ao software, como quedas de luz, radiação, calor, poluição, campos magnéticos ou eletrônicos. Conheço um caso onde os servidores ficavam na mesma sala com 8 desenvolvedores, onde o ar condicionado no verão mal dava pra refrescar as pessoas. A temperatura da sala girava em torno dos 24 graus diariamente. Resultado disso: queda frequente do sistema, devido ao aquecimento das máquinas no ambiente.

Os testes têm funções específicas em cada fase do desenvolvimento e manutenção do software, e servem para reduzir os riscos de ocorrências de problemas no ambiente operacional, quando os defeitos encontrados são corrigidos em fase anterior a implantação na produção.

Qualidade em software implica em testes em todas as fases do desenvolvimento, desde o planejamento, através de testes na documentação, até a fase final do aceite do cliente. O teste ajuda a medir a qualidade em termos de defeitos encontrados por características e requisitos funcionais ou não funcionais do sistema. Os resultados da execução dos testes bem projetados pode representar a confiabilidade do software, quando poucos são os erros encontrados ou quando os mesmos são encontrados e corrigidos de forma efetiva.

Testes finalizados!

Testes finalizados!

E a pergunta que não quer calar é: quando devemos parar com os testes?

Bom, não se tem uma resposta padrão pra essa pergunta, porque tudo depende de cada projeto. Diversos são os fatores que podem definir quando parar-se de testar, como por exemplo: prazo, orçamento e riscos. É nesse sentido que os testes devem trazer informações suficientes para a tomada de decisão pelos stakeholders. Seus interesses são fundamentados nas limitações do projeto e, acredito eu, no grau de maturidade e qualidade do software desenvolvido. Para isso é que temos as versões beta, não é mesmo?





Celebrar!!

9 07 2009

Esses últimos dias têm sido muito especiais pra mim, por dois motivos:celebrar

1. Terminei meu MBA em Teste de Software, agora sou oficialmente uma especialista na área.

2. Sou caloura novamente!!! Passei no vestibular da UFSC! U-hu!!! Temos que comemorar!!! Quer saber mais? Visite o outro blog.

Bom, dá pra ver que não vou parar de estudar tão cedo, mas as próximas metas são as certificações brasileira e internacional. Ninguém me segura!!!

Prometo atualizar mais vezes e começar a divulgar o blog também.