segunda-feira, 26 de janeiro de 2009

O impacto do Erro de Escrita - Exemplo Real



Pessoal,


me perdoem mas todos podemos errar. Um livro, por mais revisões e capricho que se tenha, sempre terá erros. Um software sempre terá da mesma forma. O que quero dizer que temos que saber que erro sempre estará por aí, "esperando", mas isso não é motivo para desistirmos de fazer uma boa escrita.


Qual o impacto disso? Muito. Já vi muitas pessoas colocarem frases como:


"Que analista idiota! Nem sabe escrever. Como posso confiar nele?"

"Seu incompetênte! Fora da daqui e veja se aprende um pouco de português!"

"Você não disse que fez 5 anos de estudo de inglês? Como sabe escrever essa palavra?"

"Como vou ler uma revista que leva um mês para um fazer algo e ainda sai com erros extruxulos?"


Isso mesmo pessoal: o impacto total. A imagem e um trabalho tecnicamente ótimo, cai por terra. Sabe o que a constância do erro de lingua significa? Falta de capricho, cuidado, atenção. Falta de Qualidade.

Vejam, não estou aqui para cruzificar ou exaltar. Estou apenas analisando um fato com provas de coisas que vivi.

Hoje fui no site da revista online "paga", o que acho um absurdo, da Editora DevMedia: A Revista Engenharia de Software Magazine. Que já está no número 9. Parabéns aos Editores por acreditar. Porém...

Porém vários problemas que já constatados desde a primeira edição aparentemente continuam: tem se percebido que a maioria dos autores possuem mestrado (nada contra, diga-se aqui um elogio), mas falta-lhes experiência prática como demostra-se ao escrever. Sem constar alguns artigos que ficaram em muito a desejar.

Lembram da minha análise sobre o problema da revista de apagar comentários e querer passar uma imagem que estava tudo bem? A Revista tem qualidade, não desmereço em nada a mesma, mas os artigos sendo em sua maioria muito teóricos.

Um indicativo na tentativa que obter artigos com qualidade e didática é a atual promoção mesma: artefatos eletrônicos e os brindes p/ os melhores autores. Isso é bom, mas demostra um certo desespero, e isso me preocupa. Na minha avaliação, a revista deste tipo tinha de ser free 100%, no formato da STP Magazine. Sem contar com os videos e outras coisa que são pagas. Entendo que todos precisam sobreviver, mas o Google sobrevivendo e vencendo , mesmo na crise, a base de anúncios e outras fontes. Mas mesmo assim acredito que pode dar certo (e torço por isso), mas muita coisa tem de mudar. A primeira delas seria elevar o nível dos artigos. Em outras palavras: ou muda ou se muda. Senão mudar a revista deixará de existir, o que não é uma coisa boa para todos.

Me preocupa quando a mesma revista parece (posso estar errado em algo) relaxar na qualidade do texto. Vejam o resumo do conteúdo da Edição número 8 onde encontro os seguintes erros:

-título do artigo (em mais de uma parte da pagina) com erro. Erro péssimo.
-o uso do "por que" (era p/ ser "porque" junto, pois ser uma frase explicativa. erro de texto básico). Vejam um link explicativo sobre o uso dos "porquês". Cliquem Aqui. Este tipo de erro é uma coisa que se aprende na escola.
-os termos "WebServices" estão juntos. Errado: o certo seria (como está no título) "Web Services" ou "Web services" (duas palavras separadas).

Vejam as imagens




Ao navegar aleatoriamente pela lista de vídeos/palestras constato dois vídeos com a mesma descrição. Vejam imagem abaixo:




Ainda fiquei sabendo (aí me preocupa bastante) que está para acontecer , ainda não confirmado e não divulgado, o ESM Day (indica que seria assim: engenharia de software magazine day). Um evento de patrocinado pela Ed. DevMedia. Bom se for ter palestrantes de nível e conteúdo significativo, poderá então valer a pena. Mas se os palestrantes forem os mesmos profissionais que escrevem os artigos, me questiono se o evento será de qualidade ou se será um evento teórico e acadêmico... Torço para que tudo dê certo. Não adianta chamar um ou dois "medalhões", pois não é assim que a coisa se resolve. Vejam o evento BRATESTE da ALATS. Está dando show em termos de lista dos palestrantes. É a nata do Brasil com convidados da Europa. Maravilhoso.

O meu livro, Testes Funcionais de Software tem sido um grande sucesso e se tornou um marco? Sabem o motivo? Linguagem simples e direta aliada à técnica agregada a experiência real e significativa. O meu livro tem poucos e raros erros de língua, que estão sendo registrados p/ a devida correção na 2a edição, conforme eu os encontro. Mas o conteúdo sim, supera qualquer erro. É justamente isso que quero dizer: conteúdo real é a essência da Qualidade num texto técnico. A criatividade não tem limites, e é justamente isso que falta ser otimizado (ou libertado ou liberado) na revista em questão. Futuro tem. Falta ousadia e sinceridade e, sobretudo, transparência. Reconhecer os erros é a primeira delas. Torço de coração para que dê tudo certo.

Em meu blog agradeço sempre que me apontam erros. Humildemente agradeço.

Lembrando Barack Obama: Yes, we can. The change is here!

Abraços a todos e voltem sempre!!!


Leonardo Molinari
=======================================
http://diariodaqualidade.blogspot.com/

segunda-feira, 19 de janeiro de 2009

Mutation Testing - Testes de Mutação



Pessoal
,


existem várias maneira de explicar o que é Mutation Testing ou Testes de Mutação. É simples por mais que o título seja pomposo. Veja a apresentação abaixo (mais uma) que trouxe para todos.

Mutation Testing
View SlideShare presentation or Upload your own. (tags: leonardo molinari)



Espero que entendem e vamos discutir!!!

Ela parte do presuposto que o código será "mexido" por que testará, o que dependendo do caso não será possível. Mas é uma técnica válida e interessante, pois não é específica de teste funcional mas sendo portanto considerada uma técnica mixta.

Vejam e entendem galera!!!

ps: a imagem é do X-Men, mutante, chamado Wolverine...

Abraços a todos,

Leonardo Molinari
===================================
http://diariodaqualidade.blogspot.com/

Heróis da Qualidade - Orientação aos Testadores


Pessoal,



em 2007 escrevi um post comparando a queda (infeliz) do avião da TAM em SP a desastres numa aplicação web. Desastres esses que podem ser evitados se, e somente se, medidas de segurança forem sempre verificadas, que no caso de uma aplicação web seria equivalente a realizar testes antes, durante e depois que aplicação estivesse no ar.

Alguns não entenderam o post-artigo que coloquei, mas mesmo assim foi u post de grande sucesso aqui no blog.

Dei em 2007 uma palestra em 2007 baseada neste mesmo post. Novamente alguns não entenderem e questionaram a importância do que colocava.

Nos seminários que dei ao longo de 2008, aproveitei a essência do queria passar no post em questão: realizar testes é algo que deve ser feito sempre, ao mesmo tempo que o testador deve estudar sempre e estar sempre preparado com novas técnicas e saber usar as que conheçe, exercitando-as sempre, de modo a estar sempre preparado para quando o o "teste acontecer".

Semana passada, novamente uma acidente aereo veio realçar aquilo que falei desde o início da polêmica e que não etenderam (ou não quiseram entender): um avisão foi forçado a pousar no meio do Rio Hudson em Nova York, por conta das duas turbinas terem sido atingidas por uma leva de passaros. As duas (caso raro) foram em pleno voo inutilizadas, logo após 3 minutos o avião levantar voo do aeroporto de LaGuardia.

Por mais que o avião estivesse inteiro, os sistemas (mecanicos) terem sido testados quando o mesmo estava em terra (é um procedimento default, através de um check list), e computador central estivesse ok ainda em terra, qualquer sistema está sujeito a acidentes, que no caso foi por conta de um fator externo de raríssimo caso. Mesmo quando as turbinas são atingidas (em geral, mesmo sendo um caso raro) o mácimo que acontece é uma das pás da hélice da turbina é se quabrar e mesmo assim não compromete a estabilidade do avião. O que acontece é chegar no próximo aeroporto esta pá que está quebrada ser substituida. O que aconteceu é um caso quase impossível.

Mas o mundo é feito de coisas "impossíveis", que um dia se sonhou que era realmente impossível. Mas alguém disse que era possível...

Mas o que salvou o avião? O piloto, que havia se preparado, estudado, estudado, estudado, treinado, treinado, treinado, treinado, treinado, treinado (não é erro de digitação). A qualificação do piloto era adequada a situação e o perfil do mesmo e a tomada de decisões por parte dele na hora do pouso foi única mas se sabia era possível. Sim, o piloto foi um heroi. Nenhuma vitima foi feita. Todos sairam vivos, com saldo 2 pessoas com início de hipodermia (haviam caido no rio cujas aguas estava em torno de 2 graus Celsius) e 1 pessoa com um membro quebrado e varios com arranhões. Mas todos sairam vivos.

O verdadeiro herói, se prepara, se prepara, estuda, estuda, estuda, estuda, estuda e não para se preparar.

Por isso oriento e alerto que os especialistas em testes devem estar sempre em estudo constante, e nunca se esqueçer de exercitar "lógica". Jogar um sudoku é exemplo disso.

Existem vários tipos de heróis, mas todos tem algo em comum. Estão sempre preparados, seja através da atitude, da coragem, ou da técnica. "Sully", apelido do piloto do Voo acima, uniu um pouco disso tudo. Após o acidente, muitos declararam, que o piloto estava calmo, sereno e arrumado. Parecia cena de cinema, onde pela calma demostrada pelo piloto compararam o piloto a um ator antigo de hollywood de nome "David Niven".

Se você, especialista em testes, estiver preparado, saberá se tornar um verdadeiro herói. Mesmo que não seja reconhecido, você terá sempre a consciência tranquila que fez o que era o certo. Vá sempre além, pois para que a aplicação que você tenha sempre uma boa Qualidade você precisa sair da acomodoção e tomar uma atitude. Se você vai se certificar, ok. Se você vai fazer um curso, ok. Se você vai assistir um seminário, ok. Se você você vai comprar um livro com finalidade de melhorar o qe você sabe, ok. Tome uma atitude. Não tenha medo. Mesmo que critiquem você e não o reconheçam e sejam injustos, saiba que o verdadeiro valor do que você vez, um hora aparecerá. Na minha opnião, ninguém pode evitar e nem negar o seu próprio destino, o que se faz no máximo é retardá-lo. Ficar de braços cruzados não leva a lugar nenhum, a não ser ficar parado no mesmo lugar.

Espero que finalmente, que todos tenham conseguido perceber a importância de se preparar corretamente antes de realizar uma tarefa.


Abraços a todos,

Leonardo Molinari
======================================
http://diariodaqualidade.blogspot.com/