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

56

Somos uma equipe scrum de três desenvolvedores, um 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 esses testes e remover erros foi definido como um dos critérios para considerar um PBI (Product Backlog Item) como concluído.

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

Como solução, recomendamos que a empresa contrate um novo testador. Alguém que tenha um emprego estaria testando e testando apenas. Um testador profissional oficial.

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

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

    
por Saeed Neamati 20.08.2011 / 09:41
fonte

9 respostas

59

Ex ante: Parece haver muita confusão sobre o que é considerado como testar o que não é. Claro, todo desenvolvedor precisa testar seu código enquanto o cria, ele precisa verificar se funciona. Ele / ela não pode entregá-lo a um testador antes que ele / ela ache que está pronto e é bom o suficiente. Mas os desenvolvedores não veem tudo. Eles podem não reconhecer erros. Esses erros só podem ser encontrados mais tarde no ciclo de desenvolvimento quando um teste completo é realizado. A questão é se os desenvolvedores devem ou não realizar esse tipo de teste e, na minha humilde opinião, isso precisa ser analisado do ponto de vista do gerente de projeto:

Os desenvolvedores podem ser testadores, mas não devem ser testadores . Os desenvolvedores tendem, de forma não intencional / inconsciente, a evitar o uso do aplicativo de maneira a interrompê-lo. Isso é porque eles o escreveram e principalmente testaram da maneira que deveria ser usado.

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, muitas vezes, têm 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, além de ter um testador dedicado. Eu não permitiria que os desenvolvedores fizessem um teste cruzado de seus trabalhos quando eu pudesse fazê-lo melhor por um testador de baixo custo. Somente se o ciclo de feedback entre os desenvolvedores e os testadores se tornarem muito caros, os desenvolvedores fariam crosstest do código uns dos outros, mas, na minha experiência, isso raramente acontece e depende muito do processo.

Isso não significa que um desenvolvedor deva ser desleixado e deixar tudo para o testador. O software deve ser apoiado 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ê tem correção aqui, quebra problemas ou outros bugs que nenhum desenvolvedor poderia prever, tudo bem. Além disso, o teste de integração deve ser feito 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 deve contratar um .

Mas mais importante que o testador são os congelamentos / ramificações regulares. Não apresente nada que não tenha sido testado adequadamente. Quando você adiciona um recurso ou altera algo, tudo em volta dele precisa ser verificado novamente. Você só terá uma má reputação se sua empresa não. Não solte algo instável. Quando o cliente quiser ter o software até uma determinada data, pare de desenvolver cedo o suficiente e teste-o adequadamente para ter tempo suficiente para correções de bugs. Geralmente, é melhor recusar solicitações de recursos de última hora do que implementá-las mal ou liberar sem o teste adequado.

    
por 20.08.2011 / 10:01
fonte
42

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

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

Se você realmente não quiser contratar um testador, faça com que os desenvolvedores testem uns aos outros - ou seja, se A escreve o código e faz testes de unidade, faça B examinar esses testes e ver se há outras coisas poderia ser adicionado. E faça B tentar testar o código (como usuário) e reportar defeitos.

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

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

    
por 20.08.2011 / 10:12
fonte
11

O jornalista deve escrever corretamente? Quero dizer, é trabalho de corretores e editores encontrar todos os erros gramaticais.

No entanto, os jornalistas fornecem alguma verificação ortográfica por si mesmos. No entanto, o corrector é uma profissão separada e importante.

O mesmo acontece com desenvolvedores e testadores, exceto o fato de que o controle de qualidade é uma parte ainda mais importante do desenvolvimento. Mesmo se você é um bom desenvolvedor você apenas não tem tempo para testar exaustivamente todos os casos de teste, para cobrir todos os ambientes, navegadores, sistemas operacionais suportados pelo seu produto.

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

    
por 20.08.2011 / 11:03
fonte
9

Bem, tivemos dois desenvolvedores cruzando o teste depois que o primeiro fez algumas alterações em uma 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 aplicar o zoom para fazer alguma edição por meio de um botão "Editar". A lista original foi descartada e uma nova gridview foi inserida, com filtragem, agrupamento, classificação e todos os tipos de funcionalidades legais.

Os testes foram ótimos e eles enviaram as alterações para o cliente no dia seguinte. Duas semanas depois, o cliente liga e diz: "Nós realmente gostamos 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 pegou a caixa de seleção (para seleção) e o botão editar, e como os desenvolvedores sempre clicaram duas vezes para selecionar um item de qualquer maneira, nenhum deles encontrou nada de 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.

    
por 20.08.2011 / 16:06
fonte
9

no matter how much we (3 developers and 1 designer) try to test the application and implemented use cases, still some bugs are not seen and ruin our presentation... to stakeholders.

Considere executar uma "execução controlada" para uma sprint ou duas, rastreando os esforços de desenvolvimento e teste separadamente. No final dessa execução, analise os dados coletados para descobrir quanto esforço você gasta nos testes.

Se você descobrir que o teste exige muito esforço, passe os dados para o gerenciamento - isso será uma evidência convincente de que você está apoiando sua solicitação (muito mais atraente do que a que você tem agora).

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

...we recommended that the company hire a new tester. Someone who's job would be testing, and testing only. An official professional tester.

However, the problem is that, scrum master and stakeholders believe that a developer (or a designer) should also be a tester.

Tenho que admitir, a gestão da sua empresa parece bastante idiota para mim. 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 - realmente engraçado que eles hesitam experimentá-lo, enquanto se afirmam scrum / < híf="http://www.halfarsedagilemanifesto.org/"> ágil .

    
por 21.08.2011 / 13:15
fonte
4

Como outros aqui disseram, os desenvolvedores podem fazer um teste cruzado do código dos outros (teste unitário ou funcional), e talvez o seu scrum master e product owner possam ajudar nos testes de integração. estão obtendo muito feedback dos testes do cliente - o que significa implantações frequentes com as quais os usuários reais podem trabalhar canal realmente aberto de comunicações .

    
por 21.08.2011 / 20:12
fonte
2

Você deve projetar com a capacidade de teste em mente, mas se você não tiver um testador dedicado, algumas coisas simplesmente ficarão escorregadias porque não há horas suficientes no dia para projetar, implementar e testar software.

    
por 21.08.2011 / 09:07
fonte
1

O software de teste é um trabalho profissional em tempo integral. Ele 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, não importa quão inteligente seja, pode chegar perto de um testador profissional quando o teste é apenas um pequeno componente de seu trabalho diário.

Além disso, vem o problema que subconscientemente o desenvolvedor de software não quer para encontrar bugs.

    
por 28.05.2015 / 17:52
fonte
1

Eu concordaria com o argumento deles de que os desenvolvedores / designers deveriam testar seu código, com o cavaet que o designer / desenvolvedor que fez uma seção de código não seria 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 infiltra no teste e reteste seu próprio código durante o desenvolvimento.

A partir da menção de caso de uso, assumirei que você também está usando ferramentas de cobertura de código? Caso contrário, pode ajudar a ver qual código pode não ser testado e pode estar causando falhas inesperadas em determinadas condições.

Assim, se houver trabalho suficiente ou sua organização for de tamanho decente, eu concordaria que uma pessoa de controle de qualidade profissional é necessária, ajudaria a focar um pouco mais os papéis de todos e também veria se havia algum padrão quanto ao que está sendo perdido e, mais importante, como consertá-lo.

    
por 21.08.2011 / 06:18
fonte

Tags