Bruno Pulis

Page 3 of 8

Vocabulário de QA

agosto 18, 2020 / / 0 Comments

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.

Um jovem com uma camisa cinza escura de costas no topo da camisa a palavra Github em destaque

Como criar um Github Profile

julho 26, 2020 / / 0 Comments

Introdução ao artigo

O Github abre em uma nova aba, a rede social mais adorada por pessoas desenvolvedoras vem se reinventando, desde que, foi adquirida pela Microsoft abre em uma nova aba.

Lembro quando vi o anúncio da compra do Github pela Microsoft, fiquei pensando em como seria essa nova etapa.

Uma dessas boas impressões foi o lançamento da funcionalidade de destaque dos perfis, nesse artigo eu explico como configurar e dou algumas dicas de organização e como deixar ele mais profissional.

Criando seu Github Profile

Para configurar seu Github Profile é bem simples, crie um repositório com o nome do seu usuário no Github, e adicione o arquivo README.md, nele conterá as informações do seu perfil.

O meu perfil ficou assim:

Github Profil de Bruno Pulis

Usei uma estrutura baseada em tópicos, pois é mais fácil de organizar e deixar claro cada sessão. O meu Github Profile, está divido da seguinte forma:

  • Apresentação
  • Status do Github
  • Projetos pessoais e open source
  • Últimos artigos do blog

Apresentação

Creio que a apresentação é a sessão mais importante e esse é o motivo dela estar em primeiro lugar. Concentre-se em escrever informações relevantes e importantes sobre você.

É interessante colocar alguns fatos como:

  • projetos que trabalhou;
  • projetos que você mantém;
  • hobbies;
  • programas de ação social e voluntariado.

Assim, sua apresentação fica mais completa e pode chamar atenção de recrutadores e desenvolvedores. Quem sabe sua nova oportunidade no mercado não pode partir dai?

Status do Github

Conversando um dia com o Phiter Fernandes abre em uma nova aba, ele me mostrou o Github Readme Stats abre em uma nova aba uma ferramenta para buscar as suas contribuições feitas no Github.

Ele consulta as informações através da API do Github, e gera um gráfico feito em SVG. O resultado é parecido com isso:

Github Status de Bruno Pulis

Essa é uma funcionalidade é interessante, pois exibe suas contribuições no Github, isso demonstra seu interesse e incentivo na comunidade de desenvolvimento.

Configurando

Para configurar o seu Github Status, copie o código abaixo, e cole no seu conteúdo markdown.

Bruno Pulis github stats

Um detalhe importante é trocar para o seu usuário ?username= pelo o nome do seu usuário do Github.

Projetos pessoais e open source

Liste seus projetos pessoais e open source, isso gera notoriedade e destaque aos projetos. Uma dica para quem está começando coloque seus projetos nessa sessão.

Isso irá servir como seu portfólio, no meu perfil existem alguns projetos que mantenho durante muito tempo.

Contatos e redes sociais

É interessante também manter uma sessão com os seus contatos e redes sociais. Mantenha essa lista atualizada.

Particularmente eu coloquei somente as que atuo com mais frequência, não há necessidade de colocar todas, coloque somente aquelas que você é capaz de responder.

Listando posts do blog

Essa é uma dica bônus, existe a possibilidade de criar uma integração graças ao Github Actions. Ela se baseia em consultar o RSS do seu site e listar os últimos três posts.

Em breve vou escrever como fazer essa integração que é simples e bem legal.

Conclusão

O Github Profile, permite várias possibilidades para deixar seu perfil mais profissional e atraente. Não há limites, basta ser autêntico e criativo.

Na minha pesquisa para esse artigo encontrei um lista com diversos Github Profiles criados. Deixo aqui alguns perfis que achei bem legal.

Review: Livro Acessibilidade Web

julho 19, 2020 / / 0 Comments

Introdução

