Um desenvolvedor também deve atuar como testador? [fechadas]


60

Somos uma equipe de scrum de 3 desenvolvedores, 1 designer, o scrum master e o proprietário do produto. No entanto, não temos testador oficial em nossa equipe. Um problema que está sempre conosco é que, testar o aplicativo e passar nesses testes e remover bugs foi definido como um dos critérios para considerar um PBI (Produto Backlog Item) como concluído.

Mas o problema é que, não importa o quanto nós (3 desenvolvedores e 1 designer) tentemos testar o aplicativo e implementamos casos de uso, ainda assim alguns bugs não são vistos e arruinam nossa apresentação ( lei de Murphy ) às partes interessadas.

Como solução, recomendamos que a empresa contrate um novo testador. Alguém que trabalhava apenas com testes. Um testador profissional oficial.

No entanto, o problema é que, o scrum master e as partes interessadas acreditam que um desenvolvedor (ou designer) também deve ser um testador.

Eles estão certos? Devemos desenvolvedores (também designers) também testadores?


11
Possível duplicata de programmers.stackexchange.com/questions/100637/… , embora essa seja solicitada do ponto de vista oposto.
Adam Lear

Na equipe de scrum da qual participei, todos estavam testando o aplicativo para smartphone ou tablet e todos foram uma grande ajuda.
22--13

Os escritores precisam de um editor.
JeffO 12/02/2015

Respostas:


59

Ex ante: Parece haver muita confusão sobre o que é considerado como teste do que não é. Certamente, todo desenvolvedor precisa testar seu código à medida que o cria, precisa verificar se funciona. Ela / ele não pode entregá-lo a um testador antes que ele / ela pense que está feito e bom o suficiente. Mas os desenvolvedores não veem tudo. Eles podem não reconhecer erros. Esses erros só podem ser encontrados posteriormente no ciclo de desenvolvimento quando testes completos são realizados. A questão é se os desenvolvedores devem realizar esse tipo de teste ou não e, na minha humilde opinião, isso precisa ser encarado do ponto de vista de um gerente de projeto:

Os desenvolvedores podem ser testadores, mas não devem ser testadores . Os desenvolvedores tendem a evitar, de maneira não intencional ou inconsciente, o uso do aplicativo de uma maneira que possa quebrá-lo. Isso porque eles escreveram e testam principalmente da maneira que deve ser usada.

Um bom testador, por outro lado, tenta torturar o aplicativo. Sua principal intenção é quebrá-lo. Eles costumam usar o aplicativo de maneiras que os desenvolvedores não imaginariam. Eles estão mais próximos dos usuários do que do desenvolvedor e costumam ter uma abordagem diferente para testar um fluxo de trabalho.

Além disso, o uso de desenvolvedores como testadores aumenta os custos de desenvolvimento e não beneficia a qualidade do produto, tanto quanto ter um testador dedicado. Eu não permitiria que os desenvolvedores testassem seus trabalhos quando eu pudesse fazê-lo melhor por um testador a baixo custo. Somente se o ciclo de feedback entre desenvolvedores e testadores se tornar muito caro, os desenvolvedores cruzarão o código um do outro, mas, na minha experiência, esse raramente é o caso e depende muito do processo.

Isso não significa que um desenvolvedor deve ser desleixado e deixar tudo para o testador. O software deve ser copiado por testes de unidade e os erros técnicos devem ser reduzidos ao mínimo antes de entregar o software ao testador. Ainda assim, às vezes você corrige aqui, interrompe problemas ou outros erros que nenhum desenvolvedor poderia prever, tudo bem. Além disso, o teste de integração deve ser realizado principalmente pelos desenvolvedores. O principal objetivo do testador é verificar se os requisitos foram atendidos.

Em uma equipe tão pequena (e também dependendo do tamanho do aplicativo), também posso ver o testador em uma função híbrida, escrevendo testes de unidade e testes de interface do usuário. Você definitivamente deveria contratar um .

Porém, mais importante que o testador são os congelamentos / ramificações regulares. Não apresente nada que não tenha sido testado corretamente. Quando você adiciona um recurso ou altera algo, tudo ao seu redor deve ser verificado novamente. Você só terá uma má reputação se sua empresa não. Não libere algo instável. Quando o cliente quiser ter o software em uma determinada data, pare de desenvolver cedo o suficiente e teste-o adequadamente, para que você tenha tempo suficiente para a correção de erros. Freqüentemente, é melhor recusar solicitações de recursos de última hora do que implementá-las mal ou liberá-las sem testes adequados.


9
Discordo veementemente e com veemência ... Os desenvolvedores podem ser testadores altamente eficazes, mas o desenvolvedor de um recurso NÃO deve também ser o testador do mesmo recurso. Muitas equipes pequenas desempenham os dois papéis, por três pessoas trabalhando em três recursos diferentes e depois entregando o teste a um dos outros três desenvolvedores. Funciona extremamente bem quando uma equipe não possui um testador de controle de qualidade.
maple_shaft

