Um programador deve ser auto-suficiente?

No meu local de trabalho atual, não temos testadores, a justificativa disso para a gerência é: "se tivéssemos testadores, você não testaria seu próprio código". Esse tipo de pensamento parece prejudicial para a qualidade do produto, pois enquanto eu testo meu próprio código, há muitas coisas que vou sentir falta apenas pelo fato de conhecer o sistema de dentro para fora e não saber como usá-lo. "errado". O teste da caixa preta realmente não funciona, pois subconscientemente evito as armadilhas em que um testador dedicado cairia. Muito do meu tempo é dedicado à correção de bugs que foram inseridos no código de produção e encontrados pelo usuário final.

O sistema em questão é grande, mas é desenvolvido exclusivamente por mim. Isso também fez com que algumas tarefas administrativas caíssem no meu colo, como definir horários e trabalhar com especificações.

Esse tipo de tarefa deve ser de minha responsabilidade? Eu me vejo estritamente como programador e nada mais. E se essas são minhas responsabilidades, até que ponto? Quando um projeto é tão grande que requer testadores? Um programador deve refinar a especificação, se preocupar com o gerenciamento do projeto ou até mesmo fornecer suporte ao cliente?

Nota

Alguns podem ter a impressão de que sou contra a ampliação de minhas responsabilidades - esse não é o caso, estou ansioso para conseguir uma função que envolva mais tarefas de gerenciamento, mas atualmente não está na descrição de meu cargo. Até que eu esteja oficialmente empregado como tal ou que os deveres adicionais comecem a aparecer no meu salário, vou pensar em mim como 'apenas' um programador. Infelizmente, como desenvolvedor júnior, a mudança para funções gerenciais não acontecerá muito em breve.

Excelentes respostas até agora, mantenha-as sempre disponíveis, se você tiver algo a acrescentar ou experiências pessoais para compartilhar!

Você faz tem testadores. Somente você os chama de "usuários finais". Isso é prejudicial por todos os motivos que você descreve; não importa o quão consciente seja um codificador, você simplesmente nunca será capaz de fazer um trabalho bom o suficiente para superar seus próprios preconceitos sobre como o código "deve" ser usado para que você encontre todas as maneiras pelas quais ele pode estragar tudo .

Você precisa reabrir esse problema com o gerenciamento. Nesse ponto, parece que você tem alguns dados concretos para apoiar seu caso; a abordagem atual da garantia da qualidade desperdiça seu tempo e compromete a experiência dos usuários. Você precisa ter cuidado ao apresentar isso, para que fique claro que esse é um problema estrutural e não um caso de "Você é péssimo em testar", mas parece uma discussão que precisa acontecer.

Parece que você está chegando a uma encruzilhada com esse empregador. Se você pretende continuar sendo um programador e nada mais, pode ser necessário começar a recuar e solicitar que eles comecem a obter a ajuda necessária para tirar algumas das tarefas administrativas, trazendo alguém novo ou por expandir as responsabilidades de um colega de trabalho existente. ("Não foi para isso que você me contratou e essas tarefas não estão indo embora. O tempo que gasto mal fazendo essas coisas é tempo em que não estou gastando com o que sou bom.") Mas isso pode ou não não seja realista. Você acha que poderia lidar com a mudança para uma função mais gerencial se eles lhe dessem os recursos e a autoridade de que você precisaria para fazer o trabalho corretamente?

Quanto ao tamanho de um projeto antes de precisar de testadores, não sei como definir com precisão essa linha, mas definitivamente acho que você a atravessou. Você está gastando mais tempo do que gostaria de corrigir relatórios de erros provenientes de usuários reais; para mim, diz que é hora de gastar mais esforço para impedir que os bugs cheguem aos usuários em primeiro lugar.

Sim. Se for necessário , você poderá testar seu código. (Não estou falando de testes de unidade, mas de aceitação e coisas assim.)

Não . Os testadores são melhores em testar do que você. E, como você ressalta, assim como a revisão, é muito difícil identificar seus próprios erros. Ter globos oculares extras terá um grande (bom) impacto na qualidade do seu programa.

Você tem muitas outras perguntas. Vou responder apenas uma:

Um programador deve refinar a especificação?

Sim! Você precisa implementar a especificação, para garantir que a especificação seja realmente implementável. Além disso, como programador - treinado em raciocínio claro, precisão e coisas do tipo - você pode ajudar as pessoas a descobrir o que realmente precisa ser feito e eliminar requisitos ambíguos ou logicamente defeituosos.

