Qualidade de software e Selenium IDE em testes funcionais

Hoje em dia é possível perceber uma preocupação maior das empresas de TI com relação à qualidade dos softwares por ela desenvolvidos. Estão se preocupando cada vez mais com a melhoria nos processos de desenvolvimento de software. Neste cenário, é possível definir o termo qualidade como “atendimento às necessidades do cliente”, “conhecimento do processo para melhorá-lo” ou também “seguir o padrão”.

Essa preocupação não fica só com os fornecedores de software, mas também com os clientes que estão ficando cada vez mais exigentes em relação à qualidade do produto que irão receber. Uma prova disso é que, na maioria das concorrências e licitações, eles exigem que o fornecedor seja certificado, por exemplo, MPS.BR ou então CMMI. E a exigência não para por aí! Não é somente ter uma dessas certificações, mas sim ter as certificações com, pelo menos, um nível médio de maturidade, ou seja, o fornecedor precisa ter, no mínimo, MPS.BR nível C ou então CMMI nível 3.

Mas, o que é qualidade de software? Resumidamente, qualidade de software é utilizar boas metodologias para se desenvolver um produto. As metodologias foram criadas com base em experiências já vividas, e assim, pode-se verificar o que se deve ou não fazer durante o desenvolvimento de um software.

Garantir a qualidade de software é algo de extrema importância durante o seu desenvolvimento. Imagine um software financeiro, um Internet Banking, por exemplo, que não tenha passado por um rigoroso teste. Esse tipo de software não pode conter qualquer falha, ele trata do dinheiro das pessoas. Imagine o prejuízo do banco caso alguma transação financeira seja processada incorretamente?

Porém, cada tipo de software tem as suas características específicas de qualidade e a importância de cada uma dessas características depende do tipo de software que está sendo construído. Existem fatores de qualidade que são genéricos para qualquer tipo de software, contudo, para os requisitos em si, não é possível generalizar. Um exemplo disso é: para emitir uma nota fiscal no site da Prefeitura de uma cidade, é preciso que a empresa emissora dessa nota fiscal tenha um certificado digital. Verificar se esse certificado digital é válido é um requisito de extrema importância para garantir a qualidade desse software. Já para um cadastro para recebimento de Newsletter em um site de compras, esse requisito não tem importância alguma. Nesse caso, um requisito de garantia de qualidade é validar se o e-mail informado realmente possui um formato de e-mail válido.

Um dos fatores que impacta diretamente na qualidade de um software é sua complexidade. Um software muito complexo requer uma documentação muito grande, um número grande de pessoas efetuando definições e, um alto número de iterações entre os componentes desse software. Claro que é possível se ter qualidade em um software dessa natureza, porém o trabalho para se controlar essa qualidade é maior.

Nesse artigo iniciaremos nossa discussão sobre qualidade discutindo brevemente dois modelos de maturidade que auxiliam na garantia da qualidade de software, relacionadas a melhoria dos processos da empresa: MPS.BR e CMMI.

O MPS.BR (Melhoria do Processo de Software Brasileiro) foi lançado em 2003 durante uma reunião no Ministério de Ciência, Tecnologia e Inovação. Esse programa foi criado para melhorar a capacidade de desenvolvimento de software nas micro, pequenas e médias empresas brasileiras, que possuem pouco recurso mas que precisam melhorar os processos de desenvolvimento de software.

As maiores vantagens do MPS.BR são:

- Maior quantidade de níveis de maturidade, sete no total, o que permite às empresas uma implementação mais gradual, que melhor se adéqua a empresas pequenas;

- Custo bem acessível com avaliações das empresas certificadas a cada dois anos;

- Total compatibilidade com CMMI e com a Norma ISO/IEC 15504.

Já o CMMI (Capability Maturity Model Integration) é um modelo evoluído do SW-CMM (Capability Maturity Model for Software), criado no final da década de 1980 pelo SEI (Software Engeneering Institute) para a melhoria de processos. De acordo com o CMMI Institute, ele é um modelo de melhoria de processo que pode ser adaptado para resolver qualquer problema de desempenho em qualquer nível da organização em qualquer setor. Ele está em total acordo com a Norma ISO/IEC TR 15504.

