Execução de Testes e Gestão de Testes

Execução de Testes e Gestão de Testes
Por: Fernando Palma
Abril, 2007
______________________________________________________________

Todo Profissional da Área de Testes já passou ou passará por situações em que a forma como o projeto é gerenciado dificulta o seu trabalho. O Processo que não ajuda, o rompimento da etapa de testes, ausência de estrutura eficiente e principalmente a falta de tempo são alguns dos motivos que impedem seu desempenho. Na verdade, um dos maiores dilemas enfrentado por um gerente de projeto é decidir entre a qualidade do sistema e o cumprimento de prazos. Neste artigo, serão abordadas, em paralelo, a execução e gerência de testes (processo de execução), mostrando as diferenças e dependências entre essas duas atividades.


A Execução de testes torna-se eficaz à medida que o analista de testes é capaz de imaginar e escrever o máximo de cenários de testes possíveis, assim como o homologador é capaz de interpretá-los e executa-los de maneira ágil e correta. Um bom analista de testes é criativo, intuitivo, sabe organizar seus testes de forma que os mais importantes sejam focados no inicio, prever que tipos de testes são necessários; é perfeccionista. Não menos importante, o bom homologador deve ser persistente, atento e saber descrever e reportar os erros de forma clara aos programadores.


Já uma boa Gestão das atividades de testes está relacionada com o uso de processo e estrutura eficazes. Para isso, três pontos são fundamentais: congelamento de baselines, replicação do ambiente de produção e condição de parada. Para entender melhor, é preciso analisar cada um destes preliminares.


Congelamento de baselines: quando o sistema entra em homologação, é preciso que a versão que será testada seja “congelada” até que todo o trabalho de testes seja realizado. Em outros termos, nada deve ser alterado enquanto o testador esteja trabalhando. Sem isso, não é possível desenvolver uma bom trabalho. Imaginemos que um homologador esteja encontrando erros paralelamente aos desenvolvedores estarem os corrigindo. Este processo seria trágico, pois cada vez que o programador corrige o código, existe grande chance de novos erros estarem sendo implantados, o que impossibilita o controle do que já foi ou não testado. Por isso, é essencial que o período de correções inicie depois que o sistema seja testado por inteiro.


Replicação do ambiente de Produção: muitos erros encontrados no sistema instalado em uma determinada maquina/servidor não ocorrem quando o mesmo procedimento é replicado em uma outra maquina dentro do ambiente de desenvolvimento. Isso acontece porque o comportamento do sistema é influenciado por uma serie de configurações pertencentes ao ambiente em que está sendo executado. Antes que ocorra qualquer processo de testes, o gerente responsável pelo projeto deve solicitar um ambiente exclusivo de homologação que reflita o de produção (ambiente do cliente). Estas semelhanças envolvem desde configurações do sistema operacional e navegador, até configurações de banco, de rede, e tudo enfim que oferece suporte para o desempenho do sistema. Uma vez criada a equivalência entre ambientes, haverá menos chances de o cliente encontrar erros que não haviam sido gerados no ambiente de homologação interna.


Condição de Parada: este é sem dúvida, o ponto que mais sensível. A questão fundamental desta regra é que, independente da quantidade de erros, o fim dos testes deve ocorrer após um período de homologação, algo que muitas vezes é ignorado na prática. Buscando agilidade na entrega, alguns sistemas são implantados no fim do período de correções, o que pode ser fatal. Os gráficos a seguir exemplificam esta situação:


Gráfico 1 : Quantidade de Erros encontrados em um determinado sistema:



Acompanhando a imagem : na primeira Homologação foram encontrados 100 erros, dos quais - por critério do analista do sistema / gerente do projeto - foram corrigidos 90. Na segunda Homologação foram encontrados 60 erros e corrigidos 53. Na terceira, encontrados 20 e corrigidos 17. Na Quarta Homologação foram encontrados apenas 10 erros e, finalmente, foi definido que o sistema seria implantado por não se tratarem de erros graves Ou seja, não foi necessário um novo período de correção de erros (C4 = 0). O sistema encontra-se portanto em um nível confiável. Este é o processo correto dentro da fase de homologação. Mas, por falta de tempo, muitas vezes é quebrado.


