Teste de Software e Utilidades…

Olá Pessoal,

Depois de um bom tempo ausente de novos posts, venho agora com um que anda me chamando muito a atenção.

Quando testamos, procuramos nos empenhar ao máximo na procura de defeitos, ou seja, todos nossos esforços se centralizam nesse contexto. Mas há um detalhe que aumenta a influência dos Testadores nos Projetos. A atenção não parte apenas para a Matriz GUT (vide ótimo post sobre: http://qualidadeeteste.blogspot.com/2011/01/como-priorizar-problemas-defeitos.html – por Anderson Tavares), mas também para a descrição e aprofundamento do problema detectado.

Em minha experiência em Teste de Software, vi diversos cenários, desde o cadastramento de um simples bug sendo destruído por uma descrição impossível de se entender até um cadastramento perfeito, aprofundado, embasado em tentativas e experiências. Esse é o fator que eleva o conhecimento do profissional e o faz entender completamente o processo da empresa onde trabalha.

Ok. Vamos mais devagar. O que estou querendo mostrar?

Os profissionais de Teste possuem um poder imensurável em suas mãos, mas que muitos desperdiçam. Por quê?

Vamos a um exemplo:

Um defeito simples: Temos um botão de um programa qualquer que, ao receber o clique, deveria enviar o usuário a uma próxima tela específica, mas não o faz. O Testador, ao perceber tal situação, reproduz o problema e o reporta.

Pronto. No relatório temos o seguinte problema reportado: Ao clicar no Botão “XX” o sistema não envia o usuário à próxima tela.

Testador feliz e Desenvolvedor indignado por esquecer algo tão simples no código.

Agora vamos dificultar um pouco com um novo exemplo:

Temos um Trojan, que no caso deveria ter sido morto pelo Anti Vírus, mas não foi. O Testador ao perceber tal situação, reproduz o problema e o reporta.

No relatório temos o seguinte problema reportado: Ao executar o Trojan “XX”, o Anti Vírus não o matou.

Testador feliz e Desenvolvedor indignado, porque agora os problemas podem ser vários.

Agora vamos ao ponto principal. E é aqui que definimos os perfis profissionais.

No primeiro exemplo temos um caso simples onde o problema foi um erro básico, fácil de ser detectado e não necessário de ser explorado.

No segundo exemplo temos todo um mundo a ser explorado. Quando percebemos que um trojan não foi morto, quais medidas deveríamos tomar? Quais tipos de testes poderíamos submeter a aplicação pra passar as informações ao desenvolvedor completamente limpas? O trojan possuía sua assinatura na “Base de Assinaturas” do Anti Vírus? Quais proteções do Anti Vírus estavam ativas no momento em que não matou o trojan? Houve algum conflito entre as proteções? … e por aí vai…

Mas esbarramos em um problema… quando se trata de prazos, temos a responsabilidade de entregar o produto no tempo acordado. Então nem sempre temos a disponibilidade imediata de pensar nessas possibilidades. E aqui se destacam as pessoas de visão. Gerentes, Líderes, e claro… Testadores.

Quanto mais informações transferirmos ao desenvolvedor, mais rápido ele irá conseguir detectar o problema, e menos risco o Projeto terá.

Trabalhei com diversos tipos de profissionais de Teste e percebi que o maior prazer deles está na busca do problema. Quanto mais envolvido o profissional estiver com a empresa, maior o conhecimento adquirido e maior a disposição dele na detecção do problema.

Tenha sempre em mente: O nível de aprofundamento da informação está totalmente ligado à resolução do problema. Se o Desenvolvedor possuir todas as informações dos tipos de testes que o Testador realizou, ele pode descartar qualquer redundância do processo e detectar o problema tão cedo quanto imaginar.

Nesse aspecto, temos mais um item que pode ser agregado a esta análise. Retirado do Livro: Testes Funcionais de Software, Leonardo Molinari, pág. 86/87: “O herói, na qualidade de software, é alguém que para o bem geral, toma uma iniciativa para resolver um problema ou para atingir uma meta de forma clara e precisa. Um herói não é alguém louco, mas um ser consciente de suas limitações e que age até onde é possível para superá-las de forma consciente e lógica. (…) A sua atitude pode torná-lo um herói. A atitude mais simples pode fazer o seu vizinho ver qualidade sob um novo aspecto, melhor e mais positivo.

Em linhas gerais, podemos dizer que nossas atitudes podem sim mudar tudo a nossa volta, até mesmo a visão dos nossos superiores com relação ao nosso trabalho.

…

O que mais impede um defeito ser considerado realmente como um, é a má descrição. Com isso temos uma interpretação errada do Desenvolvedor e consequentemente, o tempo perdido nesse processo.

Geralmente é preciso se atentar a alguns aspectos importantes, que são eles:

– Escrita – Uso do Português adequado: Atenção a este item. Parece simples, mas o que mais temos são frases ambíguas e o mau uso das palavras;

– Uso de Títulos intuitivos: Saber especificar um problema é essencial e se o Título for intuitivo e descrito de forma correta, muita informação desnecessária pode ser evitada;

– Passo a Passo organizado: Não basta apenas saber o que fez, é preciso organizar as informações de modo que um passo não seja excluído ou que não haja falta de informação;

– Evite redundâncias: Quanto mais complexo o defeito, mais atenção é preciso na hora da descrição. Seja objetivo;

– Neutralidade: Evitar manifestação de humor ou emoção;

– Isolamento do Problema: O que foi feito para isolar o problema? Quais tipos de ações foram feitas para reproduzir o problema de modo consistente.

Dica: Utilize sempre vídeos para demonstrar os defeitos. Testes feitos utilizando Máquinas Virtuais têm essa vantagem, e isso agrega um valor imenso à descrição do problema. Quando existe a possibilidade de visualizar o problema, surgem novos pontos a serem questionados e isso cria confiança entre as partes.

Seguindo esta linha de raciocínio, é possível melhorar de forma exponencial a descrição de defeitos e ainda agilizar o processo de correção.

Trabalhando ao lado de desenvolvedores fica fácil perceber o grau de reconhecimento e satisfação ao lerem itens tão bem descritos e embasados. Não há perda entre os lados. Com isso, a Empresa ganha em agilidade, e os Desenvolvedores e Testadores ganham em competência.

Concluindo…

Como Gerentes, temos que ter a visão macro, entender o que é mais importante e direcionar os esforços para a conclusão dos testes e entrega do produto, não esquecendo de dar foco à problemas mais complexos;

Como Líderes de uma Equipe de Testes, temos que ter uma visão um pouco mais minuciosa, direcionando esforços ao cumprimento das metas estipuladas pelo Gerente e além disso, direcionar os profissionais de Teste no cumprimento de suas tarefas;

Como Testadores, temos que ser críticos, possuir iniciativa, ser explorador e claro, ser organizado. O sucesso, tanto da Empresa como dos Gerentes e Líderes está no empenho e preocupação dos Testadores com o produto. E então entramos novamente no assunto anterior: Quanto mais envolvido estiver com a empresa e motivado com o trabalho, melhor será o desempenho do Testador.

Na Gestão de Defeitos é preciso se “viciar” nas melhores práticas de descrição e relato de defeitos. O uso da Documentação é imprescindível, devendo esta ser de total apoio ao Testador.

Para frisar a importância da gestão de defeitos, tanto em sua descrição como cumprimento de suas etapas, encerro este post com um trecho do livro “Base de Conhecimento em Teste de Software” – Aderson Bastos, Emerson Rios, Ricardo Cristalli, Trayahú Moreira – pág. 195: “(…) A demora em reconhecer defeitos pode ser muito custosa. Uma das principais causas dessa demora é a dificuldade, a incapacidade ou impossibilidade de reproduzir o defeito. Quando isso acontece, o desenvolvedor tende a ver o defeito como inválido ou adiar o reconhecimento para uma próxima ocorrência do mesmo defeito.”

… … …

Espero que este post o ajude a buscar mais dentro do seu ambiente de trabalho e que seja a fonte de inspiração para novas idéias.

Qualquer elogio ou crítica construtiva fique à vontade.

Trabalho com AutoIt há quase cinco anos. Não digo que é a melhor ferramenta a ser escolhida, mas, assim como outras, possui falhas e acertos;… neste caso, os prós, contando com uma ajuda impecável; facilidade de compreensão; criação rápida de um executável. Seguindo como contra a falta de um debugger, tendo que ser feito pelo uso de msgbox.

 Pontos relevantes, mas que só são vistos após muita prática e pesquisa.

Resolvi falar desse assunto por conta de comentários que vi durante o mês passado a respeito do uso do “Record and Play/Replay” pelo Camilo Ribeiro (www.bugbang.com.br) e pelo Elias Nogueira (http://sembugs.blogspot.com). Concordo com o que foi dito, e, retirando do twitter, segue o diálogo – Elias: “Porque sempre que automatizamos os testadores ficam preguiçosos e poem a culpa toda nela quando na verdade é no trabalho deles o problema?” – Camilo: “(…) porque exige muito mais do que gravar scripts e muitas vezes os testadores são MUITO dependentes do Record and Replay?”.

 Expondo o meu ponto de vista e dando ênfase às palavras dos dois, acredito que o uso desta funcionalidade deva ser de uso apenas para se inicializar um processo de aprendizagem, nada além disso, justamente por conta de ser um código inteiramente sujo, dependente do estado atual da máquina e dependente de manutenção.

Ao se criar um script de teste, os cuidados devem ser os mesmos que um desenvolvedor precisa ter ao escrever seus códigos, ou seja, dependendo da empresa, o uso constante de comentários e/ou variáveis com nomes fáceis e descritivos devem ser observados; o uso de indentação é imprescindível, visto que a leitura do código é completamente influenciada.

Um exemplo do que ocorre em um código utilizando ´”Record and Play/Replay” é a seguinte:

#region — ScriptWriter generated code Start —

Opt("WinWaitDelay",100)

 Opt("WinTitleMatchMode",4)

Opt("WinDetectHiddenText",1)

Opt("MouseCoordMode",0)

WinWait("C:\Users\joao\Desktop\teste.au3 - SciTE [6 of 6]","Source")

If Not WinActive("C:\Users\joao\Desktop\teste.au3 - SciTE [6 of 6]","Source") Then WinActivate("C:\Users\joao\Desktop\teste.au3 - SciTE [6 of 6]","Source")

WinWaitActive("C:\Users\joao\Desktop\teste.au3 - SciTE [6 of 6]","Source")

Send("{LWINDOWN}r{LWINUP}")

WinWait("Executar","Digite o nome de um ")

If Not WinActive("Executar","Digite o nome de um ") Then WinActivate("Executar","Digite o nome de um ")

WinWaitActive("Executar","Digite o nome de um ")

Send("calc{ENTER}")

WinWait("Calculadora","0")

If Not WinActive("Calculadora","0") Then WinActivate("Calculadora","0")

WinWaitActive("Calculadora","0")

MouseMove(111,260)

MouseDown("left")

MouseUp("left")

WinWait("Calculadora","3")

If Not WinActive("Calculadora","3") Then WinActivate("Calculadora","3")

WinWaitActive("Calculadora","3")

MouseMove(151,293)

MouseDown("left")

MouseUp("left")

WinWait("Calculadora","3 +")

If Not WinActive("Calculadora","3 +") Then WinActivate("Calculadora","3 +")

WinWaitActive("Calculadora","3 +")

MouseMove(72,258)

MouseDown("left")

MouseUp("left")

MouseMove(190,278)

MouseDown("left")

MouseUp("left")

WinWait("Calculadora","5")

If Not WinActive("Calculadora","5") Then WinActivate("Calculadora","5")

WinWaitActive("Calculadora","5")

MouseMove(198,15)

MouseDown("left")

MouseUp("left")

#endregion — ScriptWriter generated code End —

Neste exemplo estou utilizando a funcionalidade do AutoIt denominada: AU3Record. E apenas peguei o que o programa gerou ao final.

Para fins de compreensão estou abrindo uma Calculadora, clicando em ‘3’, depois no sinal de ‘+’, depois em ‘2’ e finalmente em ‘=’. Logo após ver o resultado, fecho o aplicativo. Simples assim.

Mas, o que vemos é muita coisa que não deveria estar ali. Ajustando o programa e otimizando-o, ficaria assim:

; uso desta opção apenas para visualizar os cliques na calculadora neste exemplo

Opt( "MouseClickDelay", 700 )

; método de execução padrão em todos os Sistemas Operacionais;

; por conta disso, não é preciso passar o caminho completo do arquivo, e nem a diferenciar de sistema em portugues e ingles

Run( "calc.exe" )

$CalcTitle = "[CLASS:SciCalc]"

WinWaitActive( $CalcTitle )

; clicando em ‘3’

ControlClick( $CalcTitle, "", "Button15" )

; clicando em ’+’

ControlClick( $CalcTitle, "", "Button20" )

; clicando em ‘2’

ControlClick( $CalcTitle, "", "Button11" )

; clicando em ‘=’

ControlClick( $CalcTitle, "", "Button21" )

; fechando a calculadora

WinClose( $CalcTitle )

Voltando ao primeiro exemplo, e já afirmando que ele não irá funcionar de modo satisfatório, o problema já aparece na 5ª linha, onde: ‘WinWait(“C:\Users\joao\Desktop\teste.au3 – SciTE [6 of 6]”,”Source”) ‘ . O programa está na espera de que o editor de código do AutoIt esteja aberto e na aba 6/6. Ou seja, tentar pegar esse programa e rodar em outro lugar que não tenha essa devida adaptação, não irá funcionar. Enquanto que o segundo exemplo rodará em qualquer Sistema Operacional (Windows – Plataforma 9x/NT exceto Windows 7).

Independente do modo como um script será desenvolvido é preciso se atentar à técnica de teste empregada, em específico, o ambiente de teste. Classes de janelas, botões e textos mudam, e às vezes até demais de um sistema para o outro. Cito isso por conta deste programa não rodar no Windows 7 justamente por causa da mudança de classe da janela e os Id’s dos botões, mas, como é só um exemplo, resolvi não me estender muito.

Bom, é isso. Espero que este post sirva de ajuda a quem insiste em usar somente o “Record and Play/Replay”. Fazer ajustes no código após utilizar esse método ainda sim é perigoso, pois muita coisa é desnecessária e isso pode confundir quem está iniciando, fazendo com que o mesmo utilize funções erradas durante todo o processo. Caso realmente tenha que utilizar esse método, faça a gravação, veja o resultado e pesquise as funções na ajuda do próprio ambiente de desenvolvimento, buscando funções relacionadas que às vezes podem responder tão bem quanto às utilizadas pelo “gravador”.

Atualmente estou em uma grande transição na empresa. O local da Homologação está sendo transferido para outro estado, saindo de perto da equipe de desenvolvimento. No que tudo indica, há de ser uma boa estratégia a fim de suprir a mão-de-obra escassa (em termos de lógica de programação e conhecimentos dos produtos) dentro da empresa.  Nesse contexto, os fatos relevantes até o momento são:

– A transição é lenta, e isso influencia no trabalho e na alocação de tarefa de cada membro;

– Num período de 4 – 6 meses sua equipe fica comprometida, pois membros da sua equipe precisam ir ao novo local para treinar/explicar o funcionamento básico/padrão do atual ciclo de testes;

– O tempo para homologação é acrescido demasiadamente devido a essa falta de integrantes;

– A manutenção no código em testes automatizados é reduzida drasticamente, ocasionado pela falta de mão-de-obra interna.

—

Nesses quatro meses que sucedem o início da transição vejo como faz diferença uma equipe de QA junto ao desenvolvimento. A resposta para qualquer pergunta vem de forma fácil e rápida. Não é preciso acessar nenhum meio de comunicação, no aguardo de uma resposta.

Esse, em minha opinião, é o principal ponto a ser observado. Tudo o que a equipe de desenvolvimento planeja fazer ou está fazendo é acompanhado pela equipe de QA e isso se deve ao fato das Reuniões de Pé (ao início de cada dia de trabalho, informando o que foi feito no dia anterior e o que será feito durante o dia, apontando as dificuldades encontradas e as devidas soluções) e Planejamento (reuniões quinzenais (iterações), planejando todas as tarefas que serão realizadas por cada colaborador).

E ainda nesse ponto, acredito que a Equipe de QA perto do Desenvolvimento ainda se beneficie do uso do Release Notes (Notas de Versão), que nem sempre vem completo e essa comunicação passa a valer e muito para a conclusão de um bom trabalho.

—

Além destes pontos, existe outro que afeta não só a antiga rotina de testes, mas também a nova rotina de trabalho.

Como eu disse antes, essa mudança veio para suprir mão-de-obra escassa e isso quer dizer que: o trabalho antigo será finalizado e a antiga equipe de testes será responsável por estudar e aprender novas metodologias, certo? Errado. A equipe antiga continuará prestando os mesmos serviços já prestados dobrando a carga (a nova equipe não estará preparada para realizar um teste completo e de qualidade, então é preciso prestar esse suporte), por conta da falta de integrantes e ainda aprendendo sobre as novas práticas. Ou seja, há um desgaste maior, gerando desconforto aos envolvidos.

—

Estamos seguindo a reta final desta transição e acredito que minha equipe está fazendo um excelente trabalho, se propondo a ajudar e fazendo bem feito como antes. Estou ciente de que ainda teremos muito o que ajudar  até que a transição termine. Nesse tempo, espero que as coisas se ajeitem da melhor forma.