Menu

Minha jornada inesperada para me tornar um testador de software (de nível básico a gerente)

my unexpected journey becoming software tester

Experimente Nosso Instrumento Para Eliminar Problemas

“Você constrói uma vida de sucesso ... um dia de cada vez ...”

Minha jornada como testador de software começou um pouco inesperadamente.

Eu apareci para as rodadas de entrevistas iniciais presumindo que fosse uma oportunidade de desenvolvimento. Para ser honesto, como todos os outros graduados em Ciência da Computação lá fora, eu estava um pouco cético sobre prosseguir com os Testes.

Mas, finalmente, decidi tentar. Só com a esperança de que minha natureza curiosa me ajude neste campo.

Eu não poderia aceitar a oferta sem fazer esta pergunta - Terei a oportunidade de mudar para o Desenvolvimento, caso o Teste não me interesse? :).

Acredite em mim, eu nem sequer pensei em deixar o Testing depois disso.

perguntas e respostas da entrevista c # net

minha jornada como um testador de software

Quando apareci para a rodada técnica, não estava preparado para nada mais do que o conceito básico de teste de software . Acho que a única coisa que me levou a pensar foi que estou sendo avaliado logicamente e não teoricamente '.

Este foi o meu primeiro aprendizado em testes - eu entendi como nós ( caloiros ) foram avaliados.

Ainda hoje, uso técnicas semelhantes ao contratar caloiros para minha equipe. Eu verifico sua lógica, tenacidade e abordagem para um problema acima de qualquer outra coisa.

Leitura recomendada => 4 coisas importantes que aprendi em minha jornada como gerente de teste de controle de qualidade

Entrei na Zycus como Trainee de QA e recebi um produto no terceiro ou quarto dia. Era um dos maiores (estava em conceito então) e mais ambiciosos produtos da empresa. Depois de se estabelecer nas primeiras semanas, não havia como voltar atrás para mim.

Começamos como uma equipe de controle de qualidade de dois membros e, logo depois de alguns meses, eu era o único conduzindo os esforços de teste. Nos primeiros 2 a 2,5 anos, registrei quase 3.000 defeitos em diferentes categorias, como Funcional, Desempenho, Segurança, IU, Usabilidade, Multilíngue , Multilocação, etc.

Por um tempo considerável antes de novas adições à equipe de teste, enfrentei uma forte equipe de desenvolvimento de 15-16 membros. Mesmo após as adições, a proporção QC: Dev não estava muito saudável e ainda posso dizer com orgulho que foi uma jornada de sucesso, considerando tudo o que testamos, entregamos e tratamos.

O ponto importante que quero destacar aqui é- Tudo isso veio de uma compreensão do teste na prática e não apenas na teoria.

Trabalho na área de Teste de Software há quase seis anos. Tem sido uma jornada incrível com tantas experiências diferentes e muito aprendizado frutífero.

Atualmente, estou trabalhando como Gerente de QA Sênior, cuidando de cerca de 5 a 6 produtos e módulos. Mas o que me dá verdadeira alegria e felicidade é liderar uma equipe de mais de 30 Testadores felizes e apaixonados.

Claro, muitas pessoas contribuíram para o meu aprendizado, mas ainda posso dizer que a maior parte da minha experiência e conhecimento vieram da maneira mais difícil (e provavelmente da melhor maneira), ou seja, Aprendendo / resolvendo por conta própria.

'Experiência é o melhor professor.'

Embora eu diga isso, não quero dizer que você não se beneficiará ao aprender ou seguir teorias documentadas sobre teste de software. O que eu acredito é que tudo isso certamente ajudará, mas nada pode superar a compreensão do conceito em sua essência e enfrentar os problemas com ousadia.

Eu acredito que coisas documentadas não vão te ensinar teste real , embora possa lhe dar alguma direção e então você estará por conta própria. Pelo menos no meu caso, houve problemas que podem não estar documentados para resolver meus problemas exatos ou eu não consegui encontrá-los a tempo. Minha única escolha era entender o problema / situação no centro e reagir a ele com a abordagem que achei correta.

