QA para Desenvolvedores: Mentalidade de quebra vs. construção.

Introdução

A qualidade dos produtos de software é determinada, em grande parte, pela atitude e habilidades dos desenvolvedores que os criam. Neste contexto, existe uma mentalidade predominante entre os profissionais do ramo: a "mentaldade de quebra", onde o foco está no localizar e solucionar defeitos existentes nos sistemas, em vez de se concentrar na construção de software com características positivas.

Esta abordagem pode levar a uma mentalidade de reação, onde os desenvolvedores estão sempre corrigindo problemas emergentes, em vez de planejar e executar melhorias estratégicas. Por outro lado, há uma tendência crescente para adotar práticas que visam à construção de software seguro, escalável, testado e entregue no tempo certo.

Este artigo visa discutir a relevância dessas duas mentalidades e explorar por que uma abordagem construtiva é essencial para a criação de produtos de qualidade. Além disso, apresentaremos estratégias práticas para que os desenvolvedores adotem essa mentalidade construtiva. Ao final do artigo, o leitor estará em condições de entender melhor como equilibrar as necessidades de correção de defeitos com a construção de software sustentável e eficaz.

O que é e por que importa

A "Mentalidade de Quebra" é uma abordagem que foca na identificação e correção de defeitos existentes em um sistema, usando técnicas como depuração (debugging), teste unitário (unit testing) e validação de dados. Essa mentalidade está profundamente arraigada no mundo da programação e é frequentemente associada a uma visão de que o desenvolvimento de software é uma atividade essencialmente corretiva, focada em reparar erros e problemas emergentes.

A Motivação subjacente para essa abordagem é evitar falhas críticas e garantir a estabilidade do sistema. No entanto, quando essa mentalidade predomina, ela pode levar a uma série de problemas:

• Testes de regressão que se tornam cada vez mais complexos e custosos;
• Desenvolvedores que passam a maior parte do tempo apenas corrigindo defeitos antigos em vez de trabalhar em novas funcionalidades ou melhorias;
• Falta de investimento em práticas que promovem a qualidade e a segurança ao longo da vida útil do sistema.

Essa mentalidade também pode perpetuar uma cultura onde os desenvolvedores sentem-se mais confortáveis lidando com problemas existentes, em vez de trabalhar em melhorias estratégicas. Além disso, pode levar a sistemas que são altamente customizados para resolver problemas específicos, mas faltam características essenciais para atender às necessidades futuras do negócio.

Como funciona na prática

A "Mentalidade de Quebra" é aplicada na prática através de uma série de etapas e atividades que enfatizam a identificação e correção de defeitos existentes em um sistema.

1. Identificação dos problemas

• Análise de logs: Revisão detalhada dos registros de erro para identificar padrões e causas subjacentes.
• Relatórios de incidentes: Revisão de relatórios de incidentes para entender o que foi reportado por usuários ou outros sistemas.
• Testes de regressão: Execução de testes automatizados para garantir que as correções não tenham introduzido novos problemas.

2. Isolamento do problema

• Análise de depuração: Aplicação de técnicas de depuração para entender o comportamento do sistema e identificar a causa raiz do problema.
• Testes unitários: Execução de testes unitários para verificar como as modificações afetaram a lógica individual das funções.

3. Correção do problema

• Patch: Aplicação direta da correção no código, com o objetivo de reparar o defeito o mais rápido possível.
• Teste de validação: Execução de testes ad-hoc para garantir que a correção não tenha introduzido novos problemas.

4. Revisão e manutenção

• Revisão de código: Revisão do código alterado para garantir que ele esteja em conformidade com as melhores práticas e padrões de estilo.
• Testes de integração: Execução de testes de integração para garantir que as correções tenham sido bem-sucedidas.

Essas etapas são frequentemente repetidas em um ciclo contínuo, criando uma mentalidade focada na correção de defeitos existentes.

Exemplo real

Caso de estudo: Erro de conexão em uma API RESTful

Considere um caso de uso onde uma equipe de desenvolvimento está trabalhando em uma API RESTful que fornece dados financeiros para um aplicativo web. A equipe descobre que a API começa a apresentar erros de conexão com banco de dados, levando a falhas de servidor e tempo de resposta lento.

// Exemplo de código Java que simula o erro de conexão
public class ApiRest {
    // Configuração de conexão com banco de dados (simulando um erro)
    private String urlBancoDados = "jdbc:mysql://localhost:3306/bancodedados?zeroDateTimeBehavior=convertToNull";

    public void conectarAoBancoDeDados() {
        try {
            Connection conexao = DriverManager.getConnection(urlBancoDados, "usuario", "senha");
            // Ocorre um erro de conexão aqui
            System.out.println("Erro ao conectar ao banco de dados: " + new SQLException().getLocalizedMessage());
        } catch (SQLException e) {
            // Tratamento do erro aqui
            System.out.println("Erro ao conectar ao banco de dados: " + e.getMessage());
        }
    }

    public void executarConsultaSQL() {
        try {
            Statement statement = conexao.createStatement();
            ResultSet resultado = statement.executeQuery("SELECT * FROM clientes");
            while (resultado.next()) {
                System.out.println(resultado.getString("nome"));
            }
        } catch (SQLException e) {
            // Tratamento do erro aqui
            System.out.println("Erro ao executar consulta SQL: " + e.getMessage());
        }
    }

    public static void main(String[] args) {
        ApiRest api = new ApiRest();
        api.conectarAoBancoDeDados();  // Ocorre o erro de conexão aqui
    }
}

Nesse exemplo, a equipe identifica que o problema é causado por um erro de configuração na conexão com banco de dados. Eles decidem adotar uma abordagem mais preventiva para evitar futuros problemas. Para isso, eles implementam os seguintes passos:

• Análise de logs: A equipe revisa os logs do servidor e identifica que o erro de conexão ocorre apenas durante a execução da consulta SQL.
• Relatórios de incidentes: Eles revisam os relatórios de incidentes anteriores e constatam que há uma tendência de erros de conexão com banco de dados.
• Testes de regressão: A equipe executa testes automatizados para garantir que as correções não tenham introduzido novos problemas.

Com essas etapas, a equipe consegue identificar e corrigir o problema, melhorando a estabilidade da API RESTful.

Boas práticas e armadilhas comuns

Boas práticas

• Testar a conexão antes de executar operações: Sempre é uma boa ideia verificar se a conexão está estabelecida antes de tentar executar consultas SQL ou fazer alterações no banco de dados.
• Manter a documentação atualizada: Certifique-se de que a documentação dos métodos e procedimentos esteja sempre atualizada, incluindo informações sobre as exceções esperadas e como lidar com elas.
• Implementar logging eficaz: Use logs para rastrear o fluxo da execução do código e identificar problemas de forma mais rápida.

Armadilhas comuns

• Não confiar em dados brutos: Nunca suponha que os dados provenientes da fonte de conexão estão corretos ou válidos; sempre verifique-os antes de usá-los.
• Evitar uso excessivo de try-catch: Embora o código exemplo esteja usando try-catch, é importante evitar usar-o para lidar com erros que podem ser evitados. Isso pode levar a código difícil de manter e depurar.
• Não ignorar exceções sem entender seu significado: Se uma exceção for lancada, é fundamental entender o motivo dela e não apenas ignorá-la sem investigação adicional.

Conclusão

Em resumo, essa abordagem de QA visa fortalecer a mentalidade de quebra e construção dos desenvolvedores, permitindo-lhes identificar e solucionar problemas antes que eles impactem negativamente a API RESTful. Ao integrar tais práticas, os desenvolvedores podem melhorar significativamente a estabilidade do sistema e garantir uma experiência mais confiável para os usuários.

A próxima etapa pode ser o desenvolvimento de ferramentas personalizadas ou a integração com soluções de monitoramento e gestão de desempenho para melhorar ainda mais a eficiência e resiliência do sistema. Além disso, é importante explorar outras técnicas de QA como o uso de imutabilidade e a implementação de padrões de projetos robustos para maximizar a confiabilidade da API.

Referências

• Fowler, M. Refatoração: Improvando o Design de Código. Disponível em: <https://martinfowler.com/books/refactoring.html>. Acesso: 2024.
• OWASP. Cinquenta Práticas Para Segurança Web. Disponível em: <https://www.owasp.org/index.php/Main_Page>. Acesso: 2024.
• Weslley Menezes e Carlos Junior. Desenvolvimento de Software com Java. Editora Cengage Learning, 2018.
• Martin Kleppmann. Design de Dados para Sistemas Distribuídos. O'Reilly Media, 2017.
• OWASP. Guia de Segurança para API RESTful. Disponível em: <https://www.owasp.org/index.php/REST_Security_Cheat_Sheet>. Acesso: 2024.