Tire a gente da Área 51

O Felipe Knorr Kuhn teve a iniciativa de criar um repositório para perguntas sobre Teste de Software no StackExchange (mesma plataforma do StackOverflow e que foi criado pelo grande Joel Spolsky e o Jeff Atwood) .

Abaixo, falo mais sobre esse repositório, baseado no e-mail do Felipe, que foi enviado para algumas listas de discussões.

O que é o StackExchange?

Assim como o StackOverflow, ele é voltado para armazenar perguntas e respostas, tendo funcionalidades como por exemplo: “tagear” perguntas e avaliar respostas e perguntas,. O legal do StackExchange, é que ele te permite criar o seu próprio repositório de perguntas e respostas, onde uma comunidade fica responsável por ele.

Se quiser ver um exemplo prático de uso do StackExchange, você pode clicar no link abaixo, para o repositório de Teste de Software internacional, onde pessoas como o Matthew Heusser, Justin Hunter e o Shmuel Gershon participam:

http://testing.stackexchange.com/

Que área 51 é essa?

Para pode ter um repositório no StackExchange é preciso passar por três etapas:

  • Definição: Precisamos de 60 pessoas “seguindo” a proposta e algumas perguntas que sirvam de bom ou mal exemplo para o assunto;
  • Comprometimento: Uma vez que a etapa de definição tenha sido atingida, precisamos de pessoas que decidam dar suporte à comunidade, fazendo ou respondendo perguntas;
  • Beta: É o site finalmente no ar, sendo utilizado pela comunidade.

Enquanto o nosso repositório não passar por essas três etapas ele fica numa área “secreta”, chamada área 51, uma boa analogia do pessoal do StackExchange com a Área 51 (rs).

Qual a diferença desse repositório para as listas de discussão?

O foco do StackExchange é armazenar perguntas e respostas, sendo assim a primeira diferença é que o repositório será voltado para responder perguntas relacionadas com Teste de Software. Já numa lista de discussão os assuntos podem ser mais variados, desde discussões até divulgação de eventos.

Particularmente, acho bem legal o StackOverflow (onde sempre caiu quando pesquiso por alguma exceção ou problema que estou buscando resolver), e por isso, acho que o nosso repositório no StackExchange pode ser bem legal, afinal ele é focado em perguntas e respostas, e isso pode facilitar tanto a vida de quem quer ajudar, quanto de quem está querendo ajuda.

Agora se vai dá certo ou não, só o tempo poderá dizer. 🙂

Se você achou interessante a ideia e quer participar, acesse o link abaixo para seguir o repositório e por favor, divulgue na sua empresa, grupo de amigos, etc. 😀

http://area51.stackexchange.com/proposals/10120/teste-de-software

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 20/06 a 26/06

Pessoal,

Após a primeira semana sem “o melhor da semana” (por falto de tempo de ler meus feeds), segue mais abaixo a lista, mas antes disso uma breve (vou tentar ser breve) explicação de um dos motivos de compartilhar tais conteúdos no blog.

Eu, você, o seu vizinho lemos vários conteúdos ao longo da semana. Alguns preferem política, outros humor, novela, etc. Como o blog é voltado para assuntos de Teste e Qualidade de Software, e um dos assuntos de minha preferência é esse, acabei criando “o melhor da semana”, no qual compartilho links sobre e relacionados a Teste e Qualidade de Software (alguns não tão relacionados assim rs) com conteúdos que gostei.

Após essa breve explicação (até foi breve), segue abaixo a lista com o melhor da semana, espero que gostem:

Conhecimento a um clique, esse é o QualidadeBR 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

2 anos de QualidadeBR

Exatamente hoje, 19 de Junho de 2010, faz 2 anos que iniciei o QualidadeBR. 😀

Confesso que nunca imaginei que conseguiria manter o blog por tanto tempo e com conteúdo novo toda semana.

