Ir para o conteúdo principal

🙋🏻 Novo colaborador? Comece por aqui!

Olá!

Seja muito bem-vindo(a) ao nosso time! 👋

Preparamos este espaço com muito carinho para ser seu apoio nos primeiros dias conosco. Aqui você encontrará os materiais e todas as informações necessárias para iniciar sua jornada.

Estamos super animados para ter você aqui! 😊

1. Conhecendo nossos produtos:

  • Karoo Chat One:  Nosso mais novo produto de Chat. Ele visa ser um produto mais simples, com interface e usabilidade parecidas com o que o cliente já está acostumado: Whatsapp Web.
  • Karoo BOT: O Bot visa ser um produto de simples usabilidade, permitindo personalização de atendimento e integrações com APIs.
  • Omnichannel: É um produto totalmente backend, mas não se engane, ele é o coração de todos os outros produtos.. O omnichannel visa ser a ponte principal de comunicação, garantindo gerenciamento das contas, contatos, recebimento e entrega de mensagens e status.
  • WhatsappWeb: É um produto também backend, gerenciamos nele as conexões exclusivas do Whatsapp Web. Utilizamos para isso, uma LIB específica.
  • Karoo Account Manager: Também é um produto backend. Gerenciamos nele, as credenciais de acesso aos sistemas dos clientes, através de requisições das licenças no Bimer.

2. Onde hospedamos as APIS, Serviços e Bancos dos nossos produtos?

3. Repositório dos sistemas na Rede

Antes de acessar é preciso mapear a rede, conforme esse manual da infra: Mapeamento de diretórios na Rede: Linux e Windows

O repositório pode ser acessado de duas formas:

4. Onde estão as aplicações dos sistemas?

Todos os nossos sistemas possuem quatro versões principais:
Produção (ambiente real e em uso),
Review (ambiente de testes, uma cópia fiel da produção, porém com as novas implementações a serem mergeadas em produção),
Staging (utilizada somente no Karoo chat One, é uma cópia fiel do ambiente de produção, apontada para o ambiente de review do omnichannel),
Teste (ambiente totalmente seguro para testes, e sem problemas de realizar alterações).

Abaixo, você encontrará os detalhes de acesso às interfaces de Produção e informações sobre as aplicações:

5. Acesso ao banco de dados

Atualmente, temos diferentes formas para acesso do banco de dados do ambiente de teste, e do ambiente de produção. 
Primeiramente, você precisará baixar o mongoDB compass.

Siga estes passos para baixar e instalar o Compass usando o terminal:

  1. Baixar o Pacote .deb: Você pode baixar o arquivo .deb mais recente diretamente do site da MongoDB usando o comando wget. O link abaixo é um exemplo; você deve sempre verificar a versão mais recente na página oficial de downloads do MongoDB Compass:

    Bash 

    wget https://downloads.mongodb.com/compass/mongodb-compass_1.46.10_amd64.deb

    (Nota: O número da versão 1.46.10 pode mudar. Substitua-o pela versão mais atual.)

  2. Instalar o Pacote: Use o comando dpkg (Gerenciador de Pacotes Debian) com sudo para instalar o arquivo que você acabou de baixar:

    Bash 

    sudo dpkg -i mongodb-compass_1.46.10_amd64.deb

    Se você receber um erro sobre dependências ausentes (o que é comum), execute o comando a seguir para que o apt baixe e instale automaticamente todas as dependências necessárias:

    Bash 

    sudo apt --fix-broken install

  3. Iniciar o MongoDB Compass: Após a instalação bem-sucedida, você pode iniciar o aplicativo de duas maneiras:

    • Pelo Menu de Aplicativos: Procure por "MongoDB Compass" no seu lançador de aplicativos do Ubuntu.

    • Pelo Terminal: Digite o nome do executável:

      Bash 

      mongodb-compass

Banco de Teste:
Para acessar o banco correspondente ao projeto do time Omnichannel, você seguirá este passo a passo de exemplo: 
Acesse o OKD 4 e no seu nome de usuário no canto superior direito, clique em 'Copy login command'

image.png

Abra o terminal da sua máquina e dê um Ctrl + Shift + V (enter)
Oc projects (enter - aqui listamos os nomes dos projetos)
Oc project nome do projeto (enter)
Oc get pod (enter - aqui listamos os pods do projeto)
Oc port-forward nome do banco 27017:27017 (enter)


Para acesso ao banco do karoo chat One, é só você colocar essa url de conexão no compass: mongodb://karoo:gt36KVMc63M8@blackdb-review.karoo.com.br/karoo?directConnection=true&authSource=karoo

Prontinho, agora você poderá acessar o banco de dados dos projetos no MongoDB Compass para fazer os testes necessários no produto 😀

Banco de produção: 
Para acessar o ambiente de produção, você precisará de um convite do teach Lead.
A URL para acesso é: https://cloud.mongodb.com/v2#/org/681b8dec9d89f61eaf133064/projects

6. Monitor do sistema

Atualmente temos um monitor que nos ajuda a verificar os envios / recebimentos de mensagens das plataformas configuradas do cliente no ambiente de produção. 

7. Documentações de APIS:

Utilizamos o Swagger como uma ferramenta essencial para documentar nossas APIs e realizar testes.

Com ele, você pode:

  • Visualizar todos os endpoints existentes em nossos serviços.
  • Entender a funcionalidade de cada um.
  • Consultar os parâmetros necessários para as requisições.

Além disso, o Swagger está integrado ao nosso banco de dados de testes, o que significa que todas as requisições realizadas diretamente pela interface do Swagger serão executadas neste ambiente de teste.

Para acessá-lo, basta pegar a URL da branch, e no final dela acrescentar: /api/help

8. Como funciona a Sprint? (Time Omnichannel)

Este tutorial detalha como as tarefas são criadas, priorizadas e desenvolvidas no seu time, seguindo uma metodologia ágil utilizando o Jira da Atlassian: https://jira.alterdata.com.br/

1. Criação e Organização das Tarefas

As tarefas são criadas inicialmente pelo time, sejam Devs, Qas ou o próprio time de suporte, e essas tarefas vão indo para o Backlog

Todo o backlog é organizado conforme os produtos/projetos específicos do time.

2. Planejamento (Planning) e Votação das Tarefas

O processo de planejamento ocorre em sessões de planning.

  1. Seleção das Tarefas: Antes da planning, o Tech Lead seleciona as tarefas do backlog que serão consideradas.
  2. Votação: Após a seleção, o time realiza uma votação para estimar o esforço de cada tarefa. Esta votação segue a sequência de Fibonacci (1, 2, 3, 5, 8, 13...).
  3. Discussão e Voto Final: Depois da votação individual, o time discute cada tarefa para chegar a um consenso e definir o voto final. Esse processo se repete para todas as tarefas selecionadas.
3. Início e Execução da Sprint

Uma vez que as tarefas são votadas, a sprint se inicia.

  • Duração da Sprint: Uma sprint dura 2 semanas corridas, ou, aproximadamente 10 dias úteis.
  • Papel dos Desenvolvedores (Devs): Os desenvolvedores iniciam o trabalho nas tarefas que foram definidas e votadas.
  • Papel dos Analistas de Qualidade (QAs): Os Qas iniciam a sprint com tarefas designadas para o time de qa, tais como liberações, análise de situações reportadas, etc. Quando os devs finalizam as tarefas de programação, automaticamente as tarefas de teste, vinculada as issues, ficarão disponíveis na fila de tarefas pendentes de teste.

Durante o período de desenvolvimento pelos devs, os QAs não ficam ociosos. Eles aproveitam esse tempo para realizar outras atividades importantes, como:

  • Execução de testes e levantamento de requisitos em tarefas avulsas (que não fazem parte do sprint atual, mas estão no backlog).
  • Criação de documentação referente aos produtos ou processos.
  • Resolução de problemas específicos que surgem no dia a dia.

9. Como funciona o fluxo Kanban? (Time Karoo Chat One)

Esquece o nome chique. Kanban é só um jeito muito visual de a gente saber onde está a bola e quem está com ela.

Pensa assim: é o nosso quadro de tarefas (Aqui usamos o Linear)  e move eles pelas colunas: A Fazer ➡️ Fazendo ➡️ Pronto.

  • A sacada é: Não adianta ter 20 tarefas no "Fazendo". O Kanban força a gente a focar (o tal do WIP - Limite de Trabalho em Progresso) para terminar o que começou antes de pegar o próximo. É tipo não botar mais gasolina no carro antes de esvaziar o tanque.

    👑 Prioridade QA: O Foco que Não Tem Erro

    No mundo do QA, a gente tem que ser o bombeiro e o estrategista ao mesmo tempo. A ordem para puxar as tarefas é clara:

    1. 🚨 Fogo no Parquinho (Os Bugs!)

    • O que é: Corrigir bugs, erros, falhas. Aquelas tarefas que têm a ver com o que quebrou.

    • Regra: PRIORIDADE MÁXIMA. A gente tem que apagar o incêndio primeiro. Se tem bug pra testar, ele fura a fila de tudo. Estabilidade em primeiro lugar!

    2. ⭐ As Estrelas (Os "Priority")

    • O que é: As features (funcionalidades) novas ou as tarefas que o Tech Lead/PO marcaram como "Priority" na nossa coluna de testes.

    • Regra: Depois de matar os bugs, a gente puxa o que é mais importante para o negócio agora.

    3. 🤝 A Limpa no Quadro (A Negociação)

    • O que é: O quadro do QA (ou a coluna "Para Teste") está abarrotado? Parece que tem mais tarefa do que a gente tem braço?

    • Regra: Conversa com o TIME! A gente negocia para puxar as tarefas menores (as mais rápidas) primeiro. Por quê? Pra diminuir o volume visual e dar aquela sensação de alívio. Tarefa pequena que entra e sai rápido libera a cabeça para focar nas grandes.

       

       

      🗣️ O Segredo é o Papo Reto

      Resumindo, a nossa ferramenta mais poderosa não é o mouse, é a comunicação.

      • O Kanban é visual, mas se a gente não fala, ninguém sabe que a fila do QA está entupida.

      • A negociação de puxar tarefas pequenas é 100% vital! Se o quadro está entalado, a gente avisa o Tech Lead e propõe: "Posso finalizar essas três rápidas aqui pra gente dar um respiro?".

      É flexibilidade, mas com foco. 😉

10. Shield 🤠

Para manter a agilidade e a qualidade em nossos ciclos de desenvolvimento, adotamos um sistema de rodízio para a função de "Xerife da Sprint" a cada nova troca de sprint.

Este papel crucial é assumido por um dos nossos QAs (Analistas de Qualidade) e tem como principal objetivo ser a ponte central entre o time de desenvolvimento e as demandas urgentes provenientes do suporte.

🛡️ O Papel do Xerife da Sprint:

O QA designado como Xerife é o guardião da estabilidade e da resolução rápida. Suas responsabilidades incluem:

  • Absorção e Direcionamento: Ser o ponto focal para todas as demandas de suporte que precisam de intervenção do time técnico. Ele absorve a solicitação, faz a primeira análise e direciona a situação, garantindo que a demanda não se perca ou fique estagnada.

  • Triagem e Priorização: Realizar a triagem das solicitações de suporte, analisando dúvidas e, principalmente, mensurando a prioridade e a urgência da situação. Isso evita que o time da sprint seja interrompido por questões de baixa prioridade, enquanto assegura que o crítico seja atendido imediatamente.

  • Garantia do Tempo de Atendimento (SLA): Monitorar ativamente o andamento das resoluções para garantir que todas as demandas de suporte sejam atendidas dentro de um tempo aceitável (SLA), mantendo a satisfação de nossos clientes e usuários.

Este revezamento assegura que o restante do time de QA e desenvolvimento possa manter o foco total nos objetivos da sprint, enquanto temos um profissional dedicado e rotativo cuidando da linha de frente do suporte. É uma estratégia de time para proteger nosso foco de trabalho e, ao mesmo tempo, elevar a qualidade da resposta que oferecemos às urgências.

Vale destacar, que as dúvidas básicas do time do suporte, devem ser registradas pelo Haryon aqui do KB do suporte. 
E nós, devemos registrar essas dúvidas em nossa planilha de monitoramento: Clique aqui!

💽 Sistemas úteis para baixar em sua máquina de trabalho:

🎒 Materiais de apoio: 

Materiais para QA

 

Antes de mergulhar de cabeça nessa aventura, te convidamos a fazer um curso especial: "Primeiros Passos do Técnico de Qualidade", oferecido pela nossa UCA. Ele será um excelente ponto de partida!

Clique aqui para dar seus primeiros passos como QA