- Links e botões sem descrição
- Mau uso de títulos
- Formulários da web inacessíveis
- Reprodução automática de áudio e vídeo
Referência
5 most annoying website features I face as a blind person every single day
Page 2 of 8
O que é?
Uma ferramenta que avalia as combinações de cores usando as recomendações de contraste da WCAG 2.0
Como usar?
- insira a cor usada no texto, seu tamanho e peso da fonte;
- insira a cor de fundo;
- selecione o nível de conformidade, recomendo manter o AA.
Resultados
A ferramenta valida o contraste de acordo com a recomendação da WCAG, caso não esteja em conformidade, exibe duas opções para correção:
- corrigir a cor do texto;
- corrigir a de fundo.
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
Semana passada, navegando pelo Twitter vi o anúncio do Elton Minetto sobre seu novo e-book Dicas de carreira para devs. Conhecendo a qualidade do seu trabalho, decidi fazer o download e escrever minhas impressões sobre a obra.
🔥 Você pode baixar o e-book gratuitamente através do Leanpub.
Alguns meses atrás, um post dele me ajudou a resolver um problema complexo. Precisava otimizar o tempo de execução de alguns testes do meu time.
Escrevi como resolvi esse problema, você pode conferir o artigo: Como consegui otimizar os testes do meu time.
Estrutura
O e-book é subdividido em 21 tópicos. Possui um total de 34 páginas, levei cerca de 15 minutos para finalizar a leitura.
A estrutura e lógica utilizada agrada à leitura e se a intenção foi ser uma leitura rápida que prende o leitor, Elton conseguiu com maestria esse feito.
Conteúdo
Possui uma linguagem de fácil acesso, sem exageros técnicos, utiliza algumas sacadas para fazer analogias que encaixam perfeitamente ao contexto apresentado.
Muito legal como ele relaciona as bandas com conceitos para a carreira de desenvolvedor. As analogias são fantásticas com o tema proposto.
Em diversos pontos, Elton salienta que o e-book eé uma coletânea de conselhos pessoais. Esses conselhos são práticos e simples, você pode colocar em prática agora mesmo.
Pontos de atenção
A obra como um todo é excelente, porém, gostei particularmente dos tópicos:
- Carrreira não é emprego;
- Programador Dave Grohl e não Axl Rose.
O tópico Carrreira não é emprego, me fez refletir bastante sobre como tenho pensando na minha carreira e causou impactos positivos e uma clareza que estava precisando.
Já o tópico Programador Dave Grohl e não Axl Rose, traz uma tônica recorrente na comunidade, os programadores rockstars e aqueles de fato que contríbuem para o crescimento da mesma.
O autor também comenta como ele faz para aprender e fixar um novo conteúdo. Segundo Elton, a melhor forma para isso é compartilhar conhecimento, seja por texto, vídeo ou outras meios de comunicação a intenção é compartilhar.
Cita também sua estratégia de escrever posts para o blog que mantém desde 2014. Caso ele demore mais 30 minutos para aprender algo ou resolver um problema ele escreve um post de modo que consiga fixar os aprendizados e disponibilizar esse conhecimento para a comunidade, assim, pessoas com o mesmo problema rapidamente conseguiram resolver seus problemas.
Isso é interessante porque além de acompanharmos nossa evolução podemos contribuir com crescimento de outras pessoas.
Conclusão
Não vejo pontos negativos, o conteúdo é extremamente rico e fácil. A leitura é envolvente e o e-book são serve somente para desenvolvedores, analista de qualidade e outras áreas relacionadas a programação deveria lê-lo, se pudesse eu deixaria um conselho para você:
🔥 Está esperando para ler
Bom chegamos a essa review, me conte sua experiência com a leitura do e-book, o que você mais gostou?
A acessibilidade digital é o assunto do momento, a pandemia evidenciou bastante, nesse post eu trato sobre alguns erros que são bem comuns no mundo digital.
Texto com baixo contraste
Diariamente sofro na pele com isso, para quem não me acompanha ou está chegando por agora no blog, eu possuo ceratocone,uma doença na córnea que aumenta o grau exponencialmente. Algumas combinações de cores e informações ficam bastante confusas para mim.
Para amenizar esse problema eu adotei algumas práticas:
- dar zoom em textos com baixo contraste;
- mudo as cores dos textos para uma com maior contraste via Inspetor de elementos do navegador;
- usar tema escuro.
Guia sobre contraste
Para aplicarmos as correções de maneira efetiva, devemos consultar as recomendações da WCAG. Abaixo as regras que se aplicam ao contraste:
- 1.4.3 – Contraste (mínimo) [AA] – WCAG 2.0 (em inglês);
- 1.4.6 – Contraste melhorado [AAA] – WCAG 2.0 (em inglês);
- 1.4.11 – Contraste Não-Textual [AA] – WCAG 2.1 (em inglês);
- 2.3.1 – Três flashes ou abaixo do limite [A] – WCAG 2.0.
Ferramentas para verificação
Após compreendermos as regras relacionadas ao constraste, devemos elencar ferramentas para corrigir o problema.
Atualmente estou usando o Accessible Colors gosto dele pela simplicidade, provavelmente escreverei sobre ele.
Para exemplificar, imagine que você foi contratado para validar o contraste do menu de um site. Você iria inspecionar a cor usada no background do menu e as cores decada item de menu, usando o Acessible Colors, o resultado será semelhante a:
Resultado de uma avalição das cores: #ccc para textos do tamanho de fonte 16px e background do site #fff
Tendo o resultado em mãos, você pode reportar as inconsistências. Essa correções são feitas alterando as CSS, e com poucas linhas de código o problema é sanado.
🔥 Você pode encontrar uma lista delas no Awesome A11y.
Imagens sem texto alternativo
Segundo uma pesquisa do Web AIM, em uma amostragem de 1 milhão de páginas iniciais dos sites mais populares do mundo. Foram encontradas 38,426,701 imagens, ou 38.4% por página inicial em média.
Cerca de 31.3% de todas as páginas iniciais (12 por página em média) não possuiam texto alternativo (sem contar o alt="") que é uma forma válida. Mais da metade das imagens sem texto alternativo.
Existe uma grande discussão ao redor do atributo alt, Reinaldo Ferraz escreveu um artigo, onde demonstra os benefícios do atributo. Além de contribuir para a acessibilidade ele também ajuda no SEO das páginas.
De forma prática a correção desse erro é uma das mais banais, basta preencher o atributo alt com a descrição correta da imagem.
Ex:
<img src="/imagens/duck.png" alt="Pato de borracha amarelo olhando fixamente" />🔥 Consulte o artigo: Texto alternativo: o guia definitivo
Links vazios
Links vazios, são um dos maiores erros que já encontrei em avaliações de acessibilidade. Frequentemente me deparo com ele, geralmente ocorrem quando precisamos incluir um ícone, em uma página.
Para entendermos isso, vamos consultar a definição do propósito do elemento <a>:
O elemento
<a>em HTML (ou elemento âncora), com o atributo href cria-se um hiperligação nas páginas web, arquivos, endereços de emails, ligações na mesma página ou endereços na URL. O conteúdo dentro de cada<a>precisará indicar o destino do link.
Além de descumprir com a especificação do HTML, descumpre também a recomendação 2.4.4 – Finalidade do link (em contexto) [A] – WCAG 2.0 (em inglês).
Exemplo prático
Existem duas soluções que podemos aplicar, quando preciso usar um ícone e somente ele ser exibido, posso usar essa abordagem:
<a href="https://twitter.com/obrunopulis">
<i class="fa fa-twitter"></i>
</a>Qualquer validador de acessibilidade que se deparar com esse elemento, encontrará uma inconsistência, pois ele informa um elemento <a> sem um conteúdo textual, descumprindo com o propósito de uso dele. Sem nenhum texto isso fica confuso para usuários de leitores de tela.
Nesse exemplo especifíco, um leitor de tela poderia ler o link da da URL ou o conteúdo do pseudo elemento :before que seria f002. f002 não quer dizer pesquisa ou nenhuma outra informação. não é mesmo?
Uma abordagem seria adicionar o texto visualmente ao lado dos ícones, pois eles nem sempre são tão claros para os usuários quanto pensamos. No caso dos ícones sociais, acho que é bastante claro o que são e o padrão é usado com bastante frequência. Nesse caso, você pode adicionar conteúdo visualmente oculto.
Corrigindo
Queremos adicionar texto para ser lido por um leitor de tela e ter certeza de que o conteúdo adicionado via css não seja lido.
<a href="https://twitter.com/obrunopulis">
<span class="fa fa-twitter" aria-hidden="true"></span>
<span class="sr-only">Perfil de Bruno Pulis no twitter</span>
</a>Com essa abordagem os validadores de acessibilidade não encontrarão nenhum problema, pois o link contém um texto oculto que informa o seu destino.
Observação importante
Nem sempre ter um conteúdo oculto é uma boa solução. É preciso haver uma compreensão visual de qual é o conteúdo e os links para usuários videntes, bem como para usuários de leitores de tela.
🔥 Aprenda a usar o Font Awesome do jeito certo
Labels de formulários ausentes
55% dos 4,2 milhões de formulário identificados na pesquisa do WebAIM, não estavam usando o elemento <label> ou aria-label ou aria-labelledby.
Páginas com pelo menos um controle de formulário sem rótulo tiveram em média mais 43 erros detectáveis do que páginas sem nenhum erro de rótulo.
É preocupante a má da escrita do HTML na web, a grande maioria dos sites possíveis erros básicos de marcação.
Formulários são um dos componentes mais importantes para web, podemos dizer que depois do elemento <a> esse componente é o mais importante. Com essas violações também
ferem a recomendação 3.3.2 – Rótulos e instruções [A] – WCAG 2.0 – (em inglês).
Uma das coisas que percebo muito com formulários é o uso inadequado do placeholder, a maioria dos designers e desenvolvedores utilizam o atributo placeholder com a função de um <label>.
Exemplo incorreto
<form>
<input type="email" placeholder="insira o seu melhor e-mail" />
</form>O atributo placeholder é uma string que fornece uma breve dica ao usuário quanto ao tipo de informação esperado no campo. Deve ser uma palavra ou frase curta que demonstre o tipo de dados esperado, ao invés de uma mensagem explicativa.
Nota: O atributo placeholder não é semanticamente útil como outras maneiras de explicar seu formulário e pode causar problemas técnicos inesperados com seu conteúdo.
Vale lembrar, para rotular um formulário o elemento correto para ser usado é o
label
Exemplo correto
<form>
<label for="email">E-mail</label>
<input type="email" id="email" placeholder="insira o seu melhor e-mail" />
</form>Botões vazios
Semelhantemente com os links vazios, os botões vazios querem dizer que o elemento não possuí uma informação textual definida. Quando navegamos no botão, um texto descritivo deve ser apresentado ao leitor de tela para indicar qual tipo de função que o botão possuí.
Além disso, essa violação fere duas recomendações da WCAG:
- 1.3.3 – Características sensoriais [A] – WCAG 2.0 (em inglês);
- 2.5.3 – Rótulo no nome acessível [A] – WCAG 2.1 (em inglês)
O exemplo a seguir, demonstra o problema de um botão sem informação textual.
<button type="submit">
<svg id="search" viewBox="0 0 16 16.9">
<path d="M16, 15.7L11.3,11C12.4,9.8,13, 8.2,13,6.5C13"></path>
</svg>
</button>Qualquer validador de acessibilidade notificará a inconsistência da violação das guidelines citadas acima, Para eles não existe um conteúdo textual definido, uma abordagem para correção seria inserir o elemento <title> no SVG, pois ele garante que SVGs sejam acessíveis. Scott O’Hara escreveu um artigo imagens acessíveis e SVGS (em inglês).
<button type="submit">
<svg
id="search"
role="img"
aria-describedby="searchIcon"
viewBox="0 0 16 16.9"
>
<title id="searchIcon">Search</title>
<path d="M16, 15.7L11.3,11C12.4,9.8,13, 8.2,13,6.5C13"></path>
</svg>
</button>Documentos HTML sem definição de linguagem
A linguagem do documento HTML na maioria das vezes é ignorada ou esquecida. Já fiz diversas avaliações em sites com conteúdos totalmente em português e a definição do idioma em inglês.
Usuários de leitores de tela, utilizam um sintetizador de voz embutido nos softwares para ler o conteúdo. Uma das primeiras coisas que o sintetizador de voz faz ao navegar em uma página é procurar a definição do idioma daquele documento HTML, quando isso acontece ele configurará a entonação, ritmo e sotaque da língua definida no documento. Caso não encontre uma definição ele utiliza o inglês como padrão.
Além dessa confusão linguística, ele descumpre a recomendação 3.1.1 – Idioma da página [A]- WCAG 2.0 (em inglês)
Corrigindo
<!DOCTYPE html>
<html lang="pt-br">
...
</html>Para descobrir mais sobre o atributo lang, acesse: explorando o atributo lang.
Conclusão
Bom se fosse chegou até aqui parabéns! Concluímos a maratona dos seis maiores erros de acessibilidade digital. Vimos detalhamente cada erro e quais recomendações eles ferem, também possíveis soluções para cada um.
A conclusão que chego é que existe um défict enorme sobre os padrões web na comunidade de desenvolvedores. A maioria dos problemas de acessibilidade são problemas estruturais e educacionais.
Reciclar nosso conhecimento sobre os fundamentos é sempre importante, pois os frameworks da moda irão passar, mas os velhos amigos HTML, CSS e JavaScript estarão por ai.
E para reflexão gostaria de deixar uma frase do Tim Berners-Lee:
O poder da Web está na sua universalidade. O acesso por todas as pessoas, não obstante a sua incapacidade, é um aspecto essencial.
O que podemos fazer para mudar essa situação? Deixe sua sugestão do que podemos fazer para construirmos uma web acessível para todas as pessoas.
Referências
Introdução
Sábado dia 22 de agosto, aconteceu o Minas Test Conference um evento focado na área de qualidade de software.
Eu conhecia o evento há um tempo, porém, nunca tinha participado de nenhuma edição. Foi o segundo evento que participei, desde que, mudei da área de desenvolvimento para qualidade.
Inicialmente ele seria presencial, mas devido à pandemia global os organizadores decidiram fazer o MTC em casa. Uma aposta que deu super certo, nesse artigo irei analisar alguns pontos como:
- plataforma escolhida;
- análise de cada palestra;
- considerações finais.
Plataforma escolhida
A organização escolheu o Hopin para transmitir o evento. Minha experiência com a plataforma foi super tranquila sem muitas complicações.
A impressão que tive foi de estar num evento presencial, se o intuito da Hopin foi promover esse tipo de experiência as pessoas conseguiram com maestria.
Porém, nem tudo são flores eu particularmente estava com grande expectativa para ver uma palestra em específico que não pode ser transmitida devido à falta de acessibilidade, também não encontrei um recurso para ativar legendas na transmissão.
Mesmo com esse contratempo, a organização se preocupou tornar o evento mais inclusivo, contratando assim, dois interpretes de libras que fizeram um trabalho com grande maestria, gostaria de parabenizá-los pelo trabalho.
Análise das palestras
Boas práticas para automação de testes
Essa palestra infelizmente eu não acompanhei desde o início, porém, do momento que comecei a acompanhar até o final me agradou bastante. Leonardo e Ramses com maestria tocaram em pontos importantíssimos sobre fundamentos da engenharia de software e como podemos aplicá-los no nosso cotidiano.
O mindset de consultor – O que as empresas buscam nos profissionais de qualidade de software?
Marcelo, veio com uma abordagem mais holística sobre a carreia de consultor de qualidade, conseguiu explorar diversos pontos do nosso cotidiano que não são tocados com frequencia, tais como: mudança de uma mentalidade, compreensão dos fundamentos, certificações.
Abriu meus olhos para enxergar como alguém que contribui além do código ou de técnicas. Ficou claro, que podemos contribuir com a gestão de uma forma mais assertiva. A lição que tirei dessa palestra foi: saia fora da caixa.
Test Driven Development: uma ferramenta para controlar a ansiedade
Quando eu vi o título dessa palestra fiquei curios imaginando como o Estevão iria combinar TDD com ansiedade e para minha surpresa conseguiu. Com muita tranquilidade explicou o conceito teórico da metodologia TDD e sua aplicabilidade.
Mostrou as duas escolas sobre a metodologia e deixou ainda duas referências de livros interessantes:
Além disso, fez um hands-on em como aplicar o TDD em uma funcionalidade. Deixou bem claro em como a metodologia pode contribuir para termos maior controle e previsibilidade de funcionalidades que porventura iremos desenvolver.
A importância da automação e como fazer isso utilizando o Testcafe
Taís de forma bem direta e prática mostrou uma ferramenta de automação que ainda desconhecia o TestCafe, me lembrou do meu amigo Cypress.
Ainda fez um hands-on e funcionou tudo de forma perfeita.
Queria dar meus parabéns para a organização e a todos que apoiaram a Tais num momento de nervosismo, o espirito de comunidade e empatia falou muito mais alto e isso e louvável, poucos eventos têm essa sutileza com os palestrantes.
Reduzindo o escopo da analise de resultados de testes de carga usando Machine Learning
Júlio, com seu vasto conhecimento e maestria dignos de um JEDI, exemplificou conceitos como machine learning, testes de carga com uma didática impecável, quem o acompanha sabe que estou falando.
A palestra se assemelhava a uma aula de faculdade daquelas que todos gostam. Além de explorar esses pontos, também deixou insights sobre novas possibilidades em categorizar inconsistências com aprendizado de máquina.
Um mundo de possibilidades foi aberto e diversas pessoas surtaram com novas possibilidades. E como sempre o Júlio, nos deixa reflexivos sobre estudar os fundamentos, aliar o fundamento teórico a prática.
Automação de testes utilizando braço robô
Saímos com o cérebro fritando da apresentação do Júlio, para vermos algo surreal: uma automação em um braço robô!
Luíz Lohn, trouxe uma abordagem de testes que nunca pensei que poderia ser feita. A ideia era demonstrar como essa abordagem poderia contribuir para automação de testes para o cenário que ele vivencia.
De forma clara e exemplificando os códigos do arduíno e Ruby, desmistificou a magia e vimos que como foi viável e não ser tão complicado essa automação.
Abriu a minha mente para novas abordagens de testes automatizados para Internet das coisas. Mais uma palestra que veio surpreendeu todo mundo.
Shit Happens e algoritmos mudam
Marina apesar de não ser uma pessoa desenvolvedora explicou diversos pontos relacionados a desenvolvimento de software. Desde a evolução das redes sociais até como os algoritmos e APIs influenciam nosso cotidiano.
Comentou também sobre o uso indevido de informações dos usuários nas redes sociais, como no caso da Cambriga Analytica’s, pontuou também, como podemos usar de modo seguro as redes sociais e como as empresas estão se preparando para entrar em conformidade com a Lei Geral de Proteção de Dados (LGPD).
Foi uma palestra diferente, com um olhar de um outro ângulo. O ensinamento que permeiou foi que podemos absorver muito com o marketing e o monitoramento de redes sociais para atuarmos de uma forma melhor.
Tabuleiro acessível: o diferencial da inclusão a partir de jogos analógicos
Essa palestra uniu duas coisas que gosto: acessibilidade e rpg. Paola e Rafael, mostraram como jogos analógicos podem promover a inclusão das pessoas com deficiência em algo que não tomamos como um direito: a diversao.
Demonstraram diversos jogos que podem ser inclusivos e como as pessoas interagem com eles. Gostei bastante do jogo de RPG.
A palestra traz uma mensagem muito importante, quais são nossos esforços para incluir pessoas com deficiência na diversão?
Será que as empresas pensam e veem eles como possíveis consumidores de jogos de entretenimento sejam eles analógicos ou digitais?
Sai dela pensativo em como podemos contribuir para o avanço de um projeto tão bonito como esse.
AWS for Testers – Como se beneficiar dos serviços da AWS para analisar possíveis bugs
Isabel, veio com uma abordagem interessante: como nos que testamos aplicações podemos contribuir em arquiteturas AWS?
Demonstrou total conhecimento e clareza das informações explicando passo a passo do modelo da arquitetura proposta. Confesso que muita coisa desconhecia, apesar de trabalhar num aplicação que possui os recursos na AWS.
Trouxe exemplos onde o QA possuía acesso restrito em algumas partes da arquitetura e soluções de como garantir a qualidade nesse sentido.
Além da AWS, também demonstrou como realizar requisições de API usando o Postman.
Sai da apresentação, pensando que segunda-feira quero descobrir qual a arquitetura da AWS que usamos e como posso contribuir para a melhoria contínua do produto.
From zero to hero implantando processos ágeis de qualidade
A apresentação do Alan foi cirúrgica e agregou muita informação ao meu contexto. Em um evento sobre qualidade esperava-se uma palestra como essa que focaria na qualidade do processo.
Pontou muito bem as diferenças entre os modelos cascata e ágil, o mais interessante foi o passo a passo que apresentou sobre a metodologia ágil.
Salientou que esse modelo pode ser adaptativo e variar de acordo com o contexto. O que ficou claro é que processos bem definidos contribuí para a empresa como um todo. E deixou uma frase que me marcou
Baixa produtividade é um problema de gestão.
QA OPS: O QA colaborando em um time DevOps
A abordagem de Mayara foi super interessante, pois mostrou um caso de sucesso que ela vivenciou. Iniciou sua apresentação exemplificando os conceitos de Dev Ops e QA Ops e como pode contribuir para aumentar a qualidade em todo o ciclo do desenvolvimento.
O mais interessante para mim, foi a forma como foi abordado o tema. A explicação de cada etapa de uma pipeline e como ela conseguiu otimizar isso para o time.
Sanou diversas dúvidas que tinha sobre o assunto e segunda-feira também vou começar a vasculhar as pipelines para promover algumas melhorias.
Considerações finais
Fiquei bastante satisfeito de modo geral, todo o conteúdo de alto nível e bem elaborado. A organização do evento e palestras curtas, porém, objetivas.
A curadoria de conteúdo, a divulgação tudo muito bem planejado, os sorteios com brindes bem interessantes como licenças do IntelliJ, Kindles e um computador.
Parabéns a todos os envolvidos que proporcionaram para nós um evento acolhedor, rico e bastante interativo. Aguarde 2021, pois com certeza o MTC vem pra arrebentar.
© 2021 Bruno Pulis
Theme by Anders Noren — Up ↑