Introdução Flashcards

1
Q

Qual o problema que o BDD resolve?

A

Problemas de entrega de valor.
Softwares entregues sem as features requisitadas
Softwares com entrega atrasadas ou que são cancelados

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Processo de desenvolvimento comum

A
  1. Aquele que têm a lógica de negócio fala para o analista de negócios o que ele quer
  2. O analista de negócios escreve um documento de requisitos
  3. O desenvolvedor transforma os requisitos em software
  4. O testador transfoma os requisos em casos de teste
    5a. O produto finalizado é entregue ao cliente.
    5b. O escritor técnico escreve a documentação
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Processo de desenvolvimento proposto pelo BDD

A
  1. Aquele que têm a lógica de negócio e o analista de negócios discutem sobre o que o négocio precisa
  2. O analista de negócios, o desenvolvedor e testador escrevem os requisitos do software juntos. Eles estruturam os requisitos em uma linguagem natural e ubíqua
  3. O desenvolvedor transforma os requisitos em software
  4. O testador transfoma os requisos em casos de teste
    5a. O produto finalizado é entregue ao cliente.
    5b. O escritor técnico escreve a documentação
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Processo de desenvolvimento proposto pelo BDD

A
  1. Aquele que têm a lógica de negócio e o analista de negócios discutem sobre o que o négocio precisa
  2. O analista de negócios, o desenvolvedor e testador escrevem os requisitos do software juntos. Eles estruturam os requisitos em cenários com uma linguagem natural e ubíqua
  3. O desenvolvedor transforma os cenários em software com a ajuda dos testes automatizados
  4. O testador usa os cenários como base para os testes
  5. Os testes automatiados provêem feedback do progresso e ajudam a documentar a aplicação
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Qual as duas principais razões de falha de um processo de desenvolvimento?

A

Não construir o software direito

Não construir o software certo

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

O que é construir o software direito?

A

Se concentrar em como fazer o software

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

O que é construir o software certo?

A

É construir o software que atenda a necessidade do negócio

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

O que acontece se se concentrar somente em construir software direito?

A

Um software que não satisfaz o cliente

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

O que acontece se se concentrar somente em construir o software certo?

A

Um software difícil de manter e extender

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

O que é o BDD?

A

Um conjunto de prinpícios baseados em metodologias ágeis e de engenharia, principalmente DDD e TDD para processos de desenvolvimento.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Quem criou o BDD e por que?

A

Dan North como um jeito fácil de ensinar TDD

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Quem criou o TDD e basicamente como funciona?

A

Kent Beck. Basicamente é criar um teste para uma feature, criar um código básico para que o teste passe, refatorar o código para conseguir um bom design.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Quais os problemas do TDD?

A

Desenvolvedores muitas vezes têm dificuldade em saber onde começar a testar ou o que testar em seguida.
As vezes TDD faz com o que o desenvolvedor fique focado em detalhes e esquecer a visão ampla do que o projeto precisa.
Grandes números de testes unitários acabam ficando difíceis de manter.
Os testes focam em funções e não em termos de negócio.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Como BDD melhora o TDD?

A

Ele foca no comportamento das classes e não em métodos.

Uma forma é por assinar o método de teste com ‘should’ e a descrição do que a classe deve fazer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Como BDD melhora a análise de software?

A

Usando uma linguagem ubíqua e estruturada, o Gherkin

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Outras nomes que significam o mesmo que o BDD

A

Acceptance-Test-Driven-Development(ATDD)
Accept-Test-Driven Planning
Specification By Example

17
Q

workflow BDD

A

Comece por identificar os OBJETICOS DE NEGÓCIO.
OBJETIVOS DE NEGÓCIO são constituídos por FEATURES.
FEATURES são ilustradas por EXEMPLOS
ESPECIFICAÇÕES EXECUTAVEIS guiam o desenvolvimento e os testes

18
Q

Como se subdivide as ESPECIFCAÇÕES EXECUTÁVEIS

A

Documentação viva: Ajuda testadores, analistas de negócios e usuários a saber o que está sendo feito.
Relatórios em tempo real: Quanto foi feito, quanto precisa ser feito
Documentação técnica: Faz o código fácil de manter e atualizar
Validação automática: Regressão automática e testes automáticas vêm como consequência
Features funcionais: O código em funcionamento

19
Q

Princípios BDD

A