Mas aqui estou eu, escrevendo o 226º post (rs). Fico feliz por isso, principalmente porque a cada post escrito, sempre consigo aprender algo novo, aliás, como está no About do blog, essa foi a minha primeira e maior motivação e desculpa para criar o blog. E fico mais feliz ainda, ao saber que os conhecimentos aqui compartilhados foram/são úteis para alguém.

Como diz aquela propaganda do cartão de crédito: “tem coisas que o dinheiro não comprar” e ajudar uma pessoa é uma delas.

Hora do pedido

O conteúdo do QualidadeBR sempre foi bem tendicioso ao que estou estudando/trabalhando. Acho isso bom, pois não torna a postagem superficial, mas poderia ser melhor.

E como melhor?

Com a participação de vocês 🙂

Mas como eu leitor(a) poderia contribuir para o QualidadeBR?

Com certeza há várias maneiras, particularmente, gostaria de ouvir o que você tem pra falar pessoalmente (isso seria até bom para as pessoas que acham que eu sou virtual rs).

Mas acaba sendo um pouco difícil isso, portanto criei uma conta no Formspring para o QualidadeBR.

Através do endereço abaixo, você pode fazer comentários, críticas, tirar dúvidas, dá sugestões de assuntos que gostaria que fossem abordados, etc:

http://www.formspring.me/QualidadeBR

E qual a minha intenção com isso?

Algumas (hehe):

  • Trazer conteúdos mais pertinentes para o público do QualidadeBR;
  • Aprender com as experiências/problemas de vocês;
  • Ajudar no que for possível em se tratando de testes, conforme a minha disponibilidade e conhecimento é claro;
  • Melhorar a cada post o blog.

Não se acanhe em fazer perguntas sobre Teste e Qualidade de Software, e se preferi, pode fazé-la de forma anônima.

Até mais!

Fique por dentro das novidades, assine o feed do QualidadeBR.

BDD – Behavior Driven Development

Durante a Mesa Redonda do DFTestes sobre “Implementar BDD ou ATDD é possível na realidade?“, percebi que BDD e ATDD são duas siglas pouco conhecidas pela comunidade de Teste de Software brasileira. Portanto, acabei decidindo fazer dois posts para explicar o básico de cada técnica. 🙂

Neste primeiro irei falar sobre BDD, cuja tradução é: Desenvolvimento Direcionado por Comportamento.

Como disse no começo, ambos são técnicas e técnicas para a equipe de desenvolvimento de software, não de teste. Acredito que esse seja o motivo principal, do desconhecimento por parte do pessoal da área de Teste de Software dessas duas técnicas. Porém, é altamente recomendável o pessoal de teste também ter conhecimento sobre elas, uma vez que eles podem ajudar os desenvolvedores na implementação de tais técnicas,.

Mas antes de detalhar e dá algumas opiniões sobre BDD, vou contar um pouco de história.

Surgimento do BDD

Num certo dia, um tal de Dan North estava refletindo sobre as dificuldades dos programadores ao usar TDD:

  • Saber por onde começar;
  • O que testar e o que não testar;
  • Até onde testar;
  • Como chamar os testes;
  • E entender porque um teste falha.

E essas dúvidas e mal entendimentos eram observados com uma certa frequência pelo nosso amigo Dan North.

Foi aí que o Dan North viu a necessidade de criar algo para apresentar TDD de uma maneira direta ao lado iluminado da força. Evitando todas as armadilhas que podem levar o jovem aprendiz a ser tentado pelo lado negro da força.

Dan North então respondeu essa necessidade com a criação do BDD, que possui três princípios básicos:

  • Tudo é comportamento: A área de negócios e a de Tecnologia devem se referir para o sistema da mesma forma;
  • Onde está o valor do negócio: Todo sistema deve ter comportamentos que sejam um verificador do valor para o negócio;
  • Faça o suficiente: Analisar, projetar e planejar tudo de cima para baixo, evitando o detalhamento prematuro.