O principal objetivo do CMMI é servir de guia para que as empresas melhorem seus processos e, com isso, possam ser mais eficientes, respeitando seus prazos e entregando softwares com uma menor quantidade de erros. Para se ter a melhoria de processos, é preciso dar pequenos passos, evoluir aos poucos.

Controle da Qualidade Total

O Controle da Qualidade Total (TQC – Total Quality Control) foi desenvolvido no Japão pela Union of Japanese Scientists and Engineers (JUSE) para se implementar a melhoria contínua da qualidade. No TQC todos os funcionários da empresa, de todos os setores, independente do cargo que ocupam, participam do processo dando sugestões de melhorias.

Os princípios básicos do TQC são:

- Produzir e fornecer produtos e/ou serviços que atendam concretamente às necessidades do cliente;

- Garantir a sobrevivência da empresa através do lucro contínuo, adquirido pelo domínio da qualidade;

- Identificar o problema mais crítico e solucioná-lo pela mais alta prioridade;

- Falar, raciocinar e decidir com dados e com base em fatos;

- Gerenciar a organização ao longo do processo e não por resultados;

- Reduzir metodicamente as distorções através do isolamento e suas causas fundamentais;

- Não permitir a venda de produtos defeituosos;

- Não repetir erros;

- Definir e garantir a execução da visão e estratégia da alta direção da empresa.

O TQC adota como uma das principais formas de implementação de controle de processos o PDCA (ver Figura 1). O ciclo PDCA (Plan-Do-Check-Act), também conhecido como ciclo de Shewhart, é uma ferramenta de qualidade utilizada no controle e melhoria contínua do processo para solução de problemas. Foi criada por Edward Deming, o pai do controle de qualidade moderno há mais de 70 anos. Ele possui quatro fases:

1- Plan (Planejar): Primeira etapa do ciclo de melhoria contínua. É a etapa onde são estabelecidos os objetivos a serem alcançados, o caminho para se alcançar esses objetivos e o método que será utilizado para se chegar ao objetivo. Esses objetivos definem o resultado ao qual se está buscando;

2- Do (Executar): Essa é a etapa onde o plano definido anteriormente é executado. É a etapa onde o produto é desenvolvido e onde são colhidos os insumos para as próximas etapas;

3- Check (Verificar): Nessa etapa os insumos colhidos anteriormente são verificados. É feita uma análise para se descobrir se o resultado atual corresponde ao resultado esperado. São procuradas diferenças nesses resultados, ou seja, falhas no processo;

4- Action (Agir): Nessa etapa são tomadas ações corretivas sobre as diferenças dos resultados planejado e atual, encontradas na etapa anterior. Essas diferenças são analisadas para que as causas que as geraram sejam encontradas e, assim, medidas de melhoria do processo sejam aplicadas.

Figura 1. Método PDCA.

Esse ciclo pode ser utilizado, por exemplo, para melhorar processos que são executados frequentemente ou para diminuir a utilização de mais recursos do que o necessário na execução de determinadas tarefas.

Ferramenta de apoio à qualidade de Software

No mercado existem algumas ferramentas que possibilitam a automação de testes para softwares desenvolvidos para Web, porém, a preferida de grande parte das empresas é o Selenium, é uma ferramenta OpenSource que possibilita a execução de testes de regressão frequentes, a criação e a execução de casos de teste, o reporte customizado de defeitos além de dar um feedback rápido aos desenvolvedores.

Uma das grandes vantagens do Selenium é a possibilidade da realização de testes em qualquer navegador que tenha suporte ao JavaScript. Ele é composto por três ferramentas principais: Selenium-IDE, Selenium-RC e Selenium-GRID.