Foco em features que entregam valor
Especifique features em grupo
Abrace incertezas
Ilustre features com exemplos
Não escreva testes automatizados, escreva especificações executáveis
Não escreva testes unitários, escreva especificações de baixo nível
Entregue documentação viva
Use documentação viva para apoiar trabalho de manutenção em progresso

20
Q

O que envolve o princípio:

Foco em features que entregam valor

A

Feature é uma peça de funcionalidae que ajuda o negócio a atingir o seu objetivo.
Ao invés de levantar todos os requisitos de uma vez, conversar com stakeholders e usuários finais pogressivamente que funcionalidade precisam.
Ao invés de receber uma lista de funcionalidades do cliente e não questionar nada, procurar entender o real motivo de negócio e sugerir funcionalidades que sejam realmente úteis.

21
Q

O que envolve o princípio:

Especifique features em grupo

A

Testadores e desenvolvedores têm a oportunidade de fornecer seu know-how, além de ficarem mais engajados e responsáveis pelo produto.

22
Q

O que envolve o princípio:

Abrace incertezas

A

As especificações do que deve ser desenvolvido nunca são entendidas no início, por isso entregue features com valor o quanto antes para receber o feedback ao invés de esperar ficar tudo pronto para saber se era realmente ncessário

23
Q

O que envolve o princípio:

Ilustre fatures com exemplo

A

Quebre as features em User Stories com Gherkin.

Crie exemplos para casos perfeitos e casos alternativos

24
Q

O que envolve o princípio:

Não escreva testes automatizados, escreva especificações executáveis

A

Ao escrever features você pode utilizar ferramentas que permiter executar essas especificações e gerar a documentação, deixando o processo de verificação ágil.

25
Q

O que envolve o princípio:

Não escreva testes unitários, escreva especificações de baixo nível

A

BDD não possui testes unitários, possui especificações de baixo nível.
Visto ter uma perspectiva top-down cada especificação define a próxima especificação necessária.
Normalmente é escrita como uma ferramenta de teste unitário

26
Q

O que envolve o princípio:

Entrega documentação viva

A

Ferramentas de automatização de features também devem gerar documentação atualizada com a versão mais recente do software, permitindo ser entregue até o cliente para que ele possa ver de forma clara as features e o progresso de desenvolvimento.

27
Q

O que envolve o princípio:

Use documentação viva para apoiar trabalho de manutenção em progresso

A

Quando uma manutenção precisa ser feita em um código (o que representa de 40 a 80% do custo) muitas vezes são outros desenvolvedores que precisam fazer, tendo uma documentação das features eles podem entender as regras de negócio da aplicação, tend especificações em baixo nível ele pode entender as especificações da classe.

28
Q

Beneficios do BDD

A

Reduz desperdício: somente o que é realmente necessário
Reduz custo: Por evitar funcionalidades de pouco valor, e por focar em código bem feito
Mudanças fáceis e seguras: Devido a documentação viva stakeholders e desenvolvedores podem entender o que o código realmente faz.
Entregas rápidas: Testadores não precisam mais executar longos testes manuais e verificações antes de entregar o software

29
Q

Desvantagens do BDD

A

BDD requer muita colaboração e participação dos que possuem entendimento de negócio
BDD funciona melhor em ambientes ágeis ou contexto iterativos
BDD não funciona bem em empresas muito grandes que trabalham com projetos muito definidos em que um setor aguarda o artefato do anterior e envia para próximo
Testes automatizados não bem projetados, quando se tornam muitos, ficam muito difíceis de manter aumento o custo

30
Q

Projetos de sucesso precisam construir software com …

A

confiabilidade e livre de bugs, com features que entregam valor real

31
Q

Praticantes de BDD procuram entender o que precisam fazer por meio de …

A

conversas sobre exemplos concretos

32
Q

Exemplos concretos são base para o desnenvolvimento de …

A

testes de aceitações (especificações), para saber quando a feature está pronta

33
Q

Critérios de aceitação podem ser automatizados com … que produzem …

A

ferramentas como Cucumber, JBehave

testes de regressão, documentação e relatórios

34
Q

praticantes de BDD criam features em uma abordagem …

A

top-down usando especificações como alvo e descrevendo o comportamento de cada componente com testes unitários

35
Q

Os principais benefícios do BDD são

A

focar o esforço em entregas de valor, reduzir desperdício de esforço e custo, fazer as mudanças e manutenções ficarem mais fáceis e acelerar o processo de entrega