Category Archives: Teste de software

Artigos ligados a Teste de Software, técnicas, divulgação de pesquisa etc.

Engenharia de Software Metodologia Pesquisa Teste de software

10 anos de Mestrado no IPT

(Observação: os dados acima podem estar mais atualizados que o texto abaixo, escrito em agosto de 2015)

O estudo acima resume as minhas atividades de orientação no mestrado profissional em engenharia de computação no IPT. Dos 33 alunos que iniciaram um trabalho de pesquisa comigo 29 já concluíram mas apenas 14 obtiveram o título de mestre em engenharia da computação, 10 perderam o prazo, 2 desistiram e 3 optaram por mudar de orientador. Assim a taxa de sucesso é de 14/29 = 53% (já descontando os que mudaram de orientador).

Os trabalhos que oriento seguem as disciplinas que eu ministro no curso, há um interesse maior por Teste de Software com 8 trabalhos concluído, Métodos de Desenvolvimento de Software com 3 trabalho e 3 sobre Gerenciamento de Engenharia de Software.

Visite aqui para conhecer mais sobre a minha participação no mestrado do IPT.

Cultura Geek Teste de software

Por que trocar as senhas?

Armadilha

Com essa discussão sobre a espionagem na internet, muitas pessoas estão interessadas em preservar sua privacidade e segurança on-line. Ao mesmo tempo, observa-se uma grande quantidade de desinformação e ignorância nesta área.

Grande parte da segurança on-line é feita por senhas, e existe um mito que “a troca frequente de senhas aumenta a segurança”. Eu não consigo imaginar porque trocar uma senha aumenta segurança? A única vantagem que eu consigo imaginar é se alguém conseguiu obter a sua senha e, antes que ele faça alguma coisa, você muda essa senha para evitar o acesso. Da mesma forma quando se perde a chave é aconselhável trocar o cadeado. Mas no caso da internet se alguém descobriu sua senha ele vai usar na hora e não vai guardar a senha para um dia entrar. Mudar a senha que é seguro não faz sentido nenhum.

Cultura Geek Teste de software

Achei uma falha na tradução do YouTube

Evernote:Tradução é coisa séria Evernote:Captura de tela

Não entendi quando li “Automóveis” no menu para escolher a qualidade do vídeo no YouTube. Pensei que eles queriam dizer “móvel”, definindo a qualidade para dispositivos móveis. Pra descobrir a verdade mudei a língua para inglês e descobrir que era “Auto”. Acho que foi feita uma tradução “automobilistica”, quero dizer, “automática”.

BTW. Achei muito interessante o modo de BUG REPORT do Youtube com um snapshot da tela para ajudar a informar o locar do erro. No meu caso não deu certo, mas a ideia é ótima.

[06/02/2012 as 16:50] O YouTUBE já havia corrigido a falha:
Correção no YouTUBE

Cultura Geek Engenharia de Software Metodologia Teste de software

As Três Leis da Robótica: Base para Princípios Éticos de Desenvolvimento de Software

C3PO

As Três Leis da Robótica é um conjunto de regras propostas pelo autor de ficção científica Isaac Asimov em 1942 no seu conto “Runaround”, e citadas em várias outras estórias como “I Robot”.  As leis são:

1. Um robô não pode ferir um ser humano, ou por omissão, permitir que um ser humano sofra algum mal.
2. Um robô deve obedecer as ordens que lhe sejam dadas por serem humanos, exceto àquelas que conflitem com a Primeira Lei.
3. Um robô deve proteger sua própria existência desde que tal proteção não conflite com a Primeira ou a Segunda Lei.

Asimov imaginou uma quarta lei, chamada de lei zero, porque deveria preceder as outras:

Um robô não pode ferir a humanidade, ou por falta de ação, permitir que a humanidade sofra algum mal.

Tenho introduzido o tema de ética nas minhas aulas, porque considero um tema importante, pouco discutido e relativamente complexo.  Avaliando as três leis da robótica imaginei que elas poderiam ser usadas como um princípio ético para os desenvolvedores de software se trocarmos os robôs por software de uma modo geral, e se analisarmos de forma mais ampla o sentido de: “mal para um ser humano”.

Princípio ético #1: Um software não pode fazer mal a um ser humano, ou por omissão, permitir que um ser humano sofra algum mal.

  • De nenhuma forma pode se desenvolver softwares que possam fazer mal a um ser humano. Tirar o emprego de alguém não é um mal?  Assim um software que elimina uma posição de trabalho poderia, sob este princípio ser considerado errado. Em um processo capitalista de concorrência, um sistema que aumenta a competitividade de um grupo pode, ao mesmo tempo, reduzir empregos de outro grupo, mas vou responsabilizar isso ao sistema de concorrências e não ao software especificamente.
  • Não podemos considerar que um software mal escrito, que faz perguntas desnecessárias ou que desperdiça o tempo do usuário  não está fazendo um mal para um ser humano?
  • É interessante que a segunda parte desta lei, de uma forma ampla, poderia justificar ou incentivar a criação de software livre. Ou seja, se a não existência de um software pode ser considerada um mal para o ser humano não desenvolver este software pode ser considerada falta de ética. Assim há uma obrigação ética dos desenvolvedores em produzir software que evitem um mal a um ser humano. Obrigado Linus Tovalds.