O BDD evoluiu a partir de práticas ágeis e foi desenvolvida para tornar elas mais acessíveis e eficazes para os times que estão iniciando a entregar software de forma ágil. Com o tempo, o BDD cresceu para abranger também a análise ágil e a automação dos testes de aceitação.

Mas afinal o que é BDD?

Em poucas palavras, o BDD é uma técnica de desenvolvimento de software, onde os programadores desenvolvem o software direcionados por comportamentos. Tais comportamentos são a nível de negócio e ajudam o programador a entender melhor a funcionalidade que será desenvolvida.

Além disso, várias ferramentas (ex.: JBehave e Cucumber) permitem ao programador transformar esses comportamentos em verificações automatizadas.

Melhorando a comunicação

A técnica de BDD confia no uso de um vocabulário bem específico e pequeno, com o objetivo de minimizar a falta de comunicação e garantir que TODOS (stakeholders, desenvolvedores, testadores, analistas e gerentes), não estão apenas na mesma página, mas também estão usando as mesmas palavras. BDD pode ser considerada uma Ubiquitous Language (“Linguagem Onipresente”).

Essa é a grande sacada do BDD, pois permite que todos os envolvidos no projeto possam utilizar da mesma fonte, os comportamentos, para a partir deles realizar o seu trabalho.

Comportamento?

Um comportamento é descrito através de uma história, cujo modelo é:

Como um [X]
Eu quero [Y]
Então [Z]

Onde:

  • X- é a pessoa que será beneficiada;
  • Y- é alguma funcionalidade
  • Z- é o benefício ou valor da funcionalidade;

Esse é um modelo que foi criado pelo Dan e pelo Chris Stevenson. E foi evoluído por eles para algo mais flexível para não ser artificial ou restrito aos analistas e estruturado o bastante para que as histórias possam ser quebradas e possam ser automatizadas. E aí a seguinte forma foi definida para definir um cenário, que está associado a uma história:

Dado algum contexto inicial (entradas),
Quando um evento ocorre,
Então verifique alguns resultados.

hmmm… isso me parece com algo

Sim, se parece com um caso de teste não é?

Entradas, ações e resultado esperado. Essa é a estrutura básica de um caso de teste, e é também a do cenário, proposta pelo BDD. A diferença está nas palavras e forma descrita, afinal é bom lembrar que um caso de teste nem sempre é algo tão entendível para os clientes.

BDD na prática

Eu já utilizei um pouco o BDD usando o Cucumber. E para fechar o post deixo um exemplo de implementação do BDD com o Cucumber, mais a título de exemplo mesmo (não irei explicar como instalar, implementar as steps definitions, executar, etc quem sabe num próximo post). Acredito que com ele fique mais fácil para encaixar as ideias e conceitos apresentados anteriormente.

No Cucumber temos a seguinte nomenclatura básica:

  • Funcionalidade: igual ao modelo de história elaborado pelo Dan e Steve;
  • Cenário: igual ao cenário explicado anteriormente.

Um exemplo de fluxo de BDD seria: cliente defini a funcionalidade e cenários associados a ela > desenvolvedor entender a funcionalidade e cenários e implementar as steps definitions > desenvolvedor roda um comportamento, irá falhar > desenvolvedor implementar o código para o comportamento > desenvolvedor executa o comportamento, que deverá funcionar.

Lembrando que esse é apenas um exemplo de fluxo de BDD, a forma de implementação e pessoas envolvidas pode variar de empresa para empresa, mas o fluxo básico acaba sendo esse mesmo (elaborar e rodar o comportamento, que irá falhar > desenvolver o código para o comportamento > executar o comportamento, que deverá passar), ou seja, igual ao do TDD.

Abaixo um exemplo, mostrando uma funcionalidade e cenários associados a essa funcionalidade:


#language: pt

