fbpx
Escolha uma Página

O que é uma framework de teste Automatizado de software

O que é uma framework?

Ainda hoje vejo muita confusão em torno do termo framework  (ou arcabouço em português, mas ninguém usa esse termo em português. Eu sempre lembro de calabouço quando falo arcabouço).

É comum as pessoas confundirem biblioteca com framework, dentre outras confusões e dificuldades de explicar de forma simples o que é um framework.

Vou tentar desmistificar isso de uma vez por todas e de uma forma que espero que sera fácil lembrar:

Uma framework é um conjunto de componentes e regras para se fazer algo.

Não é algo exclusivo de computação nem de testes de software pois existem frameworks de gerência de projetos, processos de software, atendimento de usuário, desenvolvimento de alguma habilidade humana, etc.

No caso de frameworks de programação, elas podem ou não conter bibliotecas (lembrando que bibliotecas são pedaços de código bem desenvolvidos, testados e confiáveis para aproveitarmos nos nossos projetos e não precisar fazer tudo na unha do zero). As frameworks podem ser server side, client side, ambos, e por aí vai.

Exemplos: Rails, que é uma framework de ruby; spring que é uma framework de Java; Zend, Cake, que são frameworks de PHP.

Assim, uma Framework nada mais é do que “um jeito” de se fazer algo usando algumas ferramentas.

O que é uma framework de automação de teste de software?

Se uma framework, de forma geral, é “um jeito de se fazer algo usando alguns componentes”, o que é uma framework de testes automatizados? o que ela precisa conter?

Para montarmos uma framework de testes automatizados devemos pensar em quais componentes (programas que nos ajudarão a realizar os testes) e quais as regras que esses programas definirão sobre a forma com que escreveremos nossos testes.

Assim, nossa framework de teste é o conjunto dos programas necessários (cucumber, selenium, capybara, watyr, phantomjs, Rspec…) para realizar os testes juntamente com as regras de como esses testes serão escritos.

O formato de se escrever os testes depende então das ferramentas que usamos para montar nossa framework de teste.

Por exemplo, se em nossa framework usamos Cucumber, é certo que precisaremos ter uma pasta específica para colocar nossas features e os step definitions dessas features, pois isso é uma regra do Cucumber.

E assim por diante, para cada ferramenta que escolhemos usar na framework.

Exemplo de framework de automação de teste de software usando Ruby

Para exemplificar mais detalhadamente, suponha que estamos definindo uma framework para realizar testes automatizados web, e que queremos usar a linguagem Ruby para escrever os testes automatizados.

Assim, um exemplo de framework de testes automáticos usando ruby como linguagem poderá conter os 4 elementos a seguir:

1. Cucumber: para escrever as features (cenários) dos testes de uma forma mais próxima da linguagem humana, usando BDD e também para coordenar os testes. O cucumber funciona como um maestro, controlando a execução dos testes. Se quiser entender mais sobre essas histórias, basta ler esse texto aqui onde falo sobre isso;

2. Rspec: para dar mais poder às verificações e comparaçõs que realizaremos (Ex: eu espero que o texto do botão curtir do facebook seja “curtir”);

3. Capybara: para facilitar a mudança entre os drivers que de fato executam os testes nos browsers, fazendo com que os testes tenham baixo acoplamento nas camadas mais baixas (não sejam dependentes dos drivers que de fato executam as ações nos browsers);

4. Selenium: driver dos testes;

Além dessas ferramentas que se tornam padrão para todo teste que escrevemos a partir da definição da framework, ainda é possível a inclusão de varias outras bibliotecas (gemas no caso de ruby) para ajudar no teste, quando necessário.

Podemos por exemplo variar os drivers, e ao invés de usar Selenium, usar Rack::Test  no lugar do selenium, ou ainda incluir gemas para lidar com JSON, XML, etc.

O importante na hora de definir uma framework de testes automatizados é que o conjunto das ferramentas escolhidas para compor a framework auxilie na escrita e manutenibilidade desses testes e não seja motivo de confusão para a equipe tornando os mais complicados e ineficientes.

Conclusão

Viu que não tem segredo a definição de framework? espero que a partir de agora você possa não ter mais medo das frameworks, seja lá onde for usá-las.

Além disso, que tal usar os 4 elementos indicados acima para selecionar e montar sua própria framework de testes automatizados de software?

Deixa aí nos comentários quais as ferramentas estão presentes na sua framework de teste =}

Além disso, um bom vídeo para começar com a área de testes é esse aqui:

Grande Abraço, e até a próxima.

Referências

Se quiser saber mais sobre a história do selenium, tem esse ótimo texto aqui em inglês que explica o histórico da criação do selenium;

Esse outro texto compara umas ferramentas de teste;

Como escrever boas user stories (histórias de usuário) para automatizar com BDD

 

Você sabe o que é BDD (Behaviour Driven Development)? se não sabe, pelo menos já ouviu essa sigla em algum lugar.

Neste texto eu explico o que é BDD e também como escrever boas user stories (histórias de usuários) com cenários de teste, que serão muito úteis para automação dos testes.

O que é BDD 

O mais comum no contexto de desenvolvimento de software é ouvir falar pelo menos de TDD (Test Driven Development), que é a técnica que originou o BDD.

De forma simplificada, o BDD (behaviour driven development) ou também conhecido como especificação por exemplo, é uma técnica de desenvolvimento ágil que incentiva a colaboração entre os membros da equipe e tem como foco a descrição do comportamento do programa que será construído.