Esse artigo é uma review com impressões pessoais que tive ao finalizar a leitura do mais novo livro do Reinaldo Ferraz. Finalizei no final de semana e decidi escrever um pouco sobre a minha experiência de leitura.

Algo que merece nota é que o mercado editorial brasileiro, possuí poucas publicações dedicadas ao tema de acessibilidade web em comparação com o exterior, fica como incentivo mais publicações impressas ou digitais aparecerem em solo brasileiro. Reinaldo Ferraz possuí cinco livros publicados e Talita Pagani (abre em uma nova janela) possuí uma publicação voltada ao tema, vale a pena conferir.

Lançamento do livro

No dia 21 de março de 2020, Reinaldo Ferraz (abre em uma nova janela) lançou pela Casa do Código (abre em uma nova janela), seu mais novo livro: Acessibilidade na Web: Boas práticas para construir sites e aplicações acessíveis (abre em uma nova janela).

Um livro completo para quem quer aventurar com acessibilidade web, não é voltado somente para pessoas desenvolvedoras, mas também, útil para consultores, gestores, analista de negócio, produtores de conteúdo e analistas de marketing.

Organização do livro

A obra foi pensada em ordem cronológica e cumpre com o seu propósito, pois inicia a discussão do assunto sobre o ponto mais básico e aprofunda-se no tema ao decorrer dos capítulos, possuindo quinze capítulos bem divididos e sucintos, com linguagem acessível e clara. O tipo de livro que não tem enrolação, vai direto ao ponto.

Eu já tinha adquirido a versão digital na pré-venda por ser mais prático. Recentemente, após uma pausa por causa do Covid-19, voltaram com suas atividades para exemplares impressos, meu conselho é: comprem a versão impressa pois é uma referência e livros assim são ótimos para ter sempre por perto, além de auxiliar no estudo pessoal e profissional.

Os temas são específicos acompanhados explicações teóricas e práticas, li e reli a especificação de acessibilidade da W3C alguns exemplos são muitos genéricos, a compreensão muita das vezes fica confusa mas Reinaldo consegue alinhar as duas coisas de forma muito clara.

Teoria e prática

Após cada exemplo apresentando das teorias e práticas, é mostrado com clareza quem será beneficiado com essas recomendações.

Escrita

A escrita é bem tranquila, sem jargões muito técnicos e quando aparecem, Reinaldo tem todo o cuidado de exemplificar de maneira simples e objetiva. As imagens e gráficos são descritos com legendas dando contexto e compreensão. É uma leitura fluída e sem dificuldade de compreensão.

Curiosidade

No primeiro capítulo é uma verdadeira aula da web. Em um determinado ponto é contada a história da especificação da tag <img>, desde sua proposta até a inclusão do tão famoso atributo alt.

É bastante interessante sobre como a especificação de um elemento HTML, foi evoluindo e acompanhá-la, de certa forma, nos inclui nessa evolução.

Além disso, toda fundamentação teórica, possuí referências, no último capítulo é um guia das referências usadas para produzir a obra. Vale a pena verificar.

Mergulhando na acessibilidade

Após essa aula introdutória, Reinaldo nos convida a mergulhar em aspectos pouco falados no meio da comunidade web, como por exemplo, a relação das pessoas com deficiência e as tecnologias assistivas. Nesse ponto exemplifica muito bem e ainda traz recursos complementares como diversos plugins para serem usados na simulaçáo de alguma deficiência.

Explica com maestria os states, properties e roles da WAI-ARIA, em um guia bastante intuitivo e de simples compreensão.

Continuemos com o nosso passeio, além da apresentação das diretrizes de acessibilidade web a famosa WCAG é apresentado os níveis de conformidade e os princípios.

Eliminando barreiras

Reinaldo dedica cinco capítulos do livro para exemplificar a eliminação de barreiras de acesso:

  • na estrutura;
  • na navegação e interatividade;
  • no design;
  • na multimídia e conteúdo não textual.

Gerenciadores de conteúdo (CMS)

