Entenda a versatilidade e a importância dos testes de softwares dentro de um processo de qualidade e como este processo qualificará sua entrega final. Leia o artigo a seguir.
Lembro-me que comecei a ouvir mais sobre conceitos de testes de Software em meados dos anos 90, quando comecei a trabalhar na área de TI, ainda no suporte técnico de computadores e redes, como a maioria dos profissionais da minha geração. Porém, nesta época, apesar do processo de testes de software já ser bem conhecido (iniciou mesmo a partir do final da década de 70), se destinava mais a processos dentro da camada de desenvolvimento dos sistemas, com o que hoje talvez chamariam de testes unitários, do que efetivamente são hoje em dia. Foi um caminho um tanto longo para o mercado poder avaliar e entender o que efetivamente isso se tratava, já que, por muito tempo, e ainda existem vestígios disso hoje em dia, processo de TI são considerados meramente custos, apesar de, talvez, 99% das empresas de hoje dependerem tecnologia para funcionar. Mas com o passar dos anos, primeiro as grandes empresas começaram a investir mais neste conceito e já começariam a surgir as primeiras áreas de QA que fariam parte de todo o processo de implementação ou atualização de sistemas corporativos.
Com o boom de processos relacionados a governança corporativa no Brasil, tais como o ITIL e o Cobit, tal foi a necessidade de “subir a régua” na qualidade do que ia para os ambientes de produção que processos cada vez mais detalhados de qualidade foram implementados nessas esteiras, onde por exemplo, em reuniões de gestão de mudanças (Ou CAB – Change Advisory Boards se preferirem), a palavra da equipe de QA poderia ser decisiva na subida, ou não, de um release de sistema. O mercado então realmente começou a olhar o processo de qualidade de software como algo a parte inclusive do desenvolvimento, porém, com grande foco já em questões de arquitetura, ou seja, a necessidade de um processo de qualidade mais proativo.
Já com o advento do que chamamos hoje de DevOps, nos anos 2010, filho esse oriundo diretamente de conceitos já constantes no manifesto ágil, de 2001, foi cada vez sendo mais consolidada a necessidade constante de comunicação entre as áreas de operação e desenvolvimento para garantir entregas mais rápidas e com cada vez menos impacto no negócio. E é ai mesmo que os processos de qualidade, mais precisamente, os vários tipos em conceitos de testes de software entram para amarrar mais uma haste desta ponte de comunicação, que é, junto com outros processos importantes, vital para que seja feita uma entrega e qualidade, ou seja, que esteja em conformidade com os requisitos Pré-acordados entre todas as partes envolvidas.
Porém, ainda existem certos pontos a serem trabalhados nessa relação que existe hoje com o processo de testes e talvez um deles, que podemos explorar um pouco melhor agora é uma questão que até parece óbvia, mas ainda gera muita dúvida e discussão: Quando devemos envolver a equipe de teste? E a resposta é, talvez, menos decisiva ainda, que é: Depende! Pois alguns pontos devem ser antes avaliados, tais como:
Qual será a função deste novo processo dentro de um sistema já existente?
Muitas vezes, em um sistema novo ou um processo de sistema que esteja sendo desenvolvido, dependendo de seu objetivo dentro do processo de negócios, a equipe de testes de software possa entrar de forma pontual e cirúrgica, isto é, somente no momento especifico para um teste isolado desta nova feature, já que a mesma vai trabalhar de forma bem isolada do resto do sistema, não sendo necessário, por exemplo, um teste de regressão para que outros parâmetros do sistema que sofressem alguma alteração em seu comportamento em detrimento a essa release tivessem que ser revisitados para eventuais correções de bugs oriundos desta mudança que passariam despercebidos por testes unitários, já que podem envolver, por exemplo, alterações na experiencia do usuário final. Neste cenário podem valer mais testes relacionados à funcionalidade de interface de forma isolada, no caso de existir uma nova tela, por exemplo e, dependendo do que esse recurso vai trabalhar, testes específicos de performance.
O sistema ou novo recurso servirá somente para um processo pontual de negócios, por um curto período de tempo, e depois será descartado.
Este é um caso onde menos é mais, já que obviamente o que subir para produção deverá ter qualidade, mas não carece de ter talvez um grande refinamento pois, após o seu uso, fatalmente será descartado. Ai provavelmente valerão testes de performance pois na maioria das vezes, processos desta natureza a serem testados envolvem grande captação e geração de dados de forma mais rápida possível (Ex: Ações de promoções de produtos em E-commerce). Neste caso o ideal é que a equipe de testes seja envolvida o quanto antes, para entender como o processo está sendo desenvolvido já que, provavelmente, os donos deste processo não terão nem tempo ou orçamento muito grandes, quer seja para testes ou para outros recursos. Portanto, quanto antes a equipe de testes se envolver de forma efetiva e somente vendo as necessidades principais, menos chance o processo tem de gerar Bugs nas etapas seguintes e, como consequência, sua entrada em produção é mais assertiva e respeitando um cronograma já mais apertado. Obviamente, esses foram somente alguns exemplos para salientarmos a importância do timming em que uma equipe de testes pode atuar de forma mais ágil e efetiva para evitar acidentes de percurso em produção, ajudando assim a garantir uma entrega final sem maiores problemas. Trataremos deste assunto mais a fundo em futuros posts!
Fernando Gomes
Posts Relacionados
