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!





Lançamento do TDC Florianópolis 2010

28 10 2010

Neste ano, o TDC Florianópolis, repetindo o imenso sucesso do TDC São Paulo, traz um modelo bastante diferenciado dos anos anteriores, organizado por trilhas, e com palestras específicas por tecnologia. A inscrição é realizada por trilha com um custo extremamente acessível.

Trilhas Stadium

As trilhas Stadium Sábado e Stadium Domingo não são restritas a um tema específico e apresentam uma grade diferenciada com apresentações de diversos temas como Arduino, Spring, Mobile, Ruby, SOA, PHP e Testes, realizando uma forte integração entre as comunidades.

Inscrições

programação está disponível e as inscrições já estão abertas.





Portal do Software Público e a qualidade de software

12 02 2010

Hoje estava dando uma re-lida em um fórum sobre teste de software que assino, e encontrei um post da Érika Hmeljevski, diretora reginal da ALATS em SC, falando sobre o Portal do Software Público. Até tuitei os links, mas resolvi colar o texto de apresentação do portal aqui no blog, até como um registro e acesso mais fácil do que as centenas de emails do fórum.

Chamo a atenção para o módulo específico sobre Teste de Software. É como se fosse um “guia dos primeiros passos” sobre a importância dos testes na qualidade do desenvolvimento de um software. Algumas páginas ainda estão em construção, mas tudo está aberto a colaboração da comunidade! Vamos começar a ajudar também???

Abaixo segue o texto descritivo sobre o Portal.

Todos os participantes do Portal do Software Público ganharam um ambiente dedicado ao tema de qualidade de Software. O espaço é composto inicialmente por 6 vetores: Ecossistema, Qualidade do Produto, Desenvolvimento de Software, Interoperabilidade, Prestadores de Serviço e Teste de Software. Os participantes do Portal SPB podem se cadastrar direto no ambiente com seu usuário e senha, pelo endereço http://www.softwarepublico.gov.br/5cqualibr/register/user-join

O ambiente foi apresentado durante a reunião de Coordenação do Portal do Software Público na cidade de Brasília no início de dezembro. O segundo grupo de Interesse do Portal SPB foi batizado de 5CQualiBr: conhecimento, comunidade, colaboração, compartilhamento e confiança para qualidade do software público brasileiro. O 5CQualiBr será coordenado pelo Centro de Tecnologia da Informação Renato Archer-CTI, com sede na cidade de Campinas. O principal objetivo do grupo de interesse será disponibilizar conteúdos para melhorar a qualidade do software brasileiro.

A intenção da coordenação do 5CQualiBr será de garantir a interação dos usuários em torno do tema, acrescentar novos conteúdos periodicamente e estimular o debate sobre qualidade de software no país. Os conteúdos serão disponibilizados em modelos de licenças livres e grande parte do material poderá ser acessado abertamente.

O Portal 5CQualiBr é um dos produtos do Modelo de Qualidade do Software Público Brasileiro, projeto em vigência desde o final de 2008, que conta com recursos da FINEP-Financiadora de Estudos e Projetos e com apoio da Secretaria de Política de Informática-SEPIN, do Ministério da Ciência e Tecnologia.

Trata-se do segundo grupo de interesse criado no ecossistema do software público. O primeiro foi dedicado aos municípios brasileiros: o 4CMBr. Que pode ser acessado pelo endereço http://www.softwarepublico.gov.br/4cmbr/register/user-join





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?





Testes Tradicionais e Testes Ágeis

14 04 2009

Como trabalho atualmente com desenvolvimento de software utilizando uma metodologia ágil, nada mais justo que falar sobre testes ágeis. Bom, retirei do blog do meu colega Abu, este post, que de certa forma, é dedicado a ele, pois é por causa dele que hoje entendo um pouco mais sobre metodologias ágeis de desenvolvimento. Aqui está na íntegra, o post dele, do dia 30-10-2008.

Este post traz uma visão do Teste de Software realizado de maneira Tradicional e de maneira Ágil.

O texto traz partes retiradas do artigo Agile QA/Testing de Elisabeth Hendrickson, mas este post não tem o objetivo de ser uma tradução do artigo. Seguindo esta visão o texto possui contribuições minhas e da Neilza. Temos também o vídeo da apresentação da Elisabeth, que é indiscutivelmente uma das melhores apresentações que eu já assisti sobre teste de software.