5
@ maple_shaft: Não há desculpa para não ter um testador. Qualquer projeto oferecerá maior qualidade com um testador dedicado e os desenvolvedores poderão se concentrar, desenvolvendo bem se houver um. Fazer com que os desenvolvedores testem o código uns dos outros é uma solução improvisada, mesmo para equipes pequenas. Você também deve ler o artigo de Joel .
Falcon

3
Os desenvolvedores podem ser testadores - e um bom desenvolvedor conhece muitos lugares onde o código pode ser fraco e sujeito a quebra. Apenas nunca as pessoas testam o código que criaram ou escreveram - isso é inútil. O código de outras pessoas pode estar ok.
StasM

4
@deadalnix: Isso realmente me intriga por que as pessoas votam sem sequer ler e entender minha resposta. Para me citar: "O software deve ser copiado por testes de unidade e os erros técnicos devem ser reduzidos ao mínimo antes de entregar o software ao testador".
Falcon

2
"Um bom testador, por outro lado, tenta torturar o aplicativo. Sua intenção principal é quebrá-lo." - Discordo completamente. Eu tenho um testador que tenta continuamente mascarar o teclado ou sobrecarregar os campos. Claro, esses são bugs, mas uma fatura de US $ 1 trilhão de trilhões que gera um erro é tão baixa na minha lista de tarefas que não é registrada. Um ótimo testador testa todos os cenários em que vários usuários usariam o aplicativo. Um bom desenvolvedor garante que todos os caminhos de código foram testados e que o aplicativo funcione quando usado como pretendido.
Paul

42

Os desenvolvedores podem ser testadores - do código de outros desenvolvedores.

Mas testar seu próprio código não é uma boa jogada - os desenvolvedores tendem a ter bloqueios mentais sobre seu próprio código e, portanto, têm dificuldade em projetar testes abrangentes ou adequados.

Sempre haverá desenvolvedores que pensam que fazem isso bem, mas geralmente não o fazem (e eu certamente sei que tenho muitos pontos cegos).

Se você REALMENTE CANTAR contratar um testador, peça aos desenvolvedores para fazer o teste cruzado entre si - isto é, se A escrever o código e realizar testes de unidade, faça com que B examine esses testes de unidade e veja se há outras coisas que podem ser adicionadas. . E peça a B para testar o código (como usuário) e relatar defeitos.

Isso não é perfeito, mas é melhor do que um único desenvolvedor tentando fazer tudo.

Às vezes, seus colegas podem ser realmente bons em interromper seu software, porque eles se divertem com isso e não se importam muito - porque não é o SEU código.


2
Ah sim, claro. Totalmente de acordo. É que, quando você não consegue 100% do que deseja, pode ter que se contentar com menos. Você sabe que menos não é tão bom, mas é melhor que nada.
quickly_now

4
Eu geralmente concordo com testes cruzados, mas em algumas equipes que apresentarão conflitos. Algumas pessoas gostam de culpar os outros ("minhas coisas funcionam, as suas não, lol, eu sou muito melhor que você") e isso é inaceitável. Eu testemunhei isso várias vezes. O teste cruzado deve ser feito apenas entre colegas que se respeitam. Na minha equipe, apresentei o desenvolvedor sem nome, responsável por todos os erros, para evitar que alguém perca a cara. Erros são sem nome, eles acontecem.
Falcon

5
Com +1, é impossível testar adequadamente seu próprio código. É incrível quais truques a mente pode usar em você - você terá 100% de certeza de que codificou e testou alguma função e será necessário que outra pessoa mostre a você que na verdade não funciona, exceto em casos muito estreitos e ser óbvio para você uma vez mostrado - mas você nunca o veria. A mente usa atalhos cognitivos e, ao testá-los, torna impossível para a pessoa que projetou e desenvolveu o código testá-lo adequadamente.
StasM

2
@StasM - concordei, com uma pequena qualificação: descobri que voltando ao meu próprio código meses depois, vejo as falhas e posso fazer um trabalho melhor ao testá-lo objetivamente. Mas teste você mesmo depois de escrever é realmente muito difícil.
quickly_now

11
@ Ben Aston: Um desenvolvedor ainda deve estar fazendo testes de unidade, testes de integração, etc. Apenas não exclusivamente. Os pontos cegos não desaparecem apenas porque você deseja.
quickly_now

11

O jornalista deve tender a escrever corretamente? Quero dizer, é tarefa dos corretores e editores encontrar todos os erros gramaticais.

No entanto, os jornalistas fornecem algum tipo de verificação ortográfica por si mesmos. No entanto, o corretor é uma profissão separada e importante.

O mesmo acontece com desenvolvedores e testadores, exceto pelo fato de o controle de qualidade ser parte ainda mais importante do desenvolvimento. Mesmo se você for um bom desenvolvedor, não terá tempo para testar minuciosamente todos os casos de teste, para abranger todos os ambientes, navegadores e SOs suportados pelo seu produto.

Se alguém, além de se desenvolver, constantemente fazendo esse trabalho também, significa apenas um fato simples - ele é um testador de meio período.


10

