Garantia da Qualidade Depois de Terminado o Projecto
A qualidade é melhoria contínua. Depois de terminado um projecto - isto acontece normalmente quando o produto foi enviado para o primeiro cliente enquanto release do produto - existem algumas coisas importantes que os responsáveis pela garantia da qualidade devem fazer.
Fechar os bugs
Todos os bugs resolvidos com a release saída do projecto têm que ser colocados em estado "fechado" e assinalados como "resolvidos", "rejeitados", ou "aceites". Para isso, convém ter em conta os passos que se seguem.
1. Decidir sobre qual a string única que irá distinguir os bugs resolvidos por uma release concreta dos bugs resolvidos por releases passadas e futuras. Esta string inclui normalmente o número de produto e de versão, excepto nos casos em que o projecto é uma continuação de trabalho anterior com o mesmo número de versão e outro produto disponibilizado mais tarde. Neste último caso, deve-se utilizar a informação da plataforma em vez do produto.
Por exemplo:
[Nome do Produto] [Ver 3.0]
2.1 ASCII 2.1
PC [Nome do Produto] [Ver 3.0.5]
É recomendável que a string utilize o "número de versão" real do produto que está a ser disponibilizado, em vez do nome interno do projecto, de modo a que o nome faça sentido para as pessoas que não estão familiarizadas com os nomes internos dos projectos.
2. Assegurar que os bugs já fechados para uma release concreta têm especificado o estatuto de "resolvidos na versão". É muito provável que fosse utilizada outra string durante a resolução dos bugs, pelo que todos os bugs fechados relativamente à release em questão precisam de ser modificados por este passo.
3. Os bugs resolvidos ou rejeitados numa release, mas que ainda não foram fechados, precisam de ser alterados para o estado de "fechado". Os bugs resolvidos são os têm maiores probabilidades de não terem sido verificados como resolvidos pela garantia da qualidade. O mesmo se passa com os bugs rejeitados e os aceites. Desta forma, para os fechar, o mais provável é que tenhamos de recorrer a um "diário de reporting dos bugs", onde são indicadas as alterações que são efectuadas a um bug "resolvido na versão" - e, finalmente, o "estado QA - Completo".
NOTA. No final de um projecto, a maior parte dos bugs que estão garantia da qualidade deverão ser de prioridade baixa e média. Isto acontece porque parte dos critérios de um projecto que atinge a fase de disponibilização do produto ao primeiro cliente já deve ter todos os bugs urgentes e de prioridade alta, bem como 50 por cento dos bugs de prioridade média verificados pela garantia da qualidade. Como tal, normalmente não existem muitos bugs urgentes ou de prioridade alta para verificar nesta fase. E se existirem alguns bugs urgentes ou de prioridade alta que ainda não foram verificados, é aconselhável remetê-los para os engenheiros da garantia da qualidade para verificação formal, em vez de mudar simplesmente o campo de "verificado" para "não" no caso destes bugs.
Bugs abertos na release
É necessário alterar qualquer bug assinalado como "aberto na release" para "não especificado", de modo a serem examinados no projecto seguinte.
Limpeza geral
Também é necessário efectuar uma "limpeza" geral dos bugs relacionados com cada projecto particular. Algumas limpezas deste género podem consistir em resolver problemas quando foram submetidos demasiados bugs com a "área do problema" não especificada, ou quando a prioridade dos bugs não foi especificada de forma adequada para o valor Pré- Alpha/Alpha/Beta/Released. De igual modo, será conveniente verificar se existem inconsistências que possam afectar as estatísticas que possam ser realizadas sobre os bugs de um determinado projecto.
Baseado num texto intitulado "QA Team", publicado no site http://www.sqatester.com/
Produzido em 2006