Reinaldo faz um comparativo com diversos gerenciadores de conteúdos, os famosos CMS, apontando suas vantagens e desvantagens. Depois, dicas essenciais de como incluir acessibilidade no processo de desenvolvimento de software.

Esse capítulo é bastante importante para gerentes de projetos e analista de negócios para compreenderem a importância da inclusão de todas as pessoas.

Inicia o capítulo com uma frase muito marcante:

Todo time deve estar envolvido com a acessibilidade. Deixar a acessibilidade a cargo de um único profissional pode criar gargalos e dificultar a comunicação entre os times. Se todos (designers, programadores, gestores e produtores de conteúdo) estiverem com a acessibilidade em mente durante suas atividades, a chance de o projeto contemplar mais recursos acessíveis é maior. [FERRAZ, 2020].

Nos capítulos seguintes é realizado uma pesquisa muito completa sobre algumas ferramentas de avaliação de acessibilidade automática, com seus prós e contras digno de montar um infográfico ou artigos sobre o tema.

Também há um capítulo exemplificando a Lei Brasileira de Inclusão (abre em uma nova janela), com os aspectos jurídicos que envolvem a acessibilidade no contexto digital e como se manter dentro da legislação vigente no nosso país.

E para fechar com chave de ouro, o último capítulo é uma aula de consciência ao acesso de como a Web vem tomando um caminho obscuro nas mãos de grandes corporações.

Tim Berners-Lee (abre em uma nova janela), vem alertando isso a um tempo em diversas entrevistas que concedeu sobre o tema. Sua argumentação é que a Web se perdeu do propósito original e que devemos torná-la novamente de todos e para todos.

Reinaldo para finalizar como um bom mestre jedi pontua uma frase que me marcou muito

Acessibilidade não é filantropia. É respeito pelas pessoas e por um mundo efetivamente justo em oportunidades para todos. [FERRAZ, 2020]

Outra frase bem marcante é:

Se o seu site não está pronto para receber todas as pessoas, o seu site é deficiente. [FERRAZ, 2020]

Conclusão

O livro é uma verdadeira aula de quem domina com maestria o assunto. Reinaldo consegue, destrinchar assuntos complexos em exemplos práticos e simples.

Se você tem curiosidade sobre o tema é ativista de acessibilidade assim como eu, essa deve ser sua bíblia, livro de cabeceira.

Se gestor que quer colocar seus produtos digitais em conformidade com as diretrizes de acessibilidade esse é um material que de fato irá ajudar bastante nessa caminhada.

Concluo essa review, incentivando você, leitor que compre e ajude a divulgar produções de livros nacionais, precisamos fomentar mais conteúdo relacionado sobre acessibilidade.

Patrocine publicações nacionais existe muita gente boa produzindo conteúdo em terras tupiniquis.

Seja um incentivador e não um detrator, compre e-books, livros, ajude a comunidade web a crescer e principalmente ajude a web ser de TUDO para TODOS.

Referências

  • Anúncio da publicação do livro de acessibilidade, 2020. Disponível em: Twitter Acesso em: 19 de julho de 2020;
  • Acessibilidade na Web: Boas práticas para construir sites e aplicações acessíveis, 2020. Disponível em: Livro disponível na Casa do Código Acesso em: 19 de julho de 2020;
  • Casa do Código, 2020. Disponível em : Casa do código Acesso em: 19 de julho de 2020;
  • Sobre Reinaldo Ferraz, 2020. Disponível em: Sobre Reinaldo Ferraz Acesso em: 19 de julho de 2020;
  • Como citar ebook, kindle e epub, 2020. Disponível em: Como citar ebook, kindle e epub Acesso em: 19 de julho de 2020;
  • Biografia de Tim Berners-Lee, 2020. Disponível em: Tim Berners-Lee Acesso em: 19 de julho de 2020;
  • Lei Brasileira de Inclusão, 2020. Disponível em: Lei Brasileira de inclusão Acesso em: 19 de julho de 2020.
