Mês: outubro 2011

#TGIF – iPads e o combate ao autismo

José Carréra #TGIF , , , , , , , , ,

Há algum tempo atrás li algumas matérias a respeito da utilização do wii na recuperação de pacientes,  fazendo uma nova busca encontrei um vídeo, que mostra o mesmo sendo utilizado em hospitais. Esse tipo de notícia parece cada vez mais frequente,  apresentando tecnologias diferentes, sendo aplicadas nos mais diversos tratamentos.

O vídeo de hoje do #TGIF, mostra a utilização de aplicativos para iPad, como ferramenta de apoio na evolução de pessoas com autismo. Impossível não imaginar a quantidade de possibilidades, que ainda podemos desenvolver e o número de pessoas, que podem ser beneficiadas por equipamentos e aplicativos desse tipo.

Clique na imagem para assistir ao vídeo no youtube.

— Update —

Link para matéria do Jornal Hoje com tecnologia desenvolvida no CIN para auxilio em tratamentos de fisioterapia.

…………………………………………………………………………………………………………………………………………..

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Criando Oportunidades

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

#TGIF – A era da revolução científica

dbdelgado #TGIF

Na seção de comentários do meu penúltimo TGIF que fala sobre conceitos, protótipos e ficção científica, recomendei um livro chamado Visões do futuro do fisíco teórico americano Michio Kaku, e no momento que estava procurando informações na internet sobre este autor, encontrei no youtube um vídeo muito interessante da BBC na qual Drº Michio participa como locutor principal, esta matéria é chamada Revolução da inteligência, e parte de uma série da BBC na qual tenho certeza que é baseado nesse livro de Visões do Futuro do Drº Michio Kaku, as outras matérias da série chamam-se respectivamente de revolução biotecnológica e revolução quântica .

Para não estender o post vamos apenas falar sobre a primeira matéria da série (Revolução da inteligência), que já levanta diversos pontos de discussão. Nesta primeira parte, Drº Michio explica como a ciência está avançando tão rapidamente a partir do momento que descobrimos o segredo da matéria (Átomo), revelamos a molécula da vida (DNA) e criamos uma forma de inteligência artificial (Computador). Ele argumenta que a descoberta das leis fundamentais da natureza no século 20, abre portas para um número imensurável de possibilidades no século 21 no qual nós estamos fazendo parte desta transição histórica de uma era de descobertas científicas para uma era de domínio científico.

Inicialmente esta revolução que estar por vir parece um pouco assustadora, mas se pararmos um pouco e voltarmos para mais de 70 anos atrás quando tivemos umas das primeiras cirurgias cardíacas de sucesso feitas pelo Dr. Alfred Blalock em parceria com Vivien Thomas, muito bem contada no filme Quase Deuses, percebemos que todos nós naturalmente resistimos um pouco à uma revolução desse tipo e sempre questionamos qual será o limite para isso tudo.

Para se ter uma idéia do tamanho do impacto social que esta revolução está por fazer, posso destacar alguns questionamentos que os cientistas estão imaginando que possam vir junto com esta revolução:

– Na evolução da realidade virtual e redes sociais virtuais, surge a questão de o que acontecerá se nós começarmos a preferir nossa redes sociais virtuais do que a nossa rede social real ? Isso surge porque hoje já temos mais de 30 milhões de pessoas no mundo que passa em média 20 horas por semana no mundo virtual, por exemplo World of Warcraft.

– Na área de inteligência artificial, onde teremos um evolução tão grande que as máquinas cada vez mais terão a capacidade de agir como a inteligência humana, surge a questão de como nós vamos nos relacionar com estas máquinas ?

– Uma última e intrigante pergunta surge com o avanço das tecnologias biológicas e eletrônicas na qual nos próximos 50 anos poderemos ter máquinas com mais componentes biológicos e pessoas com mais componentes eletrônicos. Daí surge a questão de como vamos categorizar o que é pessoa e o que  é máquina ?

Assistam o vídeo abaixo, tem quase uma hora de duração e infelizmente não está com legendas, e vamos discutir o que vocês que podem acontecer quando esta nova realidade estiver mais próxima ao nosso cotidiano.

No futuro conversaremos sobre as outras matérias da série bastante interessante da BBC.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– Steve Jobs e seu legado