Essa forma de trabalho pode ser utilizada independente do tipo de software que será produzido: programa de desktop, app, mobile, web…

Ao definir o funcionamento do programa que será feito, existe a colaboração de especialistas de várias áreas: qa’s (testadores), product owners (gerente de produto), business analysts (analistas de negócios). Essa colaboração é conhecida como three amigos.

Observe que essa colaboração de especialistas de diversas áreas não é algo totalmente novo e específico do BDD, mas é algo pregado pelo próprio manifesto ágil e presente em outros métodos ágeis como SCRUM ou XP. 

Na hora de testar o software focaremos também em se testá-lo ponto de vista do seu comportamento

Isso quer dizer que ao se desenvolver os casos de teste, o foco é no comportamento do software, de forma mais ampla, ao contrário do que fazemos no “teste de software clássico”, no qual detalhamos bem tecnicamente os casos de teste.

Apesar do que muita gente pensa, o BDD não é uma técnica de teste que existe apenas para automatizar os testes, mas uma técnica de desenvolvimento que ajuda a construir melhores testes.

O ponto central do BDD está em descrever o comportamento do software (e consequentemente, os testes) antes de codificar o software de modo que os testes guiem o desenvolvimento do software.

Assim, se escrevermos os testes somente após o software estar pronto, isso não é aplicar o BDD corretamente porque os testes não estão guiando o desenvolvimento.

Com essa forma de realizar testes, também é possível criar testes que execitem o fluxo inteiro de determinada função (end to end testing) e não somente uma função específica.

Por que usar BDD?

Usar o BDD ajuda melhorar a qualidade do produto de uma forma geral pois incentiva a colaboração da equipe desde o início, promovendo o alinhamento do conhecimento desde o início.

É interessante descrever o funcionamento do software nesse formato porque várias ferramentas de teste são capazes de executar esses cenários de usuário. Isso ajudará a criar os casos de testes mais rapidamente.

Além disso, usar o BDD falicita a conversa e o entendimento entre as equipes, ajuda na legibilidade e desacopla a descrição das funções do software das questões técnicas das implementações dos testes.

Um exemplo de ferramenta muito famosa que possui esse poder é o cucumber, que fornece suporte para várias linguagens de programação (Java, Ruby …) e idiomas (Inglês, Português …).

Como escrever  boas histórias e bons cenários de BDD

Os cenários são escritos usando o padrão composto por palavras chave:

As-I want-so (Como-Eu quero-Para) 

given-when-then (dado-quando-então).

Cada uma dessas palavras chave é usada da seguinte forma:

Como 

Papel que desempenha alguma ação no produto em teste

Eu quero

Realizar alguma ação no produto sobre teste

Para

Algum resultado específico, ou que algo seja feito

Cenário 1

Dado

Pré condições  para o meu teste

Quando

Realizo alguma ação no meu produto em teste

Então

Alguma coisa deve acontecer (o que eu quero que aconteça e irei verificar no meu teste)

Cenário 2

Dado

… 

Quando

… 

Então

….

Além dessas palavras chave acima, podemos usar a partícula “E” para compor cenários mais complexos.

Exemplo de história de usuário com cenários

Como: cliente do banco “Porquinho da felicidade” eu tenho o app do banco instalado no meu celular

Eu quero: ser capaz de controlar a minha conta corrente a partir do app

Para: ter melhor controle sobre meu dinheiro

Cenário 1: realizar transferências da conta corrente 

Dado: que eu esteja logado na minha conta do banco;

E: possua um limite de conta maior que 0 ;

Quando: eu tentar realizar a transferência de um valor maior que 0;

E: menor que o limite de transferência pelo app;

E: menor que o limite da minha conta;

Então: o banco deverá autorizar e realizar a transferência do dinheiro; 

E: eu devo rececber um sms confirmando a transação bancária. 

Observe que esses cenários não entraram em detalhes técnicos como:

qual a tela do app eu devo clicar?

em qual botão o clique será realizado?

devo estar logado com a conta XPTO?

qual o tempo de sessão do app?

a cor do texto é vermelha, verde, amarela? 

Essa “ausência de detalhes” é de propósito. Ou seja, não queremos detalhar muito os nossos cenários, a ponto de eles ficarem exatamente iguais os casos de teste clássicos cheios de informação e impossíveis de se manterem atualizados. 

Cuidado com Ambiguidades

Toda língua que não seja fomal é cheia de ambiguidades. É importantíssimo prestar atenção e tomar cuidado com ambiguidades ao escrever as histórias de usuário e os exemplos.

É bem fácil escrever algo ambíguo em Português, que será claro para quem está escrevendo mas não tão claro para outros membros da equipe. 

Uma boa forma de procurar por ambiguidades, é isolar cada palavra em uma frase em busca dos sentidos que eles podem ter. Escrever as histórias nas reuniões de refinamento do backlog também é uma boa prática que auxilia evitar descrições incompletas ou confusas.

Concluindo

O mais importante na hora de escrever essas histórias no formato BDD é focar em comportamentos. A granularidade dos testes irá depender da necessidade do produto em teste, assim como explico nesse texto aqui sobre casos de teste.

Me Avise da

próxima turma do

Curso Online:

"Como escrever melhores user stories com BDD"

OLINE