Você acredita que é uma boa idéia que os engenheiros de software trabalhem como engenheiros de garantia de qualidade por algum período de tempo? [fechadas]

Eu acredito que sim. Por quê?

1. Encontrei muitos engenheiros de software que acreditam que são de alguma forma superiores aos engenheiros de controle de qualidade. Acho que pode ajudar a extinguir essa crença se eles fizerem o trabalho de um engenheiro de controle de qualidade por algum tempo e perceberem que é um conjunto de habilidades único e valioso.

2. Quanto melhor um engenheiro de software estiver testando seus próprios programas, menor será o custo com o tempo em que seu código ocorre durante o restante do ciclo de vida de desenvolvimento de software.

3. Quanto mais tempo um engenheiro de software gasta pensando em como um programa pode ser interrompido, mais frequentemente eles consideram esses casos enquanto os desenvolvem, reduzindo assim os erros no produto final.

4. A definição de "completo" de um engenheiro de software é sempre interessante ... se eles passaram algum tempo como engenheiro de controle de qualidade, talvez essa definição seja mais parecida com o projetista do software.

Observe que eu faço a sugestão acima com um pequeno período de tempo em mente, pois sei que alguém trabalha em uma posição que não é a posição para a qual eles são contratados é definitivamente uma receita para perder esse desenvolvedor.

O que vocês acham?

1. Encontrei muitos engenheiros de software que acreditam que são de alguma forma superiores aos engenheiros de controle de qualidade. Acho que pode ajudar a extinguir essa crença se eles fizerem o trabalho de um engenheiro de controle de qualidade por algum tempo e perceberem que é um conjunto de habilidades único e valioso.

Uma boa engenharia de software tem experiência em qualidade, incluindo testes, métricas e estatísticas. Qualquer pessoa que desenvolva algum tipo de desenvolvimento de software deve estar ciente (se não estiver familiarizado) mantendo no código fonte de qualidade e produzindo / mantendo casos de teste eficazes. Com o tempo, eu suspeitaria que qualquer desenvolvedor de software entendesse as diferentes facetas da qualidade - qualidade do código, portabilidade, manutenção, testabilidade, usabilidade, confiabilidade, eficiência e segurança.

Os engenheiros de software podem se concentrar em um aspecto específico do ciclo de vida - engenharia de requisitos, arquitetura e design, construção, teste e manutenção. No entanto, independentemente do seu foco (como um trabalho ou na fase atual do projeto), é importante lembrar a qualidade.

2. Quanto melhor um engenheiro de software estiver testando seus próprios programas, menor será o custo com o tempo em que seu código ocorre durante o restante do ciclo de vida de desenvolvimento de software.

Isso pode ser verdade. Mas algumas questões são melhor vistas posteriormente no desenvolvimento. Por exemplo, problemas de desempenho e eficiência podem não ser vistos até a integração. Ter um código sólido e bom e testes de unidade eficazes são apenas o começo. A qualidade precisa começar com os requisitos e acompanhar as atividades de manutenção.

3. Quanto mais tempo um engenheiro de software gasta pensando em como um programa pode ser interrompido, mais frequentemente eles consideram esses casos enquanto os desenvolvem, reduzindo assim os erros no produto final.

Essa é uma afirmação totalmente verdadeira. Mas, novamente, também cabe aos engenheiros de requisitos verificar se não há conflitos nos requisitos, arquitetos para garantir que o design realmente atenda aos requisitos e assim por diante. Todos devem tentar abrir buracos no trabalho e, em seguida, trabalhar com as pessoas apropriadas para selá-las de maneira agradável e firme.

4. A definição de "completo" de um engenheiro de software é sempre interessante ... se eles passaram algum tempo como engenheiro de controle de qualidade, talvez essa definição seja mais parecida com o projetista do software.

"Completo" só pode ser medido em relação aos requisitos. Os requisitos foram atendidos e o projeto foi concluído ou existem requisitos incompletos e o projeto não foi concluído. Qualquer outra medida de completa é inútil.

Tornar os programadores responsáveis ​​por seu código e exigir que eles corrijam seus próprios erros pode cuidar disso. Isso e uma perda de bônus e / ou emprego.

Não que essa experiência não ajude, mas até onde você pode ir com essa linha de pensamento? Suporte técnico, vendas, usuário beta, limpe os banheiros (isso seria uma experiência humilhante).

