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!





O valor de uma vírgula

5 08 2010

Este não será um post de minha autoria, mas poderia ter sido, rsrs. Explico: sabe quando você lê alguma coisa e pensa: “Poxa, por que não pensei nisso antes???” O texto do Edwagney, fala sobre a qualidade dos textos na descrição dos requisitos de um software. E isso tem tudo a ver comigo por dois motivos: trabalho com qualidade e sou estudante do curso de  letras (inglês), e por isso também me preocupo muito com o modo de como os requisitos e casos de uso são escritos, se estão transmitindo corretamente a informação. Gostei muito do texto e gostaria de compartilhar com meus leitores. Espero que gostem!

===================================================

Caros amigos.

Ao contrário do que muitos pensam, Qualidade de Software vai além da investigação e busca por defeitos em umsoftware. Ela começa na fase de levantamento de requisitos.

De forma análoga, imagine quando você vai comprar um carro. Quais requisitos você pede? o que o carro precisa ter para que você se sinta bem ao comprá-lo? Em software é a mesma coisa… Requisito é aquilo que o cliente deseja receber quando o software ficar pronto. E a qualidade desse software será avaliada pelo cliente, ou seja, estou feliz com o que recebi?

Tá, mas o que isso tem a ver com o título desse post?

Tudo que fazemos surge de um desejo. Depois materializamos esse desejo. Em um projeto de software essa materialização começa na transposição do desejo para o papel e é nesse ponto que os defeitos começam a ser introduzidos nele. Portanto, qualidade de software está intimamente ligado à qualidade do texto que escrevemos para tornar nosso desejo em realidade.

Hoje recebi um e-mail de uma amiga sobre o uso da vírgula. E isso me deu a idéia de levantar uma questão importantíssima e que, sob meu ponto de vista, vejo cada vez mais sendo colocado de lado por muitos profissionais. O Português!

Não existe mais, ou não pode mais existir aquele pensamento de que pessoas ligadas às áreas de exatas não ligarem muito para o Português. Aquele pensamento de que, “isso pra mim não é importante, preciso apenas escrever códigos e fazer o software funcionar.” Esse é um pensamento retrógrado e arcaico. Ou você acha que para escrever um e-mail não precisa conhecer regras de português? Acha que todos os e-mails que escreve pode usar “vc” ao invés de “você”. Pode usar “naum” ao invés de “não”? Pior ainda e é aí que quero chegar, uso davírgulaconcordância.

Não é raro pegar documentos de requisitos onde o uso incorreto da vírgula muda completamente o sentido do texto. E isso para a materialização do desejo, é um tremendo erro que certamente se tornará um defeito grave no futuro, caso não seja identificado nas fases iniciais de um projeto de software.

Portanto, profissionais de qualidade, antes de estudarem técnicas e mais técnicas, irem atrás de certificações, etc, pensem em como está o nível do Português. Pensem na forma como estão escrevendo. Ao contrário do que muitos pensam, muita gente escreve textos gigantescos sem nenhuma, isso mesmo, nenhuma pontuação. Não precisa muito esforço. E-mails é o meio mais comum de disseminação dessa prática. Será preguiça de quem escreve? Talvez seja, mas que é ruim e doído de ler, isso é.

Certa vez, em um dos fóruns que participo, tivemos uma discussão acerca desse assunto. Para minha surpresa, um dos integrantes justificou que grande parte dos participantes eram estagiários e que erros desse nível era normal ocorrer, pois estavam aprendendo. Achei engraçado e ao mesmo tempo entrei em pânico, pois se eram estagiários, obviamente estavam em alguma faculdade. Ora, pelo que eu sei, a disciplina que mais pesa em um vestibular é o? PORTUGUÊS!!! Aeee!!! (mas pelo visto não era o caso deles).

Outro ponto levantado foi a justificativa de que existe muita literatura em Inglês e isso faz com que o Portuguêsfique de lado. Mais um motivo para entrar em total desespero. Quer dizer que se eu aprender o Inglês, devo esquecer meu idioma nativo? E se eu aprender outro idioma, devo esquecer o Inglês? Uma lógica um tanto quanto estranha…