Ainda sobre a imagem acima, é comum ocorrer uma situação em que o gerente do projeto decida entregar o sistema antes que a maioria dos erros seja corrigida. Pelo que vemos no gráfico, quanto mais adiante na linha do tempo isso acontecer, mais confiável estará o sistema, certo? Errado. Nem sempre a quantidade de erros encontrada em um tempo T maior será menor do que um T menor. Pode haver uma homologação em que a quantidade de erros encontrados seja maior do que na homologação anterior. Assim como, pode ocorrer uma homologação em que a quantidade de erros seja menor que a anterior, mas a gravidade desses erros seja maior. Esta situação é demonstrada na próxima imagem:


Gráfico 2 : Gravidade de Erros encontrados em um determinado sistema




Fluxo desenhado nesta imagem: no instante T1 foram encontrados erros com gravidade 80, em uma escala de 0 a 100. Este índice caiu na segunda homologação mas voltou a crescer na terceira. Caso o gerente do projeto tenha encerrado os testes no instante T = 4, mal sabia ele que o sistema estava com uma qualidade pior do que no instante T = 3. Na verdade, ninguém sabia porque não foi realizado uma nova homologação (testes de regressão). Nesse caso, era mais seguro ter entregue depois da segunda Homologação (T = 3), quando os erros do sistema eram conhecidos. O resultado deste tipo de decisão tomada é a ocorrência de diversos erros inesperados e conseqüente insegurança do usuário em relação à confiabilidade. Além disso, o gerente não poderá ter certeza se os erros que ocorreram no ambiente do usuário foram implantados em C2 (T = 4), ou se eles já existiam antes, o que indicaria uma falha de quem realizou os testes. Da mesma forma, ainda que o(s) profissional(ais) de testes esteja(m) fazendo um bom trabalho, isto não estará bem visível. Por esta razão, o fim do período de testes de sistema deve ocorrer com o término de uma homologação, nunca no fim de uma Correção.


Dentro de uma fabrica de testes, em um núcleo de testes, ou no trabalho executado por um único profissional de testes, deve existir a atenção ao processo gerencial dos testes que estão sendo executados. Ele é o suporte para que tudo ocorra bem. A intensidade e quantidade de testes aplicados é opcional, a boa gerencia não. Não adianta investir em Analistas de Testes e homologadores capacitados, se a estrutura que os acompanha não for melhorada. O testador deve cuidar para que um bom processo seja realizado. Isto é, exigir a maneira adequada de conduzir os testes. Isto é, buscar a valorização de seu trabalho. Sim, um profissional de testes que não tenha seu trabalho bem gerenciado nunca poderá demonstrar sua capacidade.

