Categoria: Qualidade de Software

Motivos para não automatizar em linguagem diferente do time

Introdução

Automatizar cenários de teste é uma parte integrante de nossa atuação como profissionais focados em qualidade. Em um contexto ágil é de extrema importância, pois, contribui para promover e permear a qualidade no projeto.

A ideia por trás dos testes automatizados e simples: otimizar nosso tempo. Naturalmente existe uma tendência em aumentar a cobertura de testes automatizados, para focarmos em cenários mais complexos e de alto risco.

Em contrapartida, existe uma grande decisão ha ser tomada: qual ferramenta escolher, o que automatizar e como o time pode colaborar.

Esse artigo elenca alguns pontos para uma escolha consciente de ferramentas para automatizar nossos testes.

Pontes ao invés de muros

Deixa eu contar uma história, quando estava fazendo o TSPI do Júlio de Lima, chegamos a uma etapa do treinamento onde ele aborda sobre a prática de testes automatizados.

Empolgado com a aula, decidi aplicar no time que atuo. Nós decidimos que nossa stack de desenvolvimento seria duas linguagens: PHP e Javascript e decidi automatizar em Ruby, pois estava estudando e gostando da linguagem.

Lembro de ter comentado com o Júlio, no princípio ficou contente pela minha conquista, mas me colocou uma pulga atrás da orelha com a seguinte pergunta:

“Pulis, porque não automatizar na linguagem que o time usa?”

Começamos a conversar e me explicou detalhadamente que tudo depende do contexto. Colocar uma tecnologia desconhecida ao time iria criar mais uma barreira do que promover pontes.

O que eu fiz? Abandonei o Ruby e iniciei alguns experimentos com algumas bibliotecas nas linguagens do time.

Stack de desenvolvimento

Uma das coisas mais importantes que devemos considerar e a stack que o time definiu, tratando-se em um contexto ágil a responsabilidade de testar a aplicação não é somente do QA, mas compartilhada com time.

Isto promove o empoderamento dos integrantes do time e aumenta a consciência sobre o aspecto da qualidade também, aumento o sentimento de “dono do produto”.

As autoras Janet Gregory e Lisa Crispin, dizem muito a respeito dessa responsabilidade do time em testar também. Essa citação exemplifica o conceito:

O coração do teste ágil envolve toda a equipe no teste e construção de qualidade em nosso produto.

Para conseguirmos alcançar esse objetivo devemos ter uma consciência de qualidade, onde todos contribuem e são donos produto.

Devemos atuar colaborativamente, ou seja, a linguagem de programação do projeto deve ser a mesma, pois assim, todos possam “conversar a mesma língua”.

Desenvolver testes automatizados em uma linguagem sem nenhum contexto, irá segregar os profissionais de qualidade e afastar eles do código da aplicação e gerar outros desdobramentos que iremos pontuar a seguir.

Separei cinco pontos nocivos, sobre automatizar cenários de teste em uma linguagem diferente ao que o time utiliza.

1 – Curva de aprendizado

Ao usarmos uma linguagem diferente, a curva de aprendizado pode ser muito maior para os profisisonais de qualidade. Cito alguns pontos que podem ser nocivos:

  • tempo de aprendizagem;
  • aprendizado do ecossistema em torno da linguagem;
  • falta de alguém como referencial no time;
  • falta de suporte;
  • segregação implícita dos QAs com o resto do time.

2 – Baixa produtividade

Outro ponto importantíssimo é a produtividade. Em um mundo onde tudo tem urgência, ter foco e produtividade é essencial para o sucesso dos produtos e/ou serviços que desenvolvemos.

Com uma nova linguagem em mãos a produtividade pode cair consideravelmente, pois, o profissional não teria domínio e nem expertise na mesma.

Outro ponto que deveríamos levar em consideração é que a etapa de testes não deveria ser um gargalho para finalizar uma versão do produto ou ser algo impeditivo.

Até o profissão de qualidade compreender a linguagem e pegar a “maldade” demanda tempo e em muitos cenários nosso tempo é bem escasso.

3 – Segregação dos testes

Ao usar essa abordagem a responsabilidade do teste fica inteiramente na mão do QA, reforçando uma má prática no contexto ágil. Essa má prática pode ocasionar em:

  • desconforto do time em relação a segregação;
  • antipatia entre devs e analistas de qualidade;
  • falta de engajamento do time;
  • separação por silos, indo contra os princípios da agilidade;
  • falta de colaboração do time nos testes;
  • base de conhecimento somente nas mãos de pessoas específicas.

