A automação de teste pode melhorar o processo de desenvolvimento de software em diversos casos. A automação de teste está inicialmente associada a um esforço aumentado, mas os benefícios relacionados são imediatamente notados. Testes automatizados podem ser executados com rapidez e frequência, o que é muito rentável para produtos de software com uma longa vida útil e, portanto, também com custos de manutenção mais elevados. Ao testarmos em um ambiente ágil, faze-se necessário responder rapidamente a alterações de sistemas de software e requisitos. Novos casos de teste baseados em recursos atualizados podem ser adicionados simultaneamente à automação em paralelo ao desenvolvimento do próprio software. O processo de automação também leva a um ciclo de desenvolvimento mais curto combinado com um software de melhor qualidade e, portanto, os benefícios do teste automatizado de software ajudam a superar rapidamente os custos iniciais.
O STLC é constituído por várias fases do teste de software que são seguidas de forma sequencial para garantir uma melhor qualidade e entrega do software. As fases de um processo STLC incluem estratégia de teste, desenvolvimento de testes, execução de teste, gerenciamento de falhas e entrega. Essencialmente, a “Automação” para a aplicação acontece nas fases de estratégia de teste e desenvolvimento de testes. Na fase da estratégia, os aspectos técnicos e funcionais devem ser definidos em relação ao desenvolvimento da automação. Na fase de desenvolvimento, como o nome sugere, o desenvolvimento da estrutura de automação ou aplicativo começa com a documentação adequada das funcionalidades que precisam ser automatizadas como um guia, juntamente com a abordagem técnica que precisa ser tomada para criar o bloco de código de automação.
Na era atual do desenvolvimento de software, especialmente no que diz respeito ao modelo ágil, o deploy de recursos em um aplicativo tornou-se muito regular. Então, manter o controle de todas as funcionalidades existentes, além das novas que surgem pelo caminho é muito difícil, a menos que haja alguma aplicação que faça o trabalho de verificar a regressão do deploy do aplicativo durante um determinado intervalo de tempo.
A regressão é um termo que determina que os módulos existentes dentro do sistema de software não devem quebrar ao introduzir novos módulos dentro do aplicativo. A regressão pode ser classificada principalmente em três tipos:
Regressão funcional: executa uma regressão completa em toda a aplicação para determinar se todos os recursos funcionam bem.
Regressão de unidade: executa regressões específicas nos módulos da unidade para verificar se cada módulo que compõe o aplicativo inteiro está funcionando corretamente.
Regressão visual: verifica visualmente o layout de um aplicativo na web ou celular e todos os componentes na web e no celular.
Quando se trata de testar no DevOps, a integração contínua desempenha um papel fundamental no processo de lançamento do software. A principal preocupação da integração contínua é justamente resolver problemas de integração. No Extreme Programming, a integração contínua era usado em combinação com testes de regressão automatizados escritos através das práticas de desenvolvimento automatizado test-driven. Inicialmente, isso foi concebido como executando todas as regressões e testes no ambiente local do desenvolvedor e verificando que todos passaram antes de fazer o commit no mainline. Isso ajuda a evitar que o trabalho em progresso de um desenvolvedor interfira no trabalho de outro desenvolvedor. Na mesma linha, a prática de entrega contínua prolonga ainda mais a integração contínua, ao certificar-se de que o aplicativo verificado no mainline esteja sempre em um estado que possa ser implementado para usuários e tornando o processo de deploy atual muito rápido.
A integração contínua fornece um aspecto importante na atual era do desenvolvimento de software, pois ajuda a recuperar os erros de integração e detectá-los o quanto antes possível, acompanhando a estabilidade do aplicativo ao longo de um período de tempo.
A configuração de um processo de integração contínua pode ser obtida através de ferramentas como Jenkins, Travis CI, Atlassian Bamboo e CircleCI. Jenkins e Travis CI são open source.
Referência:
Configurando um trabalho de CI usando o Jenkins.
Estas são algumas das tendências de desenvolvimento que estão sendo seguidas hoje:
Behavior-Driven Development, ou BDD, é uma síntese e refinamento de práticas de Test Data-Driven Development (TDD) e Acceptance Test Data-Driven Development (ATDD). Ele usa um formato que é conhecido como a linguagem Gherkin, que ajuda na automação de cenários de teste em um formato específico de comportamento em que os testes são formatados em inglês simples com base no comportamento dos elementos na aplicação. O benefício esperado do uso do BDD é que ele ofereça orientações mais precisas na organização da conversa entre desenvolvedores e testadores e especialistas no domínio. As notações originadas na abordagem BDD, em particular o canvas given-when-then, estão próximas de qualquer linguagem e todos na equipe podem entender. Além disso, as ferramentas e frameworks visando uma abordagem BDD geralmente oferecem a geração automática de documentação técnica e de usuários finais das especificações do BDD.
O desenvolvimento orientado por testes (TDD) é uma abordagem evolutiva para o desenvolvimento que combina o primeiro desenvolvimento de teste, onde o programador escreve um teste antes de escrever apenas o código de produção suficiente para cumprir esse teste e refatoração. Um objetivo do TDD é a especificação e não a validação. Em outras palavras, é uma forma de pensar as necessidades ou design antes de começar a escrever um código funcional. Outra visão é que o TDD é uma técnica de programação. Como Ron Jeffries gosta de dizer, o objetivo do TDD é “escrever código limpo que funcione”.
Regressão visual ou Visual Regression é uma técnica usada para automatizar o processo de captura de problemas baseados em UI/UX a longo prazo para múltiplos dispositivos. Isso pode ser alcançado usando diferentes ferramentas e técnicas. A regressão visual pode assumir uma parte muito importante no processo de entrega.
Uma ferramenta de teste de regressão visual executa testes de regressão de front-end ou UI capturando a tela de páginas da web/interfaces de usuário e comparando-as com as imagens originais (capturas de tela históricas ou imagens de referência no site em exibição). Se a nova captura de tela se desviar da captura de tela da baseline ou da tela de referência, a ferramenta Visual Regression envia notificações sobre as falhas de teste em um relatório HTML. No contexto de aplicações web, as ferramentas de Regressão Visual realizam testes de regressão visual principalmente em alterações de CSS. Algumas das estruturas e bibliotecas que podem ser usadas para realizar a Regressão Visual são Galen, Wraith, Backstop JS e PhantomCSS. Todas são iniciativas de código aberto e podem ser usadas diretamente instalando seus respectivos binários. Existem outras ferramentas licenciadas, incluindo o popular Applitool.
Reference: Visual Regression using Galen
BrowserStack é uma ferramenta de teste cross-browser baseada em nuvem que permite aos desenvolvedores testar seus sites em vários navegadores em diferentes sistemas operacionais e dispositivos móveis, sem exigir que os usuários instalem máquinas, dispositivos ou emuladores virtuais.
Referência:
Setting up your automation on BrowserStackk
Há outra plataforma conhecida da nuvem onde você pode executar seus testes: é o SauceLabs.
Headless refere-se à execução de testes automatizados sem permitir que os usuários vejam qualquer interação direta do navegador, de modo que a maioria das funcionalidades são executadas a partir do back-end. Então, basicamente, um headless browser (e não “navegador sem cabeça”) é um navegador da Web sem uma interface gráfica de usuário. O Google começou a usar navegação headless em 2009 para indexar o conteúdo de sites usando o Ajax.
A automação sem cabeça pode ser alcançada usando PhantomJS, CasperJS, ou usando o SlimerJS. O conceito de interação headless foi trazido por Ariya Hridayat, que criou um webkit que poderia ser executado como um navegador sem ter UI. O PhantomJS está disponível no Selenium e pode ser facilmente usado com ele também.
Referências:
Headless automation using CasperJS
Headless automation using Selenium and PhantomJS driver
Todos os tipos de testes no STLC podem ser tratados sob uma abordagem de automação, dependendo do projeto e também de outros aspectos como ETA, sprints, deploys etc. Mas a equipe de controle de qualidade definitivamente precisa fazer um ROI antes mesmo de iniciar a automação porque o cliente precisa ter certeza de que o tempo e o esforço investidos no desenvolvimento de uma estrutura de automação irão beneficiar o ciclo de vida do projeto.
Fonte: DZone.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.