– “Tudo” sobre o iPhone 5

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Imagine um mundo SEM bugs no software

José Carréra Agilidade, Programação, Testes de Sw , , , ,

Na indústria de software estamos habituados a ideia de que todo software possui defeitos e que pouco podemos fazer para mudar isso. No vídeo a seguir, de apenas 9 minutos, Jeff McKenna, co-fundador do Scrum apresenta uma visão radical: um mundo sem bugs no software. O vídeo foi extraído de seu próximo livro “Conscious Software Development.”

O vídeo é excelente e nos faz pensar principalmente na atitude em relação aos bugs que temos em nossos projetos. Segundo Jeff, não basta corrigirmos os defeitos encontrados precisamos entendê-los e aprender com eles, só assim construiremos sistemas SEM defeitos.

Assista ao vídeo. Em seguida, destaco os principais pontos abordados por McKenna.

 

“Temos sistemas de gerenciamento de defeitos, realizamos triagens, mas será que em algum momento pensamos sobre o que eles são? ou como surgiram? como fazer para não surgirem mais?”

Segundo Jeff, temos sido muito complacentes com os defeitos, acreditamos que existem muitos, e que os mesmo são parte de todos os sistemas. Porém, o autor não acredita nisso e nos convida a imaginar um mundo SEM bugs de software.

“Podemos atingir números bem menores do que as pessoas consideram razoável, e isso pode ser feito de maneira simples”

McKenna indica que, a simples conscientização a respeito dos bugs já possibilita imensos ganhos. Precisamos entender porquê eles estão presentes e agir para evitar novas falhas.

Como diminuir a quantidade de bugs?

– Reduzir o tempo entre a introdução de um bug e sua correção

A medida leva em conta o momento no qual o bug foi introduzido no sistema e não o momento em que o mesmo foi detectado. Para isso é necessário utilizar as ferramentas de controle de código, assim, após identificado o motivo do defeito podermos voltar versões do código e identificar o momento em que ele ocorreu.

“Olhando para o exato momento em que o erro aconteceu podemos aprender a escrever menos bugs. Porque esse é o verdadeiro objetivo.”

O objetivo não é encontrar mais bugs e a função dos analistas de qualidade não se resume a isso.

“Classificação e triagem de feitos são uma perda de tempo, em termos de aprendizado sobre como escrever menos bugs”

Segundo McKenna, pouco importa a severidade do defeito e suas características, pois geralmente o critério de correção está diretamente ligado a questões de negócio, como a importância de um determinado cliente. Logo, se estamos tentando aprender a escrever menos bugs, não há diferença entre os mesmos, sejam eles de alta ou baixa prioridade todos são comportamentos não esperados do sistema.

“Corrigir os defeitos era a atividade de maior prioridade”

Jeff, exemplificou suas recomendações com as seguintes práticas executada em um de seus projetos:

1- Sempre que um bug surgisse, a primeira pessoa que estivesse livre passaria a trabalhar no defeito. Onde, um profissional era considerado livre quando terminava a tarefa que estava executando no momento. Bugs possuem prioridade mais alta, que todas as demais tarefas ainda não realizadas. Desse modo, no máximo em alguns dias o defeito era analisado.

2 – Corrigir e entender o problema. A mais alta prioridade era a correção do defeito, associado a criação de novos testes automáticos. Porém, o mais importante é você falar porquê aquele bug estava lá, a razão do mesmo ter ocorrido.

“O que queremos fazer é encontrar o bug o quanto antes para que possamos consertá-lo o mais cedo possível e provar o aprendizado”

Para McKenna, temos o prazo máximo de até 6 meses da introdução de um defeito, para podermos aprender algo através de sua correção, após isso a oportunidade de aprendizado terá sido desperdiçada.

“O objetivo real é escrever software SEM defeitos.”

E para atingir esse objetivo, a principal característica que temos que desenvolver é a de olhar sempre para frente. Se ficamos sempre olhando para trás 6 meses, 1 ano, analisando um código que não vemos a muito tempo, isso literalmente é perda de tempo. Então, o que queremos fazer é olhar para frente a todo o momento e ter a atitude de ZERO defeitos.

“Um bug é algo que você esmaga imediatamente.”