Exemplos - como abordei em diferentes situações

Deixe-me explicar isso com a ajuda dos problemas / situações que enfrentei e como os abordei.

# 1) A compreensão do negócio é um degrau superior em relação aos testes de compreensão

Bem, todos vocês sabem disso. Testar não é apenas testar algumas validações e fazer algumas verificações.

Como um testador, devemos visualizar todos os cenários possíveis, mesmo o mais raro dos raros cenários, sem falhar. Devemos considerar todos os dados de teste possíveis que o usuário real pode estar usando.

Por tudo isso, devemos entender o negócio ao máximo.

Não será errado se eu disser que devemos entender o negócio e a base de usuários tanto quanto ou até mais do que um analista de negócios.

Eu estava enfrentando probabilidades semelhantes.

Eu deveria entender cenários de negócios complexos no domínio de compras, faça um brainstorming dos novos requisitos e avalie-os do ponto de vista do usuário. Eu não apenas deveria trabalhar meus casos, mas também contribuir nas fases de Requisito e Projeto de cada iteração. Mesmo aqui, nenhuma referência pronta veio em meu socorro além de minha capacidade de pensamento e raciocínio.

Para entender melhor o negócio e projetar seus cenários / casos melhor, nada funciona como caneta e papel.

Leia também => 5 ferramentas que não são de teste obrigatórias para testadores para tornar a vida mais fácil

Antes de ir para Discussão de requisitos reunião, eu costumava anotar possíveis dúvidas / correções / pontos pouco claros com antecedência. Eu costumava escrever os cenários que desejo experimentar ou construir casos de teste; às vezes, até mesmo desenhar seus cenários funciona perfeitamente.

Quando você escreve / desenha, isso entra em sua mente com melhor clareza e, em seguida, sua mente trabalha com essa informação e produz mais cenários e dá melhor clareza. Isso continua até que você tenha aquela sensação de FEITO !!!

# 2) Desempenho contra as probabilidades e sob pressão

Eu estava trabalhando em um produto que era / é grande e complexo o suficiente para formar uma equipe de 30 engenheiros trabalhando continuamente por três longos anos para chegar a um nível de venda.

Na maior parte da fase inicial, ou eu estava (sozinho) contra uma equipe de 15-20 desenvolvedores de nível júnior, médio-sênior e sênior ou estava acompanhado por um ou dois outros testadores. Todos eles estavam adicionando novos recursos ao produto de maneira implacável, o que exigia atenção igual e paralela do lado dos testes.

Participar de reuniões de requisitos, redigir casos, executá-los, rodadas exploratórias, manutenção de servidores, implantações, nada era opcional.

Naquela época, eu não conhecia nenhuma metodologia, Melhor prática , curso ou um livro que pode me mostrar soluções para tais problemas. Ainda hoje não tenho certeza se há algo que possa ajudá-lo precisamente a lutar contra as realidades terrestres enquanto as enfrenta.

O que eu estava fazendo é agressivo e rodadas rápidas de testes exploratórios (Eu não sabia o nome na época) em cada recurso, um por um, e depois repita. Esta solução funciona puramente em quão rápido você pode mudar seus pensamentos e enquadrar situações / cenários.

Claro, isso exigiu um trabalho muito rápido e agressivo, mas funcionou para mim.

O que quero dizer com rodada agressiva é, você visa uma coisa de cada vez (Diga um elemento de um formulário por vez) e teste-o independentemente e em associação com outros elementos / coisas vinculadas.

Leitura recomendada => Como ser um viciado em produtividade (especialmente como testador)

Por exemplo. Como testar uma caixa de texto.

O que você pode testar aqui é:

  1. Se aceita e armazena dados como estão
  2. Validação de tipo de dados
  3. Validação de comprimento máximo
  4. Tratamento de personagem especial
  5. Tratamento de XSS
  6. Tratamento de dados multilíngue
  7. Tratamento de espaços vazios / sem dados
  8. Comportamento das teclas tab e enter
  9. Tratamento de erros (navegador cruzado)
  10. Alinhamento da IU (navegador cruzado)
  11. Copiar colar dados / arrastar dados de links para a caixa de texto
  12. Mais importante - o comportamento deste campo w.r.t. outros elementos vinculados (qualquer expectativa de negócios vinculada a este campo, como preencher algo em algum outro campo com base nos dados deste campo)

