Quem testa o botão vermelho?

Para aqueles que possuem a atividade de teste de software o que vem a ser falado não é novidade. Sempre, acredite, o software vai apresentar problemas durante o desenvolvimento. Não duvidando da competência da equipe que o desenvolve, mas pelo fato de serem humanos, os desenvolvedores podem cometer erros. A pergunta do título é simples. Quem irá testar o botão vermelho (aquele que exige a operação mais complicada e/ou no caso de todas as outras darem errados)?

Fora este cenário ainda pode-se pensar em situações como sistemas cirúrgicos, de segurança, aéreos, militares, etc. Como é possível simular situações que não são esperadas. Como é possível provar que funciona um software que não pode dar errado?

Fazendo uma analogia, imagine o que seria de Davi se a pedra não derrubasse o Golias. No mínimo ele ficaria machucado. Para executar o arremesso da pedra Davi deve ter calculado, estudado a posição do vento, condições de altura, movimento da atiradeira, peso da pedra, etc. Será que realmente isto ocorreu? Independente se foi bem estudado ou não vale se pensar que, muito provavelmente, a ira de Golias seria bem maior após uma tentativa de o derrubarem. E representando esta analogia em tempos atuais (mas não tão atuais assim) pode-se imaginar que o esforço que tiveram pra se reerguer em Hiroshima poderia ser revertido para revidar o ataque caso a bomba caísse sem surtir o efeito que era previsto.

Com o tempo passa-se a ficar um pouco neurótico. Será que o software do equipamento que será utilizado para auxiliar na realização de uma cirurgia em mim (um exemplo) foi testado adequadamente? E se faltar energia, o cirurgião poderá realizar todos os procedimentos manualmente para me manter vivo????

Calma, segundo o TMM nível 5 o teste "é um processo com o objetivo de prevenir defeitos" (o que dará assunto para um próximo post). Basicamente, não será necessário testar (entenda-se por testes manuais) de fato o meu software. Poderá até ser realizado um ciclo de testes para "garantir" alguma coisa (que funciona, que não funciona, que atende os requisitos, etc) mas não será tão necessário já que todos os defeitos foram prevenidos.

Mas a pergunta continua, você se colocaria de cobaia para um teste de erro de um sistema cirúrgico ou daria uma martelada em uma bomba* para provar que uma tremulação durante o transporte não iria a fazer entrar em atividade?


* Sei que uma bomba não é um software, é só um exemplo para mostrar um erro grave que pode ser cometido e envolve risco


Imagens (por ordem que aparecem):
[1] https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7knLItxCr0h8IlXr8lrYpziL6my0toU5lxTOM6Gp7vic5hvo1dcOrTJm3Ajm-qjVqHgKWiN-nNLWI4PV-9KX-k8AkFlfCFziItDZYEBbVmjPBUh7Oz-T1nhCtAWIpjLTNRz4U4_MG7EtK/s1600-h/bot%C3%83%C2%A3o+vermelho.jpg acessado em 09/11/2008
[2] http://www.palavradaverdade.net/Humor/charge0420-20Davi20e20Golias.gif acessado em 09/11/2008
[3] Eu mesmo que fiz para o post! ;)

Ensinando o computador: Estruturas Condicionais

Para ajudar aqueles que estão iniciando na área de programação, uma pequena e breve explicação sobre estruturas condicionais simples e compostas (utilizando o comando SE).

Antes de tudo devemos perceber que o computador é, de certa forma, "cego". O que acontece é que o mesmo se comporta de acordo com o que programadores dizem que deve ser feito em cada situação, reconhecendo um conjunto limitado de instruções.
Para que este responda de acordo com as expectativas devem-se dar as instruções corretas. Sabe-se que os programas são executados de cima para baixo de forma sequencial. Mas em certos momentos será necessário modificar este curso de acordo com as decisões que devem ser tomadas. Isto poderá ser feito através de perguntas realizadas pelo comando SE (em inglês IF).

Existem três situações bem definidas dentro da programação, para o comando SE, que são: Estrutura Condicional Simples, Composta ou Encadeada.

Fluxograma
Uma breve explicação sobre fluxograma para logo em seguida dar continuidade ao foco principal do post.

Fluxograma “é um tipo de diagrama, e pode ser entendido como uma representação esquemática de um processo, muitas vezes feito através de gráficos que ilustram de forma descomplicada a transição de informações entre os elementos que o compõem. Podemos entendê-lo, na prática, como a documentação dos passos necessários para a execução de um processo qualquer. É uma das Sete Ferramentas da Qualidade. Muito utilizada em fábricas e indústrias para a organização de produtos e processos.” [ Wikipedia, acessado em 5 de outubro de 2008]

Formas para representação do fluxograma

Como exemplo será utilizado o seguinte cenário: "Minha mãe me impôs uma condição para que eu pudesse andar de bicicleta. Para que eu pudesse pegar a bicicleta, antes eu deveria tomar banho". A partir do que foi especificado pode-se extrair o seguinte fluxograma:
Agora, indo ao que interessa, pode-se obter o seguinte algoritmo a partir do fluxograma apresentado:

Estrutura Condicional SE (Simples)

Algoritmo
--DECLARE tomeiBanho, LÓGICO
--ler tomeiBanho;
--Se (tomeiBanho) então
----(andar de bicicleta, oba!)
--Fim-Se
Fim-Algoritmo

Estrutura Condicional SE (Composta)
Repare que agora possui o comando senão

Algoritmo
--DECLARE tomeiBanho, LÓGICO
--ler tomeiBanho;
--Se (tomeiBanho) então
----(andar de bicicleta, oba!)
--senão
----(ficar triste, pois mamãe não deixa andar de bicicleta sem tomar banho)
--Fim-Se
Fim-Algoritmo

Lógica de programação: a primeira vista

Era dezembro de 2004, quando fui para a primeira aula de lógica de programação no ITECI. Um pouco atrasado chego ao local e, sem sequer me ser questionado o nome, sou colocado em uma sala por uma das atendentes do local. A aula já havia iniciado e tinham muitas pessoas na sala. O instrutor exibe um slide com a seguinte frase: "A caneta está na gaveta, para pegar a caneta preciso abrir a gaveta". Claro! É óbvio que para pegar uma caneta que está dentro da gaveta eu preciso antes abrir a gaveta.

Olhei para os lados me questionando: "Será que alguém daqui não sabe abrir uma gaveta e tirar a caneta?". Estaria eu em uma sala para pessoas, digamos assim, "especiais". Todos pareciam normais a minha volta (apesar de serem da área de TI).

Chega o intervalo, resolvo perguntar ao instrutor se eu estava, realmente, na sala de lógica de programação. Para minha surpresa... Estava! Começamos a ver outros procedimentos simples do cotidiano e eu ainda a me perguntar se valeria a pena um curso daquele. Era claro que eu sabia tirar caneta de gaveta, abrir geladeira, fazer uma ligação de orelhão para um amigo.

Chega a hora de fazermos fluxogramas...

"Faça uma ligação para um amigo pelo orelhão", era o que dizia o exercício para fazermos em um fluxograma. Isso eu sei... Pega cartão... Liga pra o amigo... se não atender, liga de novo... atendeu, falou, "tchau"! Entrego o fluxograma feliz da vida. Acabei antes de todo mundo... [ÊÊÊÊ!!!]

O instrutor pergunta: "Se eu não tiver cartão?". Volto... Nem sento na cadeira e coloco um outro bloquinho daqueles que representa uma condição... setinha pra lá... setinha pra cá... Pronto! Está aqui meu fluxograma "completão"! E ele pergunta: "E se o orelhão estiver quebrado?".

Para resumir a história, passei a noite inteira fazendo um fluxograma que não cabia em várias folhas juntas de papel paltado. E no final acabei percebendo que tirar uma caneta da gaveta não é um procedimento tão simples. Precisamos dizer para a máquina o que ela vai fazer em cada situação. Somos nós quem damos a inteligência que ela possui.

Eu possuia uma visão leiga de que para fazer um software era apenas questão de desenhar uma tela e dizer "Alakazam!" para que tudo estivesse resolvido. Vi que não é tão fácil como muitos imaginam. Já mais a frente no curso, depois de passar duas semanas virando noites e reunindo-se na casa dos colegas de grupo, apresento o projeto (feito em Java com Swing, todo na mão, tinha até DesktopPane no meio, que tirei nota máxima) para minha mãe e ela fala: "Tu passou duas semanas dormindo mal pra fazer essa coisa?". Mas quer saber? Valeu, muito, a pena.

Cenários a se pensar para construir? Existem muitos... Para quebrar... Mais ainda!

Para deixar claro... Não consegui fazer a ligação de orelhão sem que o intrutor quebrasse em algum lugar, que sorrindo me disse: "Está bom por este, vamos para um próximo exercício!".

Motivação

"Motivação", este foi o tema do primeiro texto que tive a oportunidade de ler do professor Douglas Daniel Del Frari. Grato, sou, a Deus por poder trabalhar no mesmo ambiente que esta pessoa, onde posso trocar idéias nas horas de almoço. O que mais me admira neste profissional é o empenho para passar, não somente para seus alunos mas, para a comunidade o seu conhecimento, o que ele acredita ser importante e valioso para a área de tecnologia da informação. Não é fácil encontrar professores que se importem tanto com os alunos a ponto de ajustar a própria aula para que todos possam tirar proveito do conteúdo. Espero um dia ter o privilégio de estar em alguma aula ministrada por ele.

A motivação para se criar o blog já existia, mas foi a partir do post de como se preparar para o mercado de trabalho que foi dada a partida. Espero demonstrar aqui coisas que considero importantes para atuar na área. E tentar, até mesmo, me manter atualizado quanto a tendências do mercado.

Assumi este casamento com o desenvolvimento de software a algum tempo com a ajuda e apoio do meu pai, outro profissional da área que admiro bastante (profissionalmente e pessoalmente). Esse amor que adquiri por desenvolver é o que me faz ficar feliz durante e após as noites de sono que não tenho por estar estudando ou fazendo projetos. Esse amor é a minha motivação. Tomando uso das palavras de um poeta, que seja eterno enquanto dure. Que venham mais linhas de códigos que tragam vontade de pôr molduras e pendurar na sala de casa. E venham mais noites não dormidas que gerem bons resultados.

Falando um pouco mais do meu pai. O que seria de mim se não fosse por ele? Foi ele quem me disse: "Se você pretende mesmo fazer ciências da computação este curso é interessante". O curso ao qual ele se referia era o de programador trainee (que eu havia pego o folder). O preço pago por se antecipar, alguns períodos chatos na faculdade em que eu pensava que poderia estar em outros lugares aprendendo alguma coisa. Mas de tudo deu pra se tirar algum aprendizado. Voltando ao meu pai, não teria dia melhor para dizer o quanto ele é importante. Feliz dia dos pais, "painho", apesar de estar, quase, no final do dia! Obrigado por tudo!

Para deixar claro os meus agradecimentos, obrigado Deus, "painho", "mainha", minha irmã, e a todos aqueles que me dão, de alguma forma, motivação para continuar a enfrentar meus desafios. Do mundo, sabemos que, não levaremos nada. Então espero plantar, quem sabe aqui, bons frutos para aqueles que nele, irão, passar.