How to set the Definition of Done of User Stories?

Agile teams tend to have a hard time while defining the Definition of Done - DoD of user stories (requirements).  The user requirements are defined, documented, approved and passed on to the development team for estimation and implementation (coding). But how can the agile team clearly state that they delivered what was defined on user stories?
The best way to accomplish this is by having user acceptance automated tests. Those tests can be written in the Gherkin language, forming a live and dynamic documentation. If a test fails, a requirement fails. If a test pass, it proves that the user story is complete and correctly implemented.
Delivering a requirement is demonstrating that it is working as expected and guaranteeing that the DoD has been fulfilled can be accomplished by having the acceptance tests passing.

Gherkin: Declarativo VS. Imperativo

Ao escrever testes de aceitação utilizando uma linguagem de negócio como o Gherkin; tendemos a escrever de forma imperativa. Ou seja, definindo explicitamente os elementos da interface (UI) com os quais o usuário deverá interagir.
Por exemplo, definir exatamente quais botões ou quais elementos de um formulário devem ser clicados ou preenchidos, fará com que seu Gherkin tenha que ser reescrito caso a interface se altere.

Veja os exemplos abaixo.

Modo imperativo:

Funcionalidade: Receber email ao preencher formulário de cadastro

    Dado que o usuário clicou em "Fazer novo cadastro"

    Quando preenche os campos "Nome", "E-mail", "Senha" 

    E clica no campo de "Aceito os termos do contrato"

    Então ele recebe um email confirmando seu novo cadastro

Modo declarativo para a mesma funcionalidade:

    Dado que o usuário deseja fazer um novo cadastro

    Quando preenche os campos obrigatórios

    E aceita os termos do contrato

    Então ele recebe um email confirmando seu novo cadastro


Devemos manter por padrão a forma declarativa, a intenção da linguagem Gherkin é explicitar casos de uso em linguagem de negócio. Detalhes da interface devem ser encapsulados por frameworks como PageObject e detalhes de navegação por frameworks como Capybara. Esse frameworks ficam para um próximo post...

Evolução (natural) do profissional de Software Quality Assurance

Automação de testes, BDD, TDD, ATDD, Agile, Integração contínua, Testes exploratórios e outras keywords não podem mais ser ignoradas pelos testadores; principalmente o fato de não saber ou não querer se envolver com programação. O testador que somente executa testes manualmente pode estar com seus dias contados ou perder muito em produtividade caso não se envolva com as mais novas práticas. Viemos para mostrar que fatores não técnicos como: coragem, atitude, pró-atividade, relacionamento interpessoal, respeito, motivação e trabalho em equipe são essenciais para um testador. Com esses fatores em prática, podemos nos nivelar e ganhar o respeito de desenvolvedores, designers, analistas de negócios e de outros testadores, levando-os a pensar em soluções com qualidade desde o início. Testar manualmente tem sido o mais comum, o de praxe, mantendo muitos testadores na ‘zona de conforto’; devemos quebrar esse paradigma e fazer com que a programação facilite nosso trabalho e faça com que testes manuais exerçam nossa criatividade, senso critico, detalhismo e nossa inteligência, deixando para que a máquina faça o trabalho repetitivo. Bem vindos à nova era do Software Quality Assurance.