Pensar nos testes acima dá a você a confiança de que nada pode realmente dar errado nesse campo?

Bem, almejar uma coisa de cada vez sempre funcionou para mim e eu costumava obter alguma conclusão de trabalho também.

# 3) Quando você está enfrentando o 'inesperado'

como testar métodos privados usando mockito

Qual livro você acha que de repente vai ajudá-lo com ‘Como fazer’ quando você deveria fazer algo que nunca fez antes?

Se falarmos especificamente, então- Nenhum.

Lembro-me da época em que, na ausência de nosso líder de produto, eu e alguns outros membros juniores e intermediários tínhamos que implementar nosso aplicativo na instância de demonstração (era produção para nós na época) pela primeira vez. Foi muito crítico para a primeira demonstração do nosso produto.

Bem, fizemos isso, mas com muita tentativa e erro. O motivo é que nenhum de nós tinha experiência em Linux e script de shell . Lembro-me de que houve preocupações levantadas por nosso departamento de TI (tudo de boa fé) ao meu então gerente sobre eu executar comandos errados em servidores de produção. Talvez isso fosse apenas um catalisador e shell scripting / Linux fosse meu interesse natural, mas pouco tempo depois, acabei assumindo a responsabilidade de manter e atualizar de cinco a seis ambientes simultaneamente.

Shell e Linux chamaram tão bem meu interesse, que logo fui eu quem começou a conduzir treinamentos internos sobre ele.

# 4) Quando seu desempenho é medido, sua experiência não é

Bem no início da minha carreira, eu estava sendo comparado e medido com os testadores experientes e evoluídos. Acredito que muitos de vocês devem ter passado por uma situação semelhante e sabem o que essas expectativas extras fazem a vocês.

O remédio aqui era Empurre-me e evolua .

O único caminho a seguir era não pensar sobre o quão menos experiente eu sou, não me limitando pelos padrões mundiais de medir o quão lento / rápido devo crescer / aprender. Não me limitando aos critérios mundiais de quando alguém deve começar a liderar e o título que precisa antes de fazê-lo.

Bem, em torno deste ponto, devo dizer, independentemente de qual campo você pertence, recomendo que você leia The Leader Who Had No Title de Robin Sharma. Isso o ajudará a liberar o que está dentro de você. Isso vai lhe dizer que ninguém, exceto você, pode impedi-lo.

Se eu tiver que vincular minha experiência em algumas frases, é assim:

“Sua curiosidade, atenção aos detalhes, disciplina, raciocínio lógico, paixão pelo trabalho e capacidade de dissecar coisas é tudo o que importa para ser um testador destrutivo e bem-sucedido. Funcionou para mim e acredito fortemente que funcionará para você. Se você tem essas qualidades, tem que funcionar para você. ”

Bem, lendo até aqui, se você está pensando que estou promovendo qualidades humanas básicas sobre um conhecimento teórico mais profundo, então isso não é totalmente verdade. Acredito que começar com algo e provar o sucesso nisso depende um pouco mais de suas qualidades inatas do que das informações que você aprendeu. No entanto, para ir longe em qualquer campo, você precisa aprender lições, princípios e experiências.

Também no meu caso, tive que aprender as terminologias, os conceitos, as teorias até certo ponto à medida que avançava na minha carreira. A razão é que, como testador, você tem que interagir com várias pessoas que vão falar nesses termos e você tem que entender isso.

Como líder ou co-testador, você terá um novo testador vindo de alguma parte do mundo com seu próprio conhecimento de fatos, definições e terminologias. Aqui também, você não pode ficar passivo em relação a essas coisas; você tem que ter um conhecimento prévio sobre o máximo possível de coisas usadas / ditas por aí.

O aprendizado é inevitável.

