6 erros de controle de qualidade e como evitá-los

Elkling passando sua sabedoria

Sete anos de experiência no ramo de garantia de qualidade do desenvolvimento de software me dão a confiança ilusória de me sentar na minha cadeira de balanço, reunir os filhotes e começar uma história sobre como era nos velhos tempos, os erros que cometi e irritantemente incomode os juniores para aprender com meus defeitos. Enquanto olho conscientemente para o fogo crepitante (sim, agora há um fogo, continue com a fantasia), adoto de mau humor um olhar severo e começo a pregar. Aqui estão seis erros de controle de qualidade e como evitá-los!

1. Esqueça a imagem maior

Quando alguém começa como testador júnior e tem a emoção de um filhote de golden retriever bem descansado, é inevitável às vezes esquecer o quadro geral. É quando um júnior preenche meu quadro de Jira com melhorias, pixels desalinhados, ícones que estão levemente fora do centro e com ponto e vírgula duas semanas antes de eu precisar enviar um candidato a lançamento final. É também a maneira mais rápida de me ver hiperventilando. O que eu preciso neste estágio é garantir que os principais recursos estejam funcionando, que nada esteja quebrado, que as falhas sejam uma memória distante e que o aplicativo seja fácil de usar e facilmente acessível - não verificação gramatical e perfeição da interface do usuário.

A melhor coisa dos novos testadores é a sua vontade infinita de encontrar o maior número possível de bugs e provar que são valiosos. No entanto, a pior coisa dos novos testadores é o desejo infinito de encontrar tantos bugs ... você sabe como isso acaba. Às vezes, eles tendem a se concentrar em pequenos detalhes nos piores momentos possíveis. Priorizar é algo que é aprendido e, com o tempo, começa-se a entender que há um momento certo para arquivar triviais e que um prazo assustador que se aproxima provavelmente não é o momento.

2. Adicione problemas com base em seus sentimentos

Eu acho que esse ícone ficará melhor se fosse laranja em vez de azul. Eu sinto que essa lógica é um pouco difícil de entender, então eu sinto que precisamos adicionar pelo menos mais quatro pop-ups. Não! Os testadores juniores não conseguem fazer sugestões. Isso é muito duro? Ok, deixe-me tentar novamente, os testadores juniores podem fazer sugestões no momento certo para as pessoas certas.

Quando começamos a desenvolver um recurso ou módulo no início dos projetos, geralmente todas as sugestões são bem-vindas. Pensamos de maneira criativa, porque precisamos pensar em todos os casos extremos possíveis e cenários de usuário para escrever casos de teste detalhados e completos. É quando os arquitetos ou designers de soluções são mais propensos a ouvir sugestões e levar nossas idéias em consideração.

Se você realmente acredita que sua opinião é valiosa e já fez sua pesquisa, vá em frente e nos surpreenda. No entanto, se nossos fluxos de trabalho, renderizações e propostas já tiverem sido aprovados, implementados e testados, geralmente é tarde demais para mudar as coisas, por melhores que sejam suas idéias. E nunca arquive bugs com base apenas em suas próprias preferências.

3. Esqueça a existência do seu designer

Falando em renderizações, fluxos de trabalho e questões sobre eles, não há maneira mais rápida de enganar seu designer por inimigos do que passar por cima deles e adicionar melhorias em seu trabalho ou, pior ainda, erros de design. Eu amo meus designers e confio muito na competência deles de que, se eles criaram um recurso de uma maneira, eles têm uma boa razão para apoiar isso. Sei quanto esforço eles dedicam à pesquisa de idéias diferentes e sei que eles geralmente estão em estreita colaboração com o cliente e provavelmente estão mais conscientes das demandas de interface do usuário do que eu.

Se eu tiver que ser completamente honesto, às vezes ainda cometo esse erro e, no calor do momento, decido adicionar algo a um recurso sem consultar o meu designer primeiro. Faço isso com a melhor intenção de melhorar algo, mas minha melhor intenção significa pouco se estiver interrompendo o processo acordado e adicionando um atraso inesperado.

4. Irrite seus desenvolvedores