4 – Maior esforço para manutenção

O esforço em manutenção iria aumentar consideravelmente. Numa squad com cinco desenvolvedores e um QA, todos poderiam dar manutenção e prover novas melhorias.

No cenário desenhado anteriorment a carga de manutenção dos scripts automatizados ficaria somente nas mãos do QA, podendo assim, trazer uma quantidade de trabalho muito grande e gerando gargalhos em suas atividades.

Outro ponto importante é a sensação de não ter tempo para melhorar os scripts, engana-se quem pensa que scripts de testes uma vez desenvolvidos nunca mais são tocados.

Assim como, um código de uma aplicação scripts automatizados são passíveis de refatoração e manutenção eles são parte integrante do código da aplicação.

5 – Pipelines isoladas

A etapa de integração e entrega contínua é uma das mais importantes para um time ágil. Geralmente são construídas pipelines para realizar essas atividades.

Quando automatizamos em uma linguagem que não é falada pelo o time, criamos uma série de possíveis problemas, tais como:]

  • maior custo de infraestrutura;
  • arquitetura da pipeline pode ficar bastante complexa;
  • construção de uma nova estrutura de pipeline;
  • time desconhece a linguagem não podendo contribuir;
  • aumento de trabalho para os DevOps.

Considerações finais

Automatizar testes é uma etapa importante de um processo de qualidade, mas deve ser alinhado com o time e sempre procurar essa responsabilidade entre os membros.

Ao segregar os testes essa responsabilidade cai nas mãos de uma única pessoa, trazendo diversos problemas como os que foram citados anteriormente.

Devemos sempre tentar optar por linguagens falada por todos, pois, linguagens de programação também são uma forma de comunicação.

Acredito que a regra de ouro nesse assunto seria tudo depende do seu contexto.

Agora é com você:

Quais são os seus pensamentos sobre o assunto? Gostaria muito de saber sua opinião.

Referências

Vocabulário de QA


Este artigo é uma tradução e adaptação livre do artigo “QA Testing Vocabulary” que pode ser acessado no blog abre em uma nova aba. O autor foi notificado e houve permissão para realizar a tradução..

Vocabulário de um QA

Se você trabalha em um time onde exista um QA, com certeza já se deparou com ele dizendo vários jargões técnicos, não é mesmo?

Pensando nisso, foi criado esse mini dicionário para entendermos cada jargão e dar sua devida importância.

Quando o time aumenta a compreensão desse vocabulário, fica mais fácil de entender cada etapa e alinhar as expectativas de cada parte. Então vamos lá?

Essa lista deve ajudá-lo a ter uma compreensão básica do vocabulário que um QA usa no seu cotidiano.

Tipos de teste

  • Teste manual:  significa testar o aplicativo ou site manualmente. Por exemplo, abrir um navegador e navegar manualmente para diferentes seções de um site, procurando por problemas de experiência do usuário ou bugs. (Para mais informações, consulte O que é teste manual?);
  • Teste automatizado significa usar uma linguagem de programação (como Java) para escrever scripts que irão navegar em um site ou aplicativo. Esses scripts podem gerar relatórios para problemas como links quebrados, texto ausente, etc. (para mais informações sobre as diferenças entre manual e automatizado, consulte Teste manual vs. automatizado .);
  • Teste de API significa verificar a qualidade/precisão de uma API. As APIs enviam solicitações e respostas de/para servidores remotos.
  • O teste de desempenho:  envolve verificar o tempo de resposta de um aplicativo ou site em cenários de uso típicos;
  • O teste de carga: é muito semelhante ao teste de desempenho, mas com ainda mais foco em encontrar o ponto exato em que um aplicativo ou site travaria, ou cairia.

Métodos de teste

  • O Teste de Aceitação do Usuário (UAT): significa fazer com que usuários reais testem o beta de seu aplicativo ou site e forneçam feedback;
  • Teste de acessibilidade  significa verificar se o aplicativo ou site é amigável para todas as pessoas. Por exemplo, verificar se os vídeos possuem legendas para pessoas com deficiência auditiva ou se as imagens têm descrições para pessoas com deficiência visual;
  • Teste de unidade (unitários): significa criar scripts automatizados para testar partes individuais do aplicativo ou código do site. Embora seja uma forma de teste, o teste de unidade geralmente é feito por desenvolvedores. O objetivo dos testes de unidade é garantir que cada área do código esteja funcionando corretamente;
  • Teste Ad-hoc: significa testar um aplicativo ou site sem seguir nenhum caso de teste específico. Em vez disso, o QA vasculhará o aplicativo à vontade, identificando quaisquer problemas que detectar durante o processo;
  • Teste exploratório: significa testar com a experiência e conhecimento existentes do aplicativo móvel ou site. Esse insight dá ao QA a capacidade de ter um envolvimento focado sem seguir casos de teste formais.

