Teste com mais inteligência, não com mais testes: Conceito de Shift-Right Test com análise de impacto

Postado em 28 de agosto de 2019, em AgileAPI TestingUnit Testing

Blog Graphics-10

Escrito por Mark Lambert

A análise de impacto dos testes foca na realização dos testes especificamente nas mudanças feitas durante cada iteração e em testar exatamente o que precisa ser testado e automatizado. As equipes que usam essa tecnologia podem otimizar seus esforços de testes em desenvolvimento com feedback instantâneo sobre o que precisa ser feito.

Confirmado com frequência pelas pesquisas e relatórios do setor, o teste de software ainda é um gargalo mesmo após a implementação de processos modernos de desenvolvimento como Ágil, DevOps e Continuous Integration/Deployment. Em alguns casos as equipes de testes não estão testando o suficiente e precisam lidar com bugs e vulnerabilidades de segurança nos maiores estágios do ciclo de desenvolvimento, o que cria uma falsa suposição que esses novos processos não cumprem suas promessas. Uma solução para certas classes de problemas é adotar o conceito de shift-right nos testes, os quais focam na monitoração da aplicação no ambiente de produção, porém, isso requer uma infraestrutura sólida para reverter as novas mudanças se um defeito crítico aparecer.

Como resultado, as organizações ainda estão perdendo os prazos, e a qualidade e a segurança ainda sofrem as consequências. Mas há uma forma melhor! Para testar de forma mais inteligente, as organizações estão usando uma tecnologia chamada análise de impacto de teste para entender exatamente o que testar. Esta abordagem orientada a dados suporta tanto os testes no modo shift-left quando no shift-right.

O Ágil e DevOps e o Gargalo do Teste

Testar em qualquer processo iterativo é um compromisso de quanto teste pode ser feito em um ciclo limitado de tempo. Ao invés disso, um conjunto limitado de teste é executado, e exatamente o que testar está baseado nas melhores premissas e expectativas. Os testes são novamente carregados no ciclo uma vez que geralmente não há novas features completas suficientes para testar. O gráfico de esforço versus o tempo resultante termina como um dente de uma serra conforme mostrado abaixo na figura 1. Em cada ciclo, somente um conjunto de testes é executado até o ciclo final onde um teste de regressão completo é realizado.

Agile processes result in a "saw tooth" of testing activity. Only the full regression cycle is able to do a "complete" test.

Figura 1:  Processos Ágeis resultam em um “dente de serra” das atuvudades de teste. Somente um ciclo de regressão completo é capaz de fazer um teste “completo”

Infelizmente nenhum projeto alcança o ciclo final com zero bug e zero vulnerabilidade de segurança. Encontrar defeitos nestes estágios causa atrasos, pois os bugs são resolvidos e retestados. E mesmo com esses atrasos e tudo mais, muitos bugs ainda acabam chegando no produto entregue como ilustrado abaixo.

Integration and full regression testing is never error-free. Late stage defects cause schedule and cost overruns.

Figure 2: Teste de integração e testes de regressão completa nunca são livres de defeitos. Defeitos nos últimos estágios causam estouros de custo e de prazo.

Essa situação resultou na adoção de o que foi denominado de “shift-right testing” no qual as organizações continuam testando suas aplicações nas fases de implantação. A intenção do shift-right testing é aumentar e estender os esforços dos testes com testes mais adequados na fase de implantação tal como monitoração de APIs, alternando features em produção e obtendo um feedback das operações na vida real.

E nesse artigo você ainda verá:

  • O que é o Shift-Right Test?
  • Testar de forma mais inteligente, não com mais testes através do foco nos seus testes
  • Análise de impacto do teste