Tive que aprender mais sobre os diferentes tipos de teste, como executá-los e maneiras de explicá-los para as pessoas da minha equipe no estágio certo. Tive que avaliar novas ideias, ferramentas e implementá-las. Aprender novos conceitos e metodologias torna-se igualmente importante à medida que você sobe na escada.

Leia mais => O guia de A a Z sobre como selecionar a melhor automação

Conclusão

Embora seja quase impossível escrever cada coisa importante e minuciosa que aprendi ao longo dos anos, esta é minha tentativa de resumi-la em uma lista com marcadores.

  • O teste é muito difícil de definir. Alguém pode fazer testes excelentes e pode não ser capaz de defini-los em palavras. É como você vê.
  • Todos podem ter sua própria definição de teste. O meu era simples- “Você recebe uma coisa - encontre falhas e torne-as melhores.”
  • Você não precisa necessariamente de grandes teorias, matrizes complexas ou ISTQB para ser um testador destrutivo. Você tem que ser curioso , focado e apaixonado, pensa logicamente e tem habilidade de dissecação. No entanto, saber mais não prejudica, mas não ao custo de perder o ponto crucial.
  • As abordagens / conceitos tradicionais também têm a sua própria importância e tenho o mesmo respeito por eles, considerando o facto de haver uma boa parte do mundo onde eles são uma necessidade justa. O teste sozinho não pode evoluir; o ambiente também precisa evoluir para isso.
  • Como testador, é igualmente importante aprender novo ferramentas, técnicas e metodologias conforme você avança . Planejamento de teste, melhores abordagens para realizar diferentes tipos de teste, testes situacionais são alguns para citar.
  • Como os testes são fluidos, a definição de ser a opção certa também difere muito de organização para organização. Ser um testador destrutivo ou excelente pode ser bom o suficiente para receber um cheque de pagamento se você tiver sorte, ou pode exigir um conhecimento extra de como os testes funcionam em empresas tradicionais. Ambos estão em seus próprios lugares.por exemplo.Eu contrato pessoas de acordo com minha definição de teste (que varia um pouco conforme a experiência do candidato e o perfil do curso).
  • Como existe um estilo de codificação, condução, culinária; há também um estilo de teste. Você pode não gostar, a menos que esteja fazendo do seu jeito. O que quero dizer é que o teste pode ter diretrizes, mas não deve ser limitado pelos microprocessos.
  • A liderança eficaz deve fazer sua equipe escolher o trabalho ao invés de atribuí-lo. Ele pode alterá-lo ocasionalmente para a melhoria do Produto.
  • Tente treinar seu pessoal em sua área de interesse e onde você deseja que eles sejam treinados. Alinhe os pensamentos e esforços de sua equipe com o objetivo final, que é ‘A melhor qualidade’.
  • Não tente gerenciar seu pessoal, lidere-os. Seja amigável e acessível, isso torna o trabalho muito mais fácil.
  • Cada membro de sua equipe deve amar o trabalho que está fazendo, ter apego ao produto e ser afetuoso com as pessoas ao seu redor. Então, apenas o melhor deles sairá.
  • O mundo dos testes precisa evoluir. Uma parte considerável do mundo está mudando para abordagens mais práticas, como testes exploratórios, testes orientados ao contexto (que muitas pessoas fazem sem saber que é), que até mesmo outros deveriam tentar e desenvolver mais técnicas como
  • Mais comunidades de teste devem ser formadas e pessoas com ideias semelhantes devem se reunir em uma escala maior. Há muito para compartilhar, aprender, adaptar e inovar.

Espero que minha experiência e descobertas ajudem você a se tornar um testador melhor ou a compreender melhor os testes.

Leitura adicional => Do iniciante ao profissional: um guia completo para a jornada de sucesso de um profissional de teste

Sobre o autor: Este artigo foi escrito pelo membro da equipe STH Mahesh C. Ele está atualmente trabalhando como Gerente Sênior de Garantia de Qualidade, tendo experiência em liderar frente de teste para vários produtos e componentes complexos.

Adorará ouvir de volta. Comente aqui ou entre em contato conosco. Muito obrigado pela leitura.

Leitura recomendada

^