Testes básicos

Smoke test: é uma das formas mais rápidas/básicas de testar. Envolve fazer um teste simples dos principais recursos, geralmente logo antes do lançamento. O objetivo é verificar se alguma coisa “pega fogo”, por assim dizer.

Ele é usado como um backup para ser extremamente cauteloso quando não há tempo suficiente para o nível ideal de teste.

O smoke test é uma das frases mais comuns no vocabulário de um QA. Saiba mais em nosso artigo: O que é teste de fumaça?

Testes detalhados

O teste de regressão é muito mais completo do que o smoke test. Uma regressão envolve a verificação de todos os aspectos possíveis das features pré-existentes do aplicativo após a implantação de uma nova feature ou correção de bug. Isso é para garantir que as atualizações de código não prejudiquem nenhuma outra área do software;

Cross browser/cross-device  significa que o teste está sendo feito, ou um bug está ocorrendo, em vários navegadores de internet (como Safari, Chrome, Firefox, Internet Explorer, etc) ou vários dispositivos (Androids, iPhones, tablets, desktops, etc).

O teste entre navegadores/dispositivos é importante, pois muitos bugs estarão em um navegador ou dispositivo, mas não em outro.

Planejamento

Casos de teste são requisitos com etapas para testar se uma determinada parte do aplicativo ou site está funcionando corretamente. Se isso soar vago ou confuso, não se preocupe – temos uma explicação completa (com exemplos!) Em nossa postagem O que são casos de teste de controle de qualidade?

Test Suite é um conjunto de casos de teste. Por exemplo, você pode ter casos de teste para a seção de registro, a página inicial, a reprodução de vídeo, etc. Um conjunto de testes é uma planilha que consiste em todos esses diferentes casos de teste.

Sprint é um determinado período de tempo em um processo de QA Agile. Um sprint inclui um determinado número de tarefas que a equipe espera concluir no prazo (geralmente uma a duas semanas).

Antes do início de um Sprint, a equipe se reúne para o Planejamento do Sprint. Durante esta sessão, gerentes de produto, desenvolvedores e QA’s decidirão quais correções de bug ou features podem ser incluídos de forma realista no Sprint. Para saber mais sobre o processo de priorização, consulte Como priorizar correções de bugs.

Processo

Agile é um processo de desenvolvimento de software que envolve lançamentos regulares. Também envolve a atualização de requisitos em tempo real. Ao trabalhar com um processo Agile, é comum que novos lançamentos / atualizações sejam lançados a cada poucas semanas. Para saber mais, consulte nosso artigo sobre o Processo de controle de qualidade do Agile.

Os critérios de aceitação  são um conjunto de condições que devem ser atendidas para que um recurso seja considerado pronto para liberação. Com um processo ágil, as condições exatas podem mudar instantaneamente. Afinal, as equipes Agile giram em torno de novas informações ou ideias. No entanto, para considerar o recurso concluído, o conjunto final de critérios de aceitação deve ser atendido.

Por exemplo, aqui estão os critérios de aceitação para um recurso de mensagens:

  • Os usuários premium devem ser capazes de enviar mensagens a qualquer usuário de sua lista de amigos;
  • Todos os usuários devem ser capazes de bloquear qualquer usuário;
  • Os usuários administradores devem ser capazes de excluir uma mensagem;
  • Todos os usuários devem ter seções “caixa de entrada” e “enviado”.

Especificações (abreviação de especificações) são documentações ou recursos que descrevem como um aplicativo ou site deve se parecer ou se comportar. Por exemplo, um testador pode pedir “especificações de design” para se certificar de que as imagens e o layout correspondem às expectativas.

Os requisitos são essencialmente os mesmos que as “especificações” – documentação que detalha todas as informações sobre um recurso. Isso permite que os desenvolvedores criem e testem os detalhes corretos.

O Desenvolvimento Orientado a Comportamento usa uma linguagem chamada Gherkin para documentar os requisitos. Esses requisitos se tornam a base para testes automatizados. Gherkin usa um formato de “Dado, Então, Quando” que ajuda os membros da equipe menos técnica a entender o recurso.

Por exemplo:

Dado um usuário quiser postar em Facebook
Quando se digita a mensagem e clique em “publicar”
Então seus amigos podem ver o post

