Quality Test

Diante da constante evolução do teste de software necessitando cada vez mais de rapidez e agilidade no processo, a automação se torna a palavra chave para suprir esta necessidade.

Embora exija um tempo maior de elaboração dos casos de teste e o acréscimo de tempo para a criação dos scripts de teste, a automação evita o retrabalho, pois facilita o teste de regressão, viabilizando a execução de testes em telas já homologadas, garantindo que as funcionalidades testadas não apresentam falhas após a implantação de novas funcionalidades.

Uma vez gerado o script, é possível validar inúmeros casos de teste, realizar testes de regressão quantas vezes forem necessárias e alterar os scripts reaproveitando-os para a elaboração de novos testes automatizados (desde que a ferramenta permita), além de garantir que os passos foram seguidos exatamente como nos testes anteriores.

As ferramentas para automação oferecem diversas formas de gerar scripts, sendo necessário ou não, conhecer alguma linguagem de programação. Uma das técnicas conhecidas é o keyword-driven, no qual é preciso apenas da palavra-chave, do parâmetro e do comando específico para a execução dos testes. Já a outra técnica conhecida como data-driven é necessário usar uma linguagem de programação de acordo com a ferramenta.

A automação trás muitos benefícios, desde que a empresa tenha um processo que gerencie os scripts de teste adequadamente, utilize a ferramenta que se adapte as necessidades técnicas do projeto e saiba definir os casos de teste a serem automatizados. Afinal, a automação serve para auxiliar o testador e não substitui os testes manuais.

Com o passar dos anos as organizações estão cada vez mais preocupadas com a performance de suas aplicações. Com o grande crescimento da web, as aplicações Saas (Software as a service) vêm crescendo proporcionalmente e a facilidade de acesso muitas vezes comprometem a performance dos sistemas. Medir esforços apenas no projeto, implementação e requisitos funcionais são coisas do passado, pois com o avanço tecnológico, os requisitos não-funcionais do sistema, como o desempenho, são fundamentais para a qualidade do software.

Uma página web, por exemplo, não deve levar mais que sete ou oito segundos para aparecer completamente, pois o ser humano, por natureza, não espera muito tempo para uma página web ser carregada, e a conseqüência neste caso é certa, o usuário irá se aborrecer e sair do site ou ter uma imagem negativa da aplicação web. Sendo assim a necessidade de efetuar testes que validem a robustez e a estabilidade da arquitetura projetada, bem como seus requisitos não-funcionais, deve tornar-se um hábito no processo de desenvolvimento de software, e assim evitar problemas futuros.

A velocidade e estabilidade das aplicações interferem totalmente na confiança do usuário final. Estes fatores, dentre outros como escalabilidade e vazão são muito importantes e devem ser avaliados nos testes de performance.

O usuário final não está interessado em saber sobre a estrutura, ou por onde passa o request da aplicação, o importante, e o que ele precisa saber, é se a aplicação é rápida, e é obrigação da empresa responsável pelo software saber se o tempo de resposta da aplicação está confortável para o usuário, pois, o que para o desenvolvedor pode ser rápido, para o usuário não é viável por ser considerado lento.

Analisando a realidade das Softwares Houses , mediante a reta final de um projeto e a pressão do cliente, a performance do sistema é um dos primeiros pontos a gerar problemas, por esse motivo, o teste de performance deve ser parte de todo o processo de desenvolvimento, evitando problemas causados pela pressão e tendo como objetivo a eliminação de possíveis gargalos que possam existir no software, resultando assim em benefícios significativos.

Algumas pessoas mencionam que o termo “bug” foi usado pela primeira vez em 1878, por Thomas Edison, quando um inseto causou um erro de leitura em seu fonógrafo.

Mas com o mesmo significado que usamos atualmente (voltado a computadores), foi usado por Grace Hopper em 1945. Nesta época, os computadores não eram como os que temos hoje, “pessoais”, leves e pequenos. Eles eram gigantescos, movidos a válvulas e ocupavam até um andar inteiro de um prédio.

Durante o desenvolvimento do Mark II (nome dado ao computador), aconteceu um problema de funcionamento. Os pesquisadores passaram 3 dias para descobrir qual o problema que estava acontecendo com o computador.
O problema era: um inseto (bug) morreu torrado e queimou um relê que era utilizado para o cálculo de funções booleanas.

E a partir daí o termo “bug” passou a ser utilizado quando ocorrem problemas relacionados a computadores.

A baixo uma foto do ENIAC (1946).

Nós da Quality Test nos identificamos muito com esta imagem. Sabe por quê?

A visão das águias é muito aguçada. Mesmo voando em alturas elevadas, planando e elevando-se, localizam uma presa a centenas de metros de distância, e então se lançam ao ataque, apanhando o animal com suas garras.

A águia tem sucesso em sua caça devido a sua velocidade em ação, sua excelente visão e a capacidade de identificar sua preza dentro de tudo o que está em seu campo de visão. Essas qualidades também são encontradas em boas equipes de teste, além da velocidade durante os testes, precisa usar o sentido da visão para buscar bugs mesmo quando difíceis de encontrar.

Outro fato que gostamos muito, é que segundo especialistas as águias nunca fazem o mesmo voo, elas sempre superam o voo anterior. E neste espírito empreendedor, é que sempre buscamos nos superar, tanto em qualidade quanto em eficácia em nossos serviços.