Princípio ético #2: Um software deve obedecer as ordens que lhe sejam dadas por seres humanos, exceto aquelas que conflitem com o Primeiro Princípio.

  • Um software deve executar as funcionalidades previstas, exceto aquelas que conflitem com a Primeira Lei. O que faz com que não seja ético desenvolver software ruim, e que trate mal seus usuários

Princípio ético #3: Um software deve proteger a sua própria existência desde que tal proteção não conflite com o Primeiro ou Segundo  Princípio.

  • O software não deve deixar de executar, a menos que continuar executando conflite com a Primeira ou Segunda Lei. Uma garantia para a existência e integridade de um sistema.

É interessante como estes princípios se aplicam à escolha de um método de desenvolvimento de software,  já que o uso de um método não adequado ao problema a ser desenvolvido também causa desconforto aos envolvidos no processo de desenvolvimento sejam eles stakeholders ou desenvolvedores. De forma análoga, as leis criam princípios éticos para o processo de teste de software, uma vez que uma falha funcional ou na usabilidade é, sem dúvida, é um mal a um ser humano.

Assim, proponho, que usemos um princípio ético  geral para o desenvolvedor, enunciado como:

Um software não pode fazer mal à humanidade, ou por falta deste software, permitir que a humanidade sofra algum mal,

como um corolário às leis da robótica de Asimov.

Engenharia de Software Metodologia Pesquisa Teste de software

Novos Temas de Pesquisa: O caminho das pedras

Um dos grandes fantasmas que assombram os alunos de mestrado que me procuram é o tema de pesquisa. Alguns tem dificuldade em definir um tema porque não tem uma área específica de interesse, outros tem dificuldade de traduzir uma ideia em um tema de pesquisa. Muitos, mais afortunados, já tem um tema mas não sabem se um tema do seu interesse pode se tornar uma pesquisa de mestrado. Não vou tentar aqui dar algumas dicas de como definir um tema de pesquisa. Para isso sugiro livros de metodologia da pesquisa. O que vou listar aqui são os temas de pesquisa de meu interesse, no momento. Isso não quer dizer que uma área diferente deste possa interessar, mas neste caso o projeto deve estar bem definido e a pesquisa deve apresentar um bom potencial.

Caminhos da história, João Pessoal, PB

Para apresentar um projeto de pesquisa sugiro seguir as dicas de Como Escrever um Projeto de Pesquisa de Mestrado. Mesmo para as áreas abaixo a apresentação do projeto de pesquisa é essencial.

As pesquisas são divididas em duas grandes áreas: teste de software e processos de desenvolvimento de software. Não é coincidência que estas são as áreas das duas disciplinas que ministro no mestrado, assim, um requisito importante para quem quiser ser orientado nestas áreas é fazer estas disciplinas, assim poderemos nivelar nossos conhecimentos e evitar transformar a orientação em aula.

Área de Teste de Software
Grande questão de pesquisa: Como eliminar os defeitos de um software de modo mais efetivo (eficientemente e eficazmente) ?

Validação Experimental de Técnicas de Teste de Software, com coleta e análise de dados de teste de software. Implantação de técnicas de teste de software. Proposta de Novas técnicas para teste de software em contextos específicos. (Metodologias aplicáveis são estudos de caso e pesquisa-ação)
Ex. Avaliação do uso de revisão de pares na eliminação de erros de desenvolvimento. (ex de Metodologia estudo de casos múltiplos).

Aumento da Eficiência (ou da eficácia) de técnicas em contextos específicos. Os contextos podem variar com um domínio de um problema, uma classe de problemas, limitações de linguagem ou de arquitetura ou uma restrição funcional. (Metodologias aplicáveis: pesquisa empírica, pesquisa-ação, pesquisa experimental)
Ex. Proposta de Automação de testes de webservices; Aumento da eficácia dos testes de usabilidade no TDD (Uma área típica para uma pesquisa-ação)

Desenvolvimento de Ferramentas (ou Frameworks) para teste, em contexto específico. Os contextos podem variar com um domínio de um problema, uma classe de problemas, limitações de linguagem ou de arquitetura ou uma restrição funcional. Geração automática de casos de teste. Comparação entre ferramentas/técnicas de automação de teste de software.
Ex. Testes de integração em programas orientados a aspectos. (Metodologias aplicáveis pesquisa-ação, pesquisa experimental)

