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]


12

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
Meu primeiro trabalho foi o controle de qualidade. Eu odiava, mas consegui REALMENTE entender a importância do controle de qualidade.
Job

Não apreciei totalmente a criatividade por trás do controle de qualidade até ler o clássico de Glenford Myers, The Art of Software Testing .
Macneil

5
Eu encontrei muitos engenheiros de software que acreditam que eles são de alguma forma superior a todos os outros no planeta ;-)
Steven A. Lowe

Steven verdade demais.
Macy Abbey

1
Sugiro perguntar se é uma boa idéia para os engenheiros de software fazer algumas coisas de controle de qualidade, em vez de pensar que alguma entidade não identificada os forçará a fazê-lo.
precisa

Respostas:


13

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.


Obrigado Thomas, essa é uma resposta muito informativa e atenciosa.
Macy Abbey

6

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).


Verdadeiro Jeff, mas acho que a primeira abordagem não necessariamente ensina a eles as ferramentas necessárias para se tornarem programadores mais eficientes / robustos. Mas coloca pressão, o que é bom.
Macy Abbey

Além disso, um dos pontos negativos dessa abordagem é perder um programador por um período de tempo, uma semana ... duas semanas, um mês? E eu não acho que é uma boa idéia ter-lhes fazer trabalhos que têm muito pouco a ver com seu trabalho atual ... (esfregando os banheiros: P)
Macy Abbey

6

"... 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.


Olá Greg, fiz a pergunta pensando em um engenheiro de software que é novo no campo e que não entende o valor do controle de qualidade e que não teve muita experiência em desenvolver um conjunto de critérios de aceitação bem definidos. A razão pela qual escolhi "preciso" é porque, como você disse, não acho que muitos engenheiros de software optariam por trabalhar como engenheiro de garantia de qualidade (como seu único dever) porque escolheram claramente ser um desenvolvedor de software. Eu definitivamente aprecio e compartilho sua perspectiva sobre qual deve ser a atitude e o relacionamento de um desenvolvedor de software verdadeiramente bom com o controle de qualidade.
Macy Abbey

Você acha que ter um novo engenheiro de software trabalhando como engenheiro de controle de qualidade os ajudaria a chegar ao ponto em que você está agora?
Macy Abbey

1
Absolutamente não. Certifique-se de que eles entendam como as equipes funcionam; Desenvolver uma atitude de propriedade dos problemas; Cultive uma atmosfera aberta que incentive as pessoas a trabalhar em equipes ad-hoc para discutir e resolver problemas. Muitas pessoas e empresas incentivam silos de conhecimento e uma atitude "nós contra todos eles". Honestamente, o "nós contra todos eles" precisa desaparecer dentro dos muros da empresa, porque isso machuca a todos.
the Tin Man

2
@Macy Abbey, uma tática a considerar pode ser a de que os desenvolvedores trabalhem em conjunto com a equipe de controle de qualidade para desenvolver os cenários de teste. Os testes de unidade podem ser escritos e projetados em conjunto, ou a equipe de controle de qualidade pode adicionar seus testes à pasta "tests", na qual o desenvolvedor tem testes de unidade. Algumas pessoas pensam que deve haver separação entre desenvolvedor e controle de qualidade, mas isso promove a concorrência. Se ambos os grupos usarem seus olhos e testarem truques juntos, talvez possam descobrir os bugs e os recursos perdidos ainda mais rapidamente.
the Tin Man

@ Greg Obrigado Greg, isso parece uma boa tática. Eu acredito que você me convenceu de que uma mistura de outras táticas é melhor do que o que eu propus inicialmente.
Macy Abbey

5

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.


1
Obrigado Ptolemy, faço essa sugestão com um pequeno período de tempo, 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.
Macy Abbey

Não é apenas o fato de eles não estarem trabalhando em um cargo para o qual foram contratados, eles também não estariam em um cargo que escolheram como profissão e estudaram. Esse é um grande tapa na cara de muitas pessoas que colocam seus corações em suas carreiras. Para aqueles que consideram apenas um trabalho como salário, tudo bem.
the Tin Man

@ Greg: Os que estão no salário também não vão gostar. O currículo deles será mais valioso com X + 1 anos de engenharia de software do que X anos de engenharia de software e um ano de controle de qualidade, pelo menos no início. Sem mencionar que você deve pagar tanto ao pessoal de controle de qualidade quanto ao pessoal de software, porque ninguém nele recebe um contracheque de bom grado.
precisa

Er, isso pressupõe que você esteja trabalhando em um local que pague menos por pessoal qualificado em controle de qualidade do que por desenvolvedores. Sei que alguns lugares o fazem, mas isso não reflete minha experiência - quando conheço os salários das pessoas, elas geralmente estão no mesmo nível.
Testerab

1
Nos primeiros anos de programador, seu salário depende muito de quantos anos de experiência em programação você tem. Portanto, ter 2 anos de C # e 1 ano de controle de qualidade oferece um salário de 2 anos em C # em vez de um salário de 3 anos.
Michael Shaw

3

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.


Verdadeiro Roopesh, embora eu ache que haja definitivamente uma interseção entre os dois conjuntos de habilidades, onde trabalhar como controle de qualidade por um pequeno período aumentará a velocidade com que alguém aprimora suas habilidades de teste.
Macy Abbey

1

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.


0

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.


Esta anedota não parece conter nenhuma resposta para a pergunta.
ninguém

-2

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.