10 comentários:

  1. Ótimo artigo, Fernando!
    Um comentário sobre o "Congelamento de baselines". Você disse que é necessário que a correção dos erros deve ser realizada depois da conclusão dos testes. Se você separar em dois ambientes, um para desenvolvimento e outro para homologação, não seria viável corrigir os erros durante a realização dos testes, tentando otimizar o tempo de correção e de testes? Existem desvantagens em abordar este paralelismo?

    ResponderExcluir
  2. Este comentário foi removido pelo autor.

    ResponderExcluir
  3. Ok, João! Realmente, neste caso não haveria grandes problemas funcionais em existir o paralelismo entre as atividades de homologação e correção. Portanto que sejam em ambientes diferentes.

    O importante é que o que está sendo testado não sofra modificações. E que os erros sejam devidamente documentados (mesmo os que forem tratados no outro ambiente antes dos testes terminarem, como propôs).

    Talvez, isso pudesse ser acrescentado ao artigo, como uma tática que é desenvolvida na pratica para acelerar o processo sem comprometer a qualidade. É verdade que as fabricas de software realmente adotam esse recurso.

    Mas é preciso tomar alguns cuidados, que muitas vezes tornam essa estratégia não recomendada. Vamos às ressalvas:

    1. Para corrigir um erro, o programador precisa de uma avaliação do Analista do Sistema/Gerente do Projeto, uma espécie de “ok, temos que corrigir isso!”. Mas pra esta decisão, o responsável pelos testes deve estar presente e participar da decisão (algo como, defender o trabalho dele). Só que ele ainda está testando o sistema.

    2. Quando os programadores não conseguem simular os erros encontrados, pedem ajuda ao homologador que o encontrou. Se isso acontecer enquanto a homologação estiver ocorrendo, pode dispersar o profissional.

    3. Uma parte das falhas encontradas são influenciadas pelo ambiente, pela configuração. Portanto só podem ser avaliadas e corrigidos no ambiente de homologação.

    4. Quanto aos outros erros (que não dependem de ambiente), os programadores devem tratar em desenvolvimento e ao final do trabalho do homologador, repetir seus testes unitários no ambiente de Homologação. Ou seja, ele não pode pré-supor que está funcionando porque corrigiu em desenvolvimento. Isso significa que ele se vê obrigado a fazer o teste unitário 2 vezes; enquanto no processo tradicional, faria uma vez só no lugar definitivo : em homologação.

    5. Quando um programador acompanha um relatório de erros e vai os corrigindo na medida que toma conhecimento, corre o riso de ter que fazer uma correção que envolve e modifica algo que ele acabou de corrigir (há 5 erros atrás, por exemplo). Por isso, costumo propor uma leitura completa antes de iniciar as correções. Essa pratica não seria possível antes do fim dos testes.

    Mesmo assim, a estratégia ainda pode ser usada se for tomado o devido cuidado e criadas algumas “regras alternativas” (baseadas nos problemas elencados aqui).

    Boa observação!
    Até mais.

    ResponderExcluir
  4. Fernando, muito bom o artigo! E excelente iniciativa de ter um espaço a mais sobre testes. Parabéns!!!

    ResponderExcluir
  5. Trabalho numa empresa pequena que busca melhorar a qualidade de seus software. Conseguimos alcançar boas marcas com teste de software, mas nosso problema é a continuidade; manter constante as boas práticas demanda tempo, que numa pequena empresa corresponde a dedicação, coisa difícil quando um profissional "joga em todas posições".
    Se é que é possível, sugiro um artigo sobre manter a qualidade de software com poucos recursos.
    No mínimo, é um desafio.

    ResponderExcluir
  6. Nando,
    Massa essa iniciativa que esse blog tenha bons frutos!

    abraço!
    depois visite http://estudantenaengenharia.blogspot.com

    ResponderExcluir
  7. Olá, Lucio,
    Como tentei abordar no fim do Artigo, penso que podemos até atingir uma qualidade razoável usando poucos recursos e menor quantidade de testes. Mas com uma quebra destes ciclos gerenciais que mencionei acho pouco possível. Por exemplo: você pode decidir fazer 50% dos testes e ter um resultado razoável ou até bom. Mas se decidir testar sem um ambiente de homologação já está se arriscando demais.
    Espero que tenha abordado o que realmente você quis expressar...

    Eu estou terminando um Artigo que não é exatamente o que propôs, mas é bem semelhante, fala de como evoluir o processo dentro de uma estrutura simples, com apenas um profissional de testes. Aguarde !

    obrigado pela sua visita e comentário!
    Até mais.

    ResponderExcluir
  8. Este comentário foi removido pelo autor.

    ResponderExcluir
  9. excelente artigo publicado, estou começando agora no ramo de teste de software e ache muito interessante dicas e expecificações!gostaria de estar sempre me atualizando sobre o assunto, se puder postar mais assuntos.obrigado

    ResponderExcluir