Área de Processos de Desenvolvimento de Software
A grande questão de pesquisa nesta área é: Quais são os passos/técnicas que aumentam a chances de sucesso de um projeto de software? A hipótese desta área é que existam métodos, na forma de passos bem definidos, que quando executados em um contexto específico, podem aumentar a chance de sucesso de um projeto de software. A adoção de práticas também podem ser estudadas neste contexto.

Validação experimental de técnicas ágeis. Avaliação da eficácia (e/ou eficiência) de técnicas hibridas (ágil _ RUP, UC + TDD, EVM + SCrum). Implantação de ténicas específicas (Scrum , XP, UP, OpenUP, RUP) por meio de estudo de casos.

Escalabilidade de processos ágeis. Estudar o efeito da adoção de práticas individuais ágeis descritas no XP, Scrum, FDD, TDD, etc. por meio de experimentos empíricos. (ex. Integração de Casos de Uso de TDD)

Migração/adoção de ferramentas de controle e gestão (PMI, etc..) ao Processo de desenvolvimento ade software. Gráficos de controle, estratégias de gestão (EVM), documentos, avaliando as práticas que atendem à àrea de software. Com interesse especial nos métodos de desenvolvimento ágil, que ainda necessitam de técnicas de apoio em diversas áreas.

Colaboração entre o desenvolvimento de software ágil e os testes. Propostas que alinhem os princípios ágeis com as praticas de teste. mudanças nas técnicas de teste em função da adoção de uma filosofia ágil de desenvolvimento de software. Ex. TDD + Testes de Usabilidade (Pesquisa -ação); Fatores críticos de sucesso na implantação de teste ágil (estudo de casos múltiplos).

Práticas e Tecnologias de apoio
São técnicas que podem ser usadas em diversas áreas mas não acredito que tenham requisitos de inovação ou motivação suficientes para formarem a base de uma pesquisa especifica. Assim, as áreas abaixo podem ser usadas como apoio para outras pesquisas, nas áreas acima, mas não serão o objeto principal da pesquisa.

* GQM – Goal Question Metric, e métricas são técnicas para apoiar outros estudos,
* POA – Programação Orientada a Aspectos, podem ser usadas como técnicas de apoio.
* MDD – Model Driven Development/Model Driven Architecture
* UML – Unified Modeling Language
* RUP – Rational Unified Process e suas variações
* TDD/Refactoring – Test Driven Design/Refatoração.

Engenharia de Software Livros Resenhas Teste de software

Livros que eu Li/Ouvi em 2010

Aqui está a lista de livros que eu li este ano, na ordem e com um breve comentário. Na verdade a maioria dos livros eu ouvi na forma de audiobooks.

Livros e IPod

1. An Hynm before the battle (por John Ringo) – SciFi já comentado no blog

2. Rework – um livro sobre o trabalho em tempos de startups, internet e web2.0. Questiona conceitos tidos como certos no mundo corporativo. Vale a pena ler para se questionar. Não vale a pena tomar como uma nova biblia porque a abragência destes novos conceitos é limitada. Leitura rápida e interessante.

3. The Strangest Man (biografia de Paul Dirac) o melhor livro que eu li em 2010. Comentado no blog.

4. Millionaire Upgrade – regular, parecido com o famoso Think and Get Rich . Já comentei no blog.

5. The Accidental Billionaires – interessante biografia não autorizada do fundador do Facebook, que deu origem ao filme A Rede Social. O livro dá uma dimensão totalmente diferente do filme, se você gostou do filme, deve ler o livro então. Comentado no blog.

6. Lucifer’s Hammer – Melhor livro de SciFi que eu li no ano em função da relação com a realidade possível. Muito bem escrito e ótimo ritmo. Comentei no blog.

7. Reappraisals (Tonny Judt) Part 1 – como ainda não li a parte 2 não vou comentar. Mas o livro é ótimo.

8. The Intelligent Investory de Benjamin Graham – Boas dicas de como investir, conservador e informativo.

9. Radio Free Albemuth (Philip K. Dick) – mais um clássico do melhor autor de ficção científica na minha opinião.

10. The Colors of Space by Marion Zimmer Bradley. Comentado no blog

11. Switch by Dan and Chip Heath. Um livro muito interessante sobre mudança de comportamento. Com dica valiosas de como se provicar uma mudança de comportamento. Vale a pena ler.

12. What Would Google Do? by Jeff Jarvis. O jornalista tenta definir as regras do sucesso no mundo da internet 2.0. Uma leitura interessante, mas um pouco forçada demais. Os conceitos desta nova economia ainda não estão tão claros assim. Mas vale a leitura. O audiobook é um pouco chato por causa da voz do autor ser muito cansativa.

13 e 14. Daemon e Freedom Inc by Daniel Suarez. Dois ótimos livros de ficção científica. Com certeza vão ser de grande sucesso. Ainda vou escrever um post mais detalhado no blog, porque os livros merecem. Um gênio da computação, faz fortuna com jogos eletrônicos e decide controlar o mundo, transformando-o em um grande video game, após a sua morte. Interessante observar que toda a tecnologia usada no livro está disponível de alguma forma. Não foi colocado como o melhor livro de ficção porque eu acho que o ritmo caiu no segundo livro da série.

