Acabei de fazer semana passada um curso sobre patentes que levantou muitas questões interessantes. Assim como a vontade de conseguir registrar ou patentear algo novo.
Também descobri que é muito fácil se perder uma boa idéia fazendo um cadastro equivocado da mesma no instituto nacional de propriedade insdustrial (http://www.inpi.gov.br). Ali existem inúmeras tentativas de patente que não deram certo... E que por não darem certo, entram no estado da arte (são publicadas) e por isso, impedem uma nova tentativa de pedido de patente de algo semelhante, mesmo que a tentativa anterior tenha sido sua mesmo!
Mas acho que o mais interessante foi entender que software pode, sim, conseguir uma patente (mesmo que em geral as regras digam que não deve, atualmente os países todos tem autorizado patentes de software). O registro de autor até serve para você ter em mãos uma forma de punir aqueles que pirateiam o seu software, mas não serve para muito mais do que isso. A patente, porém, pode proteger a sua idéia, dependendo de como escrever isso (tem que ser criativo, porque dependendo de como escrever, pode simplesmente perder a idéia, como disse acima).
Por exemplo, o famoso duplo clique que a Microsoft patenteou e agora processa o linux por fazer uso. Quando tiveram a idéia de usar o duplo clique para acessar uma funcionalidade na Microsoft, alguém muito esperto patenteou a idéia e disse como que implementou a idéia (como que se faz o duplo clique). Agora, independetemente de o Linux ter feito a funcionalidade de duplo clique com um código diferente, eles "roubaram" a idéia da Microsoft e por isso devem pagar... Enfim, apesar de você ter que dizer um meio para conseguir uma patente, os fins são protegidos também, o que torna a patente bastante valiosa, mesmo para software.
O curso também valeu para ouvir falar de algumas patentes brasileiras que fizeram sucesso, como o escorredor de arroz ou o mecanismo que deixa o guarda-chuvas automaticamente aberto - antes você tinha que rosquear o guarda-chuvas para ele se manter aberto. Mas a dica principal mesmo, é para prestar atenção nestas pequenas melhorias que podem ser feitas, mesmo que não esteja inventando o próprio guarda-chuvas... Isto é especialmente verdade em software. Abra os olhos!
terça-feira, 23 de setembro de 2008
sexta-feira, 16 de maio de 2008
Medindo o desempenho do seu teste...
Os testes possuem uma medida de qualidade e estimativa de tempo dos testes (APT) baseada em Pontos por Função que erra por volta de 10%, pelo menos segundo o professor e estatísticas levantadas em uma empresa grande que ele tentou implantar a medida.
Mas como não pretendemos calcular PF na empresa que trabalho, isso já ficou de lado, nem vou comentar muito. Mas ele deu outra estatística (chamada de Defect Removal Efficiency ou DRE), dizendo que o resultado médio das empresas é de 0,3 (sem equipes de testes ou pelo menos um processo de testes bem feito, o que atualmente é raro) e o ideal seria acima de 0,75 (ou ainda chegar acima de 0,9 que é considerado high level). Essa estatística já achei bem mais interessante por ser muito mais fácil de medir e mesmo que não seja 100%, é algum guia.
Esse número é calculado com a fórmula:
NBE = Número de Bugs Encontrados
NBN = Bugs Não Encontrados (achados em produção)
DRE = NBE/(NBE+NBN)
Em média as empresas encontram apenas 1/3 dos defeitos no seu processo de validação. Dito isso eu fiz o cálculo para algumas versões mais simples de calcular, no meu trabalho, o que certamente não é o valor real de verdade, mas deve ser bem razoável (em produção só tenho uma estatística de problemas mais graves, já que detalhes não são pegos lá e são pegos aqui dentro o que distorce um pouco o número).
Por isso acabei descartando os problemas mais simples que encontramos em validação. Ainda assim chegamos em um resultado bem animador de 0,88. Nem perto de estar ruim para uma equipe com um software grande para dar manutenção e sem equipe terceirizada de testes =)
Mas como não pretendemos calcular PF na empresa que trabalho, isso já ficou de lado, nem vou comentar muito. Mas ele deu outra estatística (chamada de Defect Removal Efficiency ou DRE), dizendo que o resultado médio das empresas é de 0,3 (sem equipes de testes ou pelo menos um processo de testes bem feito, o que atualmente é raro) e o ideal seria acima de 0,75 (ou ainda chegar acima de 0,9 que é considerado high level). Essa estatística já achei bem mais interessante por ser muito mais fácil de medir e mesmo que não seja 100%, é algum guia.
Esse número é calculado com a fórmula:
NBE = Número de Bugs Encontrados
NBN = Bugs Não Encontrados (achados em produção)
DRE = NBE/(NBE+NBN)
Em média as empresas encontram apenas 1/3 dos defeitos no seu processo de validação. Dito isso eu fiz o cálculo para algumas versões mais simples de calcular, no meu trabalho, o que certamente não é o valor real de verdade, mas deve ser bem razoável (em produção só tenho uma estatística de problemas mais graves, já que detalhes não são pegos lá e são pegos aqui dentro o que distorce um pouco o número).
Por isso acabei descartando os problemas mais simples que encontramos em validação. Ainda assim chegamos em um resultado bem animador de 0,88. Nem perto de estar ruim para uma equipe com um software grande para dar manutenção e sem equipe terceirizada de testes =)
sexta-feira, 9 de maio de 2008
Normatização de Testes
Um ponto importante do curso foi sobre este tema. E vimos que a norma da IEEE ou a formalização do QAI tem modelos de o que deve ser feito no Plano de Testes e guias de como se trabalhar nesse processo.
Não tivemos acesso a norma completa da IEEE, nem sei quanto custa, mas se tiver a possibilidade de comprar pelo pouco que vi, vale à pena para quem está montando o processo do zero.
De qualquer forma, a idéia geral da norma é bem atendica com a implantação de um bugzilla ou mantis (que é um cadastro organizado de bugs...)
Também fiquei com a impressão de que nosso documento do Roteiro de Validação está com texto demais em muitos pontos e faltam alguns campos que o IEEE considera importantes em um RV, mas não é nada grave de qualquer forma... A empresa que trabalho atende bem à norma.
Segundo o IEEE também os tipos de testes deveriam ser realizados durante todo o processo e o fato de não termos uma equipe independente para ir executando estes testes prejudica um pouco, mas se conseguirmos que os testes automáticos abordem todos estes pontos poderemos ter a versão testada em paralelo com muito menos esforço do que fazermos, por exemplo, uma semana de desenvolvimento e outra de testes.
Um outro ponto interessante é que além de abordagens também ficaram algumas estatísticas a respeito do processo de testes:
- 50% do tempo de validação deveria ser gasto com o "planejamento dos testes", 45% com a execução e 5% com a implantação em produção (a "equipe de testes" deveria acompanhar a implantação na produção);
- Por estimativa estatística daria pra dizer que 1-2 horas de teste são necessárias por ponto de função para a execução de um bom teste;
- Um último número mágico é o de que na experiência do professor, os testes devem levar cerca de 10% do tempo de desenvolvimento para alcançarem um bom nível de custo/benefício. Alguns lugares podem levar menos tempo (como em uma promoção de dia das mães que não pode deixar de ser lançada, por mais que tenha bugs ou mais tempo no caso de lugares que precisam presar mais pela qualidade de seus produtos)
Não tivemos acesso a norma completa da IEEE, nem sei quanto custa, mas se tiver a possibilidade de comprar pelo pouco que vi, vale à pena para quem está montando o processo do zero.
De qualquer forma, a idéia geral da norma é bem atendica com a implantação de um bugzilla ou mantis (que é um cadastro organizado de bugs...)
Também fiquei com a impressão de que nosso documento do Roteiro de Validação está com texto demais em muitos pontos e faltam alguns campos que o IEEE considera importantes em um RV, mas não é nada grave de qualquer forma... A empresa que trabalho atende bem à norma.
Segundo o IEEE também os tipos de testes deveriam ser realizados durante todo o processo e o fato de não termos uma equipe independente para ir executando estes testes prejudica um pouco, mas se conseguirmos que os testes automáticos abordem todos estes pontos poderemos ter a versão testada em paralelo com muito menos esforço do que fazermos, por exemplo, uma semana de desenvolvimento e outra de testes.
Um outro ponto interessante é que além de abordagens também ficaram algumas estatísticas a respeito do processo de testes:
- 50% do tempo de validação deveria ser gasto com o "planejamento dos testes", 45% com a execução e 5% com a implantação em produção (a "equipe de testes" deveria acompanhar a implantação na produção);
- Por estimativa estatística daria pra dizer que 1-2 horas de teste são necessárias por ponto de função para a execução de um bom teste;
- Um último número mágico é o de que na experiência do professor, os testes devem levar cerca de 10% do tempo de desenvolvimento para alcançarem um bom nível de custo/benefício. Alguns lugares podem levar menos tempo (como em uma promoção de dia das mães que não pode deixar de ser lançada, por mais que tenha bugs ou mais tempo no caso de lugares que precisam presar mais pela qualidade de seus produtos)
quarta-feira, 7 de maio de 2008
Montando um Plano de Validação...
Uma boa prática de Roteiro de Validação segue o seguinte plano:
- Testes Unitários (desenvolvedor) - De preferência automáticos, para garantir que serão bons testes (testes unitários manuais tendem a fazer o "caminho feliz");
- Testes de Sistemas (desenvolvedor) - Verificações com o sistema funcionando ou testes de partes integradas e não mais de funções individuais;
- Validação por Cenários (testador independente - testes trocados) - Execução de roteiros de validação mesmo;
- Testes de Aceitação (usuário final/gerente de produto) - Deixar o produto nas mãos deste usuário para validar as funcionalidades novas, pode encontrar outros problemas, mas não há roteiro envolvido;
Além disso há algumas normas que ajudam a dizer qual o mínimo que se deve fazer para se ter um bom processo. Mas este é um assunto que vai ficar para outro post...segunda-feira, 5 de maio de 2008
Área de Testes Independente
Até por ser do interesse dele (o professor que está ministrando o tal curso que mencionei no post anterior), ele passou muito tempo falando da importância de se ter uma área independente do desenvolvimento para os testes, com argumentos como é essencial para o CMM3, etc.
Mas é realmente a prática mais aceita como "State of the Art" internacionalmente. O que significa que alguns desses argumentos foram bons, mesmo no lado financeiro que eu posso descrever bem melhor e com exemplos se for o caso (ter um coordenador de testes + alguns testadores é mais barato que parar os desenvolvedores por diversas razões...
Enfim, existem diversas vantagens que a maioria das empresas grandes valoriza mais do que as desvantagens:
* encontrar problemas mais cedo;
* complexidade menor de gerenciar a validação se já são pessoas independentes do desenvolvimento executando os testes;
* diminui a chance de se subdimensionar os esforços de testes (coordenador específico disso);
* possibilidade de execução em paralelo (desenvolvimento/testes);
Porém, claro que há algumas desvantagens de se ter a tal área de testes:
* custos maiores, pelo menos nos custos fixos ( é relativo, mas o benefício de detectar mais bugs, mais cedo pode até ser medido - mas em geral o ROI é de 400-600% segundo diversas estatísticas que foram apresentadas);
* tendência da equipe de desenvolvimento em relaxar na parte que lhe cabe (verificação);
* desentendimento entre as duas equipes (dedo duros Vs. preguiçosos);
Mas é realmente a prática mais aceita como "State of the Art" internacionalmente. O que significa que alguns desses argumentos foram bons, mesmo no lado financeiro que eu posso descrever bem melhor e com exemplos se for o caso (ter um coordenador de testes + alguns testadores é mais barato que parar os desenvolvedores por diversas razões...
Enfim, existem diversas vantagens que a maioria das empresas grandes valoriza mais do que as desvantagens:
* encontrar problemas mais cedo;
* complexidade menor de gerenciar a validação se já são pessoas independentes do desenvolvimento executando os testes;
* diminui a chance de se subdimensionar os esforços de testes (coordenador específico disso);
* possibilidade de execução em paralelo (desenvolvimento/testes);
Porém, claro que há algumas desvantagens de se ter a tal área de testes:
* custos maiores, pelo menos nos custos fixos ( é relativo, mas o benefício de detectar mais bugs, mais cedo pode até ser medido - mas em geral o ROI é de 400-600% segundo diversas estatísticas que foram apresentadas);
* tendência da equipe de desenvolvimento em relaxar na parte que lhe cabe (verificação);
* desentendimento entre as duas equipes (dedo duros Vs. preguiçosos);
domingo, 4 de maio de 2008
Estatística de Descoberta de BUGS
Recentemente, estive fazendo um curso preparatório para o certificado CBTS (certificado brasileiro de teste de software) que me mostrou diversas coisas interessantes para melhorarmos o nosso processo de testes na empresa, porém, vou começar com uma coisa que é apenas a base para se começar... A idéia de que um processo de testes perfeito, provavelmente é uma opção imperfeita! Por isso, vou mostrar as estatísticas de percepção de bugs que foram levantadas há um bom tempo atrás e também mostrar a idéia de quando é bom se parar de testar... Nada objetivo, mas é bom se ter isso em mente sobre um processo de testes antes de começar.
Estatística de percepção de bugs:
- entre 30-50% dos defeitos de um software podem ser pegos por testes unitários;
- 30-50% dos defeitos restantes podem ser pegos com testes de sistema;
- revisão de código pode diminuir mais 20-30% dos defeitos restantes;
- ou seja, 49% dos defeitos podem sair desse processo da verificação, mas a média deve estar mais próxima de 30-40% dos defeitos passam pela verificação;
Conclusões:
- de 30-50% dos defeitos que passam pela verificação podem ser detectados em uma validação;
- não há como provar que não existem defeitos no software, só que nenhum defeito foi encontrado;
Ponto Ótimo de Teste:
- Existe um custo envolvido em não se detectar um defeito (mancha na reputação da empresa, custo de alteração no cliente, etc) e existe um custo envolvido em se detectar estes defeitos (executar os processos de validação, verificação).
- Um dos pontos importantes é saber achar esse ponto, porque buscar o estado de "Zero-Defect" pode sair mais caro do que deixar alguns problemas passarem;
- Conforme se executa verificações e validações, a idéia é ir eliminando os problemas mais graves/prováveis e deixar estes de baixa ocorrência para um possível cliente descobrir, porque chega um ponto onde é mais caro descobrir/corrigir estes problemas do que arrumar o problema do cliente;
Estatística de percepção de bugs:
- entre 30-50% dos defeitos de um software podem ser pegos por testes unitários;
- 30-50% dos defeitos restantes podem ser pegos com testes de sistema;
- revisão de código pode diminuir mais 20-30% dos defeitos restantes;
- ou seja, 49% dos defeitos podem sair desse processo da verificação, mas a média deve estar mais próxima de 30-40% dos defeitos passam pela verificação;
Conclusões:
- de 30-50% dos defeitos que passam pela verificação podem ser detectados em uma validação;
- não há como provar que não existem defeitos no software, só que nenhum defeito foi encontrado;
Ponto Ótimo de Teste:
- Existe um custo envolvido em não se detectar um defeito (mancha na reputação da empresa, custo de alteração no cliente, etc) e existe um custo envolvido em se detectar estes defeitos (executar os processos de validação, verificação).
- Um dos pontos importantes é saber achar esse ponto, porque buscar o estado de "Zero-Defect" pode sair mais caro do que deixar alguns problemas passarem;
- Conforme se executa verificações e validações, a idéia é ir eliminando os problemas mais graves/prováveis e deixar estes de baixa ocorrência para um possível cliente descobrir, porque chega um ponto onde é mais caro descobrir/corrigir estes problemas do que arrumar o problema do cliente;
terça-feira, 19 de fevereiro de 2008
Campus Party até 16/02/2008
A festa não foi assim nenhum espetáculo. Claro que ter internet muito rápida é legal... Mas não é uma das coisas que mais preciso na vida. Em geral, 2MB são mais do que suficiente para fazer tudo o que eu preciso por ai.
Mas sem dúvida tinha algumas coisas legais, que muita gente já poderia até saber. Como, por exemplo, o site de linux que esteve por lá que focou bastante nas crianças com seu touro mecânico. Ou o jogo de luta, onde você se ve na tela e os seus movimentos são capturados para simular o Kung Fu, que é possível me ver experimentando na imagem ao lado ;-)
Só que algumas coisas me surpreenderam realmente. Como o pagSeguro da UOL. Não só porque a fila para se cadastrar no serviço e ganhar um kit era incrivelmente demorada. Mas por causa da idéia em si. Ah sim, eu sei que a idéia não é do UOL, mas os sistemas como o payPal me fascinam muito.
É uma forma excelente de tornar o dinheiro "virtual". Pode haver taxa para colocar o seu dinheiro ali, pode até haver taxa para retirar o dinheiro virtual também. Mas uma vez que está lá o seu crédito, é seu. Não há mais barreiras de países, de nada. Se alguém de portugal, quiser lhe vender um serviço através deste sistema, nada vai lhes impedir. E é aqui que a história começa a ficar interessante para mim.
Isso porque podemos começar a imaginar um mundo onde não há mais fronteiras monetárias. Todo o dinheiro seria virtual. Com tudo o que se quisesse sendo comprado ou vendido através de sistemas como esse. Se fosse assim, sua empresa poderia ser de qualquer lugar do mundo que chamarei de A, você morar em qualquer lugar do mundo, que chamarei de B. Note que B pode ou não ser igual a A, que isso não fará a menor diferença.
Com o dinheiro virtual e o serviço cada vez mais dificil de se distinguir que país é responsável pelo que... os impostos vão ficar cada vez mais dificeis de serem cobrados. Os bancos não serão mais tão necessários. A sociedade em si poderia ou poderá ser muito diferente. Precisaremos repensar muitas coisas... Mas por enquanto, vou deixar isso de lado que ainda preciso do papel.
segunda-feira, 4 de fevereiro de 2008
Onde será que está o Davi?
Vira e mexe sempre aparece alguém profetizando o fim da Microsoft. É difícil de explicar e realmente temos uma tendência de torcer o nariz para alguém tão rico e poderoso e vibrar quando alguém menor começa a ameaçar o gigante. Mas para mim, ela está demonstrando mais uma vez que não vai cair assim tão fácil.
E não é como se ela não tivesse adversários, apesar de muitas vezes, parecer que não há... Apple? Netscape? Linux? Google? Talvez o Google, quem sabe, mas a empresa já deu muitas mostras de que é capaz de se manter bem, mesmo com tantas oportunidades e acontecimentos diferentes no mundo todo, com os processos contra monopólio, etc.
Agora anuncia uma oferta de $44,6 bilhões pelo Yahoo (ficando assim ainda melhor preparada para enfrentar as buscas da Google) que até hoje é o meu servidor de email. Não, eu nunca quis trocar minha conta de email por uma do Gmail... Muitas vezes por preguiça de trocar de endereço virtual, eu admito. Mas também é uma empresa que sempre me ofereceu um bom serviço. Pelo visto eles ainda vão dar muito o que falar, por mais que cometam seus erros também (Vista?).
E não é como se ela não tivesse adversários, apesar de muitas vezes, parecer que não há... Apple? Netscape? Linux? Google? Talvez o Google, quem sabe, mas a empresa já deu muitas mostras de que é capaz de se manter bem, mesmo com tantas oportunidades e acontecimentos diferentes no mundo todo, com os processos contra monopólio, etc.
Agora anuncia uma oferta de $44,6 bilhões pelo Yahoo (ficando assim ainda melhor preparada para enfrentar as buscas da Google) que até hoje é o meu servidor de email. Não, eu nunca quis trocar minha conta de email por uma do Gmail... Muitas vezes por preguiça de trocar de endereço virtual, eu admito. Mas também é uma empresa que sempre me ofereceu um bom serviço. Pelo visto eles ainda vão dar muito o que falar, por mais que cometam seus erros também (Vista?).
terça-feira, 29 de janeiro de 2008
And in today already walks tomorrow. ~Samuel Taylor Coleridge
O site http://cio.uol.com.br/tecnologia publicou um artigo que achei muito interessante para começar o ano: Dez tecnologias que prometem emplacar em 2008.
E a lista me pareceu muito boa, com internet móvel finalmente virando uma tendência (e olha que recebi uma oferta da Claro por R$ 99 que me pareceu uma ótima opção ainda nesse mês), notebooks educacionais, TV digital, redes sociais (como o OpenSocial da Google), buscas semânticas, etc.
Mas o item que mais me "mexe" é um só: modelo de software como serviço. Porque isso mexe e muito em como a TI deverá funcionar no futuro.
Já houve uma época em que para se ter um computador você precisava da IBM. Depois da criação de padrões e a entrada de tantos fabricantes no mercado, o hardware deixou de ser o principal investimento, deixando muito espaço para a Microsoft liderar a próxima "era". Com o software sendo uma grande oportunidade de se ganhar dinheiro. Agora, as empresas percebem que já não vale mais à pena comprar o pacote todo quando elas podem ter um serviço adequado a suas necessidades.
Junto ao lado corporativo, as portas para aplicações hospedadas online também se abrem para usuários finais, com um investimento cada vez maior em aplicativos corporativos, como o OpenOffice.org ou o Google Docs, se popularizando. A previsão, segundo o artigo, é de que até 2011 um quarto dos softwares serão entregues como serviço. E isso deve mudar mais uma vez as regras do jogo.
Assinar:
Postagens (Atom)