TestOps

    Wearing the Operations hat is no more a role exclusive of Developers, being the so called DevOps. Nowadays we can evidence the fact that Testers are also starting to wear the Operations hat and getting involved into more technical tasks; going deeper than just the usual writing and executing test cases.
     On October, 2011, Simon Munro wrote in his blog about the ideal Quality Assurance professional for the cloud computing era, calling him a TestOp; then Seth Elliot, from Microsoft, also wrote about the new term in the Software Test Professionals magazine. The term TestOp defines the future of the Quality Assurance professional.
    Being a TestOp is, for example: getting involved with Continuous Integration, with the Deployment process,  being able to use an operating system like Linux or Unix, setting up the environment for test automation. Also setting Continuous Integration server jobs, looking for plugins and tools and configuring it. Those are some sort of activities that a regular Tester is not used to acting on.
    Another important topic is computer programming, the regular Tester is fearful and avoids it. The TestOp is used to automating tasks, writing automated test scripts and dealing with test automation frameworks. Programming should be one of the main activities of the TestOp.
    The term was initially related to the cloud computing revolution but it is way broader and could be applied to all sort of environments.
 

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...

TEST AUTOMATION (Human) PATTERNS

 

Aproveitando o diagrama TEST AUTOMATION PATTERNS de Dorothy Graham, consultadora britância em testes de software, podemos ver alguns fatores humanos entre os muitos fatores técnicos citados:

• Pode parecer banal mas é importante para a motivação da equipe, 'CELEBRATE SUCCESS', celebrar o sucesso não somente com um obrigado mas em alguns casos de maior importância pode ser comemorado com um evento mais elaborado, premiação ou homenagem.

• Outro fator como 'ASK FOR HELP' evidencia que falta de comunicação, timidez ou egos inflados podem ser bloqueantes para o sucesso do projeto, causadores de perda de tempo (dinheiro) e retrabalho. Comunicar-se de forma fluente entre a equipe, praticar o 'WHOLE TEAM APPROACH' e eliminar os ruídos são essenciais para manter o ambiente ágil e alinhar pensamentos, expectativas e egos.

• 'LEARN FROM MISTAKES' para aprender com os erros primeiro é necessário assumir o erro e estar pronto (open-minded) para receber feedback. A Retrospectiva (prática ágil) é uma ferramenta.

•    'PAIR UP'; trabalhar em pares, saber ouvir e interromper quando necessário, dar idéias e entrar em discussões construtivas.

• 'LAZY AUTOMATOR' é um fator curioso pois a pessoa que é 'preguiçosa' irá pedir ajuda, não irá reinvertar a roda e usará o que já estiver pronto em termos de código, frameworks, bibliotecas e outra ferramentas. Acaba sendo produtiva essa atitude de preguiça sadia.

Os demais fatores podem ser vistos como técnicos mas também requerem atitude, coragem, disciplina, motivação e outros fatores humanos. 

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.