Como incentivar o cliente a fazer alguns testes de QA em casa?

14

Atualização / Esclarecimento Meu cliente entende a necessidade de seus testes internos e ele / ela sempre jura que vai "fazer melhor" (ou seja, fazer alguma coisa), mas simplesmente não acontece. Eles não têm orçamento para testes externos. Eu acho que estou perguntando (vagamente, eu reconheço) sobre o que poderia incutir um teste "testando cedo, testando com frequência, sobre o ethos das máquinas-alvo".

Pergunta: como incentivar os usuários a testar e relatar problemas explicitamente com novos lançamentos, e não "testá-los enquanto estão" em projetos de produção.

Contexto: Tenho um pequeno cliente para quem escrevi um conjunto de ferramentas de apresentação multimídia. Eles são um bom cliente e temos um bom relacionamento. O projeto está em andamento, adicionando recursos à medida que avançamos.

Há dois problemas que tenho:

  1. A definição de recursos é feita imediatamente, geralmente por telefone, sujeita a alterações, revisão e reversão. (um pouco como o de Kennedy: "Vamos para a lua e fazemos as outras coisas" - sempre me diverti com a parte "outras coisas" disso)

  2. Praticamente, nenhum teste de QA é feito do seu jeito.

Eu posso lidar com o # 1, mais ou menos. Este não é um cliente que leria uma especificação antes de uma reunião, quanto mais escrever uma. Estou acostumado com isso. É o item # 2 com o qual tenho o problema: eles não testam ou não testam novos lançamentos. O que eles fazem é usá-los para produção, então, quando os bugs aparecem, eles encontram uma solução alternativa e não informam, ou estão com tanta pressa para começar o projeto, que os relatórios de bug são vagos.

Tivemos muitas discussões sobre tudo isso, mas só consegui empurrá-los um pouco (por exemplo, usamos o github para rastreamento de problemas - embora eu use principalmente). As razões principais são duas: elas são uma pequena empresa de consultoria e não têm (ou não acham que têm) os recursos para testes (nem o orçamento para terceirizar). E cultural: embora eles se considerem "desenvolvedores", eles são apenas usuários de um pacote de software multimídia. (por exemplo, eles não têm nenhuma das obsessivas neurose atenção aos detalhes dos desenvolvedores "reais").

Isso me afeta como você esperaria: sem feedback, não sei dizer se um recurso está completo (veja o item 1) ou se há outras consequências. Também está me deixando um pouco preguiçosa.

    
por No Grabbing 10.12.2015 / 20:41
fonte

4 respostas

18

they have none of the obsessive neurosis attention to detail of "real" developers

Prefácio : O tipo de linguagem que você usa aqui é tipicamente uma bandeira vermelha para mim. Quando ouço as pessoas falarem sobre desenvolvedores "reais" ou o (um e único) jeito "certo" de fazer as coisas, eu começo a pensar em tunnel visionned desenvolvedores de cultos de carga .

Agora, eu não estou dizendo que você é definitivamente um desses desenvolvedores (eu não tenho provas suficientes para afirmar isso), mas se você é, então você pode se beneficiar desta resposta.

Resposta

Parece que você e seu cliente estão otimizando para coisas diferentes. É um fato lamentável na engenharia de software que muitas vezes as necessidades do negócio e os desejos dos desenvolvedores não se alinham necessariamente.

Desenvolvedores de software geralmente são pessoas apaixonadas com foco em aprimoramento. Eles gostam de melhorar o desempenho do software, o processo de desenvolvimento, os processos de negócios, os métodos de comunicação, etc. E isso é ótimo. Concentrar-se nessas coisas é o que separa os artesãos e as artesãs dos inestéticos keypushers.

Mas seu cliente não é um artesão de software. Seu cliente é um negócio com um conjunto de prioridades completamente diferente. E, às vezes, essas prioridades parecem ridículas para nós, artesãos de software ... mas isso é apenas porque estamos otimizando para coisas diferentes.

Frequentemente, os negócios desejam otimizar itens como lançamento antecipado no mercado e economias de custo de curto prazo. Ao fazê-lo, eles podem precisar sacrificar coisas como controle de qualidade, experiência do usuário, redução de custos a longo prazo e outras coisas que fazem os desenvolvedores funcionarem.

Isso é uma coisa ruim? Bem, não necessariamente. Eu não posso falar por todas as empresas, mas na minha experiência, meus clientes fazem essas coisas para aumentar seu próprio ROI (retorno sobre o investimento). Fazer coisas como QA, refinamento de UX e planejamento a longo prazo oferecem um ROI mais baixo. Pior ainda, muitas empresas têm estruturas de investimento que apenas recompensam as vitórias de curto prazo, em oposição a abordagens sustentáveis e ganhos de longo prazo.

Então, enquanto você poderia tentar vender a idéia de QA ao seu cliente, você pode estar desperdiçando seu tempo e forçando seu relacionamento com eles. Na melhor das hipóteses, você terá alguém ansioso para experimentar suas ideias (improvável). Na pior das hipóteses, você terá que convencer toda a empresa a refazer suas estruturas de incentivo para que os investimentos de longo prazo, como o controle de qualidade, sejam recompensados. Em ambos os casos, suas chances de sucesso são baixas.

    
por 10.12.2015 / 22:11
fonte
10

A pergunta interessante é quando você é pago, não se seu cliente faz algum teste próprio.

  • se você receber o pagamento com base no seu tempo, sem problemas.
  • se você for pago antecipadamente, não há problema.
  • se você receber o pagamento quando o cliente declarar que o projeto "acabou", um grande problema.

O problema é como você pode saber quando o cliente aceita o software e pagará a você. Isso claramente não funciona quando o cliente altera continuamente o projeto com novas solicitações vagamente definidas. Se isso significa que o dia de pagamento é sempre diferido - e se torna mais improvável por cada solicitação - isso se torna insustentável para você.

Um contrato fixo que especifica cuidadosamente todos os recursos e define sob quais condições o cliente aceitará esses recursos é claramente muito desconfortável, mas permite que você planeje o projeto com antecedência (também o próximo projeto). Também garante que você receberá seu dinheiro para o software que entregou, se ele corresponder à especificação. Nesse cenário, a única responsabilidade de um cliente é durante a fase de definição do contrato e, no final, para o teste de aceitação .

Esse teste de aceitação feito por um cliente é separado de outras formas de teste:

  • testes unitários
  • testes de integração do sistema
  • testes de usabilidade
  • testes de carga
  • testes de pré-lançamento

Na medida do possível, você anteciparia os testes de aceitação e os executaria antes de fornecer a funcionalidade, a fim de evitar constrangimentos. Além dos testes de aceitação (que medem apenas cumprimento do contrato , não qualidade do software ), toda a Garantia da Qualidade é de sua responsabilidade. Em particular, seu cliente não tem necessariamente uma mentalidade de QA, o conhecimento técnico necessário ou a obrigação contratual de fazer QA. Além disso, acho que terceirizar a caça aos bugs para o cliente não é profissional.

Isso não quer dizer que os erros não aconteçam. Supondo que você tenha um relacionamento baseado em projeto para seu cliente, você desejará seguir uma linha entre ser gentil e fornecer rapidamente correções e explicar que aceitou o release atual como suficiente para suas necessidades - grandes mudanças exigem um novo contrato. Se você tiver um contrato de suporte contínuo, você certamente terá que manter o nível de serviço acordado.

Em um ambiente ágil, a resposta às necessidades do cliente é mais valorizada do que cumprir a letra do contrato, mas você ainda deseja receber o pagamento. Portanto, muitas metodologias de projeto orientadas para o ágile valorizam a interação próxima com o cliente, a ponto de o cliente poder se tornar parte da equipe. Você poderia, então, sempre falar com esse “product owner” para esclarecer quaisquer pontos necessários. Como o PO tem a autoridade de conceder a você o tempo necessário para trabalhar em qualquer recurso que eles considerem valioso, isso pode funcionar mesmo quando se inicia com necessidades vagas do cliente. Se você não tem uma comunicação tão próxima, precisará seguir uma abordagem mais formal.

  • Quando você souber das novas necessidades do cliente, trabalhe com o cliente para traduzi-lo em requisitos. Isso ajuda o cliente a obter o que realmente deseja.
  • Os requisitos são objetivamente mensuráveis - eles são cumpridos ou não. Isso salva o cliente de meias soluções que só funcionam.
  • Todas as solicitações de clientes devem ser fornecidas por escrito para que você possa faturá-las. Isso os protege de serem cobrados por coisas que você gostaria de trabalhar - como reescrever toda a interface ao pedir que um botão seja alinhado de forma diferente.

    Muita comunicação pode ser feita pessoalmente ou por telefone, mas no final você vai querer que um pedaço de papel documente que o cliente queria que você trabalhasse com esses requisitos. Em casos simples, pode ser suficiente recapitular uma chamada telefônica e enviar um e-mail para verificar o que eles pediram para você fazer.