Ao eliminar rapidamente os bugs encontrados acabaremos com tarefas, como a priorização de defeitos. Afinal, a quantidade de bugs pendentes será sempre pequena e desse modo o foco poderá ser maior no que está sendo construído.

Este é um vídeo para ser visto diversas vezes, e se conseguirmos absorver sua ideia central, penso que, poderemos melhorar ainda mais nossos processos e principalmente nossa atitude.

Conheci esse vídeo primeiramente no Software Testing Club, uma excelente fonte de informações para testadores, com bons textos e vídeos sobre a área. Espero que tenham gostado.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

#TGIF – Se os problemas de computador fossem reais

José Carréra #TGIF , , ,

Chegou a sexta-feira e com ela mais um #TGIF para relaxarmos um pouco. No post de hoje trazemos um vídeo curtinho do youtube, que satiriza como seriam na vida real os problemas enfrentados frequentemente pelos usuários de computador.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– “Tudo” sobre o iPhone 5

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Cobertura de código, como ?

dbdelgado Programação, Testes de Sw, Tudo

No meu ultimo post falei sobre a importância da cobertura de código e o quanto ele é comumente utilizado com critério de saída nas primeiras fases de um projeto de software. Lá eu falei das duas técnicas de medição de cobertura de código mais usadas, são elas a Statement Coverage e Decision Coverage. Agora venho escrever este post para cumprir a promessa que deixei no ultimo post, que é mostrar na prática como utilizar uma ferramenta para fazer a medição da cobertura dos testes, neste exemplo, unitários.

A ferramenta que utilizei para exemplificar as duas técnicas acima foi um plugin para o Eclipse chamada CodeCover.
CodeCover é uma ferramenta de teste glass-box grátis e desenvolvido em 2007 na Universidade do Stuttgart.

Para iniciarmos o exemplo, vou mostrar uma classe (Example.java) com dois métodos bastante simples para facilitar o entendimento das técnicas utilizadas.

public class Example {

	public void firstExample(int a, int b) {
		int c =  a + (2*b);
		if (c>50){
			System.out.println(c);
		}
		System.out.println("Fim 1");
	}
}

