Oi Meu nome é Dasha, estou testando um aplicativo móvel 2GIS no iOS. Quero compartilhar nosso processo de condução de recursos, o que ajuda não apenas a economizar tempo, mas também a atualizar minhas habilidades pessoais. Leia o artigo para descobrir como conseguimos manter produtos, designers e desenvolvimento no mesmo contexto. Acreditamos que a revisão da primeira montagem de teste por todas as pessoas interessadas realmente facilita a vida. E a comunicação é a chave para gerenciar um recurso.
Nossa dor
Ao me comunicar com testadores de outras empresas, percebo com frequência que o teste de seus recursos é algo confuso e desestruturado. Por causa disso, o tempo é desperdiçado, a força das pessoas envolvidas no desenvolvimento. As pessoas ficam com raiva, começam a odiar seus colegas, esperam por eles nas varandas.
Anteriormente, também tínhamos algo parecido: ao planejar um sprint, uma tarefa foi executada, no início do sprint foi levada para o desenvolvimento, desenvolvemos a tarefa no processo. Se havia dúvidas sobre a interação com outras equipes, fomos ao produto. Muitas vezes acontecia que em algumas equipes o trabalho já estava em pleno andamento: todo mundo estava ansioso pelo lançamento, alguém já havia sonhado com o recurso em batalha; e na outra equipe, eles nem sabiam sobre sua existência. Tal processo foi ineficaz, gastou muito tempo / esforço, trouxe o caos.
Como resultado, eles perceberam que era impossível viver assim e começaram a construir um novo processo. Ele já ajudou a salvar os nervos de alguém e possivelmente a vida.
Sobre a equipe
Nossa equipe é composta por: 9 desenvolvedores, 6 testadores, um produto e um designer. Ao planejar uma iteração (o que faremos nos próximos 4 meses), são compilados recursos que você deseja liberar no período atual. Quando a lista é compilada, um recurso é alocado para cada recurso da equipe desde o desenvolvimento e o teste, que estará com os recursos do começo ao fim.
Para nós, destaque é uma pessoa que vive com recursos do TK para lançamento. Ele tem informações atualizadas sobre o que acontece com o recurso como um todo e serve como ponto de entrada para perguntas sobre como trabalhar em recursos para pessoas de outras equipes. Você pode aprender mais sobre os recursos no final do
relatório de Sasha Kartavtsev . Lembre-se deste termo, então ele será encontrado mais de uma vez.
Lançamento em 9 etapas
Todo o processo de lançamento dos recursos pode ser dividido em 9 estágios principais. Para maior clareza, pegamos o recurso recém-lançado do "Rewards" e contamos como o conduzimos em todos os nove estágios.
Os prêmios são uma recompensa para os usuários por sua contribuição ao produto. Os usuários os solicitam para escrever resenhas, fazer upload de fotos e adicionar novas empresas ao diretório. Eles podem ser vistos na aba “My 2GIS”.
Etapa 1 - Processo de desenvolvimento da TK
Antes de começar a elaborar os recursos, criamos uma sala de bate-papo com folga e ligamos para todas as pessoas envolvidas. Concordamos que discutiremos todas as questões sobre recursos e eventos na vida dos participantes do bate-papo que podem afetar o curso do lançamento. Não é necessário dizer que você tomou leite, mas precisa falar sobre férias / licença médica, caso contrário, corre o risco de se deparar com o ódio por falta de resposta.
Primeiro, os recursos de desenvolvimento e teste analisavam TK / designs, perguntas, propostas de melhorias, com base na experiência de outros recursos. O recurso foi monitorado para que as perguntas fossem respondidas dentro de um dia. Se os prazos fossem atrasados, esses mesmos funcionários sugeriam ao produto / responsável que o tempo está passando e que seria bom responder já.
O processo de desenvolvimento de TK é considerado concluído quando todas as principais questões são encerradas, há projetos finais, o desenvolvimento não tem dúvidas sobre a implementação de recursos.
No primeiro estágio, é muito legal criar um protótipo de um recurso e usá-lo no desenvolvimento do TK: ajudará a sentir o recurso no dispositivo e a identificar imperfeições em um estágio inicial, apresentar casos para testes. Os produtos poderão fazer alterações na lógica mesmo antes do início do desenvolvimento da plataforma.
Etapa 2 - Elaborando a lista de verificação
No processo de elaboração do ToR, eu, como destaque para teste, compilei casos de teste para o recurso no TestRail, segundo os quais o recurso foi verificado posteriormente. Casos priorizados para sua automação adicional. Como existe um back-end no recurso, adicionei um cheque ao plano de teste: quais campos enviamos, que recebemos e o que acontecerá se houver alguma bobagem incompreensível aqui. Vamos dar a lista de verificação final ao desenvolvimento e aos produtos para sincronizar as expectativas do recurso, para que não aconteça que os testes pensem em uma coisa, o produto espere outra e o desenvolvedor faça outra coisa.
Etapa 3 - Desenvolvimento
Após o desenvolvimento do ToR, o desenvolvimento de recursos começou. Os testes naquele momento encerraram / debateram questões abertas no ToR e na sala de bate-papo, informaram o desenvolvimento de todas as alterações, se houver alguma: novos requisitos, novos designs, novos textos, qualquer outra coisa - o desenvolvimento deve estar ciente de tudo, caso contrário, não há como evitar uma briga.
Etapa 4 - Revisão da primeira montagem de recurso
Depois de receber a primeira montagem, lançamos em um bate-papo sobre recursos, onde chamamos os produtos e designers para uma revisão. Os testes controlavam que a montagem fosse visualizada e recebesse feedback - quanto mais rápido, melhor. Isso é feito nos estágios iniciais, para que situações desagradáveis posteriores não ocorram.
Um exemplo de uma situação desagradávelVocê senta quieto à noite em casa, não toca em ninguém. Você acha que tudo está para trás, amanhã o recurso irá para a batalha. Mas então, à uma hora da manhã, um produto maligno entra em sua casa (isso é real, porque ela mora três andares acima de mim) ou o designer (isso já é menos real, ele mora longe de mim, mas ele tem um carro) com os requisitos para corrigir urgentemente a fonte / cor / estofamento, caso contrário “não seja liberado! você não pode sair assim ", e de manhã a empresa de relações públicas já estava delineada, e é isso, está tudo no ralo. E agora você se senta às duas da manhã, liga para o desenvolvedor, inicia os ingressos. Em geral, o feedback recebido em tempo hábil das pessoas certas é valioso. Obtê-lo no início não permitirá que você aperte a liberação deste flanco.
Etapa 5 - Teste de plataforma
Paralelamente à revisão da primeira montagem, os testes começaram na plataforma usando casos de teste compilados anteriormente. Durante o processo de teste, se você encontrasse problemas que ameaçassem interromper o lançamento ou percebesse que algo poderia ser melhorado, eles adicionariam recursos ao bate-papo ou deixariam um comentário na declaração de trabalho. Garantimos que a pergunta não permanecesse em aberto.
No mesmo estágio, houve mudanças na lógica dos recursos (interface do usuário, por exemplo) - eles também entregaram a montagem ao produto e ao designer para uma revisão para garantir que as expectativas coincidissem com a realidade.
Etapa 6 - Teste de integração
Este item é necessário se equipes diferentes de telefones celulares participarem do desenvolvimento do recurso. Por exemplo, telefones celulares + back-end. Se substituirmos a fonte ou a cor do ícone, é claro que nenhuma integração ocorrerá. No entanto, em nosso exemplo com o Rewards, um back-end está envolvido - a integração era indispensável.
A primeira coisa a fazer foi atracar no Confluence. Como regra, a princípio uma pessoa faz isso.
O documento prescreve:
- datas de realização;
- participantes - para que a equipe conheça os heróis de vista, e os heróis não possam refutar esse fato;
- lista de cheques;
- lista de casos - verificação de cenários com condições específicas.
Depois de compilar um dock, joguei-o no bate-papo sobre recursos e convidei todos os participantes da integração a revisar / complementar os casos.
No dia X, os participantes da integração se reuniram em um escritório e verificaram todos os cenários nas docas de integração. É ótimo realizar integrações conjuntas com a equipe de back-end - você resolve imediatamente todos os problemas no local e esclarece todas as esquisitices.
Etapa 7 - Instruções de Suporte
Antes do lançamento, eles informavam ao suporte que um recurso seria lançado em breve, é hora de se preparar. Dali leu TK, cutucar o conjunto. Eles relataram quais bate-papos escrever e com quem entrar em contato se receberem feedback dos usuários.
Etapa 8 - Lançamento
Começamos a rodar o recurso, notificamos o bate-papo sobre ele e, paralelamente, assistimos o Crashlytics, comentários na loja e suporte. Esperávamos o melhor, bebi valeriana. Tudo correu bem com o Rewards, mas estávamos prontos para fazer imediatamente um hotfix e informar a todos no bate-papo sobre recursos se durante o lançamento um bug crítico fosse encontrado no lado da plataforma.
Etapa 9 - Suporte para recursos após o lançamento
Depois que o recurso entrou na batalha, nosso papel se tornou informativo: eles responderam às perguntas recebidas, solicitaram, resolveram alguns problemas da plataforma ou, se entenderam que o problema estava no back-end, os transmitiram. Após o lançamento, eu também coloquei os casos no check-in do Rewards no armazenamento do caso principal na pista de teste para que eles pudessem ser reutilizados no futuro.
E se brevemente
- Sempre mantenha todos no mesmo contexto. Relatar mudanças importantes.
- Assim que uma montagem com recursos aparecer, organize uma revisão da primeira montagem por todas as partes interessadas.
- Se ocorrerem alterações na lógica de um recurso em qualquer estágio, organize também uma revisão.
- Obtenha a resposta: escreva, ligue, chute, até responder.
- Prepare o suporte para um novo recurso e ajude-o após o lançamento.
O conhecimento e a experiência que adquiri no processo me ajudam no trabalho e na vida. Eu bombeei comunicação, independência, responsabilidade, mergulhei no produto além do trabalho de nossa equipe. A equipe, a propósito, também está feliz - no caso de um fakap, agora ele bebe vinho, não valeriana.