Usuários (ou “usuários finais”) são as pessoas que usam seu aplicativo ou site. Por exemplo, seus clientes ou clientes.

Lançamentos

MVP significa Mínimo Produto Viável. Para uma versão de um aplicativo ou site ser “MVP”, ela precisa atender aos critérios que a equipe decidiu ser o mínimo necessário para o lançamento.

Por exemplo, o proprietário de uma empresa pode decidir que uma seção de GPS de um aplicativo é um “recurso MVP”, o que significa que deve ser incluída mesmo para um lançamento suave. Eles também podem decidir que um recurso de vídeo é “Pós-MVP”, o que significa que pode ser adicionado após o lançamento inicial.

Candidato a lançamento (release)  é uma versão que está pronta para ser lançada ao público, assumindo que nenhum bug importante seja encontrado durante o teste.

Por exemplo, digamos que você queira que a próxima versão de seu aplicativo iOS apresente novo conteúdo. Você também deseja incluir uma correção de bug na seção “favoritos”. Os desenvolvedores enviarão um novo build ao QA como um “candidato a lançamento” assim que concluírem a atualização do conteúdo e a correção do bug. Se o QA encontrar algum bug significativo, o build não é mais um candidato a lançamento. Por outro lado, se o QA não encontrar nenhum bug notável, ele está pronto para ser lançado.

Código completo significa que os desenvolvedores concluíram a implementação da correção do bug ou do novo recurso. Isso significa que ele está pronto para o controle de qualidade ou estará em breve, quando o código for implantado. “Código completo” não significa que a nova versão não terá bugs. Na verdade, provavelmente vai! O trabalho do QA é verificar a validade e a qualidade assim que a primeira passagem do desenvolvedor for concluída.

Qualidade

Por exemplo, um site que leva dois minutos inteiros para carregar seria um bug bastante simples. Mas se uma empresa deseja que a cor de fundo seja azul e apareça como verde, isso também seria um bug (mesmo que não pareça ruim para os usuários).

Relatórios de bugs são formas formais de documentar problemas com um aplicativo ou site. Os relatórios de bugs são geralmente arquivados como ‘tickets’ em um sistema de gerenciamento de projeto como o Jira.

Para saber mais sobre relatórios de bugs e ver exemplos, confira nossa postagem sobre Melhores práticas para relatar bugs.

Showstopper é um bug absolutamente crítico. Se o controle de qualidade encontrar qualquer obstáculo em uma nova versão de um build de teste, ele não deve ser lançado ao público. Showstoppers são considerados prioridade para os desenvolvedores corrigirem – especialmente se forem encontrados em uma versão ao vivo.

Por exemplo, se um aplicativo móvel travar consistentemente sempre que os usuários se inscrevem, isso seria considerado um bug bloqueador.

Blocker é essencialmente a mesma coisa que showstopper (veja acima). Um bug bloqueador impede um novo lançamento.

Erros de casos extremos acontecem apenas em raras situações. Isso pode significar apenas em um sistema operacional ou dispositivo antigo, ou ocorrendo apenas 1 em 200 vezes. A priorização para casos extremos geralmente é baixa. Em muitos casos, os casos extremos ficarão permanentemente no backlog.

Por exemplo, digamos que 99,9% de seus usuários estejam no iOS versão 10 e superior. Um caso extremo pode ser um bug de formatação no iOS 9, que afetaria apenas 0,01% dos usuários.

Defeitos são problemas em um aplicativo ou site que não atendem aos critérios de aceitação (veja acima). Por exemplo, talvez um fundo tenha o tom errado de azul. Isso não pareceria necessariamente um “bug” para usuários reais. Mas porque não atende aos requisitos da empresa para o projeto, seria um “defeito”.

Hot Fix é uma correção de bug crítica que precisa ser lançada antes da próxima data de lançamento agendada.

Experiência do usuário se refere à qualidade da experiência e das interações que um usuário tem com um aplicativo ou site. Um aplicativo pode ter uma experiência ruim para o usuário sem ser explicitamente “bugado”.

Por exemplo, digamos que você tenha uma seção de registro em um aplicativo iOS. Talvez cada campo funcione corretamente e os usuários consigam salvar e registrar-se com sucesso. Mas se um usuário tiver que ir para uma nova tela sempre que terminar um campo (em vez de ter vários campos em uma página), isso seria uma experiência ruim para o usuário.

“Experiência do usuário” é um tópico importante no vocabulário de teste de controle de qualidade de qualquer pessoa. Para saber mais, consulte O que é experiência do usuário?