O que eles estão dizendo e a realidade são provavelmente duas coisas diferentes. Provavelmente, o raciocínio é:
"Por que tenho que pagar o salário de um testador quando posso apenas fazer o programador cumprir duas tarefas?"

Claro, eles não vão dizer isso e inventarão todo tipo de desculpas que considerem razoáveis. Eu posso pensar em várias refutações ao ponto deles, mas honestamente eles não vão ajudar. Eu já vi essa batalha repetidamente e eles mudarão de abordagem sempre que você desmerecer o raciocínio atual. Eventualmente, eles desistirão e o instruirão a fazê-lo de qualquer maneira, e você será rotulado de reclamante.

A melhor abordagem que posso pensar é tratá-la não do ponto de vista da qualidade, que a gerência nunca parece valorizar até que haja problemas, mas do ponto de vista do custo. Os testadores são, ou pelo menos são percebidos como, mais baratos que os programadores. Lembre-os de que, ao fazer a dupla tarefa, eles estão pagando um recurso pago mais alto (programador) para realizar o trabalho que poderia ser realizado por um recurso mais barato (testador). Portanto, eles não estão maximizando o valor que estão extraindo da sua habilidade de programação.

Essa abordagem tem a desvantagem de desmoronar se você estiver assalariado e eles não tiverem condições de fazer você trabalhar mais horas extras não remuneradas, mas vale a pena tentar.

O sistema em questão é grande, mas é desenvolvido exclusivamente por mim. Isso também fez com que algumas tarefas administrativas caíssem no meu colo, como definir horários e trabalhar com especificações.

Justo.

Esse tipo de tarefa deve ser de minha responsabilidade?

Em última análise, cabe a sua gerência decidir.

Eu me vejo estritamente como programador e nada mais.

Talvez você esteja no emprego errado então. Muitas pessoas gostam de receber a responsabilidade extra.

E se essas são minhas responsabilidades, até que ponto?

Se a gerência diz isso, sim.

Quando um projeto é tão grande que requer testadores?

Quando há muito outro trabalho que os desenvolvedores precisam fazer. Nesse ponto, a gerência precisa decidir se deseja empregar um testador dedicado ou correr o risco de poupar nos testes. (Por fim, os desenvolvedores só podem fazer muito.)

Há vantagens definidas em ter testadores dedicados, mas também há desvantagens ... além do custo de empregar pessoal extra.

Se um programador precisar refinar a especificação,

Se necessário, sim. De fato, se a especificação precisar ser refinada e não houver mais ninguém trabalhando nela, é provável que a falha ao fazer isso faça com que o projeto falhe.

se preocupar com o gerenciamento do projeto

Se necessário, sim.

ou até mesmo fornecer suporte ao cliente?

Se necessário, sim.

Parece-me que você está sobrecarregado e reagindo à pressão. Isto é um problema. Mas assumir a posição de que "não é seu trabalho fazer X, Y, Z" não vai ajudar. Um plano melhor é deixar claro que há muito o que você pode fazer e ressaltar que isso provavelmente fará com que os prazos sejam perdidos, a qualidade caia, o mau atendimento ao cliente e assim por diante. Mas faça o seu melhor de qualquer maneira ... sem prejudicar sua saúde, relacionamentos etc. no processo.

Temos testadores. Eu não gostaria de trabalhar sem eles. Embora eu escreva testes de unidade (usando TDD) e teste de integração automatizada para todo o meu código, os testadores ainda têm uma função muito valiosa.

1. Eles são altamente qualificados e têm habilidades diferentes para os programadores.
   1. Eles têm muita experiência e conhecimento sobre como fazer o teste de controle de qualidade e como verificar se o código produzido realmente corresponde à expectativa do usuário e ao comportamento real dos usuários.
   2. Eles experimentaram muitos erros e são muito bons em pensar em situações que podem quebrar o software.
   3. Eles tendem a ser cínicos e sistemáticos. Eu observei que os programadores geralmente são muito mais otimistas.
2. Eles fornecem feedback antecipado valioso sobre usabilidade. Por exemplo, ao criar uma API REST recentemente, as áreas que os testadores de controle de qualidade não conseguiam entender com facilidade eram uma boa indicação de áreas com as quais o usuário também não estaria satisfeito.
3. Eles testam no ambiente real, de fato, muitas configurações do hardware real, SO, etc.
4. Eles sabem como construir em grande escala, realistas, bancos de ensaio e realizar testes de desempenho, carga e estresse
5. Eles estão focados em impedir que lançamentos ruins saiam. Os programadores tendem a se concentrar em obter o código liberado. É quase como um programador liberar o código por padrão, mas um testador de controle de qualidade precisará de um motivo para liberá-lo (foi demonstrado que ele funciona!)