Para ver esse artigo na íntegra em inglês e acompanhar todas as dicas. Clique aqui ou preencha os dados abaixo para receber mais informações sobre a Parasoft.

    Contato

    Informe seus dados e deixe uma mensagem para que possamos direciona-lo(a) para um de nossos consultores.

    Primeiro Nome:

    Sobrenome:*

    Celular:

    E_mail:

    Descreva um resumo da sua dúvida ou sugestão:

    Primeiros passos com o AppSec usando o OWASP

    owasp-top10

    Postado por Arthur Hicken  em 18 de julho de 2019.

    Continuamos vendo grandes brechas de dados que afetam organizações de todos os tamanhos. À medida que os problemas de segurança cibernética continuam e até aumentam em frequência e gravidade, ficamos imaginando: “Somos os próximos?” E “O que posso fazer sobre isso?” É aí que entra o OWASP.

    Qual é o Top 10 do OWASP?

    Melhor conhecido por OWASP Top 10, o OWASP é o Projeto Aberto de Seguranças de Aplicação Web, uma comunidade aberta com informações e treinamentos gratuítos sobre segurança de aplicações. O Top 10 OWASP é uma lista de grandes riscos mais conhecidos para aplicações web, revisada periodicamente para se manter atualizada. Se você não tem feito muito em termos de segurança de aplicações , ou se o que você está fazendo está desorganizado ou de forma exploratória, o Top 10 OWASP é um excelente ponto de partida.

    Quais são as Top 10 Vulnerabilidades de Hoje?

    O Top 10 OWASP foi atualizado pela última vez em 2017 e é composto pelas seguintes vulnerabilidades A1-A10:

    • A1: 2017 – Injection
    • A2: 2017 – Autenticação Quebrada
    • A3: 2017 – Exposição de Dados Confidenciais
    • A4: 2017 – Entidades Externas, XML (XXE)
    • A5: 2017 – Controle de Acesso Quebrado
    • A6: 2017 – Configuração Errada de Segurança
    • A7: 2017 – Scripting Cross-Site (XSS)
    • A8: 2017 – Desserialização Insegura
    • A9: 2017 – Uso de Componentes com Vulnerabilidades Conhecidas
    • A10: 2017 – Monitoramento e Logs Insuficientes

    A OWASP fornece uma documentação para as Top 10, com uma página Web dedicada para cada vulnerabilidade. A página descreve o que é cada vulnerabilidade e fornece uma nota para cada risco que é usada para priorizar e rastrear possíveis vulnerabilidades. Veja um exemplo na página abaixo:

    owasp-screenshot

    As várias seções na página lhe ajudam a entender a importância e perigo de cada uma das vulnerabilidades.

    Nesse artigo você ainda poderá ver as seguintes questões:

    • A Aplicação está Vulnerável?
    • Exemplos de Cenários de Ataques
    • Como Prevenir
    • Referências
    • Por que Usar o Top 10 OWASP?
    • Começando pelo Final
    • Mais do que DAST e SAST
    • Ferramentas e Dicas de Análise Estática de Código
    • O Poder da Prevenção

    Para ver esse artigo na íntegra em inglês e acompanhar todas as dicas. Clique aqui ou preencha os dados abaixo para receber mais informações sobre a Parasoft.

      Contato

      Informe seus dados e deixe uma mensagem para que possamos direciona-lo(a) para um de nossos consultores.

      Primeiro Nome:

      Sobrenome:*

      Celular:

      E_mail:

      Descreva um resumo da sua dúvida ou sugestão:

      Uma Melhor Abordagem para DevSecOps

      devsecops-01

      Publicado porMark Lambert em 30 de maio de 2019.

      A maioria dos problemas com o DevSecOps hoje volta às organizações tentando “consertar” a segurança adicionando testes no final do ciclo do produto na esperança de capturar algumas das vulnerabilidades críticas. Neste post aprenda como contornar isso através de uma estratégia eficaz para deslocar os testes de segurança para os primeiros estágios de desenvolvimento em apoio ao DevSecOps.

      No meu post anterior, discuti sobre o SecDevOps e por que é um termo melhor do que o DevSecOps comumente usado. A segurança geralmente é deixada como um processo adicional ou uma atividade realizada antes de lançar um produto, mas é difícil corrigir problemas de segurança quando um produto está quase na fase de lançamento. Deslocar a segurança para a esquerda, como no SecDevOps (onde o nome mais comum DevSecOps não importa), é a chave para o sucesso. A segurança deve fazer parte do fluxo de trabalho do dia-a-dia de cada desenvolvedor e estar integrada ao pipeline de software.

      Como vice-presidente de produtos da Parasoft, meu trabalho é garantir que isso seja mais fácil para nossos clientes. O que isto significa? Bem, para começar, isso significa automatizar o “shift-left” dos controles e políticas de segurança para ajudar nossos clientes a implementar a segurança no pipeline e ao mesmo tempo reduzir o impacto e o risco do DevSecOps. Então como você faz isso? Leia mais abaixo para aprender como aliviar os desafios tradicionais da integração da segurança no DevOps. Em seguida, inspecionaremos o fluxo de trabalho do DevSecOps que deslocará com sucesso a segurança para a esquerda, onde deveria estar.

      Resolvendo os Desafios que Impedem Estratégias Bem Sucedidas de DevSecOps

      A maioria dos problemas com o DevSecOps hoje volta às organizações tentando “consertar” a segurança, adicionando testes no final do ciclo do produto, na esperança de capturar algumas das vulnerabilidades críticas. Aqui estão algumas das razões como e por que isso está ocorrendo e como você pode resolvê-las com uma abordagem mais inteligente da segurança.

      Nesse artigo todos os desafios abaixo são discutidos com suas soluções:

      • Difícil Saber como “Consertar” a segurança
      • Testes de segurança no final do ciclo resultam em atrasos e vulnerabilidades que passam para a produção
      • Desconhecimento da situação do dos riscos de segurança do projeto até o último momento

      Para ver esse artigo na íntegra em inglês e acompanhar todas as dicas. Clique aqui ou preencha os dados abaixo para receber mais informações sobre a Parasoft.

        Contato

        Informe seus dados e deixe uma mensagem para que possamos direciona-lo(a) para um de nossos consultores.

        Primeiro Nome:

        Sobrenome:*

        Celular:

        E_mail:

        Descreva um resumo da sua dúvida ou sugestão:

        Práticas Recomendadas para Testes Unitários: Como Aproveitar ao Máximo Sua Automação de Teste

        Unit Testing Best Practices

        O teste unitário é uma prática bem conhecida, mas há muito espaço para melhorias! Neste post, as melhores e mais eficazes práticas de testes unitários, incluindo as práticas para maximizar o uso de ferramentas de automação ao longo do caminho. Também discutiremos a cobertura de código, dependências de ação de simulações e as estratégias gerais de teste.

        O Que é Teste Unitário?

        O teste unitário é a prática de testes de unidades ou componentes de uma aplicação individualmente a fim de validar se essas unidades estão funcionando apropriadamente. Geralmente, uma unidade deveria ser uma pequena parte de uma aplicação – Em Java uma unidade é geralmente uma classe simples. Note que eu não estou definindo estritamente “unidade” aqui, e isso fica por conta do desenvolvedor decidir o escopo do código testado para cada teste.

        Pessoas geralmente contrastam os termos “Teste Unitário” como “Teste de Integração” ou “Teste ponta-a-ponta”. A diferença é que, geralmente, teste unitário é feito para validar o comportamento de uma unidade individual que seja testável, enquanto que os testes de integração validam o comportamento de múltiplos componentes juntos, ou a aplicação como um todo. Como eu disse, a definição do que constitui uma “unidade” não está estritamente definida e depende do que você decidir para o escopo de cada teste.

        Nesse post de Brian McGlauflin você também poderá ver os seguintes temas.

        • Por que Aplicar Testes Unitários?

        • Boas Práticas para Testes Unitários

          • Os testes unitários devem Ser confiáveis
          • Os testes unitários deve ter manutenibilidade e serem legíveis
          • Um testes unitário deve verificar somente um caso de uso
          • Testes unitários devem ser isolados
          • Testes unitários devem ser automatizados
          • Use uma boa mistura de testes unitários e de integração
          • Os testes unitários devem ser executados dentro de uma prática organizada de teste

        Veja esse artigo na íntegra em inglês e acompanhe todas as dicas. Clique aqui ou preencha os dados abaixo para receber mais informações sobre a Parasoft.

          Contato

          Informe seus dados e deixe uma mensagem para que possamos direciona-lo(a) para um de nossos consultores.

          Primeiro Nome:

          Sobrenome:*

          Celular:

          E_mail:

          Descreva um resumo da sua dúvida ou sugestão:

          Instituições Financeiras se Preparam para Serem Testadas para Software Open Banking no Futuro

          open-bank-Parasoft-comp-bluefug-01

          Horário dos Bancos? Esse clichê será aposentado em breve. Agora, exigimos nada menos que 24/7 de acesso direto através das camada de aplicações aos serviços bancários que colocam a experiência do cliente na linha de frente. O que é o Open Banking, por que isso importa e como testamos isso?

          O setor financeiro global está avançando em direção a um futuro estado do Open Banking. Os bancos que forem bem-sucedidos nesse conceito revolucionarão sua própria interface de serviço, expondo controles em nível de APIs para que aplicativos de terceiros e novos serviços de tecnologia possam procurar contas, movimentar fundos e confirmar transações sem nem mesmo visitar a filial, o site ou o aplicativo móvel do banco.

          Mas os bancos e as novas startups estão aptas e seus negócios prontos para serem testados por essa transformação do Open Banking?

          O que é o Open Banking e Por que Isso Importa?

          O Open Banking é a mudança para o uso de APIs abertas no setor financeiro, que abrem as portas para novos desenvolvimentos e inovações a fim de beneficiar as empresas e o consumidor.

          Uma transformação centrada no cliente para APIs do Open Banking

          A transformação centrada no cliente acontece em todos os setores, de modo que os bancos devem adotar essa mudança como uma oportunidade de aprimorar ainda mais os serviços e mostrar velocidade, confiabilidade e opções de fundos e financiamentos que os tornam especiais.

          O Open Banking já se estabeleceu na Ásia e na África, onde os clientes ultrapassaram grande parte da camada intermediária do banco online e saltaram diretamente para a adoção comum de aplicativos em dispositivos móveis para microcrédito e pagamentos, como o WePay. Se os bancos desamparam o mercado, quem pode culpar os clientes por encontrarem um caminho melhor?

          Uma Legislação para a Abertura

          Os governos também estão pressionando pelo Open Banking, em nome de seus cidadãos. Depois que as novas regulamentações do PSD2 entraram em vigor em 2018 na Europa, várias grandes instituições dos EUA, como Citi, Wells Fargo e Visa, seguiram o exemplo e estão entrando em ação.

          Seria fácil interpretar essas iniciativas como um desafio competitivo à hegemonia dos maiores bancos do mundo. O Open Banking oferece a possibilidade de novas startups desintermediarem a experiência do cliente e oferecerem novos aplicativos móveis comerciais mais sofisticados para pagamentos, microempréstimos, crédito, investimento, seguro e muito mais.

          Like Europe’s GDPR privacy mandate, this initiative will likely be a leading indicator for financial industry guidelines and regulations that the United States adopts. Citizens want more openness among banks to put more choices and better services in the hands of banking customers with greater ease.

          Como a legislação de privacidade da GDPR da Europa, essa iniciativa provavelmente será um indicador importante para as diretrizes e regulamentações do setor financeiro adotadas pelos Estados Unidos. Os cidadãos querem mais abertura entre os bancos para colocar mais opções e melhores serviços nas mãos dos clientes bancários com maior facilidade.

          Se quiser ver esse artigo original em inglês na íntegra, clique aqui ou solicite mais informações abaixo.

            Contato

            Informe seus dados e deixe uma mensagem para que possamos direciona-lo(a) para um de nossos consultores.

            Primeiro Nome:

            Sobrenome:*

            Celular:

            E_mail:

            Descreva um resumo da sua dúvida ou sugestão: