Como uma startup toma decisões de tecnologia? – Parte 3 – Qualidade

Descubra como a área de Qualidade se encaixa no processo de tomada de decisões de uma startup

Trabalhar em uma startup é como estar em um carro a 100km/h que nunca pode diminuir a velocidade ou parar, mas ainda é necessário trocar as peças em movimento para que ele continue andando. E como fazer isso e ainda aumentar sua potência?

Essa é a terceira e última parte da série “Como uma startup toma decisões?” Nos artigos anteriores, foi explicado como se encaixam no processo de decisão as áreas de Produto  e de desenvolvimento de software.

Nesse artigo final, vamos falar sobre a área de Qualidade. Venha descobrir como nasce uma ideia em uma startup, como são tomadas as decisões e como Qualidade se insere nessa conversa.

E afinal, onde entra a Qualidade nisso tudo?

A qualidade entra em tudo! Precisa estar à frente de tudo, da concepção do produto até a entrega final, inclusive em definições de arquitetura.

Conceituar qualidade pode ser uma tarefa complexa, mas no conceito de software podemos entender como um conjunto de características a serem satisfeitas de modo que o nosso produto atenda às necessidades das pessoas que o utilizam.

Vamos lá! Imagine um ciclo de desenvolvimento no qual a área de qualidade atue apenas quando tudo já foi construído e, lá no final, comece a encontrar várias inconsistências. O que acontece? É preciso abrir retrabalhos para que a equipe de desenvolvimento possa arrumar o que for crítico para conseguirmos subir a nova funcionalidade para produção. Como as coisas giram rápido demais, problemas que não impedem o funcionamento dificilmente seriam tratados ou priorizados, sendo, provavelmente, deixados de lado.  Mas dessa forma, estamos trazendo a melhor experiência para os/as nosso/as usuários/as?

Como tudo é muito rápido em uma startup, quando se está, desde o começo, com o alinhamento certo e estratégias de teste bem definidas, é possível entregar em produção um software com uma boa experiência e qualidade. Problemas que seriam encontrados apenas no final, são prevenidos desde o começo. Conseguimos, como time já definir em quais camadas teremos as automações e efetuar os testes durante todo o desenvolvimento! 

Hummm.. Isso quer dizer que, desta forma, teremos um software livre de defeitos? Na verdade, não!  Não existe software sem defeitos (você pode até ainda não ter encontrado, mas ele existe). A questão é que, dessa maneira, é possível trazer uma funcionalidade muito melhor para os/as usuário/as e no tempo certo. Isso evita perder o tempo de lançamento ou, ainda, que quem utilize acabe desistindo do produto por uma experiência desagradável logo na primeira versão do software.

Agora que já você já está por dentro de qual é o melhor fluxo dentro de um contexto onde as coisas giram rápido, vamos entender como conseguimos chegar nesse conceito na prática:

O início

Quando entramos em um novo lugar e vamos atuar na área de Qualidade, precisamos entender como as coisas funcionam. É preciso estar a par do objetivo do produto em que trabalhamos para entender qual é o nosso público e, nessa hora, a parceria entre as áreas de UX (User Experience) e PM (Product Manager) é extremamente fundamental. É preciso também identificar quais são as falhas existentes no produto e como podemos iniciar os trabalhos em busca de melhorar o processo e aumentar a qualidade. Uma boa tática para isso é utilizar a ISO25010 (para mais informações, acesse aqui, mas são conteúdos em inglês).

Em seguida, chega a hora de compreender como está a estrutura de desenvolvimento, sua arquitetura, se existe ambiente de testes, como todo o processo de desenvolvimento é feito, se existe um processo de desenvolvimento definido (como padrão de código, code review etc), para, a partir disso, poder pensar quais melhorias serão realizadas.

