Teste – provavelmente a parte mais desvalorizada do desenvolvimento de aplicativos

Por que eu deveria pagar você para testar seu próprio trabalho?

Essa é uma pergunta que ouvi muito ao longo dos anos ao discutir orçamentos de teste com clientes. Para os não iniciados, parece uma pergunta justa. No entanto, qualquer pessoa envolvida no desenvolvimento de software sabe como os testes podem ser complexos e demorados. O teste é, de fato, uma das partes mais importantes de qualquer projeto de desenvolvimento de software.

Uma grande plataforma de comércio eletrônico é uma coisa incrivelmente complexa com milhões de linhas de código, gigabytes de dados e muitos pontos de integração. Existem tantas partes móveis interligadas; tantos elos na cadeia que é muito fácil algo dar errado. O aplicativo será usado de milhões de maneiras diferentes por meio de uma infinidade de navegadores em vários dispositivos móveis e desktop. O projeto de desenvolvimento terá durado pelo menos 6 meses com muitas pessoas diferentes trabalhando nele. O número de áreas e cenários que podem ser testados é quase ilimitado. É uma maravilha qualquer coisa funciona em tudo!

Os testes podem ser divididos em várias áreas diferentes, mas cada área de teste é importante a ser considerada. Cada projeto é um pouco diferente; alguns clientes gostam de fazer muitos testes sozinhos, alguns gostam de terceirizar enquanto outros esperam que seu desenvolvedor faça tudo. O teste também não é uma entidade fixa; você pode fazer um monte de testes e você pode fazer um pouco. Quanto mais você testar, mais você reduzirá o risco do projeto, mas mais tempo levará e mais custará.

Teste de unidade

Um teste de unidade é aquele que testa pequenas 'unidades' de código para garantir que funcionem conforme o esperado. Por exemplo, quando um formulário é enviado, ele deve salvar os detalhes inseridos em uma tabela de banco de dados. É um teste autônomo que especificamente, e somente, garante que a unidade funcione conforme o esperado. Usando uma verdadeira metodologia de desenvolvimento orientado a testes, um desenvolvedor primeiro escreverá um teste antes de realmente criar qualquer código para que o código possa ser considerado concluído somente quando o teste for aprovado. Na prática, o teste de unidade é usado apenas em algumas áreas-chave do aplicativo para garantir que as funções principais estejam funcionando conforme o esperado. Embora o teste de unidade possa reduzir a probabilidade de ocorrência de problemas funcionais, ele também pode aumentar o tempo de desenvolvimento.

Teste de fumaça

Você provavelmente ouvirá sua agência de desenvolvimento falar muito sobre testes de fumaça. Um teste de fumaça é um subconjunto pragmático de casos de teste que cobrem as principais jornadas e funções do usuário em todo o seu aplicativo. No mínimo, seu desenvolvedor deve realizar testes de fumaça antes de entregar qualquer coisa a você para UAT.

Teste de IU

O teste de interface do usuário (UI) pode ser uma coisa muito complexa e demorada. A enorme variedade de dispositivos móveis, tablets e desktops, sistemas operacionais e navegadores que serão usados ​​para acessar um site significa que testar exaustivamente cada combinação manualmente é quase impossível. Devido ao grande número de variações diferentes que precisam ser cobertas, o teste de interface do usuário é um candidato perfeito para testes automatizados. As ferramentas de teste automatizadas são capazes de seguir uma jornada com script pelo seu site e testar se os resultados esperados são alcançados. Eles também podem gravar cada jornada para que cada uma possa ser reproduzida. Embora esse método não seja perfeito, ele pode reduzir significativamente o número de grandes problemas de interface do usuário que um site pode enfrentar.

Alguns serviços de teste de terceiros, como o Bug Finders, oferecem um serviço de crowdsourcing onde centenas de testadores humanos freelance de todo o mundo são usados ​​para testar um site e são pagos quando encontram um problema. Essa abordagem pode ser uma maneira relativamente econômica de testar seu aplicativo em centenas de combinações de dispositivo/plataforma/navegador. É normal que um ciclo de teste resulte em cerca de 200 questões levantadas. O desafio geralmente está em categorizar e priorizar os problemas para que você concentre seus recursos em lidar com os mais importantes. Todo site terá um acúmulo constante de problemas de baixo nível que provavelmente nunca serão resolvidos.

Teste de regressão

O teste de regressão é uma parte extremamente importante do desenvolvimento contínuo. Ele foi projetado para testar se alguma alteração em uma parte do aplicativo causou um problema em outra parte. Por exemplo, uma alteração em uma função JavaScript usada para validar o formulário de contato pode afetar os formulários usados ​​na finalização da compra. Devido à natureza complexa de qualquer plataforma de comércio eletrônico, problemas de regressão não são incomuns, portanto, elaborar um plano de teste de regressão sólido é vital para garantir que a experiência de seus usuários não seja prejudicada por esses problemas.

UAT

O teste de aceitação do usuário (UAT) é uma parte crítica de qualquer projeto de desenvolvimento e envolve o cliente realizando testes completos de ponta a ponta da plataforma antes de entrar em operação. O UAT é o processo que vejo subestimado com mais frequência. É também a parte de um projeto que é a primeira a sofrer quando os prazos são apertados. No entanto, é provável que isso leve a uma maior taxa de falha. Para qualquer nova construção de site, aconselhamos que pelo menos 2 meses de UAT sejam planejados. Seu site de comércio eletrônico é apenas uma parte de qualquer negócio de comércio e o processo de ponta a ponta envolvendo pesquisa, checkout, gerenciamento de pedidos, pagamento, despacho, atendimento ao cliente, finanças e todas as outras partes da cadeia precisam ser testado.