"... tem que trabalhar como engenheiro de controle de qualidade ..."? Você faz parecer contraditório ou castigo.

Eu sou um desenvolvedor de software. Considero que também faz parte do meu trabalho ser engenheiro de controle de qualidade, apesar de termos um departamento de controle de qualidade. É meu trabalho fornecer software que realize certas coisas e, para isso, preciso escrever testes de unidade e garantir que o software seja aprovado.

Estou em parceria com nosso departamento de controle de qualidade. Meu objetivo é facilitar o trabalho deles, assim como o trabalho deles é me ajudar a cumprir meu objetivo de fornecer software que faça o que deveria, facilitando assim minha vida. Eu os considero meu segundo par de olhos e uma espécie de rede de segurança, assim como eu faço meus testes de unidade.

Eu escolho desenvolver software e quero desenvolver software. Se algum gerente viesse até mim e dissesse que eu não podia fazer isso e tivesse que fazer o controle de qualidade, diria que eles precisam encontrar um novo desenvolvedor de software E uma pessoa de controle de qualidade, porque não vou trabalhar lá. Sou anal como pode ser com meu código, mas o processo criativo e o quebra-cabeça / desafio de programação são extremamente importantes para mim. Prefiro voltar a dirigir empilhadeiras se não puder escrever código, porque estar em um ambiente corporativo sem o privilégio de ser criativo e ser desafiado do jeito que sou seria um inferno para mim.

Em geral, as opções que você apresenta parecem muito contraditórias e me perguntam se você teve algumas experiências realmente ruins com alguns desenvolvedores terríveis. Na minha opinião, um desenvolvedor SEMPRE deve estar ciente dos problemas e testes de qualidade e deve ter orgulho de seu trabalho, para não considerá-lo concluído até que seja aprovado em testes tão rigorosos em seus testes de unidade quanto o que o departamento oficial de controle de qualidade usará. Se eu tivesse um colega ou fosse o líder técnico de uma equipe e tivesse um desenvolvedor que mostrasse alguma "tude" em relação ao controle de qualidade, ele me veria levando-o para uma correção de atitude. Se os dois lados da moeda de entrega de software não puderem cooperar e agir em equipe, haverá um problema real de cultura. Eu não gostaria de trabalhar lá e o RH, juntamente com a alta gerência, precisaria ser informado.

Fazer os programadores trabalharem como engenheiros de controle de qualidade é uma receita para perder seus melhores desenvolvedores. A programação e o controle de qualidade exigem diferentes conjuntos de habilidades e processos de pensamento.

No entanto, é importante que seus programadores sejam especializados na arte de testar e validar seu próprio trabalho antes de transmiti-lo à equipe de controle de qualidade. Os desenvolvedores e o controle de qualidade têm acesso a diferentes ferramentas, conhecimentos e habilidades. Os desenvolvedores precisam ser hábeis em orientar seu código em busca de comportamento inesperado, teste de unidade para condições de limite, código estressado em busca de condições de corrida, etc., ou seja, testes na perspectiva do desenvolvedor.

O controle de qualidade faz seus testes da perspectiva do usuário. Pensar como diferentes tipos de usuários, inventar casos extremos e tornar reproduzíveis problemas obscuros são habilidades de controle de qualidade.

Não necessariamente - tanto os programadores quanto os testadores precisam ter habilidades diferentes. Só porque você é um bom programador, não significa que você pode ser um bom testador (muitas pessoas não entendem isso, mas ser um programador não o qualifica automaticamente para ser um testador).

Um grande testador precisa ter habilidades realmente diabólicas, ser capaz de fazer coisas que o software não foi projetado para fazer, mas pode esperar que o usuário faça no mundo real. Isso requer habilidade, paciência, capacidade de ver o que pode dar errado, onde, uma compreensão da mentalidade do usuário e muitos outros fatores.

Observe que eu uso as palavras programador e testador - mas se você é um engenheiro de software e ainda não decidiu se deseja ser um programador ou um testador, ele abrange essas duas coisas e, portanto, sim, você deve ter experiência em pelo menos nos primeiros anos de sua vida antes de tomar a decisão.

Isso não significa que você pegue um programador experiente e faça-o testar por um tempo apenas para fazê-lo entender o quanto os engenheiros de controle de qualidade trabalham.