Depois que entendemos isso, é preciso analisar se as pessoas compreendem o papel do QA (Quality Assurance) dentro do time e qual a definição de pronto (Definition Of Done). Caso isso ainda esteja obscuro, é bom clarificar, afinal, quando todo mundo rema na mesma direção chega-se mais rápido ao objetivo.

Mão na massa

Entendemos quais são as demandas, qual é a nossa definição de pronto e já iniciamos a prevenção de inconsistências e mapeamento de riscos do que precisamos entregar. Para ciclos rápidos de entrega, passar horas escrevendo planos e casos de teste, pode não ser a melhor opção. O ideal, aqui, é trabalhar de maneira rápida. Uma tática muito bacana que aprendi é trabalhar com mapas mentais. A organização por meio dele para exemplificar o que deve ser validado e para traçar estratégias de teste é extremamente vantajosa, sendo de fácil leitura e trazendo agilidade para a execução.  Para montar a estratégia, podemos frisar:

É importante começar um fluxo de testes automatizados, pois assim, trazemos segurança para que o time possa implementar novas funcionalidades num startup.

Eu tenho notado que muitas pessoas desenvolvedoras falam sobre teste, mas não compreendem o que e como deve ser testado. Se eu desenvolvi um teste que nunca vai falhar, qual a finalidade?  Caso o time ainda precise consolidar os conceitos de teste, ofereça ajuda! Fazer pair programming e pair testing com a equipe de desenvolvimento pode ser um passo importante para ajudar a consolidar os conceitos passados.

Ferramentas de automação

Todo o trabalho que precisa ser executado mais de uma vez pode ser automatizado. Quando falamos em testes, temos algumas camadas como:

• Unidade;
• Serviço;
• UI – interface da pessoa usuária;

Para cada camada existem diversas ferramentas que auxiliam na automação de testes. Tendo em vista que a automação não é do QA e sim do time, chame seu time para participar dessa escolha e opte por ferramentas que façam sentido no seu contexto e que estejam de acordo com as habilidades do seu time. Por exemplo, se o seu time trabalha com C# escolha ferramentas que tenham a mesma linguagem. Isso poupa tempo no processo de aprendizagem.

Lembrete: É importante que a automação rode em uma pipeline, e não localmente na máquina da pessoa que a escreveu.

As etapas pelas quais o software passa, desde a máquina da pessoa desenvolvedora até chegar à produção podem ser automatizadas através de uma pipeline. Essa automação ajuda a organizar as fases do desenvolvimento e a fazer entregas frequentes do software, evitando também erros que podem ser cometidos se forem sempre feitos de forma manual.

Ao fazer o commit de um código para o git, a compilação é feita de forma automática, os testes são executados também de forma automática e colocada em um próximo ambiente. Uma pipeline é fundamental para que possamos trabalhar com CI/CD:

CI – Integração contínua: Testes das mudanças e conferências do código nos controles de versão. 

CD – Entrega contínua: Entrega automatizada de aplicações para ambientes de desenvolvimento ou produção.

Chegamos à parte final. Como as validações já são realizadas durante o processo inteiro, a validação final se torna muito mais rápida.

Quando o time entende que o processo de qualidade começa antes do desenvolvimento e continua durante todo o ciclo, as surpresas no final diminuem significativamente. Há um processo mais fluido, onde há a participação do QA na concepção, passando por todo o ciclo do desenvolvimento até a entrega para a minha pessoa usuária final.

Processo ajustado, tá bonito, tá beleza!

Unindo o profundo conhecimento dos/as usuários/as e seus contextos a um processo de desenvolvimento ágil e inteligente, assegurando qualidade e segurança em todas as etapas do ciclo, criamos um time alinhado com o negócio, que sabe para onde deve ir e como podemos chegar. Esse time será capaz de tomar qualquer tipo de decisão e traçar estratégias para tornar a empresa mais competitiva no mercado no tempo certo.

 

Este conteúdo faz parte da Sprint PrograMaria powered by Z-Tech | Mulheres em Startups.