Para aprendermos um outro idioma, necessariamente espera-se que pelo menos o SEU idioma seja dominado. Você fala e estuda ele desde que nasceu e TEMOBRIGAÇÃO de saber lerfalarescrever muito bem.

Peço por gentileza em nome de todos os profissionais, que como eu, gostam de ler bons textos. NÃO DETURPEM A LÍNGUA PORTUGUESA. Mesmo conhecendo “n” outros idiomas, moramos no Brasil, trabalhamos no Brasil, fazemos projetos no Brasil, isso por si só nos dá subsídio mais do que o suficiente para saber que, PRECISAMOSDEVEMOS saber falar e escrever BEM o nosso rico e belo Português Brasileiro.

E para discontrair um pouco e refletirmos um pouco mais sobre o poder que tem uma vírgula. Dêem uma olhada abaixo:

1. Vírgula pode ser uma pausa… ou não.
– Não, espere.
– Não espere.

2. Ela pode sumir com seu dinheiro.
– 23,4.
– 2,34.

3. Pode criar heróis..
– Isso só, ele resolve.
– Isso só ele resolve.

4. Ela pode ser a solução.
– Vamos perder, nada foi resolvido.
– Vamos perder nada, foi resolvido.

5. A vírgula muda uma opinião.
– Não queremos saber.
– Não, queremos saber.

6. A vírgula pode condenar ou salvar.
– Não tenha clemência!
– Não, tenha clemência!

E por fim, como prêmio aos que conseguiram chegar ao final desse texto… Onde você colocaria a vírgula no texto abaixo?

SE O HOMEM SOUBESSE O VALOR QUE TEM A MULHER ANDARIA DE QUATRO À SUA PROCURA.

Aguardo o resultado nos comentários.

Abraços e até a próxima!!!





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?





SCRUM ou CMMI? Temos mesmo que escolher?

8 09 2009

Recebi este link para uma ótima palestra sobre Scrum e CMMI, ministrada pelo professor Dr. Marcello Thirry, para os alunos da Unisul Virtual.

Vale a pena ver e rever várias vezes!

http://unisul.streambrasil.com/ONDEMAND-UV/unisul_sv_030909.html

Abraços

Fernanda





Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste

10 04 2009

Atualmente, a maioria das empresas de software enfrenta problemas relacionados à necessidade de melhorar a
qualidade do produto e a satisfação do cliente mantendo custo baixo e cumprindo prazos. O artigo anexo relata a
experiência de uma organização que utiliza a análise dos indicadores de teste como ferramenta para a melhoria
do processo de desenvolvimento e a garantia da qualidade do produto.

Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste





Um conto… nada real

11 03 2009

Inicio minhas atividades neste blog com um conto de autoria de um autor renomado na área de testes no Brasil: Leonardo Molinari.
Emprestei o seu último livro pro meu estagiário, e ele me veio com este conto, trocando os nomes dos personagens. Qualquer semelhança com nomes e acontecimentos, É SIM, mera coincidência. A coincidência maior foi eu ter assistido o filme Tropa de Elite no final de semana passado. Tomei a liberdade de fazer umas adaptações pra tornar o texto mais parecido com o filme que deu base ao conto.
O que tem haver com testes afinal? Bom, esta é a maneira incorreta de tratar qualquer pessoa da sua equipe, seja ela seu testador ou o desenvolvedor. E eu sou muito agradecida por não trabalhar num ambiente assim. Ao contrário: aqui testadores e analistas fazem parte da mesma equipe, e trabalham em conjunto para um objetivo maior: entregarmos um software com qualidade de acordo com os requisitos do nosso cliente.
Deliciem-se com a paródia, e sejam bem-vindos a nova casa!

Conto tecnológico: Tropa de Testadores de Elite

