Trabalhando as interfaces

"É na interface onde residem os problemas."

A frase se refere às interfaces do produto, como um componente de software com relação a outro, um sistema com outro, ou uma peça mecânica com a outra. Existe muito cuidado na especificação de cada peça ou componente, mas geralmente a interação entre diferentes partes não é tão bem planejada. Isto veremos em um capítulo futuro, onde discutiremos as atividades que são feitas para garantir o correto acoplamento entre as partes de um software.

No entanto esta frase também é verdadeira quando se fala de interfaces entre times, e não é uma excessão com as interfaces do time de verificação.

Em primeiro lugar é necessário dizer quem são as interfaces principais do time de verificação, deixando à parte as relações hierárquicas, que são diferentes em cada organização. Irei explicar as relações horizontais, com grupos que têm o mesmo nível hierárquico, que são dois: um que exerce o papel de fornecedor e outro de cliente.

O time que fornece dados para a verificação acontecer é o time de desenvolvimento. São eles que produzem os requisitos de software e a implementação. Este material é usado como fonte de informação para a realização das revisões, análises e testes, assim como o produto que será testado. A interface com o time de desenvolvimento pode ser um pouco conflituosa, pois os problemas encontrados pela verificação nem sempre são bem recebidos por quem é responsável por ele. Normalmente significa retrabalho, às vezes envolvendo até o re-projeto da arquitetura do software. Isto quando os defeitos não são considerados insignificativos e entra-se na discussão de se eles são realmente um problema que necessita correção ou não.

"Nós temos a tendência de cometer os mesmos erros. Frequentemente o desenvolvedor desconsidera as observações do time de verificação, dizendo que o teste foi muito rigoroso e que tal condição nunca ocorreria na vida real. Mas isto não é verdade." [Yogananda Jeppu - apresentação Testing Safety Critical Control Systems]

A situação se inverte quando descrevemos a interface de verificação com o seu cliente: o auditor. Note que esta interface nem sempre existe, e há muitos casos em que o time de verificação é a ponta da organização. Em casos em que a empresa tem a obrigação de entregar um software de alta qualidade, como por exemplo no caso de softwares críticos para a aviação, existem auditorias de processo. Às vezes até mais do que um auditor, quando existe o auditor interno e o auditor de uma agência externa que regulamenta um setor.

Estas auditorias têm o objetivo de avaliar se o processo foi bem seguido, incluindo o processo de verificação, de forma a garantir que o produto que a organização atestou ter qualidade, realmente foi verificado de forma correta. Estas auditorias são feitas por inspeções de amostras de arquivos do ciclo de vida do software, que será detalhado adiante. Os arquivos que passaram pela verificação são auditados junto com os resultados produzidos, normalmente relatórios de verificação, onde é questionado se o processo foi bem realizado. Um relatório com resultados válidos a respeito de um software onde a auditoria encontrou problemas põe em cheque a reputação do time que executou a verificação.

Em outras palavras, nestas auditorias é verificado o trabalho realizado pelo time de verificação. Não completamente, para não se duplicar o trabalho, mas amostralmente. E assim como ocorria com a interface com desenvolvimento, a mesma disputa se repete, agora com a auditoria no papel de apontar problemas e o time de verificação no papel de defender que o seu trabalho está correto.

Estas disputas deveriam ter como objeto apenas o aspecto técnico, mas cada time coloca-se na defensiva considerando que é o seu trabalho que está sendo criticado. Passa-se a um aspecto pessoal, onde cada um defende a sua reputação profissional.

Quando falamos de desenvolvedor, verificador e auditoria interna, não existe hierarquia entre os times e é essencial que o gestor tenha a competência para julgar e a habilidade para solucionar o conflito. Ele deve se manter em equilíbrio, de forma a garantir a qualidade do software produzido, sem pesar demais o processo de trabalho. Quando o auditor é externo este conflito é mais fácil de ser resolvido, pois a agência de consultoria é mais acreditada.