15. Thinking for Living (by Thomas H. Davenport) – ótimo livro sobre gestão de conhecimento e o trabalho com o conhecimento por um dos especialistas no assunto. Bastante bem fundamentado, o autor passeia pela prática com um pé na academia. Fácil leitura com boas dicas de como lidar como os trabalhadores do conhecimento com regras diferentes das válidas para os trabalhadores em geral.

16. Nemesis by Philip Roth. Um ótimo livro de literatura americana atual.Escrito por um dos melhores autores americanos da atualidade. Muito bom mesmo, recomendo. Daria um ótimo filme.

17. The short second life of Bret tanner by Stephanie Meyers. Para que gosta da série Crepúsculo (Twilight) e está com saudades dos vampiros, esta é a estória de Bret Tanner, aquela vampira-criança que apareceu no 3o filme da série, onde os Cullen atacam a Victória. Ela é a vampira que se rende para os Cullen, mas que acaba sendo destruida por ordem dos Volturi no final. Digestivo.

18. Perfect Software — and other illusions about testing. por Gerald Weinberg. (2008). O autor do excelente “Secrets of Consulting” faz uma análise bem humorada sobre as falácias do teste de software. Nenhuma novidade para quem já é da área, mas vale a pena revisitar os conceitos e as idéias do teste de software expostas de maneira tão clara.

Se quiser mais alguma dica é só perguntar.

Engenharia de Software Metodologia Teste de software

Introdução do Desenvolvimento Dirigido por Testes (TDD)

por Scott W.Ambler traduzido por JEDeboni do original

O TDD ou desenvolvimento dirigido por testes (do inglês: Teste-drive design) Beck 2003 ; Astels 2003 ) é uma abordagem revolucionária de desenvolvimento que combina o “test-first development” onde se escreve o teste antes de se escreve o código apenas necessário para atender aquele teste com a refatoração. Qual é o objetivo principal do TDD? Uma visão é que o objetivo do TDD é de especificação e não de validação (Martin, Newkirk, and Kess 2003 ). Em outras palavras, é uma forma de pensar no seu projeto antes de escrever o código funcional. Uma outra visão é que o TDD é uma técnica de programação. Como Ron Jeffries gosta de dizer, o objetivo do TDD é escrever um código limpo que funcione. Eu acho que existe mérito nos dois argumentos, apesar que me inclino para a visão da especificação, mas deixo para você decidir.

Conteudo
1. O que é TDD?
2. TDD e o teste tradicional
3. TDD e documentação
4. Desenvolvimento de Banco de Dados Dirigido por Teste
5. Escalando o TDD via o Desenvolvimento Dirigido pelo Modelo Ágil (AMDD)
6. Por que o TDD?
7. Mitos e conceitos errados
8. Sumário
9. Ferramentas

1. O que é o TDD?

Os passos para o TFD – Test – First Design são vistos no diagrama de atividade da UML na figura 1. O primeiro passo é adicionar rapidamente um teste, basicamente uma parte do código vai falhar. A seguir se roda os testes, em geral toda o conjunto de testes apesar de que para ser mais rápido você pode decidir executar apenas um subconjunto, para garantir que o novo teste realmente falha. Você então atualiza a parte funcional do código para fazer ele passar nos novos testes. O quarto passo é executar os testes novamente. Se eles falharem você deve atualizar seu código funcional e testar novamente. Uma vez os testes tendo passado o próximo passo é começar novamente (você pode precisar refatorar qualquer duplicidade do seu projeto, transformando o TFD em TDD).

Esquema do TDD
Figura 1. Os passos do TFD.

Eu gostaria de descrever o TDD por meio de uma fórmula bem simples:

TDD = Refatoração + TFD

TDD muda completamente o desenvolvimento tradicional. Quando você vai implementar uma nova funcionalidade, a primeira questão que se pergunta é se o projeto existente é o melhor projeto possível que permita você implementar esta funcionalidade. Se for, você avança com a abordagem do TFD. Se não for, você refatora localmente para mudar a porção do projeto afetada pela nova funcionalidade, permitindo você adicioná-la o mais facilmente possível. Como um resultado você estará sempre melhorando a qualidade do projeto, consequentemente fazendo ele mais fácil de ser trabalhado no futuro.

Ao contrário de escrever um código funcional em primeiro lugar e depois o código de teste como um trabalho posterior, se é que você vai escrever os testes, você deve escrever o código dos testes antes do código do funcional. Além disso, você vai fazer isso em passo muito pequenos – um teste e um pouco do código funcional correspondente por vez. Um programador que adotar a abordagem do TDD recusa escrever uma nova função até que exista um código que falhe porque esta função não esta presente. Na verdade, eles se recusam a adicionar uma simples linha de código até que exista uma teste para ela. Uma vez o teste está no lugar então ele deve garantir que agora o conjunto de testes passam (o novo código pode quebrar alguns dos testes existentes assim como o novo teste). Isso parece um princípio simples, mas quando você esta iniciando na abordagem do TDD exige-se uma grande disciplina porque é fácil “escorregar” e escrever o código funcional sem escrever um novo teste.

