Menu

O que é dívida técnica e por que os testadores de controle de qualidade devem se preocupar com isso?

  • Principal
  • Teste Ágil
  • O que é dívida técnica e por que os testadores de controle de qualidade devem se preocupar com isso?

what is technical debt

Experimente Nosso Instrumento Para Eliminar Problemas

Dívida técnica é uma ideia metafórica que argumenta que, assim como alguém pode ter problemas de endividamento em finanças, as organizações de software encontram algo semelhante no acúmulo de trabalho inacabado durante projetos anteriores e lançamentos de versões / sprints.

O que é dívida técnica?

Ele representa o esforço necessário para corrigir os problemas / defeitos que permanecem no código quando um aplicativo é lançado. Em palavras simples - é a diferença (em termos de bugs) entre o que é esperado e o que é entregue.

Quando uma equipe de desenvolvimento está ocupada trabalhando em um projeto e corrigindo bugs, infelizmente, muitos novos bugs aparecem. Fora de estes, alguns são corrigidos e alguns são diferentes para versões posteriores. Quando essa diferença de problemas continua aumentando, em um ponto se torna realmente difícil lançar o produto no prazo e sem problemas. Esta é a pior consequência de Dívida técnica se não for resolvido a tempo.

Neste artigo, você aprenderá - o que é dívida técnica, por que a equipe de QA deve se preocupar com isso e, o mais importante, como gerenciá-la.

o que é dívida de tecnologia

imagem fonte

Ward Cunningham , o fundador do software wiki, concebeu esta ideia na década de 1990, traçando paralelos com o impacto da inadimplência no setor financeiro, literalmente aludindo à experiência desagradável de ter que pagar juros excessivos após a inadimplência dos empréstimos.

melhor software para criar fluxogramas

O desafio de aumentar o débito de tecnologia por sprint pode ser visualizado na Fig.1.

Deve ser mencionado aqui, porém, que há uma ligeira diferença no significado de dívida técnica (também conhecida como dívida de código ou dívida de design) de sua analogia correspondente no mundo das finanças - a primeira é mais como uma ideia abstrata , sem equações matemáticas para visualizar como os juros realmente se acumulam.

aumento da dívida técnica

Figura 1: Visualizando o aumento escalonável no débito de tecnologia em sprints

O que você aprenderá:

Por que as equipes de controle de qualidade sofrem mais devido à dívida técnica

Durante um ciclo típico de design e desenvolvimento de software, há várias coisas que podem levar a um “ dívida técnica ”Como situação- documentação imprópria , teste inadequado e correção de bugs, falta de coordenação entre as equipes, legado código e refatoração atrasada , ausência de integração contínua e outros fatores fora de controle.

Por exemplo, foi observado que os esforços de duplicação de código podem levar a qualquer coisa entre 25 para 35% trabalho extra.

modelagem de dados perguntas e respostas da entrevista pdf

No entanto, em nenhum lugar estão os desafios devido ao débito técnico mais evidentes do que nos testes de controle de qualidade onde as equipes de teste têm que cumprir prazos inesperados e tudo pode ficar errado.

Quantas vezes seus testadores enfrentaram dilemas no último momento quando, inesperadamente, o gerente de entrega veio e disse a eles: “Equipe! Temos que lançar nosso produto em uma semana, desculpe por não podermos comunicar isso a tempo. Conclua todas as tarefas de teste com urgência para que possamos estar prontos com a demonstração. ”

Basicamente, qualquer teste perdido ou abordagem 'resolva mais tarde' pode levar a um problema de dívida de tecnologia. Falta de cobertura de teste , histórias de usuários superdimensionadas, sprints curtos e outros exemplos de “atalhos” devido à pressão de entrega desempenham um grande papel por trás do acúmulo de dívidas técnicas na prática de QA.

Um exemplo do mundo real

Um varejista online com sede nos Estados Unidos com presença significativa em vários sites e aplicativos móveis se viu em um desafio de 'dívida técnica' do mundo real quando a complexidade da malha de teste começou a aumentar a cada novo corrida .

Isso aconteceu devido ao aumento repentino no número de dispositivos móveis a serem testados, vários idiomas a serem suportados e mais de meia dúzia de sites de redes sociais a serem aproveitados.

Com uma cobertura de automação inferior a 40%, o desafio da dívida de tecnologia apareceria das seguintes maneiras:

  • Consumo de tempo excessivo no teste de lançamento - Com o número de navegadores, dispositivos e scripts crescendo a cada sprint de teste, o ciclo de lançamento continuaria atrasado, levando à perda de tempo de colocação no mercado.
  • O aumento do custo de contratação - O número de testadores necessários para apoiar o projeto quase dobrou, o que se traduziu em custos adicionais de $ 500k
  • Complexidade no projeto - Com a crescente complexidade do projeto, acompanhar os casos de teste e bugs estava se tornando um desafio
  • Muito tempo perdido na busca de falsos positivos - Mais uma vez, uma consequência das crescentes complexidades do projeto.
  • Aumento no esforço de desenvolvimento de teste em até 60% - Vai com o território

Gerenciamento de dívida de tecnologia em práticas de QA