Abaixo temos os primeiros testes unitários escritos na classe ExampleTest.java para verificar o funcionamento do método firstExample(int a, int b).

	@Test
	public void testFirstExample() {
		try {
			ex.firstExample(20, 15);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

	@Test
	public void testFirstExample1() {
		try {
			ex.firstExample(20, 25);
		} catch (final Exception e) {
			Assert.fail();
		}
		Assert.assertTrue(true);
	}

Para medir a cobertura dos testes acima apenas precisamos marcar as classes Example e ExampleTest para ser usado pela ferramenta de Medição de Cobertura ( Figura 1)

Tela 1 - Clique para ampliar

Após marcar as classes envolvidas (classe de teste e classe a ser testada), iniciamos a execução dos testes no modo CodeCover para JUnit. Ao finalizar a execução dos testes, aparecerá uma aba chamada Test Sessions, no qual podemos marcar os teste unitários executados e visualizar as linhas de código da classe testada que foram exercitado pelo teste. Na tela 2 abaixo podemos ver que o teste testFirstExample exercitou apenas 3 linhas de código de um método que possue 4 linhas de código.

Tela 2 – Clique para ampliar
Tela 3 – Clique para ampliar

Na tela 3, quando marcamos apenas o teste testFirstExample1, verificamos que o mesmo possui uma cobertura completa do método firtExample(int a, int b). Isso quer dizer que apenas o segundo teste (testFirstExample1) é suficiente para se ter 100% de Statement Coverage, ou seja todas as linhas de código foram exercitadas.

Mas se prestar atenção na tela 3 a linha de código numero 8 da classe: “if (c>50) {”  está pintada de amarelo, isto quer dizer que essa linha de código não está completamente exercitada, ou seja, esta estrutura condicional ainda precisa ser estimulada por mais teste para que outro fluxo seja tomado, e isso a gente consegue garantir quando testamos esse método com os dois teste anteriores. Olhando para tela 4 abaixo, percebemos que quando marcamos os dois testes (testFirstExample e testFirstExample1), temos 100% de cobertura  de Decision Coverage, pois ambos os teste exercitaram a linha 8 para que o fluxo fosse tomado tando para que C fosse maior que 50 e C fosse menor que 50, exercitando assim a estrutura condicional (if) pode completo.

Tela 4 – Clique para ampliar

Analisando direitinho, podemos perceber que toda suíte de teste que cobre 100% de decision coverage, também cobre 100% de statement coverage, no entanto o inverso nem sempre  é verdade.

Espero ter esclarecido melhor o conceito de Statement e Decision coverage com os exemplos acima. O que vocês acharam ? Caso tenham dúvidas relacionadas a este tema, por favor utilizem o espaço de comentário para que possamos discutir mais sobre o assunto.

Obrigado e até breve !!!

#TGIF – Steve Jobs e seu legado

dbdelgado #TGIF, Tudo

O TGIF de hoje não poderia ser indiferente ao triste acontecimento que ocorreu essa semana. O mundo perdeu um dos maiores visionários da história, muitos já o comparam com da Vinci, Henry Ford, Thomas Edison entre outras personalidades importantes da história da humanidade.

Para conhecer um pouco mais desse cara que foi um ícone de algumas gerações, existem alguns livros e filme que de um forma ou de outra falam de sua vida e sua personalidade. São eles:

A segunda vinda de Steve Jobs – Sinopse: Baseado em dezenas de relatos de pessoas que conviveram com o executivo nas últimas três décadas, este livro é a biografia do personagem que melhor representa o sonho americano de Silicon Valley. Autor de perfis para as revistas Vanity Fair e GQ e correspondente da Fortune, o jornalista Alan Deutschman inicia a narrativa em 1985, no momento em que Jobs sai da Apple acusado de roubar segredos da   empresa. Seguem-se a ascensão e queda de sua própria empresa, a Next, o enorme sucesso de seu estúdio de animação, a Pixar, produtor dos filmes Toy Story e Vida de inseto, e, no final dos anos 90, seu retorno triunfal à empresa que o    havia demitido. O livro tem como fio condutor os altos e baixos da vida profissional de Jobs, mas mostra também o          lado reservado do empresário – a relação de amor e ódio com Bill Gates, as negociações com Michael Eisner e Jeffrey Katzenberg, da  Disney, seus métodos de administração e seu contato com a imprensa.

A Cabeça de Steve Jobs – Sinopse: É difícil acreditar que um homem revolucionou os computadores nos anos 1970 e 1980, o cinema deanimação e a música digital nos anos 1990. Por outro lado, são lendárias as histórias de seus repentinos acessos de raiva, revelando o verdadeiro Steve Jobs. Então, o que há, realmente, dentro do cérebro de Steve? Segundo o autor, é um feixe de contradições. O autor destila os princípios que guiam Jobs ao lançar produtos arrasadores, ao atrair compradores fiéis e ao administrar a sua empresa. O resultado é este livro sobre Steve Jobs que é, ao mesmo tempo, uma biografia e um guia sobre liderança.

Steve Jobs – Sinopse: Este livro, baseado em mais de quarenta entrevistas com Steve Jobs e entrevistas com familiares, amigos, colegas, adversários e concorrentes -, narra a vida deste empresário, cuja paixão pela perfeição e cuja energia contribuíram para seis indústrias – a computação pessoal, o cinema de animação, a música, a telefonia celular, a computação em tablet e a edição digital.

Também existe um filme clássico chamado Piratas do Vale do Silício, que fala basicamente sobre a história dos dois principais personagens da tecnologia do mundo: Bill Gates e Steve Jobs na década de 70 e início da década de 80.

Vamos deixar aqui um vídeo nesse post, que com certeza esta sendo visto milhares de vezes nos últimos dias, uma palesta famosa que o próprio fala um pouco de sua vida na formatura de uma turma da universidade de Standford. Isto é para deixar registrado em mais um lugar na grande rede a importância que esse cara representa para toda a nossa geração.  Descanse em paz Steve.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– “Tudo” sobre o iPhone 5

– Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Os bugs também têm sentimentos

José Carréra Testes de Sw , , , , ,

Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.

A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.

Se você encontrar um bug:

1 – Reporte-o, bugs não gostam de ser esquecidos.

Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.

Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.

Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.

Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.

5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.

Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.

Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.

Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.

Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.

Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.