Uma das vantagens da programação em pares é que o seu par pode ajudá-lo a se manter na linha. Uma das hipóteses assumidas pelo TDD é que você deve ter um ambiente de teste de unidades disponível para você. Os desenvolvedores ágeis de software geralmente usam uma ferramenta de código aberto da família XUnit, como o JUnit ou VBUnit, apesar de que existem opções em ferramentas comerciais disponíveis. Sem tais ferramentas o TDD é virtualmente impossível. A Figura 2 apresetna um diagrama de estados da UML sobre como as pessas trabalham, tipicamente, com as ferramentas xUnit. Este diagrama me foi sugerido por Keith Ray.


Figura 2. Testando com o Framework xUnit.

Kent Beck, que popularizou o TDD na programação extrema (XP) (Beck 2000 ), define duas regras simples para o TDD (Beck 2003 ). Em primeiro lugar, você deve escrever um novo código de negócio somente quando um teste automatizado falhar. Em segundo lugar, deve eliminar qualquer duplicidade que encontrar. Beck explica como estas duas regras simples geram um comportamento complexo em grupo e individualmente:

  • Você projeta organicamente, com um código executável oferecendo repostas entre as decisões.
  • Você escreve seus próprios teste porque você não pode esperar 20 vezes por dia que alguém faça isso para você.
  • Seu ambiente de desenvolvimento deve oferecer uma resposta rápida para pequenas mudanças (isto é, você precisa um compilador rápido e um conjunto de testes de regressão)
  • Seus projetos precisam ter componentes altamente coesivos, fracamente acoplados (por exemplo, seu projeto deve ser altamente normalizado) para fazer os testes mais simples (isto também faz com que a evolução e a manutenção do seu sistema mais fácil também).

Para desenvolvedores a implicação é que eles precisam aprender a escrever testes de unidade eficazes. A experiência de Beck é que bons testes:

  • Executem rápido (eles tem um rápidos setup, execução e finalização)
  • Executam isoladamente (deve-se ser capaz de reordená-los)
  • Usam dados que fazem eles fáceis de ler e entender
  • Usam dados reais (por exemplo, cópias de dados da produção) quando são necessários
  • Representam um passo na direção de um gol maior.

2. TDD e o teste tradicional

O TDD é, principalmente, uma técnica de projeto com um efeito colateral de garantir que o código fonte é completamente testado na unidade. Entretanto, existe mais teste a fazer do que isso. Você precisa ainda considerar outras técnicas que testes ágeis como o teste ágil de aceitação e o teste investigativo. Muito deste teste pode ser também realizado cedo no seu projeto se você escolher fazer assim (e você deveria). Na verdade, os testes de aceitação do XP para uma [estória do usuário] são especificados pelos stakeholders do projeto seja antes ou em paralelo à codificação, dando aos stakeholders a confiança que o sistema na realidade atende aos seus requisitos.

Com o teste tradicional um teste de sucesso é o que acha um ou mais defeitos. Acontece a mesma coisa com o TDD; quando um teste falha você esta fazendo um progresso porque é quando você precisa resolver o problema. Mais importante, você tem uma medida clara do sucesso quando o teste não falha mais. o TDD aumenta a sua confiança que o sistema verdadeiramente atende os requisitos definidos para ele, que o seu sistema funciona de verdade e portanto que você pode prosseguir com confiança.

Assim como com o teste tradicional, quanto maior o perfil de risco do sistema, mais completo seus testes deve ser. Com ambos os testes tradicionais e o TDD você não está buscando a perfeição, ao contrário, você está testando a importância do sistema. Parafraseando Agile Modeling (AM), deve-se testar com um propósito, e saber porque se está testando alguma soia e qual o nível que ela deve ser testada. Uma consequência interessante do TDD é que você consegue testar com 100% de cobertura – cada linha de código é testada – algo que o teste tradicional não garante (apesar de recomendar). Em geral, eu acho que é bem razoável dizer que apesar que o TDD é uma técnica de especificação, um valioso efeito é que resulta em um código significativamente melhor testado que as técnicas tradicionais.

Se vale a pena construir, vale a pena testar.
Se não vale a pena testar, porque você esta perdendo seu tempo com isso?

3. TDD e Documentação