Link do PDF original: http://testobsessed.com/wordpress/wp-content/uploads/2006/11/agiletesting-talk-nov2006.pdf

Teste de software de maneira Tradicional

Nós não vivemos no mundo perfeito onde os requisitos levantados no início do projeto não vão mudar, e o entendimento desses requisitos será possível junto com a tarefa de seu levantamento.

No mundo perfeito o processo levantamento de requisitos, design, codificação e testes será feito uma única vez, pois nesta única execução ele já vai ser realizado de maneira correta.

O teste de software executado de maneira tradicional irá realizar o teste após o término da análise, design e codificação, e os erros encontrados serão entradas do processo de análise, onde o analista de sistemas realiza a validação do erro encontrado pela equipe de testes e após o trabalho do analista de sistemas, é executado o processo de maneira seqüencial, isto é, design, codificação e teste novamente (figura 1).

Um problema que ocorre na não existência de um mundo perfeito é que os cronogramas de projetos não comportam o processo de análise, design, codificação e teste mais que uma vez.

Quando esse processo é executado mais de uma vez, acarreta em impactos nos cronogramas e consequentemente na tríplice restrição: Escopo, tempo e custo, que traz impacto direto na qualidade.

fig1

Na falta do mundo perfeito os gerentes do projeto na hora de estabilizar o cronograma realizam cortes de tempo, o que acarreta em impacto na qualidade (tríplice restrição), assim o primeiro tempo a ser cortado é o tempo dos testes de software (figura 2).

Como software nada mais é que algoritmo implementado, o tempo de codificação é sempre protegido o máximo possível, sem código implementado não existe teste e é nessa visão de execução que o teste é punido.

fig2

Testes Ágeis

Para a implementação de técnicas ágeis no ambiente de testes, temos a necessidade de mudar a maneira que as equipes estão acostumadas a trabalhar. Uma das mudanças necessárias é a introdução ao conceito de colaboração com o cliente, ao invés de se utilizar documentação abrangente, este item faz parte do manifesto ágil. Desta maneira passamos a fazer um trabalho mais próximo com o cliente, onde a sua participação no processo é peça chave para que a técnica ágil de testes possa ser adotada. Outro ponto importante é que todos da equipe devem realizar testes e não apenas o analista de testes. Em ágil nós falamos que a equipe é infectada por testes e desta maneira o sistema é construído para estar testado desde o início do projeto e não apenas no fim da codificação.

A qualidade passa a ser da equipe e não apenas dos analistas de testes ou profissionais que possuem a palavra “Qualidade” nos seus cargos.

O projeto que nasce com cobertura de teste desde início permite Teste de Regressão, que é executar testes em todo o sistema e não apenas na funcionalidade implementada.

Ter um sistema com cobertura de testes desde o início, é realizar o máximo possível de uma cobertura automatizada de testes, para que o trabalho manual e repetitivo não venha a ocorrer.

Esta técnica traz ganho de tempo na execução do teste, onde o custo de transformar um caso de teste em automatizado rapidamente se paga. Eu tenho observado em minhas equipes um custo de 30% a mais na execução e transformação do teste em automatizado, mas após a terceira vez que eu executo a bateria de testes, eu já vejo como este custo de 30% saiu barato.

O tempo de execução do automatizado com relação ao manual é incomparável, os ganhos de velocidade de execução e a possibilidade de a qualquer momento realizar um teste de regressão são maiores.

Os testes de maneira ágil devem seguir o conceito de pequenas interações, para que a informação de retorno como está sendo construído o sistema e os erros que existem sejam rapidamente identificados e corrigidos. O término de uma interação deve ter todos os testes executados com êxito (figura 3).

fig3

Os desenvolvedores e os testadores devem fazer parte de uma mesma equipe, para que exista colaboração e comunicação entre eles. Assim conseguiremos criar o conceito de equipe e poderemos realizar a condução dos testes e do desenvolvimento do sistema como uma única equipe, isto é, todos juntos, onde os acompanhamentos da execução do desenvolvimento e da execução de testes estão sincronizados, e estes profissionais acompanham a execução, falha e status de ok do código validado pelos testes.

É uma mudança de paradigma, mas é uma mudança que trás resultados rápidos e perceptíveis.

Abraços, Abu e Neilza.

Fernanda