Ao desenvolver uma nova função de software ou modificar algo existente, precisamos ter uma forma de dizer que o trabalho está finalizado.
Como dizer que algo que a equipe se comprometeu entregar está terminado? ou seja, pronto?
Observe as diferentes respostas que podemos obter ao perguntar para diferentes membros de uma equipe ágil:
desenvolvedores: eu entendo como finalizado quando não há mais o que ser codificado, e meus testes unitários e de integração foram codificados e estão rodando com sucesso;
testers (QA/QE): eu finalizari a codificação dos tester automatizados, os testes foram executados e passaram com sucesso e nenhum defeito severo foi encontrado;
product owner: eu entendo como pronto quando o que eu pedi foi desenvolvido, foi testado e está em produção funcionando corretamente.
Durante o ciclo de desenvolvimento de software, uma função em desenvolvimento pode receber diversos status que simbolizem em qual momento do processo ela está, por exemplo:
em codificação, pronta para teste, em teste, bloqueado, etc.
No entanto, o status final que ela recebe deve ser bem conhecido e entendido por toda a equipe.
Mas então, quem está certo? quando dizemos que uma função está pronta (finalizada/entregue)?
No contexto de equipes ágeis, especialmente as que utilizam Scrum, que é o método ágil mais popularmente utilizado, é necessário que a equipe entre em acordo sobre o que é dizer que algo está pronto.
Seja uma nova função, ou modificação de funções existentes, essa definição de pronto (definition of done) é muito importante para que todos falem a mesma língua e estejam alinhados sobre o término de algo que a equipe entrega.
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:
-um conjunto de instruções ( ou seja, aqueles programas que falamos no item anterior) que, quando executadas, produzem a função e o desempenho desejados;
-estruturas de dados que possibilitam que os programas manipulem corretamente as informações;
-documentos que descrevem a operação e o uso dos programas.
-Software não é apenas o programa, mas também toda a documentação associada e os dados de configuração para fazer com que eles operem corretamente.
Assim, podemos pensar em software como algo mais abstrato, intangível, não palpável que envolve não só as instruções para o computador propriamente ditas, mas todas as informações para fazê-lo funcionar.
De forma geral, um Bom Software (de boa qualidade) é aquele que entrega as funções e desempenho que o usuário espera. Além disso, ele deve ser manutenível, usável, dentre outras características de qualidade.
O que é um sistema?
Se um programa é um conjunto de instruções e software é um conjunto de instruções + documentação e dados, como diferenciar sistema?
Segundo, Sommerville: um sistema é um conjunto de componentes inter-relacionados que funcionam juntos para atingir um certo objetivo. Essa definição de sistema é conhecida em algumas outras áreas como engenharia de sistemas e outras.
Exemplos de sistemas que encontramos no nosso dia a dia:
– sistemas de computador;
– sistemas operacionais;
– sistema educacional;
– sistema de governo;
– sistema de abastecimento;
– sistema bancário;
– sistema elétrico, etc.
Quando falamos de um sistema de software estamos falando de mais do que um único componente (mais do que um único programa ou software).
O sistema é formado por um determinado número de programas separados e arquivos de configurações para eles, podendo incluir documentação específica para descrever a estrutura do sistema, documentação de usuário, etc;
O fato de um sistema ter documentação é uma das principais diferenças entre desenvolvimento amador (sem documentação) e profissional (outros vão usar, então precisa de explicação em bons documentos).
Resumindo
Software x Programa x Sistema são termos muitas vezes usados de forma intercambiável, porém que para a computação, e em especial Engenharia de Software, possuem significados bem diferentes.
Toda área profissional tem suas terminologias bem definidas no teste de software, isso não seria diferente.
Sendo assim, trago aqui uma lista simples com alguns termos e seus significados na área de teste.
Anomalia: qualquer sintoma, comportamento ou resultado diferente do esperado ou previsto.
Ciclo de Teste: Execução da massa de teste sobre o produto de software a cada versão que é liberada. Um passo pode conter um ou mais ciclos de teste.
Critério de Cobertura: de maneira simplificada é o que define regras práticas para quando parar os testes. Porcentagem do software que será testada e a equipe entende como aceitável. Ex: 75% de cobertura.
Defeito/Bug: passo, processo ou definição de dados incorretos. Ou ainda qualquer problema existente no software ou sistema sob teste que pode causar sua falha em atender as expectativas do usuário. Em outras palavras, um defeito é uma fonte potencial de insatisfação com o produto.
Engano: ação humana que produz um defeito. Erro: estado inconsistente, observado em momento de execução, de um produto ou sistema de software. Esse erro pode ou não causar uma falha.
Falha: estado inseperado do produto ou sistema de software ocasionado por um erro.
Ferramenta de teste: qualquer ferramenta de hardware e/ou software utilizada durante a execução de um caso de teste. Podendo ser utilizada para configurar o ambiente, criar condições de teste, ou medir os resultados dos testes. Uma ferramenta de teste geralmente é separada do caso de teste em si. Ex: Postman, Selenium, etc.
Feedback de usuário: informações do ponto de vista de usuário sobre determinado produto, atividade, ou assunto. Pode ainda ser entendido como a avaliação de determinado assunto.
Passo de teste: (test step): cada instrução presente em um caso de teste. Ex: abrir a página do google; digitar “vinicius pessoni”; clicar no botão pesquisar.
Testadores (Teters, QA- Quality Assurance, QE – Quality Engineer): responsáveis por configurar o ambiente de teste, iniciar os testes, interpretar resultados, reproduzir anomalias manualmente, isolar defeitos por experimentação, e restaurar o ambiente ao seu estado anterior à configuração para execução do teste. Em adicional possuem a responsabilidade de dar manutenção no sistema de teste, especialmente nos casos e conjuntos de teste.
Teste de Unidade ou Componente: testa a menor parte de um software, definido quando utilizado. Exemplo: função, método, classe.