Gostem ou não, a maioria dos programadores não leem documentação escrita para um sistema, ao contrário, eles preferem trabalhar com o código. E não há nada errado com isso. Quando tentam entender uma classe ou uma operação, a maioria dos programadores vão olhar, em primeiro lugar para a amostra de código que as envolve. Testes de unidade bem escritos fazem exatamente isso – oferecem uma especificação para o código funcional – e como resultado os testes de unidade passam a ser uma importante parte da sua documentação técnica. A implicação é que as expectativas da turma pró-documentação precisa refletir esta realidade. Analogamente, os testes de aceitação podem formar uma parte importante da documentação de requisitos. Isso faz muito sentido quando se para para pensar sobre isso. Seus testes de aceitação definem exatamente o que os seus stakeholders esperam do sistema, por isso eles especificam os requisitos críticos. Seu conjunto de testes de regressão, particularmente com a abordagem do test-first, efetivamente se tornam uma especificação detalhada executável.

Os testes podem ser uma documentação suficiente? Muito provavelmente não, mas eles formam uma parte importante dela. Por exemplo, você está prestes a descobrir que ainda precisa da documentação do usuário, uma visão geral do sistema, documentação operacional e de suporte. Você ainda pode até descobrir que precisa uma documentação resumida cobrindo todo o processo de negócio que o seu sistema suporta. Quando você aborda a documentação com a mente aberta, Eu suspeito que você vai concordar que estes dois tipos de teste cobrem a maioria das suas necessidades em documentação para desenvolvedores e stakeholders. Ainda mais eles são bons exemplos das práticas de gerencia ágil como a pratica do ponto único de informação e uma importante parte do esforço global para se manter o mais ágil possível apesar da documentação.

4. Desenvolvimento de Banco de Dados Dirigido por Testes

Enquanto este texto estava sendo escrito uma importante pergunta está sendo feita na comunidade ágil “o TDD pode ser usado para desenvolvimento de Bancos de Dados?” Quando se olha o processo descrito na Figura 1 é importante notar que nenhum dos passos especifica uma linguagem orientada a objetos como Java ou C#, apesar de que estes são os ambientes em que o TDD é tipicamente aplicado. Por que você não poderia escrever um teste antes de fazer uma mudança no seu esquema de banco de dados? Por que não se pode fazer uma mudança, executar os testes e refatorar seu esquema como requerido? Me parece que você só precisa escolher trabalhar assim.

Minha idéia é que os termos banco de dados TDD ou talvez TDDD (Test Driven Database Design), não vai funcionar tão bem quanto a aplicação TDD. O primeiro desafio é o suporte de ferramentas. Apesar de estarem disponíveis ferramentas para teste de unidade como o DBUnit , ainda existe uma tecnologia emergente enquanto este artigo esta sendo escrito. Alguns DBAs estão melhorando a qualidade dos testes que estão executando, mas ainda não vi ninguem adotando uma abordagem do TDD para o desenvolvimento de bancos de dados. Um desafio é que as ferramentas de teste de unidade ainda não são bem aceitas na comunidade de banco de dados, apesar de que isso está mudando, assim a minha expectativa é que nos próximos anos o TDD para banco de dados vai crescer. Em segundo lugar, o conceito de desenvolvimento evolucionário é novo para a maioria dos profissionais de banco de dadso – porque uma mentalidade serial ainda domina na comunidade tradicional e a maioria das ferramentas não suporta o desenvolvimento evolutivo. Minha esperança é que os fornecedores de ferramenta vão alcançar esta mudança de paradigma, mas minhas expectativas são que teremos que desenvolver ferramentas de código aberto. Em terceiro lugar, minha experiência é que a maioria das pessoas que trabalham orientadas a dados parecem preferir uma abordagem orientada a modelos e não orientada a testes. Uma causa disso parece que é porque uma abordagem orientada a testes ainda não foi amplamente considerada até agora, outra razão pode ser que os profissionais de bancos de dados são mais visuais e por isso preferem a abordagem orientada a modelos.

5. Escalando o TDD via AMDD (Desenvolvimento Ágil Dirigido a Modelos)

TDD é muito bom como uma especificação detalhada e validação, mas não muito boa para pensar em problemas maiores como uma visão geral do projeto, como as pessoas vão usar o sistema, ou o projeto da interface (por exemplo). Modelagem, ou ou o AMDD (Desenvolvimento Ágil Dirigido a Modelos) (o ciclo de vida é apresentado na figura 3) é mais adaptada para isso. O AMDD atende o problema de escalar os problemas do TDD não resolve.

Figura 3. O ciclo de vida do AMDD (Desenvolvimento Ágil Dirigido a Modelos)

Comparando o TDD e o AMDD:

  • O TDD abrevia a realimentação da programação enquanto o AMSS abrevia a realimentação da modelagem.
  • O TDD provê uma especificação detalhada (testes) enquanto o AMDD é melhor para pensar os grandes problemas.
  • O TDD promove o desenvolvimento de software de alta qualidade enquanto o AMDD promove uma comunicação de alta qualidade com os stakeholders e outros desenvolvedores.
  • O TDD fala com os programadores enquanto o AMDD fala com os analistas de negócio, stakeholders e profissionais de dados
  • O TDD oferece uma realimentação concreta muito fina e da ordem de minutos enquanto o AMDD permite uma realimentação verbal da ordem de minutos (uma realimentação concreta requer que os desenvolvedores sigam a prática de provar com o código e então se tornam dependentes de técnicas não AM)
  • O TDD é orientada não-visual enquanto a AMDD é orientada visualmente.
  • Ambas as técnicas são novas para os desenvolvedores tradicionais e por isso podem ser uma ameaça para eles.
  • Ambas as técnicas suportam o desenvolvimento evolutivo.

