terça-feira, 13 de setembro de 2011

Exemplo do uso incorreto de templates

Estava visitando alguns sites de Testes em inglês e me deparei com o seguinte texto:

What should be done after a bug is found?
The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the 'Tools' section for web resources with listings of such tools). The following are items to consider in the tracking process:

* Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
* Bug identifier (number, ID, etc.)
* Current bug status (e.g., 'Released for Retest', 'New', etc.)
* The application name or identifier and version
* The function, module, feature, object, screen, etc. where the bug occurred
* Environment specifics, system, platform, relevant hardware specifics
* Test case name/number/identifier
* One-line bug description
* Full bug description
* Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
* Names and/or descriptions of file/data/messages/etc. used in test
* File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
* Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
* Was the bug reproducible?
* Tester name
* Test date
* Bug reporting date
* Name of developer/group/organization the problem is assigned to
* Description of problem cause
* Description of fix
* Code section/file/module/class/method that was fixed
* Date of fix
* Application version that contains the fix
* Tester responsible for retest
* Retest date
* Retest results
* Regression testing requirements
* Tester responsible for regression tests
* Regression testing results


Nesse momento, o Analista de Testes inexperiente (espero que o chapéu não sirva) vai lá e cria um "template" maravilhoso para reportar defeitos encontrados no sistema com tooodos aqueles itens acima listados.

O problema é que ele esqueceu da citação do próprio autor: "The following are items to consider in the tracking process". Ou seja, para quem gosta de tradução: "Os itens a seguir devem ser CONSIDERADOS ..."

Nesse caso, o próprio autor deu a dica. Mas a impressão que eu tenho é que o camarada sai desesperado no Google atrás de "itens para compor meu documento", vê um "troço" desses e sai montando odiosos artefatos no processo das empresas. É graças a esses "gênios", que a área de Testes tem esse "prestígio todo"...

1 comentários:

Bárbara Cabral disse...

Oi Tavo, você como sempre "abalando" as estruturas... heheh

Então, concordo plenamente e ainda mais... em empresas pequenas, cenário comum com aqui em Florianópolis, obviamente não se justificam esses dados todos.

O que vejo geralmente é que quando um Analista de Testes não elabora documentos ou relatórios complexos a Gerência e os demais envolvidos não dá aos documentos a devida importância.

Sou a favor de documentos simples mas que nos digam alguma coisa... nada desse negócio de inventar informação para mostrar que tem tudo "sob controle". Temos que ter em mente a objetividade e o propósito de informação adicionada... inclusive ter em mente que os documentos servem como "contrato" acordado entre as partes interessadas nos testes de um determinado software e não como um repositório de informações sobre o software.

 

My site is worth$4,271.36Your website value?