Feature  é um serviço ou funcionalidade em um aplicativo ou site. Por exemplo, poder ‘curtir’ tweets é um recurso do Twitter.

Você chegou ao final do nosso vocabulário de QA – parabéns!

Embora essas definições não sejam exaustivas, agora você conhece os termos mais comuns de um profissional de qualidade.

Como conseguir otimizar os testes do meu time


Testes são uma das partes mais importantes na concepção de um produto digital. Através deles obtemos garantia que determinada funcionalidade cumpre com os requisitos e atende ao cliente de maneira satisfatória.

Para alcançar esse objetivo devemos ter em mente que a entrega dos testes deve ser a mais rápida possível.
Com na pirâmide de testes, os unitários são rápidos, baratos e fáceis de implementar.

Subindo o nível na pirâmide o grau de complexidade aumenta e por consequência sua execução também.

Esse post irá cobrir três partes: a apresentação do problema, o uso do xdebug e configurações extras no ph

Esse post é a resolução de um problema que estava enfrentando no meu time. Nossos testes no backend estavam demorando cerca de 32 minutos para rodar uma suíte com 600 testes e aproximadamente 2000 asserções, confesso que estava me incomodando profundamente.

Segunda-feira iniciei um processo de investigação nos testes e o primeiro passo foi detectar os testes lentos. Mas como iria fazer isso?

Identificando os testes lentos

Pesquisando na web encontrei o artigo do Elton Minetto, onde ele apresenta um pacote chamado phpunit-speedtrap. No post do Elton ele explica passo a passo como configurar o speedtrap.

O speedtrap executa juntamente com os testes e ao final da execução exibe os 10 primeiros testes mais lentos. Com um ponto de partida, continuei a investigar e juntamente com os desenvolvedores descobrimos que alguns testes estavam com um gargalo muito grande.

Por enquanto esses testes ainda não foram refatorados, mas está no nosso radar em corrigí-los para melhorar a performance dos testes.

Logo após isso, questionei os desenvolvedores sobre outros pontos que poderiam estar afetando a execução dos testes, eles me informaram que poderia ser a extensão de debug do PHP, chamada Xdebug que vem habilitada com o framework de testes que utilizamos, o PHPUnit.

Xdebug

Meu próximo passo foi pesquisar referências na web sobre a possível lentidão dos testes relacionado ao Xdebug. Para minha sorte encontrei diversas informações a respeito que mostravam como desabilitar ou até mesmo criar filtros para melhorar a performance dos testes.

Tentei desabilitar a extensão do Xdebug no arquivo php.ini, localmente porém não tive sucesso. Eu sabia que poderia realizar esse tipo de teste, mas iria precisar de um devops para configurar essa opção no servidor.

Mais uma vez o Elton Minetto salvando a pátria. Dessa vez ele aborda em um artigo publicado em 2016, a relação da lentidão dos testes com o Xdebug, a título de comparação ele conta no artigo que possuía uma base de código que sem o Xdebug habilita terminava em 1.08, ao habilitar o Xdebug transformou para 22.26 minutos.

Ou seja, deve um aumento significativo. Infelizmente, a opção que era apresentada no artigo não consegui realizar pois precisaria de instalar um novo pacote no servidor. 😭

Conhecendo o xdebug-filter

Seguindo o lema de ser brasileiro e não desistir nunca, persisti em buscar outras alternativas para resolver meu problema. Encontrei um artigo no próprio site do Xdebug, explicando sobre a relação da cobertura de código com o Xdebug.

Ele é frequentemente usado em combinação com PHP_CodeCoverage como parte padrão do PHPUnit.
O PHPUnit atribuí uma coleção de cobertura de código para o Xdebug que por sua vez, inicia a cobertura do código por meio do método xdebug_start_code_coverage() e interrompe através do xdebug_stop_code_coverage().

Para cada teste ele utiliza o xdebug_get_code_coverage() para recuperar os resultados.

Sua saída principal é detalha quais linhas nos quais os arquivos foram “atingidos” durante a execução do código.

Usando o Xdebug para tais atividades podemos ter um impacto adicional no desempenho, pois ele irá certificar de algumas informações como:

  • analisar quais linhas de código possuem código executável;
  • quais linhas de código podem ser atingidas;
  • também podem instrumentar para descobrir quais ramificações;
  • caminhos em funções e métodos foram seguidos.

Filtros para o resgate

Desde a versão 2.6 do Xdebug é possível criar filtros para a cobertura de código. Com um filtro, podemos incluir através de uma whitelist caminhos e prefixos que podem ser executados e também é possível negar através de uma blacklist.