Terminal de um computador com vários comando digitados na tela

Criando alias para ganhar produtividade

maio 11, 2020 / / 0 Comments

Introducão

No dia a dia de um desenvolvedor é muito comum repetirmos diversos comandos, fazendo assim, o trabalho um pouco repetitivo. Pensando nisso os alias foram criados como uma forma de encurtar alguns comandos. Nesse post eu te mostro como criar dois alias de forma rápida e prática.

Em nosso cotidiano, digitamos uma infinidade de comandos, seja no código fonte ou no terminal.

A grande maioria desses comandos, são tarefas repetitivas que podem ser otimizados com a criação de alguns alias, que assim, tornam nosso dia mais produtivo.

Exemplo prático

Como analista de teste, utilizo o git como versionador de códigos juntamente com o meu time. Dentre algumas tarefas que faço todos os dias e atualizar minha base de código e enviar algumas alterações relacionados aos testes que possuímos.

Além disso, abro alguns pull requests para a melhoria contínua da aplicação.

Para atualizar nosso código usamos o comando git push que envia as modificações para o servidor. Todos os dias faço o uso dele, como descrito logo abaixo:

git push origin master

Todos os dias também, tenho que usar o docker para subir a aplicação e preciso digitar dois comandos que sempre esqueço. 😂

Os dois comandos estão descrito abaixo

  # Inicializa o docker
  docker-compose up -d nginx mysql redis workspace

  # Executa o container
  docker-compose exec workspace bash

Pensando nisso decidi criar um alias para otimizar esse comando e encurtar ele. Pessoalmente eu detesto ter que ficar digitando uma infinidade de comandos no terminal, sou fã de coisas simples, como iniciar um banco de dados com apenas uma única linha.

Com os alias isso é possível, desde que, passamos os paramêtros corretos para o alias. A estrutura do alias consiste em:

alias comando_encurtado='comando real'

# exemplo de um comando alias
alias ..="cd .."

Ao digitar no terminal .. ele irá entender que o .. é um atalho para o cd ... Isso é fantástico, eu posso customizar comandos do sistema operacional e também de aplicações, como por exemplo, iniciar o Visual Code com uma única linha de comando.

Para utilizarmos precisamos configurar os alias em nosso terminal. O arquivo de configuração padrão no Ubuntu é o .bash_profile, no meu caso estou usando o zsh que é uma outra versão do bash. O ZSH possuí o arquivo de configuração .zshrc.

Caso esses arquivos não existem eles devem ser criados com o comando:

# Bash padrão
touch .bashrc

# ZSH
touch .zshrc

Importante, a primeira coisa que iremos fazer e verificar se existe o arquivo de configuração. Caso não exista, devo criar o arquivo conforme acima.

# vai para o diretório raiz
cd ~/

# listo os diretórios
ls -lha

Se a minha resposta for parecida com essa, então meu arquivo de configuração está criado:

-rw-r--r--  1 pulis 4,5K mai  6 11:49  .zshrc

Com o arquivo criado, iremos abri-lo digitando no terminal: gedit .zshrc e vou incluir os alias que quero para o docker.

alias init='docker-compose up -d nginx mysql redis workspace'
alias run='docker-compose exec workspace bash'

# reiniciando o terminal para aplicar as modificações
source .zshrc

Após o terminal reiniciado ele reconhecerá os comandos. Assim digitaria:

# inicializando
init

# executando
run

Conclusão

Os comandos alias são poderosos e podem te ajudar bastante no dia a dia. No meu github eu tenho uma coleção de alias.

Como conseguir otimizar os testes do meu time

maio 6, 2020 / / 0 Comments

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

Repensando sobre o HTML

abril 30, 2020 / / 0 Comments

Introdução

O HTML é o bloco de construção mais básico da web. É o responsável por definir duas características importantíssimas: significado e a estrutura do conteúdo da web.