Aqui estão alguns problemas em potencial que vejo com sua proposta:

1) Se você está sugerindo que coloque novos engenheiros de software em campo no departamento de controle de qualidade por um curto período, isso não terá apenas o efeito oposto? - eles podem assumir que o controle de qualidade é algo que você faz quando é novato e não entende o que está fazendo - afinal, foi assim que funcionou para eles.

2) Ser um testador muito ruim por um tempo não necessariamente lhes ensinará algo valioso. Mas isso pode torná-los intocáveis ​​mais tarde, porque eles assumem que sabem tudo sobre testes agora, porque passaram 6 semanas em um departamento de testes uma vez.

3) Dado que eles obviamente estarão lá apenas por um curto período de tempo e o departamento de controle de qualidade saberá disso, também é provável que eles recebam tarefas fáceis e relativamente pouco exigentes que exigem pouca supervisão ou entendimento, mas que os mantêm ocupados . Isso apenas reforçará 1 e 2.

4) Se você deseja evitar 1, 2 e 3, como convencerá seu departamento de testes de que vale a pena investir uma quantidade enorme de energia em ensinar e supervisionar alguém que nem sequer está interessado em testar? (Posso dizer, é preciso uma quantidade assustadora de tempo e energia para trabalhar com alguém que, lembre-se, não foi escolhido por sua aptidão para testar . Você não oferece à equipe de teste recursos adicionais por algumas semanas, você está pedindo que eles percam uma de suas pessoas mais experientes por algumas semanas, enquanto ensinam seu novato).

Dito tudo isso, acho que seu objetivo geral - aumentar o entendimento dos novos engenheiros de software sobre os testes - é realmente fantástico. Acho que é mais provável que a sugestão de Greg o consiga - faça com que as equipes de desenvolvimento e QA colaborem estreitamente e trabalhe para quebrar as barreiras entre as equipes. (Atualmente, estou trabalhando em uma empresa em que testadores e programadores estão na mesma equipe - é realmente ótimo e nunca quero voltar a trabalhar em equipes separadas.)

Se você ainda deseja que os programadores façam uma restrição no controle de qualidade - aqui está uma sugestão: liderar pelo exemplo. Vá você mesmo primeiro. Talvez transforme-se em algo que os membros de sua equipe realizem quando já são bons e desejam obter essa vantagem extra, passando um pouco de semana por semana com outras equipes especializadas em áreas sobrepostas - teste, DBAs etc. Se você apresentar assim, terá mais chances de sucesso.

Eu tive um tipo de carreira que é o inverso do que você normalmente vê. Comecei como suporte de software para a física cientificamente desafiadora e depois trabalhei na interseção de arquitetura, programação e algoritmos de uma empresa de computadores. Depois disso, otimizei o desempenho de um grande código de engenharia por vários anos, mas até esse trabalho acabou. Agora que estou chegando à idade da aposentadoria, estou fazendo o controle de qualidade no mesmo código. É uma combinação de desafio e trabalho árduo. Temos um cara novo muito afiado trabalhando 100% em correções de bugs, e eu gasto muito trabalho com ele. É uma posição desafiadora, e você pode aprender muito fazendo isso. Neste ponto, meu principal interesse no desenvolvimento profissional é para meus meninos gêmeos, que são calouros da faculdade de ficção científica. Então, tenho um novo interesse em aprender (ou reaprender) coisas que serão relevantes para suas carreiras, especialmente matemática aplicada. Tenho uma perspectiva diferente das coisas agora que me preocupo com o controle de qualidade / validação, pois no quarto de século anterior era velocidade, velocidade, velocidade a qualquer custo.

O teste de software é o processo destrutivo, e não construtivo. Mas o programador pensa em construir seu produto para garantir que o produto seja concluído dentro do prazo e do orçamento. Se o desenvolvedor de software pensar como destruidor de seu próprio produto, quem será o próximo a construir o produto. Portanto, cada parte do ciclo de desenvolvimento de software deve ser realizada pelas pessoas designadas em cada parte do ciclo de desenvolvimento. Se você se envolveu em dois ou mais campos, é certo que você nunca será perfeito em nenhum deles, então faça um programa ou controle de qualidade ou qualquer outra opção e seja perfeito nisso.