Devbox testing: melhorando a garantia de qualidade e acelerando o desenvolvimento
Nos últimos tempos, tem surgido a necessidade de adequar os processos de desenvolvimento de software para se tornarem cada vez mais fluidos, reduzindo o tempo entre deploys e consequentemente, aumentando a velocidade das entregas.
Com isso, a visão de que a garantia da qualidade de software faz parte apenas da etapa final do processo, mostra-se ultrapassada, pois deve acontecer desde o início do ciclo, assim como no devbox testing.
Mas o que é o devbox testing?
Em um processo de desenvolvimento, utilizando Scrum como exemplo, ocorre o seguinte:
- O desenvolvedor implementa uma user story;
- Submete o código para avaliação em um pull request (PR);
- Somente então, disponibiliza a alteração em um ambiente de testes;
- Caso um bug seja encontrado, ele é registrado e o processo todo se repete novamente, para que por fim, o bugfix seja disponibilizado no ambiente de testes e revalidado.
Com o devbox, a etapa de teste é antecipada para o momento anterior à abertura do PR. O desenvolvedor implementa a user story, convida o QA para realizar um teste em seu ambiente local, e a partir daí os dois comparam se o que foi implementado está de acordo com os requisitos definidos anteriormente.
O intuito é antecipar o surgimento de bugs e reduzir o tempo que seria gasto na submissão deles na etapa de bugfix. Isso é possível, devido ao fato de os testes estarem sendo realizados antes da abertura do pull request.
A reiteração que normalmente aconteceria em um processo tradicional, torna-se inexistente, pois sobra apenas a necessidade de corrigir o código, e remove-se o tempo necessário para submissão e aprovação dos pull requests subsequentes.
É importante ressaltar que, durante o devbox, sejam realizadas apenas verificações da conformidade do software com os requisitos e alguns outros testes básicos. Como a proposta é antecipar bugs e reduzir o tempo de desenvolvimento como um todo, não vale a pena tentar realizar todos os testes possíveis logo nessa etapa.
Entretanto, uma dúvida que muitos tem, é:
Essa prática não vai causar uma diminuição na métrica de bugs?
Utilizar número de bugs como medida de qualidade é uma visão ultrapassada, pois até pequenos ajustes no processo de desenvolvimento, mesmo os externos às atividades de teste, podem impactar na redução dessa métrica.
É como diz a famosa frase do cientista da computação Edsger W. Dijkstra:
“Testes de software mostram a presença de bugs, mas não a sua ausência.”
Isso significa que, por mais que sejam dedicadas horas e horas de teste no final da sprint e vários bugs sejam encontrados, ainda existirão vários outros “escondidos”.
A qualidade do software é responsabilidade do time como um todo. Esperar que tudo se resolva apenas na fase de bugfix, é ilusório e improdutivo.
Por isso, é importante que mais iniciativas como essas surjam, e auxiliem na adaptação dos processos de desenvolvimento de software nas empresas para um modelo mais moderno, em que a garantia de qualidade é obrigatória em todas as etapas e colabora para entregas mais frequentes, com mais valor agregado e menos sujeitas à falhas.
Referências
- Engenharia de Software Moderna, por Marco Túlio Valente
- Dev Box Testing: Reduce Your Bug Life Cycle, by ShriKant Vashishtha