A maioria dos gerentes de controle de qualidade vê impulsivamente o débito tecnológico como a consequência razoável de concentrar toda a sua energia apenas no sprint atual, o que leva a alcançar a cobertura do teste de alguma forma por meios manuais e ignorar completamente a automação.

Isso é conhecido como abordagem rápida e suja que foi abordado em um blog por Martin Fowler, o autor do quadrante de dívida técnica .

Princípios ágeis ditam que visualizemos o problema da dívida de tecnologia como uma incapacidade de manter e atender Benchmarks de controle de qualidade .

Na verdade, baseado em uma pesquisa pelo Instituto Nacional de Padrões e Tecnologia (NIST), ferramentas e métodos de teste insuficientes custam anualmente à economia dos EUA entre $ 22,2 e $ 59,5 bilhões , com cerca de metade desse dinheiro gasto em testes extras por desenvolvedores de software e cerca de metade por usuários de software para evitar falhas.

Em vez de reagir às falhas conforme e quando o incidente acontece, uma abordagem proativa seria identificar os defeitos após cada atividade ou tarefa que pode ser medida. Você pode fazer tudo isso manualmente, mas dados os milhares de cenários de casos de teste para um projeto médio, o controle de teste automatizado é uma necessidade.

Claramente, teste eficaz pode ajudá-lo a ganhar terreno sério na guerra contra a dívida técnica. Então, o que significa basicamente? Significa o quão bem equipado seu sistema está na identificação de defeitos na aplicação geral.

eficácia do teste

Como mostra a equação acima, a eficácia do caso de teste pode, teoricamente, chegar a até 100% se o número de defeitos encontrados pelo cliente (ou seja, defeitos de pós-produção) tivesse sido mapeado precisamente para o número de defeitos encontrados em cada estágio de cobertura de teste.

Para ter uma bancada de teste bem projetada que possa medir com precisão os defeitos assim que eles se infiltrarem, a automação é um pré-requisito.

servidor privado gratuito de world of warcraft

Automação de teste ajuda a minimizar o número de scripts que estão sendo executados, relatando os resultados e comparando-os com execuções de teste anteriores. O método ou processo usado para executar a automação é chamado de teste automação estrutura .

Exemplos típicos seriam ferramentas disponíveis no mercado ou gratuitas, como Selenium, MonkeyTalk, robôs , Borland SilkCentral, HP Quality Center e IBM Rational Rose .

No passado, o controle de qualidade / teste era frequentemente visto pelas organizações e suas equipes de software como uma atividade de suporte para resultados de negócios mais importantes, e não uma prática disciplinada em si mesma que exigiria foco central e dedicado. Na verdade, uma abordagem não essencial para teste / controle de qualidade é precisamente o que levou ao desafio contínuo de dívida técnica em primeiro lugar.

Considerando o rápido ritmo de evolução em habilidades de controle de qualidade / teste que ocorreu na última década, as organizações estão tendo muita dificuldade em atualizar suas habilidades e competências para os níveis mínimos desejados de acordo com os benchmarks atuais do setor.

Na verdade, há uma tendência crescente da indústria de se contentar com nada menos do que os profissionais mais experientes em automação de testes - mais ou menos como os comandos de elite de teste / QA; eles são conhecidos como engenheiros de software em teste ( Desde a ) e desenvolvedores de software em teste ( SDiT ) Esses profissionais estão em alta demanda devido à sua vasta experiência em um vertical escolhido (por exemplo, e-commerce) ou uma categoria profissional específica.

A maioria das empresas de desenvolvimento de software e produto, como falamos agora, está lutando para encontrar os recursos técnicos qualificados e desejados em face dos prazos de entrega mais curtos. A solução para este desafio é fazer parceria com um player offshore de automação de QA que pode resolver sua falta de habilidades com o conjunto certo de recursos SDiT / SEiT.

Outros atributos desejados de um player de terceirização em QA / Testing que se mostram úteis incluem uma abordagem ágil e disciplinada para a execução do projeto, experiência suficiente no setor, incluindo acesso prático a estruturas de automação reutilizáveis ​​e casos de teste e, por último, mas não menos importante, uma intenção clara e capacidade de lidar com os desafios da equipe remota e conflitos culturais para que o cliente não seja sobrecarregado com o trabalho extra de gerenciamento de contratados.

Conclusão

Como qualquer outra dívida, a dívida técnica pode provar ser a ruína das empresas e a causa raiz de seu acúmulo é a falha na implementação de uma prática proativa de controle de qualidade que remove todos os atrasos na automação.

Sobre o autor: Esta é uma postagem de convidado da equipe eInfochips. Eles criaram uma abordagem única chamada Tech Debt Zero que é uma das formas mais estruturadas e eficientes de eliminar gradativamente o débito técnico nas atividades de QA / automação. Para saber mais sobre dívidas de tecnologia, Assista esse video em uma abordagem para reduzir o departamento de tecnologia.

Espero que você tenha uma ideia clara sobre o que é dívida técnica. Deixe-nos saber se você tiver alguma dúvida relacionada a ele ou como gerenciá-lo na prática.

Leitura recomendada

^