O desenvolvimento de software sob a óptica da qualidade

O desenvolvimento de produtos envolve muitos processos e a forma como ele é conduzido faz toda a diferença quando o assunto é garantir a satisfação do cliente. Na SoftExpert, entendemos que a qualidade deve estar sempre associada a processos, sendo esse um dos pontos fundamentais para a manutenção da ISO 9001, na qual somos certificados.

Neste post, falaremos sobre o processo de desenvolvimento de produtos na SoftExpert sob a óptica da qualidade. Vamos lá?

Metodologia ágil

Na SoftExpert, durante o processo de desenvolvimento do produto, as equipes já são conduzidas a desenvolverem um requisito com foco em qualidade.

Com isso, por meio da metodologia ágil, a Companhia teve uma grande evolução em termos de qualidade, pois o time que desenvolve o produto (Product Owner, o Scrum Master, Analista de Teste e Desenvolvedores) participa do planejamento, das críticas ao requisito, assim como das soluções propostas, chegando na fase de codificação com conhecimento pleno sobre o requisito.

Codificação

Ainda durante a etapa de codificação, são desenvolvidos testes unitários visando garantir que mesmo com a evolução do código, as funções/métodos continuarão funcionando. Finalizada a codificação, o desenvolvedor realiza testes, visando identificar se o requisito está se comportando conforme o que foi planejado, e revisa os cenários de testes quando necessário.

Revisões

Após concluído os testes pelo desenvolvedor, é realizada a revisão do código por um ou mais membros da equipe (chamada Code Review). Essa etapa tem como objetivo identificar falhas que passaram despercebidas pelo desenvolvedor, assim como verificar se o código desenvolvido atende aos padrões estabelecidos pelo framework PSR-2.

Realizada a revisão do código, o requisito é enviado para o Cross Testing, fase essa similar ao Code Review, na qual o requisito é enviado para um membro da equipe validar se foi desenvolvido conforme o planejado e respeitando aos critérios de aceitação definidos no plano de teste.

Homologação e aprovação

Somente após as três etapas de testes anteriores (testes do desenvolvedor, Code Review e Cross Testing) estarem concluídas e evidenciadas, o requisito é enviado para o analista de testes realizar a homologação e aprovação para que o código seja efetivado no repositório de código-fonte.

Nessa etapa, o analista de teste realizará uma revisão do plano de testes, executando os testes, validando as evidências das fases anteriores e reportando defeito quando identificado.

Após todos os requisitos planejados para uma determinada versão forem concluídos, o produto é submetido a uma intensa bateria de testes manuais, onde todas as equipes realizam a execução do SAT (System Acceptance Testing), buscando garantir que o produto em geral está funcionando conforme o especificado, e que os requisitos novos não gerem impacto sobre os já existentes.

 Testes Alfa e Beta

 Finalizada a etapa de execução do SAT, o produto é submetido à etapa de alfa teste, que consiste em validar o requisito em um uso simulado, onde usuários selecionados poderão testar o sistema em um ambiente controlado e com o acompanhamento e suporte das áreas técnicas. Para esse teste é utilizada uma cópia da base de dados de produção onde um roteiro pré-definido é executando, baseando-se nos processos de cada usuário selecionado.

Durante a execução, as correções e alterações no produto são realizadas (quando necessário) visando aprimorar a experiência do usuário. Essa etapa também fornece insumos para tomada de decisão sobre a aplicação do produto em beta testes.

Caso aprovadas as etapas de testes anteriores, o produto é submetido à etapa de beta testes, que consiste em aplicar a versão no ambiente de produção da SoftExpert, antes mesmo da liberação oficial. Durante o período de beta testes, é realizado um acompanhamento e monitoramento diário do produto, verificando se há defeito e o impacto que ele pode causar no ambiente de produção.

Validações automatizadas

Vale destacar que durante todo o ciclo de desenvolvimento são executadas validações automatizadas sobre o produto. Vou destacar algumas delas:

  • Validação estática de código: durante todo o desenvolvimento o código-fonte é submetido ao Sonarqube (ferramenta para identificação de bugs e vulnerabilidades por meio de regras automatizadas);
  • Pipeline de teste: trata-se de um processo automatizado que é disparado a cada commit e/ou merge request, a fim de garantir que padrões de desenvolvimento e qualidade estejam sendo seguidos. Nesse processo são verificados scripts de banco, padrões de código, execução de testes unitários, cobertura de código, testes de integração, compilação do código, entre outros;
  • Testes automatizados: é realizada diariamente sobre o produto uma extensa bateria de testes de aceitação, são mais de 1.900 cenários, testes de webservices com 95% de cobertura e testes na interface de integração com 95% de cobertura.

Liberação do produto

Finalizado o processo de desenvolvimento e expedição do produto, ele é liberado para o mercado por meio de uma nova versão de 1º, 2º ou 3º dígitos, habilitando o processo de manutenção do produto. Esse processo é iniciado pelo cliente que identifica e registra um chamado no portal de clientes. Nesse caso o processo de manutenção é acionado quando o chamado registrado se trata de um defeito no produto.

Chamados

Os chamados podem ser classificados como ambiente, customização, dúvida, defeito e solicitação. A tabela a seguir mostra os critérios utilizados para classificar a natureza de um chamado:

AmbienteUtilizado quando a causa do chamado está relacionada a uma variável/característica do ambiente do cliente.
CustomizaçãoA causa do chamado está relacionada a recursos customizados, ou demais demandas atendidas pela equipe de customização.
DefeitoQuando a causa do chamado está relacionada a uma falha do produto.
DúvidaQuando a causa do chamado está relacionada à dúvida em relação ao uso da aplicação.
SolicitaçãoQuando a causa do chamado está relacionada a uma alteração do produto, ou seja, é solicitado algo que o produto ainda não possui e por conta disso será registrada uma solicitação de melhoria. Também poderá ser utilizada quando a causa do chamado está relacionada a uma solicitação de material como: manual, procedimento, pacotes específicos, entre outros.

Assim que identificado o chamado como defeito, é iniciada a correção, passando por todas as etapas de testes até a liberação da correção em patch de 4º digito.

Periodicamente, é realizada uma análise crítica sobre os chamados com a finalidade de retroalimentar o nosso processo de melhoria contínua, criando cenários de testes automatizados, identificando melhorias a serem realizadas no produto ou processo.

Avaliação de Satisfação

Além disso, a avaliação de satisfação é uma forte aliada nesse processo, afinal, por meio dela é possível identificar as oportunidades de crescimento e promover melhorias.

Recentemente, divulgamos aqui, os números das avaliações de satisfação do primeiro semestre de 2020, que superaram os resultados do mesmo período de 2019. E a expectativa é aperfeiçoar cada vez mais a experiência de uso dos produtos e serviços da companhia, além de melhorar os processos.

    Juliana Silva

    Autor

    Juliana Silva

    Analista de Comunicação na SoftExpert, Juliana Silva é formada em Jornalismo, pós-graduada em Gestão da Comunicação Empresarial e Relações Públicas, com atuação nas áreas de Assessoria de Imprensa e Comunicação Corporativa.

    Receba conteúdo gratuito em seu e-mail!

    Assine nossa Newsletter e receba materiais sobre as melhores práticas em gestão produzidos por especialistas.

    Ao clicar no botão abaixo, você confirma que leu e aceita nossa Política de Privacidade.

    Por favor, preencha o formulário e fale conosco

    Campo obrigatório
    Campo obrigatório
    Campo obrigatório
    Por favor insira um número válido.
    Campo obrigatório

    Ao clicar no botão abaixo, você confirma que leu e aceita nossa Política de Privacidade