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:
Ambiente | Utilizado quando a causa do chamado está relacionada a uma variável/característica do ambiente do cliente. |
Customização | A causa do chamado está relacionada a recursos customizados, ou demais demandas atendidas pela equipe de customização. |
Defeito | Quando a causa do chamado está relacionada a uma falha do produto. |
Dúvida | Quando a causa do chamado está relacionada à dúvida em relação ao uso da aplicação. |
Solicitação | Quando 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.