Um exemplo, seria informar ao PHPUnit para coletar informações somente da sua pasta src onde fica sua base de código e os outros arquivos ele iria desconsiderar, assim, dependências do Composer, arquivos de configuração seria descartados na cobertura do código.

Existem algumas formas de criar esse filtro, eu criei o filtro baseado nesse artigo. Com um filtro configurado corretamente podemos esperar um ganho de velocidade duas vezes maior.

Esses são alguns relatos de pessoas que usaram os filtros:

Antes de aplicar a técnica de filtros do Xdebug os testes estavam executando assim:

Relatório informando que testes demoram 32 minutos para ser executados

### Habilitando o filtro

Para criarmos o filtro basta utilizar dois comandos que irão reduzir drasticamente o tempo de execução dos testes.

O primeiro comando cria o arquivo `xdebug-filter.php` dentro do diretório `build` ele será gerado no diretório raiz da aplicação. Na minha pesquisa não verifiquei se podemos colocar ele em outro diretório.

# dump filter file
# Caso não tenha configurado globalmente o PHPUnit rode assim.
php vendor/bin/phpunit --dump-xdebug-filter build/xdebug-filter.php

# Configurado globalmente
phpunit --dump-xdebug-filter build/xdebug-filter.php

Após executar o comando do `xdebug-filter` sua saída é exatamente essa:

“`php

Tive um ganho aproximadamente de 80% de execução! O processo agora está mais rápido e todo mundo feliz.

Dicas para o phpunit.xml

O arquivo `phpunit.xml` é o setup de configuração para suíte de testes que utilizam PHPUnit.

Vou mostrar alguns paramêtros que podem ser passados que irão melhorar a performance.
Ele vem com uma série de paramêtros pré-configurados.

O primeiro paramêtro é o `cacheResult=”true”`, que permite o PHPUnit execute somente os testes que falharam anteriormente, com uma suíte grande testes isso é um ganho de tempo de resposta absurdo.

Podemos também usar os paramêtros `stopOnFailure=”true”` que irá executar a suíte de testes até no momento que ela encontra alguma falha, bloqueando os restantes testes. O `stopOnError=”true”` executa a suíte até encontrar algum erro bloqueando assim, a execução dos outros testes restantes.

O meu arquivo do phpunit.xml ficou da seguinte forma:

<!-- wp:paragraph -->
<p>```xml<br> <br><br><br>./tests/Unit</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><br>./tests/Feature<br><br><br><br><br>./app<br><br>./app/Modules/User/routes.php<br><br><br>```</p>
<!-- /wp:paragraph -->

Conclusão

Ficou claro para mim que a curiosidade a gana para resolver esse problema foi o fator primordial, com isso tive vários aprendizados. Sempre seja curioso e tenta ao máximo melhorar as condições de trabalho do time.

Garantir a qualidade está também nos pequenos detalhes que podem refletir em grandes conquistas. Todas as referências de artigos que foram pesquisados estão logo abaixo.

Referências

* Xdebug code coverage
* Tips to speed up phpunit tests
* Speed up your phpunit test disable xdebug
* Speed up phpunit code coverage analysis
* Generating code coverage with phpunit and phpdbg
* Melhorando a performance do phpunit
* Speed up phpunit weird trick

Conhecendo o Deepcode

Recentemente navegando pelo Youtube vi um vídeo do Filipe Deschamps, onde ele mostrou uma ferramenta para avaliar questões de segurança no Code Review chamada DeepCode.

DeepCode

O DeepCode é uma ferramenta que auxilia no processo de Code Review, ela nos ajuda a desenvolver um code base com qualidade e segurança.
A diferença e a grande promessa da ferramenta é a utilização de Inteligência Artificial para propor mudanças no code base.

A IA aprende com outros códigos fontes e mapeia as vulnerabilidades criando assim uma base de dados gigantesca com esses achados.

Segundo o site deles foram analisados 100 mil commits e encontrados problemas relacionados a segurança e vulnerabilidades que nenhuma outra ferramenta encontrou.

O algoritmo de Machine Learning deles tem 90% de precisão e o mais interesse dessa ferramenta ela possuí zero configuração.

Deepcode sendo usado em uma avaliação de code review.

Linguagens suportadas

Atualmente eles suportam as linguagens: Javascript, Java, Python e Typescript. Caso a linguagem que você desenvolve não esteja na lista basta fazer um pedido que será analisado pela equipe deles.

Extensão para o Visual Code

Editor de texto Visual Code

Outro recurso bastante interessante é a possibilidade de instalar uma extensão do DeepCode no próprio Visual Code, com ela podemos analisar o código antes mesmo de submeter o mesmo para Code Review.

Para instalar a extensão basta ir no Visual Studio Marketplace ou atráves do próprio Visual Code na aba de extensões e procurar o DeepCode e instalar.

Considerações finais

O DeepCode é uma excelente ferramenta que surgiu para guiar um desenvolvimento seguro e de alta qualidade. O algoritmo de Machine Learning é incrível e detecta diversas issues, testei no meu próprio site e tenho obtido resultados bastante interessantes.

Se posso te dar um conselho, teste essa ferramenta e explore os recursos que ela pode oferecer para garantir um software com um alto índice de valor e entrega.

Em breve escreverei como configurar o DeepCode em um projeto open source para garantir qualidade e segurança.

Até mais.

E um bom ano novo.

21 Qualidade de um bom QA

Post traduzido por Bruno Pulis e escrito originalmente por Try QA.

Atualmente, toda organização está usando tecnologia. De grandes mídias a gigantes têxteis, fundos mútuos a startups,
cada uma tem seus requisitos exclusivos de software e automação. Embora o desenvolvimento e a implementação do software sejam vitais para essas organizações, há uma necessidade crescente de bons testadores de software que adoram testar. Uma pergunta comum é: “Como se tornar um testador de software? Antes de entrar nos detalhes técnicos dos testes de software , é importante garantir que você tenha as características necessárias para um testador.

Os testadores de software são a espinha dorsal de todas as organizações, porque eles são os responsáveis por garantir a qualidade do projeto ou produto. Mas como você identifica o o melhor dos melhores entre os testadores? Aqui estão 21 qualidades e características que são geralmente vistas em grandes testadores:

  1. Mente criativa: esse é um dos traços mais indispensáveis de um ótimo testador de software. Os profissionais de teste precisam pensar muito além do que é esperado do software e dos usuários. Eles devem ser capazes de pensar como os usuários podem fazer coisas que certamente não estão explicitadas nos requisitos de software ou como podem abusar do software.
  2. Habilidades analíticas: essas habilidades são essenciais para a análise de requisitos e para a compreensão do feedback do cliente ao definir a estratégia de teste. As habilidades analíticas também são imprescindíveis para obter informações, a fim de criar soluções de teste inteligentes. Os testadores precisam compreender os dados coletados nos testes e analisá-los quanto ao comportamento específico do produto ou aplicativo.
  3. Curiosidade: A característica é indispensável quando se trata de considerar as consequências. Os testadores curiosos costumam pensar imediatamente , para que possam determinar problemas em áreas onde ninguém mais pode pensar em procurar.
  4. Bom ouvinte: é uma ótima qualidade dos testadores ouvir os outros. Eles devem saber que sempre há espaço para melhorias. Eles também devem prestar atenção se alguém estiver dando alguma idéia ou implicação, pois isso certamente os ajudará a melhorar a qualidade do programa de software em teste. Você pode descobrir alguns cenários que outras pessoas podem perder se não estiverem prestando atenção.
  5. Proativamente apaixonado: A responsabilidade de um ótimo testador não é apenas validar softwares contra os requisitos estabelecidos. Ótimos testadores são apaixonados pelo seu trabalho e fornecem sugestões para melhorar o produto. Às vezes, os testadores apaixonados se tornam gerente de produto ou PO’s
  6. Aprendizado rápido: ótimos testadores devem estar bem familizados com a tecnologia. Eles sempre devem estar abertos para aprender novas ferramentas de automação, acompanhar as últimas tecnologias, usar as mais recentes técnicas durante os testes, aprender com suas experiências e aprender a ter novas idéias.
  7. Conhecimento do domínio: para executar uma sessão de teste bem-sucedida e projetar testes eficazes, bons testadores devem ter um bom conhecimento do domínio da aplicação. Eles devem ter uma visão profunda de como os usuários finais explorarão o programa. Eles também devem gastar tempo para entender a terminologia de seu domínio específico e ajudar a conceber cenários estratégicos de casos de negócios.
  8. Orientado para o cliente: Os grandes testadores devem sempre tentar fazer seus clientes felizes. Eles devem entender que os clientes não possuem as mesmas habilidades técnicas que os testadores. Os clientes podem não ter experiência no domínio ou na tecnologia e podem não ter todos os cenários e casos de uso que possam surgir. Eles devem fazer o melhor uso possível de suas habilidades de teste, tendo em mente a mentalidade de seus clientes enquanto entregam o produto que eles realmente exigem.
  9. Automação de teste e conhecimento técnico: eles devem ter um conhecimento técnico sólido para determinar quais testes devem ser automatizados em qual camada, executar testes constantemente, utilizar a disponibilidade de várias ferramentas de teste, fornecer métricas válidas para a organização e escolher as melhores e mais apropriadas. conjunto de ferramentas para ajudar no esforço de teste.
  10. Capacidade de organizar e priorizar: Um grande testador deve ter a capacidade de identificar e organizar primeiro os testes essenciais e, posteriormente, priorizar a execução com base na relevância do teste. Além disso, ao avaliar os esforços de teste, bons testadores devem considerar o histórico de defeitos.
  11. Capacidade de comunicação: eles devem ter a capacidade de se comunicar com pessoas não técnicas e técnicas. Eles também devem possuir a capacidade de se comunicar efetivamente de forma escrita ou oral e transmitir os detalhes de um problema à equipe de desenvolvimento. Um bom documento passo a passo para reproduzir o defeito ajuda os desenvolvedores a concentrarem seus esforços na correção do problema, e não na comunicação.
  12. Capacidade de relatar: ninguém estará interessado em saber o número de casos de teste executados pelos testadores de software. É por isso que um bom testador deve ser bom em relatar seu status atual no final do dia. Eles devem fornecer relatórios de erros detalhados e eficazes e também anexar capturas de tela, se possível, juntamente com o relatório.
  13. Atenção aos detalhes: Os grandes testadores estão atentos aos detalhes. Essa qualidade é útil ao validar lógica de negócios complexa e garantir que todos os cenários sejam cobertos. Também ajuda a evitar multas ou custos mais altos de correção de defeitos encontrados no final do ciclo ou após o lançamento da produção.
  14. Orientado para o negócio: Um ótimo testador de software deve ser capaz de entender o software do ponto de vista comercial, apreciar os requisitos dos clientes, ter a capacidade de entender as pessoas do ponto de vista não técnico. Ele também deve ser capaz de entender como os problemas de negócios podem ser convertidos em soluções técnicas.
  15. Capacidade intelectual: eles devem ser inteligentes o suficiente para usar sua capacidade lógica, a fim de operar em um ambiente de teste de alto nível. Eles devem ter a capacidade de solucionar problemas da origem de um problema e resolvê-lo da melhor maneira possível.
  16. Bom observador: Manter o controle dos itens secundários e dos principais projetos discutidos é extremamente importante para um grande testador. Em um ambiente dinâmico como uma startup, as coisas mudam rapidamente. É importante poder acessar o impacto da mudança e ficar por dentro das mudanças. Além disso, acompanhar o andamento do teste e fazer as alterações necessárias, se necessário, também é muito crucial.
  17. Gerir seu tempo bem: a maioria das equipes fica restrita pela quantidade de tempo disponível para desenvolvimento e teste. Os testadores precisam entender sua prioridade e gerenciar bem seu tempo. Eles precisam saber o que deve ser testado e o que deve receber menos prioridade. Quais tarefas devem ser executadas primeiro e quais podem ser realizadas no final, o que deve ser automatizado e o que deve ser testado manualmente. Quão importante é a documentação comparada com a execução real do caso de teste, no tempo determinado? Eles devem ser capazes de responder a essas e outras perguntas e ajudar seus gerentes a tomar a decisão certa.
  18. Perseverança: Grandes testadores nunca desistem. Eles são pacientes o suficiente para encontrar o maior número possível de bugs. Eles exploram o software, constantemente tentam fazer novas melhorias e aceitam todos os desafios e complexidades dos testes de maneira positiva e paciente.
  19. Capacidade de identificar e gerenciar riscos: Eles devem ser capazes de entender o processo adequado de gerenciamento de riscos – identificação de riscos, análise de riscos e redução de riscos. O teste de software deve ser baseado na incorporação de processos de teste orientados a riscos.
  20. Orientado à qualidade: ótimos profissionais de software não comprometem a qualidade em nenhum estágio de teste. Os resultados orientados à qualidade sempre levam a defeitos no software livre e garantem uma qualidade de primeira.
  21. Capacidade de trabalhar em equipe: Os testadores de software devem ser capazes de trabalhar bem dentro e fora da equipe. A troca de idéias, conhecimentos, experiências e pensamentos pode aumentar a qualidade e a eficiência da solução, para que os grandes testadores sempre estejam ansiosos para coordenar bem com os membros de sua equipe e outras equipes.

© 2021 Bruno Pulis

Theme by Anders NorenUp ↑