Além dessas características primordiais, também contribui para um melhor posicionamento de nossas páginas na web, ocasionando assim, maior visibilidade e lucro.

Outro fator não menos importante, é a promoção do conteúdo para todas as pessoas, visto que, uma vez escrito corretamente consegue atingir todos os públicos, garantindo assim a interoperabilidade do conteúdo, sem se preocupar com plataformas ou devices.

Um breve contexto

O ano é 2020, frameworks de frontend, especialmente de javascript nascem a cada seis segundos com a promessa quase messiânica de resolver nossos problemas.

Basta rodar um comando e voilá, seu projeto está pronto só esperando fazer o que é necessário: codar.

O desenvolvedor satisfeito com a agilidade fica contente e inicia seu trabalho feliz com tudo isso, começa a criar componentes “reutilizáveis”, utiliza JSX, Typescript, Webpack, Sass, Styled Components e mais de milhares de dependências do nosso amado NPM.

Passa-se alguns dias e seu projeto vai para produção, mas será que a escrita da forma mais básica cumpre os princípios básicos de significado e conteúdo?

Bom, essa analogia demonstra a realidade de muitos de nós, pensamos nas melhores arquiteturas, tecnologias e abordagens de DevOps e o pobre e velho HTML, coitado, é deixado de lado.

Frameworks são excelentes ferramentas, mas não são uma bala de prata, devemos ter cuidados e prudência, afinal você não precisa de um canhão para matar uma formiga.

Uma tendência

Atualmente a maioria dos projetos web tem alguma lib ou framework de javascript por trás, por um lado isso é excelente, a web evoluiu e fazer frontend não é a mesma coisa do que 10 anos atrás.

Lembro dos dias áureos de Dreamwever, CSS puro e VanillaJS. Era muito difícil fazer certas coisas, hoje nossa realidade é bem mais simples, temos excelentes libs, como o React e VueJS para construir componentes reutilizáveis.

Essas libs por sua vez possuem frameworks para deixar o desenvolvimento, digamos “vitaminado”, e, ser mais rápida a produção de nossas apps.

O problema é que a maioria desses frameworks possuem erros grotescos de html, ao ponto de renderizar um componente de select, por exemplo, com várias divs aninhadas.

Um exemplo do framework Vuetify com o componente select:

<v-select :items="items" label="Standard"></v-select>

Aparentemente é um componente simples e elegante, mas qual é sua saída no código HTML? Sua saída é parecida com isso:

<div class="v-input theme--light v-text-field v-text-field--is-booted v-select"></div>
  <div class="v-input__control">
    <div role="button" aria-haspopup="listbox" aria-expanded="false" aria-owns="list-1359" class="v-input__slot">
      <div class="v-select__slot">
          <label for="input-1359" class="v-label theme--light" style="left: 0px; right: auto; position: absolute;">Standard</label>
          <div class="v-select__selections">
              <input id="input-1359" readonly="readonly" type="text" aria-readonly="false" autocomplete="off">
          </div>
          <div class="v-input__append-inner">
              <div class="v-input__icon v-input__icon--append">
                <i aria-hidden="true" class="v-icon notranslate mdi mdi-menu-down theme--light"></i>
              </div>
          </div>
          <input type="hidden">
      </div>
        <div class="v-menu"></div>
    </div>
    <div class="v-text-field__details">
        <div class="v-messages theme--light">
            <div class="v-messages__wrapper"></div>
        </div>
    </div>
  </div>
</div>

Já no bom e velho HTML, o componente de select se parece com isso.

<select>
  <option>Selecione uma opção</option>
  <option>1</option>
  <option>2</option>
  <option>3</option>
</select>

Simples, não?

Exemplos assim, estão recheados aos montes pela web. A WebAIM uma empresa que presta treinamentos e consultorias sobre acessibilidade web, realizou no ano de 2019 uma pesquisa onde mapeou 1 milhão de páginas e detectou problemas relacionados a acessibilidade. E pasmem, a maioria dos problemas não era coisas hiper complexas, mas extremamente simples.