O UAT é frequentemente confundido ou mesclado com o SIT (System Integration Testing), onde você testará especificamente a integração entre vários sistemas. O SIT faz parte do teste de ponta a ponta, que garante que todas as partes da cadeia estejam funcionando corretamente em conjunto.

Um bom UAT envolve a criação de casos de teste e planos de teste. Eles geralmente assumem a forma de um conjunto de scripts (um script é um conjunto de tarefas a serem executadas) que um testador manual executará e passará ou falhará no teste de acordo com o resultado. Não é incomum que um plano de teste UAT de ponta a ponta inclua mais de 500 casos de teste.

O A em UAT é uma das razões pelas quais é tão importante. No final do processo de UAT, geralmente será considerado que você aceitou o aplicativo, por isso é importante que você o tenha testado minuciosamente para garantir que ele funcione exatamente da maneira que você esperava. Isso não significa que bugs não descobertos não estarão na garantia, mas se houver uma funcionalidade que não funcione da maneira que você esperava, isso precisa ser selecionado no UAT. A outra razão pela qual é tão importante é que é a última chance de resolver problemas antes de ir ao ar. Quaisquer bugs e problemas provavelmente afetarão negativamente a experiência do usuário.

O UAT exige muito esforço por parte do cliente, algo que muitas vezes é subestimado. Alguns clientes usam agências de testes externas para apoiá-los durante a UAT, o que pode reduzir significativamente o risco de um projeto em que o cliente não tem mão de obra para realizar a UAT de forma eficaz.

Teste de segurança

Às vezes, fico muito surpreso com o fato de alguns varejistas não levarem a sério os testes de segurança. Não é incomum descobrir que o varejista não sabe quando executou um teste de penetração pela última vez em sua plataforma web. Geralmente são aqueles que ainda não foram atingidos por um ataque cibernético (ou ainda não sabem que foram atingidos). No clima atual em que o crime cibernético continua a crescer em frequência e sofisticação, e especialmente com o GDPR no horizonte na Europa, os testes de segurança são cada vez mais importantes. Todas as plataformas da web de comércio eletrônico devem ser testadas quanto à penetração por um terceiro especialista pelo menos uma vez por ano, mas idealmente duas vezes por ano. Também é aconselhável que seu aplicativo seja verificado em busca de vulnerabilidades usando software especializado, como o Nessus, regularmente. Na Envoy, costumamos verificar as plataformas da web de nossos clientes semanalmente para garantir que as vulnerabilidades dos aplicativos sejam detectadas rapidamente. No mínimo, você deve realizar verificações de segurança do aplicativo antes de cada lançamento para produção. Não adianta esperar 6 meses até o próximo teste de penetração quando você introduziu uma nova vulnerabilidade de aplicativo.

Teste de performance

O teste de desempenho geralmente é usado para determinar quanto tráfego, solicitações de página, usuários simultâneos e volume de pedidos seu site pode suportar. É um processo mais difícil do que você pode imaginar, pois, para testar com precisão, você precisa imitar o comportamento real do usuário e, como você saberá, usuários reais fazem muitas coisas diferentes. O melhor que você pode fazer é imitar as principais jornadas do usuário, como pesquisar, adicionar ao carrinho e finalizar a compra. Idealmente, você deseja realizar testes de carga em seu ambiente de produção em vez de um ambiente de teste, pois isso fornecerá uma imagem muito mais verdadeira, mas isso também provavelmente deixará sua plataforma offline em algum momento durante o teste.

A maioria dos varejistas costuma realizar testes de carga uma vez por ano, normalmente antes de períodos de pico de negociação, como Black Friday ou Natal. O problema que isso pode causar é que, desde o último teste anual, um grande número de alterações pode ter sido feito no aplicativo, algumas das quais podem ter um impacto incremental no desempenho. Se um teste de carga anual mostra uma queda no desempenho em comparação com o ano anterior, é muito difícil determinar qual mudança ou mudanças no ano passado contribuíram para essa queda no desempenho. Isso também pode não lhe dar tempo suficiente para resolver os problemas de desempenho antes do início da negociação de pico.

Para combater isso, é aconselhável realizar avaliações de desempenho antes de cada novo lançamento de código. Eles não precisam ser executados em um ambiente de produção, desde que cada teste seja realizado no mesmo ambiente, pois o objetivo é determinar se o desempenho aumentou ou diminuiu em relação à última versão. Essa abordagem permite que as equipes de desenvolvimento entendam de onde vêm os aumentos ou diminuições no desempenho. Isso, é claro, leva tempo e, portanto, aumentará o tempo e os custos de desenvolvimento

Embora a lista acima não seja exaustiva, você pode ver que o escopo do teste no desenvolvimento de software pode ser muito grande e complexo. Cada tipo de teste leva tempo e esforço e você não deve apenas presumir que tudo é feito como padrão, sem custo adicional. As empresas com um forte foco em testes alocarão até 40% de qualquer tempo de projeto para testes, o que pode ser uma quantidade muito surpreendente. Um bom teste pode reduzir o risco de um projeto e pode se pagar a longo prazo, pois resultará em menos bugs, melhor desempenho e uma melhor experiência geral para seus clientes.