não importa o quanto nós (3 desenvolvedores e 1 designer) tentemos testar o aplicativo e implementar casos de uso, ainda assim alguns bugs não são vistos e arruinam nossa apresentação ... às partes interessadas.

Considere executar uma "execução controlada" para um sprint ou dois, rastreando os desenvolvedores e testando os esforços separadamente. No final dessa execução, analise os dados coletados para descobrir quanto esforço você gasta em testes.

Se você descobrir que o teste exige muito esforço, passe esses dados para o gerenciamento - eles serão uma evidência convincente de sua solicitação (muito mais convincente do que você tem agora).

Caso contrário (se você achar que o teste leva pouco tempo), considere investir um esforço adicional para melhorá-lo (ou aprender a fazer isso). Negocie o esforço adicional que você planeja com sua gerência - porque eles podem preferir contratar um testador. :)


... recomendamos que a empresa contrate um novo testador. Alguém que trabalhava apenas com testes. Um testador profissional oficial.

No entanto, o problema é que, o scrum master e as partes interessadas acreditam que um desenvolvedor (ou designer) também deve ser um testador.

Tenho que admitir, a administração da sua empresa me parece muito manca. Quero dizer - ok, pode ser realmente difícil descobrir quantos testadores seriam melhores para o projeto, tudo bem.

Mas ter pelo menos um testador é apenas uma aposta segura - é muito engraçado que eles hesitem em experimentá-lo, enquanto se dizem scrum / ágeis .


9

Bem, tivemos dois desenvolvedores que fizeram o teste cruzado após o primeiro fazer algumas alterações na tela de entrada. Foi quando nosso testador regular estava de licença maternidade.

Ele basicamente alterou uma tela de Listagem de faturas que os usuários usavam para selecionar faturas antes de aumentar o zoom para fazer algumas edições através do botão "Editar". A lista original foi descartada e um novo gridview foi inserido, com filtragem, agrupamento, classificação e todo tipo de funcionalidade interessante.

Os testes foram excelentes e eles enviaram as alterações para o cliente no dia seguinte. Duas semanas depois, o cliente telefona e diz: "Gostamos muito da novidade que você coloca, podemos ver todo tipo de informação agora. Mas ... er ..... onde vamos editar as faturas agora? ?? "

Acontece que o desenvolvedor retirou a caixa de seleção (para seleção) e o botão de edição e, como os desenvolvedores sempre clicaram duas vezes para selecionar um item de qualquer maneira, nenhum deles encontrou algo errado com ele ......

Desenvolvedores e usuários vivem em mundos diferentes, ter testes cruzados é melhor do que fazer com que o desenvolvedor teste seu próprio trabalho, mas ainda não é a mesma coisa.


3
Eu não diria "eles vivem em mundos diferentes", mas as pessoas têm hábitos e o código de um desenvolvedor funcionará se for usado por alguém com o mesmo hábito. Não sei contar quantas vezes não consegui reproduzir um bug encontrado por um testador, olhei por cima do ombro dele enquanto ele reproduzia o bug e disse "uau, eu nunca teria feito o que você acabou de fazer".
gnasher729

4

Como outros aqui disseram, os desenvolvedores podem fazer testes cruzados entre os códigos (testes unitários ou funcionais), e talvez o mestre do scrum e o proprietário do produto possam ajudar no teste de integração, mas, para o teste de aceitação do usuário, você deve garantir que está recebendo muito feedback dos testes do cliente - o que significa implantações frequentes com as quais eles podem trabalhar da maneira que os usuários reais fazem e um canal de comunicação realmente aberto .


2

Você deve projetar com a testabilidade em mente, mas se você não tiver um testador dedicado, algumas coisas simplesmente desaparecerão, pois não há horas suficientes no dia para projetar, implementar e testar software.


2

O teste de software é um trabalho profissional em período integral. Precisa de um bom cérebro, talento e muita experiência para se tornar um bom testador. É ridículo supor que um desenvolvedor de software, por mais inteligente que seja, possa se aproximar de um testador profissional quando o teste é apenas um pequeno componente de seu trabalho diário.

Além disso, surge o problema de que, inconscientemente, o desenvolvedor de software não deseja encontrar bugs.


1

Eu concordo com o argumento deles de que os desenvolvedores / designers devem testar seu código, com o objetivo de que o designer / desenvolvedor que fez uma seção de código não seja o único conjunto de "olhos" nesse código antes de se comprometer a viver. Enquanto isso não vai pegar tudo, pelo menos ajudará a evitar a cegueira que se aproxima ao testar e testar novamente seu próprio código durante o desenvolvimento.

Pela menção do caso de uso, assumirei que você também está usando ferramentas de cobertura de código? Caso contrário, isso poderia ajudar a ver qual código pode não ser testado e pode aparecer erros inesperados durante determinadas condições.

Dito isto, se houver trabalho suficiente ou se a sua organização for de tamanho decente, eu concordaria que uma pessoa profissional de controle de qualidade é necessária, ajudaria a focar um pouco mais as funções de todos, e eles também poderiam ver se há algum padrão quanto ao que está faltando e, mais importante, como corrigi-lo.

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.