Que abordagem eu demo adotar? A resposta depende das suas preferencias cognitivas e de seus colegas. Algumas pessoas são primeiramente um “pensador visual”, também chamado de pensadores espaciais.

6. Porque TDD?

Uma vantagem significativa do TDD é que ele permite que você tome pequenos passos quando estiver escrevendo um software. Esta prática que eu tenho promovido por anos porque é muito mais produtivo que tentar codificar em passos maiores. Por exemplo, assuma que você adicionou um código funcional, compilou e testou. A probabilidade é boa que os testes irão ser quebrados por defeitos que existem no seu código novo. É muito mais fácil encontrar, e corrigir, estes defeitos se você tiver escrito duas linhas de código do que duzentas. A consequência é que quanto mais rápido o seu compilador e conjunto de teste, mais atrativo é prosseguir em passos mais e mais pequenos. Eu geralmente prefiro adicionar poucas linhas de código no código funcional, tipicamente menos de dez, antes de recompilar e rodar os testes.

Eu acho que Bob Martin confirma que “o ato de escrever um teste de unidade é mais um ato de projeto do que de verificação. Ele também é mais um ato de documentação do que verificação. O ato de escrever um teste de unidade fecha um grande número de laços de realimentação, no mínimo aqueles que se procura na verificação de uma função.”

A primeira reação que muitas pessoas tem das técnicas ágeis é que elas funcionam bem em projetos pequenos, talvez envolvendo um pequeno número de pessoas por poucos meses, mas que eles não vão funcionar em projetos “reais” que são muito maiores. Isto simplesmente não é verdade. Beck (2003) relata trabalhar em um sistema Smalltalk completamente com a abordagem dirigida a testes que levou 4 anos, 40 pessoas-ano de esforço, resultando em 250000 linhas de código funcional e 250000 linhas de código de teste. Eram 4000 testes sendo executados em menos de 20 minutos, com o conjunto completo de testes sendo executada várias vezes por dia. Apesar de que existem muitos sistemas grandes, eu pessoalmente trabalhei em sistemas com muitas centenas de pessoas-ano de esforço e está claro que o TDD funciona para sistemas de bom tamanho.

Figura 4. Visão geral de teste para as equipes ágeis.

8. Sumário

O Desenvolvimento Dirigido por Testes (TDD) é uma técnica de desenvolvimento onde você deve escrever primeiro os testes que falham antes de você escrever um novo código funcional. O TDD está sendo adotado rapidamente pelos desenvolvedores de software para desenvolvimento uma aplicação de código fonte e está sendo até adotada pelos DBAs ágeis para o desenvolvimento de bancos de dados. TDD deve ser visto como complementar a abordagem do AMDD (Desenvolvimento Ágil Dirigido por Modelos) e os dois podem e devem ser usados em conjunto. O TDD não substitui TDD does not replace traditional testing, instead it defines a proven way to ensure effective unit testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. My experience is that TDD works incredibly well in practice and it is something that all software developers should consider adopting.

Figura 5. Como as equipes ágeis validam o seu trabalho.