"se tivéssemos testadores, você não testaria seu próprio código"

" Se o seu carro tivesse cinto de segurança, você batia o tempo todo! "

Esse tipo de tarefa deve ser de minha responsabilidade? [...] E se essa é minha responsabilidade, até que ponto?

A resposta para isso é "depende". Pelo que entendi, seus empregadores vêem você como o "departamento de TI de um homem só". Se for esse o caso, sim, eles são (sua responsabilidade). Se você tem responsabilidades que você absolutamente odeia e deseja evitar, procure uma posição dentro de uma empresa com um departamento de TI maior.

Quando um projeto é tão grande que requer testadores?

Essa não é (completamente) uma pergunta correta a ser feita. É melhor perguntar "quando é que a qualidade do produto / imagem da empresa é tão importante que requer testadores?"

Caso um programador precise refinar a especificação, [...]

Sim definitivamente. Na maioria das vezes, há uma grande discrepância entre o que um desenvolvedor / implementador precisa e o que os clientes fornecem [como especificações].

Muitas vezes, cabe a você encontrar áreas cinzentas / não especificadas e fazer as perguntas certas, perceber e apontar requisitos tecnicamente impossíveis ou contraditórios e assim por diante (especialmente se você é o único desenvolvedor).

[...] se preocupar com o gerenciamento do projeto ou até mesmo fornecer suporte ao cliente?

Isso depende das responsabilidades que você aceitou quando assumiu o cargo. Por exemplo, algumas posições exigem que você direcione os clientes diretamente. Sendo todas as outras coisas iguais, tentarei evitar essas posições (mas depende de você, e você pode não ter muitas opções de trabalho).

Antes de mais nada, testar ou, melhor dizendo, Garantia de Qualidade, não se trata apenas de testar a funcionalidade clicando no aplicativo. Garantia de qualidade é sobre processos . Não apenas para testar o aplicativo para encontrar os erros, eles também precisam impedir que os desenvolvedores os cometam.

1. Especificação do produto + casos de uso
   Mesmo que todos saibam (ou pensem que sabem) qual é a funcionalidade do produto, ela deve ser anotada. Você não pode testar um aplicativo sem uma especificação clara. Uma especificação define o que é o comportamento correto e o que é um bug.
2. Testes de unidade, testes de integração
   Testes de componentes internos difíceis de testar por meio da interface do usuário, estados excepcionais de aplicativos. Esta é uma obrigação para todos os sistemas maiores. Ambos os tipos de testes também têm outra propriedade interessante - forçam você a passar por todas as partes do código novamente e você perceberá problemas de bugs / arquitetura que nunca viu antes.
3. Qualidade do código e padrões de codificação
   Uma das tarefas que o controle de qualidade deve fazer é medir a complexidade do código. Código de baixa complexidade reduz a possibilidade de erros (prevenção de bugs).
4. Revisões de código
   Quando um projeto atinge um determinado tamanho ou é usado por muitos usuários, as revisões de código são uma obrigação. Outro programador sempre encontra problemas de código / bugs que você perdeu. Às vezes, os programadores são cegos a erros óbvios em seu próprio código.
5. Documentação
   Documente seu código e sua arquitetura, ele ajudará você a perceber possíveis falhas (minha própria experiência).
6. O Testers
   Tester não é um macaco que apenas clica na interface do usuário. Um testador pega a especificação e os casos de uso e cria casos de teste. Então ele / ela os testa um por um. Se um erro for relatado pelos usuários finais, um caso de teste deverá ser adicionado para isso.

Um programador nunca deve criar a especificação (1). Você não está lá para decidir a funcionalidade. Geralmente eles precisam conversar com os usuários finais, criar desenhos gráficos etc. É uma tarefa demorada. Se um programador decide a funcionalidade, geralmente termina com "está tudo bem, mas você pode mudar tudo nesta janela amanhã?" "isto não é o que eu queria" "funciona, mas é difícil de usar" "está faltando a única funcionalidade que realmente precisamos".

O que um programador pode alcançar é 2, 3 e 5.

Você precisa de outro programador para 4. Qualquer empresa com um grande projeto de TI e apenas um desenvolvedor que conheça o sistema caminha em um terreno muito perigoso.

Se você não tiver tempo suficiente, nunca se preocupe em criar casos de teste (5). Uma pessoa dedicada geralmente é necessária, pois leva muito tempo. Sem casos de teste, o teste é apenas uma piada.