Ahhhh, os desenvolvedores podem ser intimidantes, os desenvolvedores podem ser irritantes, os desenvolvedores podem ser arrogantes e mal-humorados. Mas os desenvolvedores são sempre seus melhores amigos, sempre! Então você tenta o seu melhor e estabelece um relacionamento de confiança. Você vai e trabalha duro até que eles te tolerem, ouso dizer que até gosto de você. Porque devs felizes = QAs felizes. Mesmo que você precise ouvir mil vezes "não é um bug, é um recurso", você morde a língua e persevera. Se você não acredita em algo que seu desenvolvedor lhe diz, pode ir para um veterano e pedir uma segunda opinião. Mas, idealmente, é melhor manter uma parceria de confiança. Você precisa confiar na experiência deles e eles confiarão na sua competência. É uma simbiose linda, mas frágil.

Os desenvolvedores precisam confiar que você tem as costas deles, e mesmo que você queira quebrar o código deles, você faz isso com a melhor intenção e para o bem maior. E você precisa confiar que, às vezes, muito raramente, um bug é realmente um recurso. :)

A maneira mais rápida de irritar um dev btw é quando você testa um módulo incompleto e adiciona vários bugs sobre coisas que ainda nem foram implementadas. Dê-lhes tempo, não apresse-os e tente manter seu entusiasmo até que eles terminem com sua parte e sua parte possa começar.

5. Suponha que você seja bom demais para documentação

Ahhh, sou eu em poucas palavras. A tarefa mais tediosa para mim é escrever casos de teste ou modificar os existentes com novos cenários de borda e informações que eu revelei durante o teste. Quando você ganha impulso e testa confiança, começa a omitir o básico. Você se sente muito pressionado pelo tempo para se incomodar em seguir um modelo de lista de verificação e faz isso pela memória sem deixar vestígios de seus resultados. Você tem tanta certeza de sua capacidade que esquece que todos os testes precisam ter uma área visível. Especialmente se você está lidando com um projeto sozinho e conhece todos os pequenos detalhes sobre ele, esquece a necessidade de documentar e isso pode facilmente voltar e mordê-lo no brinquedo.

Sou culpado disso e por muito tempo pulei algumas etapas para ter mais tempo para outras tarefas. Mas, em alguns casos, sua palavra honesta não importa, a menos que você tenha um documento para apoiá-lo. Se você diz, por exemplo, que algo é uma regressão porque costumava funcionar perfeitamente antes e então alguém pede que você mostre a eles a prova disso e você não pode, isso parece pouco profissional. Você nunca sabe quando será transferido para outro projeto ou alguém precisará assumir o seu trabalho e esse alguém estará totalmente perdido, a menos que você tenha feito sua parte no papel.

6. Não fazendo as bases

Digamos que seu projeto seja um aplicativo móvel compatível com Android e iOS. Um testador júnior está verificando um telefone Android e vê uma falha. Junior está em êxtase, um acidente é muito importante, então eles se apressam em adicioná-lo a Jira o mais rápido possível e disparam o alarme. O que eles esquecem é de todas as outras etapas necessárias antes de adicionar um bug, especialmente um importante. Há algumas bases antes de adicionar um problema. A primeira coisa é verificar se há duplicatas no sistema de arquivamento. Ninguém gosta de duplicatas e elas fazem você parecer desleixado! O segundo é verificar mais alguns lugares para ver se esse problema é específico do dispositivo, específico da plataforma ou geral. Portanto, é melhor verificar um tablet Android e, em seguida, um dispositivo iOS etc. Também seria útil reunir alguns registros para que o desenvolvedor economize algum tempo para tentar reproduzir e verificar rapidamente os registros. Também é útil ver com que frequência você pode reproduzir o problema, isso acontece toda vez ou um pouco mais aleatoriamente. Isole as etapas exatas do problema e verifique também as versões e compilações anteriores para ver se é uma regressão recém-introduzida ou se ela existe e perdeu o tempo todo.

Esses erros são parte comum da jornada de um controle de qualidade e são um passo natural para o processo de aprendizado. Agora que passei por essa carga preciosa de um legado, informe-me nos comentários abaixo se você é culpado de algum desses erros ou se há pecados ainda mais imperdoáveis ​​de controle de qualidade que eu perdi.