O desenvolvimento de software e composto por algumas diferenças históricas, desenvolvimento x operação, qualidade x tempo, expectativa x realidade.
Quando me pergunto sobre a qualidade de um software, me vem a imagem de uma lista de testes executados e todos verdinhos, já para Willian E. Deming em seu livro Qualidade: revolução da administração afirma que, a qualidade tem muitas escalas, por exemplo, um livro de qualidade é determinado pela legibilidade, papel, tamanho, inexistência de erros, ou seja, o leitor deseja encontrar no livro cultura e entretenimento, enquanto a editora deseja encontrar nele, boa oportunidade de venda. A avaliação do que é qualidade dependeria, portanto, das escalas de valor determinadas por cada entidade.
A ISO 900 define a qualidade como a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas, onde qualidades explícitas são aquelas que o produtor de software garante, explicitamente, ao cliente; enquanto as qualidades implícitas são aquelas subjetivamente esperadas pelo cliente.
As definições de Deming e da ISO convergem para necessidade de percebe-se a existência de duas entidades confrontantes para definição da qualidade, o desenvolvedor como entidade deseja um código entendível, padronizado, de fácil manutenção e que possibilite evoluções. O negócio por sua vez deseja um desenvolvimento rápido e que gere o menor número de reclamações dos clientes.
E como conseguir isso? Como conseguir criar um processo de software que atenda o dev como o negócio? Se alguém souber como me ensina.
As necessidades da área técnica para o desenvolvimento são atendidas com a adoção da filosofia de teste, seja TDD, BDD, etc. As necessidades da área negocial são atendidas também por garantir um menor impacto ao cliente, evitando uma cascata de incidentes após corrigir um, isso tudo porque é possível identificar todo o impacto de uma correção ou evolução da aplicação.
E o Tempo? O teste resolve os questionamentos voltados para o bem estar da aplicação, e não a variável tempo, que é importante para o negócio. Agora inicia-se a batalha do desenvolvimento x tempo. Como garantir que todos os requisitos da qualidade técnica foram atendidos em um tempo curto de desenvolvimento?
E comum ouvir durante uma sala de guerra, "não tivemos tempo de fazer os testes”, não concordo com essa sentença e acho errado vender que é preciso ter tempo para fazer o teste. O teste e a forma de garantir a qualidade da solução desenvolvida, se a minha solução foi desenvolvida em 72 horas (eita lasqueira) os testes são para garantir o que foi desenvolvido nessas 72 horas, nada mais.
A partir do momento em que você inicia um desenvolvimento o orientado a testes, o teste é o seu desenvolvimento. Ele faz parte da sua solução.
Desenvolvedor, pare de falar que não tem tempo para testar! Se você tem tempo de subir a aplicação e consultar via Postman você teve tempo de fazer o teste, o tempo que você abre e fecha a tela do Postman, era um teste desenvolvido.
Negócio, pare de comparar a qualidade de produtos desenvolvidos em diferentes tempos e jogar todas as features como prioritárias! Não faz sentido comparar a qualidade de uma solução desenvolvida em 200 horas com uma solução desenvolvida em 72 horas.
O processo de desenvolvimento de software de qualidade e um gerenciamento das expectativas de tempo com a expectativa de tecnologia. Sommerville diz que, se o sistema é legado você deve evitar ao máximo evoluí-lo, pois ele é um caos! Você não conseguirá rastrear o que é impactado com a alteração, logo se eu não consigo rastrear os impactos de uma alteração, quer dizer que ele não possui requisitos de testes que me possibilitem esse rastreio, levando a conclusão que se a solução não possui teste, ela e uma solução legada.
Hoje você desenvolve uma solução legada ou um produto de qualidade?
Top comments (0)