Devbox testing: melhorando a garantia de qualidade e acelerando o desenvolvimento

Leonardo Saldanha
SiDi QA
Published in
3 min readApr 30, 2021
#PraCegoVer: Pessoa utilizando um computador e umcelular, com um copo de café ao lado.

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:

  1. O desenvolvedor implementa uma user story;
  2. Submete o código para avaliação em um pull request (PR);
  3. Somente então, disponibiliza a alteração em um ambiente de testes;
  4. 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?

#PraCegoVer: As etapas no renascimento de uma borboleta, fazendo alusão a bugs, mas também à evolução.

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

--

--

Leonardo Saldanha
SiDi QA
Writer for

Eng. da Computação especializado em Qualidade de Software. Fã da automação de testes e acredita que todos deveriam saber pelo menos um pouco de programação.