Há muito tempo, numa empresa muito, muito distante… Existia um grupo diferente de testadores que passavam intermináveis horas descobrindo bugs.
– Seu incompetente! Burro! Estúpido! Se você descobriu uma falha no programa de faturamento, mostra o bug na cara deles. Quero ver os desenvolvedores encararem mais essa! Nunca serão!!!
– Mas chefe…
– “Chefe” é o Cacilda!! Eu sou a analista aqui @#%¨$#@! Testador burro! Sou analista Fernanda e quem manda nessa porra aqui sou eu.
– Sim chefe! Digo, sim senhora! Sim, analista Fernanda!

Ao falar e ainda tremendo, o jovem testador Márcio levantou-se e fez um leve sinal de reverência. A sanguinária Analista Fernanda fez um sinal de aprovação.
– Testador Márcio, o senhor está vendo o que está escrito na porta?
– Sim, senhora! Sim, analista Fernanda!
– E o que está escrito ali?
– BATE!

Neste momento, antes que o indefeso testador pudesse se defender, a analista levantou-se e deu-lhe um tapa na cara, daqueles de impor respeito até em mulher de malandro. Abalado, o testador não sabia o que fazer, além de sentir seu rosto formigar. Nesse momento o relógio marcava 18:00 em ponto.
– Burro! Pronuncia-se assim: Batalhão de Testadores Especiais, o “BATE”. Aprendeu idiota?
– Sim, senhora! Sim, analista Fernanda! (o medo da demissão era maior do que a revolta pelo tapa na cara, pois Márcio era novo e tinha casado há pouco mais de 15 dias.)
– Mostre-me o relatório de erros que você aprontou – disse a analista Fernanda com sangue nos olhos.
– Sim, senhora! Sim, analista Fernanda! Aqui está!

Nesse momento o franzino testador não conseguia parar de tremer. Fernanda analisou o relatório sem piscar, sua face demonstrava ira. Foi ai que o testador ficou confuso com uma cena bizarra que os seus olhos deslumbravam. Nesse momento a analista estava sorrindo. A analista ainda sorrindo pergunta:
– Quem fez esse programa?
Esperando ser castigado o testador responde:
– Foi… foi o Luiz – um programador novo que se aventurava o pouco na empresa.

– Acompanha-me até a sala de programação onde os desenvolvedores se amontoam – falou em voz alta a analista Fernanda.
– Sim, senhora! Sim, analista Fernanda!

Em pouco tempo estavam face a face com o desenvolvedor Luiz. Este que não sabia que seu fim poderia estar muito perto.

– Luiz, olhe para mim – disse Fernanda – Foi você que fez essa P@#$#*? – Falou apontando para o relatório onde estava o nome do programa com o bug.

– Você Luiz, você não é um programador. Você é um moleque. Você é um fanfarrão! – Finalizando a frase com um belo tapa na cara.

– Sim senhora, lá no Acre é comum ficar o dia todo na floresta tirando leite do pau e desenvolvendo assim. Mas qual é? Qual o pepino?

Nesse momento incrivelmente não se escuta nenhum passarinho cantando e com a rapidez de uma lebre a analista pegou o programador pelo colarinho, deu-lhe três tapas na cara o imobilizando. Seus olhos enchem de lágrimas, sua boca fica seca, ele até tenta reagir, mas o medo o deixa paralisado a beira dos portões do inferno e de cara a cara com o próprio diabo. Ele tentou reagir, mas Fernanda o pegou pelo pulso de forma que nada pudesse fazer. Ele chegou a contorcer de dor.
– Onde está o bug seu filho da #$%@#*&¨? Fala desgraçado!
Fernanda era violência pura. Nada a detinha.
– Não sei, não sei… ai ai ai ai… Eu não sei, eu juro!! Dizia Luiz.
– Você sabe sim, seu canalha! Diga-me ou você vai apanhar mais… Márcio, trás o saco! Trás o cabo de vassoura!!!

Em poucos segundos, como passe de mágica, o programador quase sem forças informa onde está o bug.
– Tá bom eu sei… Me larga, mas não bate na cara, na cara não! Por favor, na cara não…

