Parece-me que estas duas áreas têm muito em comum. Por exemplo, ambos os processos estão focados em investigar os resultados da má conduta, bem como suas causas e efeitos, juntamente com as práticas relacionadas de manutenção de registros e documentação. Há um ano, recebi uma oferta para o cargo de QA Manual Engineer na inDriver. Mas antes disso, passei sete anos investigando casos criminais em várias unidades e agências de aplicação da lei. Durante meu serviço, trabalhei com uma ampla gama de infrações penais, desde crimes graves que põem em risco a vida e a saúde de uma pessoa até crimes econômicos de natureza inter-regional. No meu último emprego, meu cargo era: “Investigador Sênior da Divisão de Investigação de Combate ao Crime Organizado da Diretoria de Investigação do Ministério de Assuntos Internos da República de Sakha (Yakutia)”. Agora, meu trabalho é configurar testes de regressão, escrever autotestes de interface do usuário móvel e cuidar de muitas outras coisas projetadas para acelerar o processo de entrega de novos recursos aos usuários sem perda de qualidade do produto. Iniciando uma investigação Assim como uma investigação criminal começa com a inspeção da cena do crime, o relatório de bug começa com uma descrição do ambiente onde o defeito foi encontrado. Desta forma, coletamos alguns dados sólidos e confiáveis. Então, usando esses dados como base e aplicando uma abordagem dedutiva, bem como nosso conhecimento sobre o ambiente ou o produto, podemos restringir a área de investigação e começar a planejar novos movimentos e desenvolver nossas suposições. Desenvolvendo um plano de ação Uma vez que obtemos os dados brutos, nos deparamos com a diversidade de informações. Agora é importante traçar um plano de ação. O tempo é nosso recurso número um aqui. Dificilmente seria uma boa ideia verificar todos os valores de -2.147.483.648 a 2.147.483.647 no campo de entrada do nome com o objetivo de localizar o defeito. Da mesma forma, o investigador não tem a capacidade de questionar todos os residentes da cidade ou enviar cada utensílio ou item doméstico para testes genéticos moleculares. Para resolver esse problema, o engenheiro de controle de qualidade aplica técnicas de design de teste com foco em valores de limite, classes de equivalência e emparelhamento. Por outro lado, os investigadores aplicarão táticas e combinações que possibilitarão que eles planejem seus próximos passos da maneira mais eficaz possível. Fazendo nossas primeiras suposições Suponha que recebemos um relatório de assassinato informando que houve uma falha em nosso aplicativo. Pela minha experiência como investigador, sei que quase 90% de todos os assassinatos estão ligados de uma forma ou de outra ao marido, esposa, parentes, amigos ou vizinhos da vítima. É a mesma história com o aplicativo... somos guiados pelo conhecimento do produto: digamos que pegamos um sniffer e verificamos as solicitações de saída e as respostas que obtemos. Até agora, nada de interessante: todos os membros da família têm álibis e a resposta do servidor contém “200”. Tudo parece estar em ordem aqui. Além disso, sabemos que uma pessoa sã não cometeria assassinato sem motivo. Com base nisso, podemos restringir uma lista ilimitada de suspeitos àqueles com quem a vítima estava associada financeiramente ou tinha contatos relacionados ao trabalho ou outros. Da mesma forma, no aplicativo, podemos identificar a versão de lançamento a partir da qual o defeito começa a se propagar e desenvolver nossas suposições sobre quais alterações no código podem ter causado o aparecimento do bug. Levantando os logs Em seguida, tentamos estabelecer todos os eventos que antecederam o crime, a fim de rastrear algumas evidências incriminatórias: Assistimos a imagens de câmeras de vídeo. Interrogamos os vizinhos para saber se ouviram barulho de luta ou viram pessoas suspeitas. Nós estabelecemos com quem a vítima falou ao telefone pouco antes do crime ser cometido. Ao lidar com um defeito, também coletamos evidências: Capturamos logs no Android Studio ou XCode. Verificamos os logs do servidor. No processo, descobrimos que um homem NullPointerException entrou no apartamento pouco antes do crime ser cometido. Os vizinhos o identificaram como um bandido local com ficha criminal que se embebedava regularmente e era temido por todos os inquilinos do prédio. Verificando as evidências na cena do crime Suponhamos que, produzidas as provas incriminatórias, o homem confesse o crime. A investigação não termina aí. Temos que ter certeza de que foi ele quem cometeu o crime e que sua confissão de culpa é motivada pelo remorso, e não pelo medo de estragar o humor do investigador. Para o efeito, as provas são verificadas no local do crime, onde o arguido é obrigado a revelar todos os detalhes do crime e relatar quaisquer circunstâncias que não sejam do conhecimento de qualquer parte que não esteja envolvida na prática do crime crime. Assim, ao identificar um cenário estável para a reprodução do defeito, obtivemos prova conclusiva de que havíamos encontrado a pessoa certa que procurávamos. Investigação criminal concluída = Relatório de bug Uma vez estabelecidas todas as circunstâncias do crime, não cabe ao investigador corrigir o defeito. Ele organiza as evidências coletadas no arquivo do processo criminal, elabora uma acusação e a apresenta ao tribunal. A decisão sobre a sentença, sobre como corrigir o bug ou sobre declarar esse bug como um recurso inocente é feita fora do processo de teste. Apuração das razões do crime A fim de prevenir crimes semelhantes no futuro, o investigador deve estabelecer as circunstâncias que contribuíram para o cometimento do crime sob investigação e tomar as medidas cabíveis. Ele deve estabelecer, por exemplo, o motivo pelo qual nenhuma providência foi tomada anteriormente em resposta a denúncias sobre a conduta do perpetrador, ou por que as medidas tomadas contra ele não impediram o crime. O mesmo vale para o teste: quando um bug é detectado no PROD, não custa nada identificar os fatores que contribuíram para o seu aparecimento: Cobertura de teste inadequada. Mesclar sem cobertura de teste. Formulação pobre do problema. Requisitos definidos inadequadamente. Casos de canto não verificados por um especialista em controle de qualidade. Uma quantidade insuficiente de tempo alocado para fins de teste e desenvolvimento. Baixa qualificação profissional dos membros da equipe de desenvolvimento. Requisitos que mudam com frequência. Conclusão Obviamente, os trabalhos de um investigador e de um testador não são os mesmos. Apesar de algumas características comuns, ainda existem significativamente mais diferenças do que semelhanças entre eles. Mas se por algum motivo você se deparar com o desejo de mudar radicalmente sua trajetória profissional, você pode encontrar cursos adequados em nosso parceiro, e isso é possível. Mesmo em um campo completamente diferente, você pode encontrar atividades que exigem uma mentalidade semelhante – e isso tornará um pouco mais fácil atingir o objetivo que você mesmo definiu. Também publicado aqui