O Selenium-IDE captura, através de gravação, todas as ações feitas pelo testador e gera um script de teste, onde é possível reexecutar todas as ações que o testador desejar. O Selenium-RC (Remote Control) permite ao testador criar lógicas mais avançadas de teste, através do uso de uma linguagem de programação. Para efetuar esse teste mais complexo, o Selenium disponibiliza uma API e bibliotecas para cada linguagem de programação que ele suporta (C#, HTML, Java, Perl, PHP, Python e Ruby). Já o Selenium-GRID é ideal para se fazer testes em múltiplas máquinas, reduzindo assim o tempo que seria gasto para a execução de uma suíte de teste. Esta ferramenta atua executando múltiplas instâncias do Selenium-RC em paralelo e de forma transparente, não sendo necessário se preocupar com a infraestrutura.

A Figura 2 apresenta a tela inicial do Selenium-IDE. Nesta tela é possível gravar as ações a serem feitas para se construir um caso de teste, controlar a velocidade de gravação, executar a(s) gravação(ões) feita(s), executar o caso de teste passo a passo, dentre outras possibilidades.

Figura 2. Tela inicial do Selenium.

A seguir, serão descritas algumas facilidades disponibilizadas pelo Selenium.

Construção do Caso de Teste

A ferramenta Selenium permite a criação de caso de teste. Na sequência são descritas as maneiras de se criá-lo.

Gravação

É possível criar os casos de teste a partir da gravação das interações do testador com o website. Assim que o Selenium é iniciado, a gravação já está ligada e tudo o que for feito no website será gravado para que, posteriormente, essa gravação seja executada efetuando assim a automação do teste.

Durante a gravação, comandos serão incluídos no caso de teste de acordo com as ações executadas pelo testador como, por exemplo, clique em links e inserção de valores.

Comandos de Verificações e Afirmações (Asserts)

É necessário que os casos de teste chequem as propriedades do site que está sendo testado. Essa checagem precisa ser efetuada através de comandos de verificação e afirmação (assert). É possível visualizar esses comandos deixando o Selenium IDE gravando e clicando com o botão direito do mouse em qualquer área do site. É exibida uma lista de comandos possíveis, conforme mostrado na Figura 3. Uma outra maneira de utilizar esses comandos é através do próprio Selenium-IDE. A Figura 4 mostra uma lista existente nele com alguns dos comandos assert existentes.

Figura 3. Comandos de verificações e assert.

Figura 4. Exemplos de comandos assert.

Execução do Caso de Teste

A IDE do Selenium permite que o caso de teste seja executado de diferentes maneiras como, por exemplo, rodar o caso de teste inteiro de uma só vez, rodar o caso de teste linha por linha, iniciar e parar a execução do caso de teste ou até mesmo rodar um único comando que você esteja desenvolvendo.

Essa facilidade propiciada pela ferramenta ajuda muito o testador pois ele consegue verificar um problema mais facilmente, além de não precisar rodar o caso de teste inteiro quando não for necessário.

Existe uma outra facilidade na execução dos casos de teste. É possível executar o mesmo caso de teste em domínios diferentes apenas mudando a URL no campo URL Base. Essa facilidade é muito útil quando já existe uma versão do site no ar e uma outra em desenvolvimento. Dessa forma você aproveita o mesmo caso de teste para executar tanto na versão que está no ar quanto na versão que ainda está em desenvolvimento.

Comandos do Selenium – Selenese

Para que o caso de teste seja desenvolvido, o Selenium disponibiliza uma grande quantidade de comandos, também conhecidos como seleneses, para que seu caso de teste seja o mais completo possível. Uma sequência desses comandos gera o script de teste.

Esses comandos são divididos em três grupos:

Actions – São os comandos que dizem o que deve ser feito, tal como “clique neste link” ou então “selecione essa opção”. Caso algum erro aconteça, a execução deste teste é interrompida.

Muitos desses comandos possuem o sufixo “AndWait” como, por exemplo, “addScriptAndWait” ou então “altKeyUpAndWait”. Esse sufixo indica ao Selenium que a página irá efetuar uma chamada ao servidor e que ele (Selenium) deve aguardar a página ser carregada.

Accessors – Examina o estado da aplicação e armazena o resultado em variáveis como, por exemplo, “storeTitle”. Eles também são utilizados para gerar Assertions automaticamente.

Assertions – São como os Accessors, mas eles verificam se o estado da aplicação está de acordo com o esperado. Exemplos: incluir “verificar se o título da tela é Consultar”, ou então, “verificar que o checkbox está checado”.

Todos os comandos Assertions podem ser utilizados de três maneiras diferentes: “assert”, “verify” e “waitFor”. Você pode, por exemplo, “assertText”, “verifyText” ou “waitForText”. Quando o assert falhar, o teste é abortado. Quando o verify falhar, o teste irá continuar, porém o erro será armazenado no log. Para o waitFor, se a condição não for verdadeira, o comando irá falhar e o teste será parado.

Syntax do script de teste

A syntax do script de teste do Selenium é bem simples. Ela consiste em um comando com dois parâmetros, porém esses dois parâmetros nem sempre são obrigatórios, podendo até, em alguns casos nem serem necessários. Um exemplo de script de teste para avaliar o conteúdo de um campo texto é apresentado na Listagem 1.

Listagem 1. Script de teste

<table> <tr><td>verityTextPresent</td><td></td>Bem vindo à minha home page<td></td></tr> <tr><td>type</td><td>id=ddd</td><td>(011)</td></tr> <tr><td>type</td><td>id=telefone</td><td>23468897</td></tr> </table>

Suites de teste

Uma suite de teste se refere a um conjunto de testes, onde todos eles serão executados como se fosse um batch. Utilizando o Selenium-IDE, é possível criar a suite de teste utilizando um arquivo HTML. A syntax de uma suite de teste também é muito simples. A Listagem 2 apresenta um exemplo onde são indicados os testes (no exemplo, três casos de teste) que serão executados sequencialmente.

Listagem 2. Exemplo de suite de teste.

<html> <head> <title> Test Suite Function Tests – Priority 1 </title> </head> <body> <table> <tr><td><b>Suite of Tests<b><td><tr> <tr><td><a href=”./Login.html”>Login<a><td><tr> <tr><td><a href=”./SearchValues.html”>Test Searching for Values<a><td><tr> <tr><td><a href=”./SaveValues.html>Test Save<a><td><tr> </table> </body> </html>

Localizando elementos na página

Para muitos comandos do Selenium é necessário descrever um target para que este seja encontrado no conteúdo da aplicação Web. Este target consiste de uma estratégia de localização seguida do destino no formato locatorType=location.

O locatorType pode ser omitido em muitos casos. Existem diversos locator types: localização por identificação, por ID, por caminho, dentre outros.

Localização por ID

Apesar de ser um localizador mais limitado que o locatorType, é mais explícito. Se você souber o ID de um elemento da página, use esse localizador. A Listagem 3 mostra um exemplo desse tipo de localização.

Localização por Nome

Esse tipo de localizador irá procurar na página o primeiro elemento com o nome definido no atributo. Se por ventura existirem muitos elementos com o mesmo nome de atributo, é possível utilizar filtros para posteriormente refinar a estratégia de localização. A Listagem 3 mostra um exemplo desse tipo de localização.

Listagem 3. Localização por ID e por Nome.

<html> <body> <form id=”loginForm”> <input name=”username” type=”text”/> <input name=”password” type=”password”/> <input name=”continue” type=”submit” value=”Login”/> <input name=”continue” type=”button” value=”Clear”/> </form> </body> </html>

Ao contrário de alguns localizadores XPath e DOM, os três tipos apresentados na Listagem 3 permitem ao Selenium testar um elemento de interface, mesmo que sua posição na página seja alterada.

Localização por XPath

XPath é a linguagem utilizada para encontrar nós em um arquivo XML. Ela vai além dos métodos simples de localização por ID ou por Nome, abrindo novas possibilidades tal como localizar o segundo checkbox da página.

Uma das principais razões de se utilizar localização por XPath é quando não existe um ID ou Nome apropriado para o elemento que se deseja localizar. Você pode utilizá-lo tanto para localizar o elemento em termos absolutos, o que não é recomendado pois pode falhar com o menor ajuste na aplicação, quanto para um elemento que possui ID ou Nome de atributo. Tomando como base a Listagem 3, o exemplo a seguir ilustra esse tipo de localização:

xpath=//form[@id='loginForm'] (3)

Neste caso, estamos considerando o elemento do formulário com o atributo nome “id” e com o valor “loginForm”. Já no exemplo a seguir estamos buscando o primeiro elemento do formulário com um elemento filho de entrada com o atributo “name” e valor “username”:

xpath=//form[input/@name='username'] (3)

Localização de hiperlinks com o texto do link

Esse é um método simples de localizar um hiperlink na página usando o texto do link. Se existirem dois ou mais links com o mesmo texto, o primeiro link encontrado será o considerado. A Listagem 4 mostra um exemplo desse tipo de localização.

Listagem 4. Localização de hiperlink.

<html> <body> <p< Are you sure you want to do this?</p> <a href=”continuel.html”>Continue</a> <a href=”cancel.html”>Cancel</a> </body> </html>

Localização por CSS

O CSS (Cascading Style Sheets) é uma linguagem que descreve a apresentação de um documento HTML ou XML. Ele utiliza seletores para ligar o estilo das propriedades aos elementos existentes no documento. A Listagem 5 mostra um exemplo desse tipo de localização.

Listagem 5. Localização por CSS.

<html> <body> <form id=”loginForm”> <input class=”required” name=”username” type=”text”/> <input class=”required passfield” name=”password” type=”password”/> <input name=”continue” type=”submit” value=”Login”/> <input name=”continue” type=”button” value=”Clear”/> </form> </body> </html> - css=form#loginForm (3) - css=input[name=”username”] (4) - css=input.required[type=”text”] (4) - css=input.passfield (5) - css=#loginForm input[type=”button”] (7) - css=#loginForm input:nth-child(2) (5)

Depurando

Depurar significa procurar e corrigir erros no caso de teste. É verificar o que está acontecendo, quais valores estão sendo recuperados em qualquer ponto do caso de teste. Através da inclusão de breakpoints é possível parar o caso de teste exatamente em uma linha, por exemplo, que você deseja verificar. Com o breakpoint é possível parar e continuar a execução de qualquer ponto do caso de teste que você necessitar.

Para depurar o caso de teste, você deve utilizar três botões:

• Este botão inicia o caso de teste do começo ou do ponto de início;
• Este botão pausa o caso de teste ou reinicia de um determinado ponto;
• Este botão vai rodando o caso de teste passo a passo. Deve ser clicado diversas vezes para que cada linha do caso de teste seja executada.

Uma outra facilidade ao se depurar é a utilização do botão Procurar. Com ele é possível procurar dentro da página qual elemento está sendo utilizado em determinado comando que está em execução. Ele pode ser utilizado com qualquer comando que identifique um elemento na página como, por exemplo, click, type, dentre outros.

Infelizmente, ainda não é incomum ver em algumas empresas a falta de importância que é dada a qualidade de software. Na maior parte das vezes, o que realmente importa é entregar o que o cliente solicitou, dentro do prazo estipulado, e principalmente, dentro do orçamento previsto.

Não raro, é possível encontrar profissionais sem qualquer tipo de conhecimento na área testando software. Isso impacta direta e negativamente na qualidade do software, pois esse profissional não terá conhecimento das metodologias ou ferramentas existentes que possam melhorar o trabalho a ser feito.

Como visto, uma ferramenta como o Selenium pode fazer com que a quantidade de falhas ou erros que o software tenha seja reduzido. Com a possibilidade da automação dos testes, fica muito mais fácil “estressar” o software para que mais possibilidades de teste sejam feitas e de uma maneira rápida.

Referências

Selenium IDE
www.selenium.org

Instituto de Engenharia de Software
www.sei.cmu.edu/

Instituto CMMI
www.cmmiinstitute.com

KOSCIANSKI André, SOARES Michel dos Santos. Qualidade de Software: aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software. 2 ed. São Paulo: Novatec Editora, 2007.

CAMPOS Vicente F. TQC Controle da Qualidade Total. Belo Horizonte: Fundação Christiano Ottoni. Escola de Engenharia, 1992.

FEINGENBAUM, A. V. Controle da Qualidade Total II, McGrawHill, 1994.