A analista agora agarrada nos cabelos do pobre coitado fala:
– Tá vendo esse relatório de bugs? Vocês é que financiam essa merda, é por causa de programadores que nem você que a empresa perde dinheiro.

Fernanda ainda com as mãos nos cabelos do acreano, puxa sua cabeça em sentido ao seu joelho e mancha sua calça holandesa com sangue mortal.
– Isso é para você aprender a fazer um programa decente. Desgraçado… Você tem meia hora pra colocar o código novo consertado em produção, ou então: Pede pra sair! Pede pra sair!

Não se precisa dizer mais nada. No dia seguinte estava tudo 100%.

O fato é que o analista estava treinando vários testadores novos para atuarem no BATE. Eles eram uma tropa de testadores de elite que merecia respeito. O quente não eram seus métodos de descobrir bugs. O quente eram seus métodos de resolução de bugs. A analista estava velha e ia se aposentar em 3 meses. Precisava achar alguém que ficasse em seu lugar. Ela viu em Márcio um forte candidato, pois se parecia com ela há alguns anos atrás.

O treinamento era exaustivo. Fernanda indicava o livro de testes ou qualidade que deveria ser lido de um dia para o outro, e cuja série de perguntas (ou problemas) iriam ser respondidas no dia seguinte. Era na realidade um teste por dia. Quem não lia não tinha chance alguma: ou era demitido sumariamente e se não passasse no teste era também demitido. Cerca de 50% da turma foi eliminada de cara. Eram livros em inglês, em espanhol e em português. Cada um com 300 páginas ou mais. Pauleira diária. Eles sempre gritavam todos juntos ao final de cada dia, tal como um hino:

– Bug bom é bug morto! Desenvolvedor bom é desenvolvedor sem bug!

Sempre uma vez por semana eles faziam testes reais e tinham de descobrir bugs. Eles foram devido a pressão se tornando opressores dos bugs. Uma fúria indomável surgia dentro de cada um quando descobriam um bug. Alguém tinha de pagar por aquilo.

O problema é Márcio se tornou uma cópia da analista Fernanda. Márcio se tornou mais que a Fernanda era: era tão violento e medonho quanto Fernanda, porém era mais sórdido. Começou a manipular os colegas e quem não era testador em sua visão era em pouco tempo demitido.

Márcio passou a querer mais e mais. “Fernanda tinha de ser eliminada” pensou ele.

Quinze dias da aposentadoria, Márcio mostrou um vídeo gravado por uma câmera de bolso para o diretor da empresa, ao mesmo tempo em que ele tinha descoberto vários podres do diretor. Não restava dúvida: Analista Fernanda foi demitida por justa causa. Márcio ficou em seu lugar.

Algum tempo depois quando um novo testador iniciou na empresa, Márcio se apresentou:
– Aqui meu filho é o BATE: Batalhão de testadores especiais. Aqui nesta sala quem manda é eu. Se você não entendeu é BURRO. Aqui é uma cova de leões. Matamos um leão por dia aqui. Aqui não há testadores, o que existe são sobreviventes. Boa Sorte. Eu sou o Testador Márcio. Escutou?

Caro Leitor, vejamos a não-qualidade apresentada:
1- trate todos com respeito;
2- desenvolvedor não é criminoso. Aparecer um bug não é ato de delito;
3- não adianta empurrar conhecimento goela abaixo. Ninguém é máquina. Cada um tem um modo de assimilação;
4- melhorar a qualidade de um código é muito mais que testar;
5- sempre existirá pressão no trabalho, mas alguns profissionais exageram e passa a ser uma pressão psicológica terrível. Tudo é um equilíbrio.

Texto original:
MOLINARI, Leornardo. Testes Funcionais de Software. Florianópolis: Visual Books, 2008. p166-169

Também em:
http://diariodaqualidade.blogspot.com/2007/10/contos-tecnolgicos-de-qualidade-08.html

Edição: testador Márcio e Robson B.