Abaixo uma tabela demonstrando os problemas mais recorrentes nas páginas.

Falhas mais comuns de acessibilidade na web. Fonte: [The WebAIM Million](https://webaim.org/projects/million/#intro)
Tipo de falha da WCAG % de home pages em Fevereiro de 2020 % de home pages em Fevereiro de 2019
Baixo contraste 86.3% 85.3%
Imagens sem texto alternativo 66.0% 68.0%
Links vazios 59.9% 58.1%
Faltando label em formulários 53.8% 52.8%
Botões vazios 28.7% 25.0%
Linguagem do documento ausente 28.0% 33.1%

Fica nítido uma coisa, temos um problema gritante com a semântica e estrutura

HTML semântico

Quando falamos sobre semântica, estamos falando sobre o conteúdo ter significado. Assim como um livro ou TCC respeita uma estrutura lógica de hierarquia de informação o HTML também possuí.

Nele podemos marcar corretamente: datas, cabeçalhos, sessões, citações longas e curtas, paragráfos, ênfase e diversos outros recursos.

Um dos grandes problemas na web não é a falta de acessibilidade, mas escrita incorreta de HTML, CSS e Javascript.

O nosso problema é que não conseguimos fazer o básico bem feito e logo queremos usar frameworks para resolver nossos problemas…

Muitos desenvolvedores não conseguem escrever um HTML semântico, mas sabem criar um componente super complexo que um componente nativo do HTML resolveria.

Eu sempre tenho um mantra comigo: Sempre utilize componentes nativos. SEMPRE!, mas existem casos que não é possível, nossa função é informar que não utilizando um componente nativo podemos perder em semântica, acessibilidade, posicionamento e até mesmo grana.

Essa semana a Talita Pagani iniciou uma conversa no twitter sobre o mesmo tema. Você pode ver um trecho logo abaixo.

Esse assunto no Twitter me fez lembrar de outra conversa com o Reinaldo Ferraz em um BrazilJS. Estávamos falando sobre o estado atual da acessibilidade web no Brasil e os avanços que temos feito. Ele disse uma frase que me marcou muito:

> Estamos em um momento que as pessoas precisam reaprender como escrever HTML. Só assim, conseguiremos tornar a web mais inclusiva.

Conclusão

A minha dica é desacelerar e voltar a base, não adianta nada saber os melhores frameworks e técnicas de desenvolvimento frontend, sendo que, o essencial não está bem fundado.

Isso me lembra a Parábola dos dois fundamentos, segue um trecho:

Todo aquele, pois, que escuta estas minhas palavras, e as pratica, assemelhá-lo-ei ao homem prudente, que edificou a sua casa sobre a rocha;
E desceu a chuva, e correram rios, e assopraram ventos, e combateram aquela casa, e não caiu, porque estava edificada sobre a rocha.
E aquele que ouve estas minhas palavras, e não as cumpre, compará-lo-ei ao homem insensato, que edificou a sua casa sobre a areia;
E desceu a chuva, e correram rios, e assopraram ventos, e combateram aquela casa, e caiu, e foi grande a sua queda.
(Mateus 7:24-27)

Uma fundação com estrutura sólida nos dá segurança e confiança, mas uma fundação sem segurança e instável é passível de diversas falhas.

A fundação HTML, CSS, Javascript devem ser sólidas, frameworks vem e vão.
Que tal refletirmos e escrevermos de forma semântica?

Conteúdos relevantes

Separei alguns links para aprender a escrever HTML semântico, espero que os ajude.

* Recomendações de acessibilidade
* HTML5 and CSS fundamentals
* HTML5 Coding Essentials and best pratices
* Referência da MDN sobre HTML

Referências:

* Referência da MDN sobre HTML
* Pesquisa WebAIM
* Vuetify Select

« Older posts Newer posts »

© 2021 Bruno Pulis

Theme by Anders Noren — Up ↑