Funcionalidade: Gerenciar produtos
    Para gerenciar produtos
    Como um usuário
    Eu quero criar, editar, apagar e visualizar produtos

    Cenário: Visualizar os produtos
        Dado eu tenho os produtos iPad, iPhone
        Quando eu vou para lista de produtos
        Então eu devo ver "iPad"
        E eu devo ver "iPhone"
    Cenário: Criar um produto
        Dado eu não tenho produtos cadastrados
        E que eu esteja na lista de produtos
        Quando eu clico "New"
        E eu preencho "Name" com "iPad"
        E eu preencho "Price" com "499"
        E eu aperto "Create"
        Então eu devo ver "Product was successfully created."
        E eu devo ver "iPad"
    Cenário: Editar um produto
        Dado eu tenho o produto iPad
        E que eu esteja na lista de produtos
        Quando eu clico "Edit"
        E eu preencho "Name" com "iPhone"
        E eu preencho "Price" com "199"
        E eu aperto "Update"
        Então eu devo ver "Product was successfully updated"
        E eu devo ver "iPhone"
    Cenário: Apagar um produto
        Dado eu tenho os produtos iPad, iPhone
        E que eu esteja na lista de produtos
        Quando eu clico "Destroy"
        Então eu não devo ver "iPad"
        E eu devo ver "iPhone"

Saiba mais:

Alguns bons artigos em português:

Tradução do Danilo Sato do artigo original do Dan North.

Introduzindo Desenvolvimento Orientado por Comportamento (BDD)

Artigo do Ronaldo Melo Ferraz, onde ele faz algumas considerações sobre TDD e BDD.

Algumas considerações sobre TDD e BDD

Artigo do Urubatan, mostrando algumas diferenças entre TDD e BDD e também o Cucumber.

Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://behaviour-driven.org/

http://blog.dannorth.net/introducing-bdd/

O modelo deveria ser flexível o suficiente para não parecer artificial ou restritivo para os analistas, porém estruturado o suficiente para que pudéssemos quebrar as histórias em pedaços que pudessem ser automatizados. Nós começamos a descrever os critérios de aceitação com base nos cenários, da seguinte fo

O melhor da semana 06/06 a 12/06

Pessoal,

Dentre os interessantes links do o melhor da semana, destaque para a apresentação do Alexandre Gomes (da SEA Tecnologia), na qual ele mostra bem que estamos passando por uma evolução na área de TI, e isso atingi desde a contratação do funcionário até a qualidade do software desenvolvido. Dentre os artigos, destaque para o da Dorothy Graham, que fala que o objetivo dos testes automatizados não deve ser encontrar defeitos, o que pode parecer ser uma afirmação estranha, mas se formos analisar bem, é isso mesmo.

Conhecimento a um clique, esse é o QualidadeBR 😉

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

3º Encontro Mensal do Interior – Regional Sorocaba

Pessoal,

Quem mora em Sorocaba e região já deve conhecer o Encontro Mensal do Interior, organizado anteriormente pelo Robson Agapito e André de Oliveira, ex-membros da ALATS-SP. Agora os dois, junto com o Alexandre Marketti e a comunidade Testadores estão realizando mais uma nova edição do evento.

Desta vez o encontro terá a Renata Fidelis, palestrando sobre “O que é o SCRUM e como adaptar o processo de teste de software para o seu uso”.

O encontro será realizado no dia 24 de junho (uma quinta-feira) das 19:30 até às 22:00 no auditório da UNIP-Sorocaba.

As inscrições podem ser feitas gratuitamente até o dia 23 de junho,  sendo que as vagas são limitadas (50 vagas).  E no dia do evento é necessário levar 1 Kg de Alimento não perecível entregue no dia, que será doado para um instituição carente.

Maiores detalhes do evento podem ser obtidos no link abaixo, para o folder do encontro:

http://bit.ly/3EncontroMensalDoInterior

Você pode também acessar a página do evento no LinkedIn:

http://events.linkedin.com/3o-Encontro-Mensal-do-Interior-Regional/pub/348010

Fique por dentro das novidades, assine o feed do QualidadeBR.