9. Ferramentas

    10. Referências e sugestões de leitura on-line

    Teste de software

    Recursos gratuítos na internet sobre Teste de Software

    A internet tem muita coisa útil, o difícil é saber onde estão. O meu interesse na área de Teste de Sofware tomei contato com muitos recursos disponíveis na internet para esta área. São itens que podem ser úteis para um aprendizado contínuo, para tirar dúvidas, contratar ou ser contratado.

    Butterfly closeup

    Revistas on-line sobre teste de software.


    Software Test&Performance Collaborative

    Revista on line gratuita sobre teste de software

    Testing Experience
    Outra revista on-line gratuita sobre teste de software.

    Methods&Tools
    Revista on line, com connhecimentos práticos para o desenvolvimento de software, gerente de testes e de projeto de software. Vários números disponívies.


    Websites e blogs


    Agile Testing with Lisa Crispin

    Autora do livro Agile Testing

    TestExpert A sua comunidade de teste e qualidade de software
    Comunidade de teste de software brasileira, ligada à ALATS, bom para fazer contatos locais.

    The Test Management Guide
    website meu desorganizado com algumas informações sobre teste de software. Com um glossário on-line de termos e diversas normas inglesas sobre software e teste de software.

    Lista de ferramentas de software open-source
    Na última contagem listou 433 ferramentas de apoio ao teste de softtware.

    Agile Testing : TesterTroubles
    artigos sobre teste, em um site bem organizado com um blog e artigos sobre a área de teste e métodos ágeis.

    Home Page do Prof. Atif M. Memon

    Vários artigos do Prof. Memon, conhecido professor de teste de software e engenharia de software.


    Organizações e certificadoras.

    Página de Qualidade de Software da NASA
    Alguns links interessantes com procedimentos e programas de qualidade.
    Uma série muito interessante de Cheklists para várias situações.

    ISTQB – International Software Testing Qualifications Board
    Filial brasileira da ISTQB, possui vários links sobre as certificações oferecidas pela instituição.


    Grupo de discussão

    BSTQB
    Grupo de discussão de teste de software, muitas informações sobre certificação, empregos, seminários. Muito ativo.

    Gerencia Metodologia Pesquisa Teste de software

    Programadores: uma grande ameaça ao projeto de software

    Tenho mais de 20 anos lidando com desenvolvedores de software, e alguns erros que estes profissionais cometem de tão comuns que nem posso chamar mais de erros. São características pessoais e profissionais praticados pelos desenvolvedores de software de forma recorrente, independente da linguagem, experiência ou tecnologia empregada. O problema é que estas características aumentam muito o risco dos projetos de desenvolvimento de software. Por isso classifico que o programador é uma grande ameaça para o projeto de software.

    The value of X

    1) Não aprofundar suficientemente os requisitos. Uma visão preliminar dos requisitos, em geral superficial pode levar a conclusões imprecisas e a implementações equivocadas. Uma atitude comum, do tipo “já entendi o que o cliente quer”, mesmo sem ter uma confirmação dos requisitos, pode levar ao início prematuro do processo de desenvolvimento ou à assunção de falsas hipóteses falsas que podem compremeter todo o projeto.

    2) Iniciar o projeto pela atividade mais fácil, e não pela mais importante ou mais complexa. Pode parecer uma atitude correta, mas começar a desenvolver a parte mais fácil pode dar uma falsa sensação de resultados que não será cumprida pelas próximas etapas. Começar pelo mais importante ganha confiança do cliente, traz valor ao projeto. Começar pelo mais complexo dá mais tempo para desenvolver o que é importante.

    3) Subestimar a complexidade e o esforço do desenvolvimento. Essa já é uma lenda na área. Pode levar ao mesmo tempo a um expectativa grande por parte do cliente, assim como a uma frustração no desenvolvedor por não conseguir prover o sistema no prazo e esforço inicialmente estimado. Este erro pode ser uma decorrência direta do primeiro, mas também pode ser um problema em si mesmo quando um levantamento detalhado de requisitos é realizado. É comum que os desenvolvedores assumam uma atitude simplista nos projetos. Um sistema iniciado com uma arquitetura simples terá dificuldade em evoluir para a arquitetura necessária se a complexidade foi subestimada. Acredito que este comportamento pode ser motivado por uma atitude excessivelmente otimista e auto-confiante, característica da área, mas também por uma dificuldade em se admitir as suas próprias limitações.

    4) Subestimar a necessidade de testes, ou possíveis origens de erro. Isso leva a testar apenas situações simplificadas, deixando o sistema com muitos erros que, por não serem detectados no desenvolvimento, só são encontrados posteriormente, aumentando a insatisfação muito mais do que se o prazo solicitado fosse maior para acomodar os testes necessários. Outra conseqüência do excesso de confiança, ou da incapacidade de admitir que se erra, e muito.

    5) Corrigir um erro apenas no comportamento observado, ou o erro evidente, evitando investigar as causas raízes dos problemas. Acredito que esse comportamento se deve ao desinteresse que corrigir um erro quando comparado com a possibilidade de se produzir mais erros, desenvolvendo algo novo, cedo demais.

    Para evitar que estes erros comprometam um projeto dfe software basta não deixar algumas atividades vitais delegadas exclusivamente para desenvolvedores, mas compratilhadas com analistas e gerentes de projeto. A engenharia é a disciplina em que se aprende muito com os erros. Grande parte do desenvolvimento tecnológico é fruto de pesquisa sobre erros e falhas. Se um dia pretendemos ser Engenheiros de Software não podemos mais cometer esses erros.

    Engenharia de Software Metodologia Teste de software

    Software Test & Performance Magazine : uma revista de divulgação

    Se você é como eu que gosta de pagar pouco, vai gostar de saber que a revista Software Test & Performance Magazine pemite o download gratuido dos exemplares.

    [img:logo.gif,thumb,vazio]

    A revista foca o teste de software em um aspecto prático. Procura discutir técnicas e propostas atuais como o teste nos processos ágeis(julho/09), testes de sistemas ajax(maio/09), testes de performance (fev/mar/09) entre outros.

    Os assuntos são discutidos com alguma profundidade e algumas ferramentas são avaliadas com isenção.

    Se há interesse em testes de software e performance vale a pena consultar e acompanhar os números da Software Teste & Performance.