[Opinião] Area de Testes.

Sou o único tester na a área de desenvolvimento de uma empresa.
Porem o time de desenvolvimento vive tampando buracos e raramente existem projetos novos, somente correções que eram para ontem.
Onde cada desenvolvedor cuida do seu filho e vida que segue.

Estou com a seguinte duvida.

  1. Tentar penetrar no processo e fazer com que as coisas deixem de ser para ontem e eu poder entrar no fluxo (correndo o risco de ser um filtro lento e impedindo que as coisas fluam).
  2. Deixar o que funciona do jeito que está e focar só no que é novo.

Obs: Eu sei que cada empresa é uma cultura e não existe receita de bolo para o sucesso mas talvez vocês ja tenham vivenciado coisas parecidas.

Mas quero a opinião de vocês.
O quê fariam??
como fariam??
O que não fariam??
O que deu certo??
e Principalmente o que deu errado??

É um caso delicado, mas tu precisa ver se o time, como um todo, gostaria de alguma mudança para não ter mais esses incendios para apagar. Se sim, dá para trabalhar aos poucos um processo (para que não seja doloroso) para resolver isso. Envolve todo mundo, faz gerar o sentimento de que as coisas estão sendo feitas junto…Sem uma gerencia embaixo obrigando.
Agora se todo mundo já “se acostumou e não tem interesse de mudança”, mexe muito não… A não ser que tenha muita habilidade em negociação e persuasão…

Passei pelo mesmo caso, era o único Analista de Testes de uma equipe com 6 Dev.
Tive duas tentativas de tentar mudar a cultura da empresa com algumas mudanças de processos, que foram totalmente sem sucesso, na terceira tentativa meu gerente me deu um corte que eu percebi que era melhor eu apenas fazer meu testes que tinham que ser pra ontem. Graças a Deus sai de la e hj estou em uma empresa onde também sou o único Analista de Testes, porem meu Gerente me da total liberdade para mudança de processos e de fluxo, logico que todos são discutidos com a equipe para que todos estejam de acordo com as mudanças.
Um conselho, tente conversar com seu superior para que ele entenda suas ideias e procure mudanças não muito drásticas, pois mudar uma cultura nunca será facil.
Outro ponto e demonstrar para empresa o quanto de ganho $$ ela vai ter com isso, pois BUgs em Produção Gera mais de 50% de gastos para uma empresa.
Caso precise de ajuda estamos ai.

Ederson Dias

Boa tarde @bruwesley ! Primeiramente, parabéns pela iniciativa de ter identificado que existe um problema e estar buscando a solução.
Na minha opinião, em um primeiro momento, o mais interessante seria conseguir identificar o motivo do processo estar tão lento. Importante saber identificar os gargalos e identificar os pontos fracos do processo de desenvolvimento.
Em segundo momento, você poderia identificar as melhores práticas para rodarem os testes de forma que sejam ágeis e consistentes. É importante identificar e limitar o escopo das tarefas ou das sprints e definir marcos para entrega das versões.

No mais, desejo sucesso ai na sua caminhada.

Abraços

bruwesley, a mudança de cultura de uma empresa é sempre um grande desafio. Bater de frente e tentar mudanças drásticas em geral não é uma boa estratégia.
Eu tentaria introduzir automação dos testes funcionais nos caminhos criticos da aplicação, entregando maior valor para o negócio. Por exemplo, no fluxo de venda, de onde vem a receita da empresa.
Também poderia introduzir um ferramenta de CI e de análise estática de código.
Assim, os desenvolvedores vão passar a perceber o valor dos testes e serão mais receptivos a novas propostas de mudança no processo.

@bruwesley, passei por situação similar no meu primeiro emprego como tester. Era um software legado, código VB que já existia há mais de 20 anos e muitos Devs não trabalhava mais na empresa, havia muito conhecimento no limbo. As entregas eram demoradas, as vezes 1 ou 2 por ano. Cada entrega era um parto, com muito sofrimento em que nenhum cliente queria parir o filho (isso em uma carteira de clientes com cerca de 2k CNPJs). Então segue um relato.

  • O primeiro passo foram os testes exploratórios, seek and destroy mesmo, procurando os mais banais dos bugs e aproveitando para aprender mais sobre o software. Em pouco tempo tínhamos 2k bugs cadastros. Com isso conseguimos argumentar parar contratar um estagiário para ajudar com os bugs mais simples (maxlength, unique key, SQL Injection, melhoria de mensagens de erro e etc). Com esses bugs em grande parte corrigidos, o suporte diminuiu a demanda, o que consequentemente diminui a demanda dos Devs.
  • O segundo passo foi focar na entrega (na época eu nem conhecia o termo deploy cont´inuo, hehehe). Conseguimos automatizar usando Delphi (isso mesmo, Delphi).
  • Com a entrega automatizada, chegando menos chamados no suporte e com a confiança do cliente elevada, começamos a automação dos testes. Para isso listamos as principais funcionalidades (também não sabia o que era smoke tests) e automatizamos usando o TestComplete.
  • Nesse período eu sai da empresa. Na época tinha uma bonificação no final do mês baseado no número de tickets abertos para os Devs. E pela primeira vez a empresa conseguiu chegar ao menor n´´úmero dessa bonificação (25 tickets abertos no final do mês), rolou até churrasco heheeheh e por último veio a Integração Contínua com o Jenkins. Posso te dizer que está lindo, cara.

Aqui vai duas dicas:

  • Use as métricas a seu favor. Independente de qual ferramenta vocês usam, tire as métricas possíveis. Pode ser quantidade de tickets, quantidade antes e depois, quantidade por cliente, tempo médio de desenvolvimento, tempo médio de solução de problemas, tempo entre entregas e etc.
  • O mais difícil em todo o processo é o lado cultural, humano. Mudança de processo é algo heurístico, não tente fazer com que os Devs se adequem a um processo totalmente novo, Primeiro você se adapta e aos poucos vai melhorando o processo e eliminando os desperdícios.

E isso, espero que esse breve relato o ajude a trilhar esse caminho. No final, é gratificante olhar o resultado. Abraços e boa sorte.

"Não duvido mais do que já suponho"
(Gandalf)

@acfreitas O que você fez de errado que não faria mais?

@bruwesley, primeiro eu tentei enfiar um processo goela abaixo, totalmente diferente. Logicamente não deu certo. Segundo eu demorei entender o a importância das métricas, por isso as duas dicas.

Mas nada que eu não faria novamente, teve outros erros também. Porém todos contribuíram no final, todos agregaram conhecimento e experiência. Sem dúvidas, todas trouxeram ótimas reflexões.

"Não duvido mais do que já suponho"
(Gandalf)

Acho que você mostrando os números, ou seja métricas como acfreitas citou é o primeiro passo, depois mostrar pro time que não é só você responsável pela qualidade, que todos do time são responsáveis pela qualidade, depois que todos entender isso, acho que vai ser bem mais fácil sugerir melhorias. Eu não começaria pelo processo, começaria automatizando do fluxo principal do sistema algo que os Devs podem te ajudar e você pode ganhar melhor a confiança deles, depois vai fazendo pequenas mudanças, não como obrigação mais como teste por um período.

@bruwesley cara eu to passando por isso, porém realmente é complicado apresentar algo novo quando o processo já está rolando, porém gostei das dicas do @acfreitas jeito mineiro pode funcionar. Acredito que apresentar a falhas com uma sugestão das soluções pode convencer a essas mudanças. Valeu por ter compartilhado essa experiência pois isso acontece muito.

Miécio Santos Costa


Analista de Sistemas | Analista de Testes - CTFL
miecio.costa@gmail.com.br

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.