Relatórios de bugs são sempre difíceis. Se seus clientes são desenvolvedores que devem ajudar, pois eles podem entender suas necessidades: ter passos claros para se reproduzir. Uma maneira simples de obter uma visão poderosa é ativar o registro no software implantado. Desde que os problemas de privacidade de dados possam ser resolvidos, exigir que cada relatório de bug tenha o log atual anexado não apenas garante alguma comunicação por escrito, mas também informa o que o usuário realmente fez (em contraste com o que eles pensavam estar tentando fazer) .

    
por 10.12.2015 / 22:18
fonte
2

A maneira de incentivar a comunicação de bugs é incentivar a comunicação freqüente e granular de recursos. Se você treinar uma empresa em que eles possam pedir qualquer coisa com a cerimônia zero, eles também usarão esse recurso para pequenos bugs. Desista de mudar para o fluxo de trabalho do seu cliente, a menos que essas alterações facilitem sua vida.

Fazer com que seu cliente faça testes internos é difícil, mas fazer com que eles relatem bugs não é tão difícil quanto parece. A maneira de obter mais feedback é reduzir o atrito do usuário ... mesmo que isso signifique transferir parte desse atrito para você mesmo.

  1. Use ferramentas mais simples, mesmo que essas ferramentas sejam inadequadas e inadequadas. Por exemplo, o BaseCamp é um rastreador de bugs muito ruim (porque é destinado ao gerenciamento de projetos), mas as pessoas estão realmente dispostas a usá-lo.

  2. Como os rastreadores de bugs que estávamos usando não eram compatíveis com copiar e colar imagens, eu escrevi um programa trivial que copia a imagem atual da área de transferência para o disco (como um Guid) e copia o Guid para a área de transferência. Após um treinamento mínimo, um usuário pode anexar imagens da área de transferência a problemas simplesmente pressionando a tela de impressão, clicando em um botão e colando na caixa de diálogo de seleção de bugs.

Uma captura de tela (possivelmente editada no MS Paint com anotações) e de 1 a 2 sentenças é suficiente para identificar a maioria dos recursos / bugs.

Ambas as sugestões têm como alvo os pontos de atrito que I tiveram, e ambas as sugestões aumentaram os relatórios por um fator de mais de 10. No entanto, você precisará direcionar seus próprios pontos de atrito. / p>     

por 11.12.2015 / 13:56
fonte
1

Torne o teste para seu cliente fácil, mas torne realmente difícil para seu cliente usar novos recursos em uma versão não testada em produção. Isso pode ser feito da seguinte maneira:

Sempre que você fornecer um novo recurso, implemente-o primeiro em uma "versão beta", claramente marcada com um sinal "não para produção". Você disponibiliza esta versão beta para o cliente para teste. Você também fornece a última "versão de produção" que ele usará para produção real (sem os novos recursos, mas com as últimas correções), e você se recusa a transferir os novos recursos beta para a versão de produção até receber um feedback o lado dos clientes, pelo menos, experimentou primeiro.

Se o cliente começar a usar a versão beta em seus dados reais de produção, embora mostre sempre uma mensagem grande "Não para uso em produção" sempre que iniciar o programa, você não poderá ajudá-lo, mas ao menos deixou claro que ele perde o trabalho de produção porque usou o beta para propósitos errados, o que é claramente culpa dele. Se o cliente não aprender com isso, você pode considerar desabilitar a capacidade do seu cliente de usar o "beta" em produção, desativando algumas funções cruciais, como salvar os resultados em disco no "beta", se necessário.

Fornecer um "beta" separado o forçará a estabelecer um controle de configuração / gerenciamento de configuração apropriado, para que você possa gerenciar uma ramificação de produção e uma ramificação de teste beta lado a lado, sem complicações. Mas como você está trabalhando com o Github, eu acho que você já usa algo como o GIT, o que torna esse tipo de gerenciamento muito simples.

    
por 11.12.2015 / 06:41
fonte