Os testadores devem aprovar lançamentos ou apenas reportar os testes?

20

Faz sentido dar autoridade de aprovação aos testadores? Uma equipe de teste

  1. Apenas teste recursos, problemas, etc., e simplesmente reporte com base na aprovação / reprovação, deixando a responsabilidade de outras pessoas agirem sobre esses resultados, ou
  2. Tem autoridade para suspender os lançamentos com base nesses resultados?

Em outras palavras, os testadores devem ser obrigados a assinar os lançamentos? A equipe de teste com a qual estou trabalhando acha que sim, e estamos tendo um problema com isso por causa do "escopo do teste" - a recusa em aprovar lançamentos às vezes é baseada em problemas explicitamente não abordados pelo release em questão.

testing release-management process Ernest Friedman-Hill
fonte
2
Reformule sua pergunta para que não seja uma enquete. Qual é o problema que você está tentando resolver?
M. Dudley
5
"deve" depende em grande parte da estrutura organizacional da empresa. Se eles são medidos com relação aos bugs encontrados na produção, a capacidade de realizar uma liberação de buggy é uma ferramenta essencial.
Excelente ponto, @MichaelT. Na minha organização, o teste é um papel e não uma descrição do trabalho, e a avaliação é mais ad-hoc e nem um pouco quantitativa. As implantações bem-sucedidas gerariam críticas positivas, mas os bugs na produção não seriam negativos específicos, assim como para qualquer outra pessoa da equipe.
Ernest Friedman-Hill
5
Se você tiver um problema em que os testadores se recusam a aprovar lançamentos com base em questões que não estão planejadas para serem tratadas, então você tem um problema de comunicação (eles não sabem que os problemas não estão planejados para serem resolvidos) ou um problema de pessoas (eles estão se tornando importantes; liberar é, em última análise, uma decisão comercial).
Jan Hudec 01/07/2013

Respostas:

27

Na maioria dos lugares em que trabalhei, o pessoal do controle de qualidade tem algum tipo de etapa de aprovação, mas não tem autoridade final se a liberação prosseguir ou não. A aprovação deles significa que eles concluíram os testes esperados pelo plano de lançamento, não que o lançamento seja perfeito.

Em última análise, controle de qualidade! = A empresa e a empresa precisam decidir se estão bem com a implantação do código no estado atual ou se o benefício supera a desvantagem ou o que for. Isso geralmente é feito por clientes ou partes interessadas imediatamente antes da implantação e geralmente é chamado de Aceitação do Usuário.

Se o seu controle de qualidade também for o seu grupo de Aceitação do usuário, é possível que eles tenham autoridade para definir seu candidato a liberação como inaceitável, mas se você estiver obtendo isso sobre problemas que estão fora do escopo do bugfix / iteration / sprint / change solicitar / o que quer que você dedique, o gerente de projetos ou as partes interessadas da linha de negócios precisam comparecer a Jesus com a equipe de controle de qualidade.

Não há problema em relatar defeitos preexistentes ou resultados não intencionais de novos requisitos, mas se estiver fora do escopo e não for desastroso, geralmente não será aceitável classificá-lo como um problema de bloqueio. Ele fica na lista de pendências para o proprietário do produto priorizar como todo o resto.

Conta
fonte
Quem decide se você convidará o cliente para executar um teste de aceitação na versão 1234 ou se não é bom o suficiente para o teste de aceitação?
Bart van Ingen Schenau
3
@BartvanIngenSchenau: O proprietário do produto / gerente de projeto precisa ter a última palavra sobre isso. Como os testes até mesmo a aceitação muitas vezes vai inchar, se necessário (quer recurso X agora mesmo que não pode obter Y para trabalhar com ele, ou você quer esperar mais 2 meses até que corrigi-lo?) E o proprietário do produto está negociando isso.
Jan Hudec 01/07
além do que Jan disse, em muitas metodologias haveria cronograma ou cadência aqui. algumas pessoas implantam todos os candidatos que sobreviverem ao teste inicial de fumaça no UAT, outras implementam automaticamente qualquer coisa verificada no ramo candidato, outras tudo que é verificado como principal. idealmente, você tem mostrado o progresso das partes interessadas à medida que avança, de modo que não haverá muita surpresa no final. em alguns desses casos, você acaba mostrando às partes interessadas o que o pessoal do controle de qualidade tem feito com você através dos carvões e eles apenas dizem "quem se importa" e acabou.
Bill
No SaaS moderno com implantação contínua, o ciclo de implantação do código (serviço) pode ser separado do ciclo de lançamento do recurso (comercial). Este ciclo de liberação de recursos pode ser implementado usando sinalizadores ou alternâncias de recursos, por exemplo, de alfa (interno) a beta (opção de inclusão) e disponibilidade geral. Essa é uma maneira de envolver a aprovação formal de negócios, separada e independentemente da capacidade de implantação de códigos ou serviços específicos. O contrário, vincular as liberações de recursos às implantações de serviço, introduz acoplamentos e riscos no processo que pode ser evitado com a técnica de sinalização de recursos.
Será
@ Eu não discordo, mas alguém ainda está julgando se esses recursos ocultos estão ocultos o suficiente para não serem notados por outros usuários que não a equipe beta na implantação inicial e, finalmente, em qualquer lugar que eu tenha usado para abordar a sequência mais ou menos o mesmo, mas com rótulos diferentes nas partes móveis e o risco mudou um pouco. Prefiro a situação que você descreve, mas a equipe de controle de qualidade que encontra algo preexistente ou o gerente de produto que decide prosseguir de qualquer maneira é algo tão importante neste modelo quanto qualquer outro em minhas experiências.
Bill
6

Alguém precisa dessa autoridade . Seja um testador, a equipe de testadores, o líder da equipe de testadores ou o líder da organização de desenvolvimento é um tanto irrelevante. Ou talvez com mais precisão, isso depende da organização.

Por fim, a opção de liberar software é uma função comercial. A empresa precisa decidir se a qualidade é apropriada. Indiscutivelmente, o diretor de garantia da qualidade deve tomar essa decisão ou alimentá-la com a unidade de negócios apropriada. Tudo depende do tamanho da empresa, da importância relativa da qualidade etc.

Tudo isso dito, as informações usadas para tomar a decisão começam com o testador . Se eles têm o poder de interromper uma liberação ou não, eles devem sentir a responsabilidade de informar os tomadores de decisão quando virem algo que eles acham que deve causar um atraso na liberação.

Bryan Oakley
fonte
6

Conceder autoridade de aprovação (ou seja, um direito de veto) para liberações aos testadores faz tanto sentido quanto conceder esse direito aos desenvolvedores: nenhum.

Os testadores e desenvolvedores são principalmente pessoas técnicas, portanto é provável que tomem suas decisões principalmente por motivos técnicos. Porém, as preocupações que precisam ser ponderadas ao fazer um lançamento são preocupações técnicas e comerciais. Obviamente, o cliente não ficará satisfeito se você entregar um produto cheio de erros, mas o cliente ficará igualmente infeliz se você continuar adiando um lançamento, porque ainda existem problemas em aberto no produto.

Alguém precisa encontrar o equilíbrio certo entre um bom produto e manter o cronograma prometido ao cliente. Para fazer isso, você não deve se envolver no projeto em uma função puramente técnica, mas em uma função mais orientada para negócios / gerenciamento, como gerente de projeto ou proprietário do produto e receber sua opinião dos testadores e desenvolvedores.

Bart van Ingen Schenau
fonte
1
Votei a favor, porque discordo fundamentalmente de vários pontos e suposições que você está fazendo. Não concordo que o controle de qualidade não deva ter autoridade para vetar uma liberação porque muitos grupos de controle de qualidade também operam também na função de aceitação do usuário. Além disso, eu discordo da suposição de que os testadores são pessoas técnicas. Nem sempre é o caso, nem todos os grupos que lançam software podem pagar uma equipe de controle de qualidade completa, de modo que esse papel pode recair sobre os analistas de negócios que podem não ser técnicos.
Maple_shaft
1
além do argumento de maple_shaft, vejo frequentemente a chamada final desta esquerda para quem estiver no papel de cliente, a menos que haja algo terrível identificado. em última análise, é a entrega deles e é mais provável que eles tenham o ponto de vista correto quanto ao risco, desde que você forneça informações precisas.
Bill
5

A decisão de 'liberar' ou 'não liberar' é no final do dia uma decisão de negócios, onde uma análise rigorosa de risco / recompensa precisa ser realizada.

É uma loucura para qualquer organização pedir à equipe de teste que assuma essa responsabilidade ou que a equipe de teste concorde com essa responsabilidade.

O papel da equipe de teste é fornecer uma análise da qualidade do software, sua prontidão para ser liberada e quaisquer riscos identificados como uma entrada para a decisão comercial de liberar ou não liberar.

Como outros observaram, alguém (e eu acredito que seja um indivíduo) precisa da autoridade para tomar a decisão de "liberação" ou "não liberação". Essa mesma pessoa pode ter delegado essa decisão sob condições específicas (ou seja, sem erros P1 ou P2)

Jordânia
fonte
3

Eu trabalhei com a mesma situação de testadores que alcançam e inventam maneiras cada vez mais criativas de quebrar um sistema que, quando avaliado pelo risco, é incrivelmente improvável que aconteça na produção.

Embora eu entenda e parabenize a equipe de teste por não querer enviar uma versão imperfeita, ela exige uma forte propriedade do produto para definir o que é um "risco aceitável".

Na minha experiência, a equipe de teste deve ter um veto na liberação de software, mas esse veto deve ser anulado pelo proprietário do produto, mas somente após discussão com os testadores principais.

O software nunca será perfeito; se você estiver sofrendo com a fluência do teste, nunca conseguirá liberar nada até que haja um grande problema de produção (que não será testado corretamente) e apressado.

Michael
fonte
1
Esse é um problema real, mas não tenho certeza se esse é necessariamente o problema do OP. Minha interpretação é que, de alguma forma, os testadores estão interpretando novos requisitos que não foram originalmente definidos.
Maple_shaft
2
minha experiência com equipes de teste me levou a cair do outro lado disso. Para mim, o controle de qualidade não deve ter nenhuma expectativa de poder bloquear uma implantação sem apresentar seu caso ao resto da equipe ou fazer com que o proprietário substitua a equipe.
Bill
1
É verdade - eu provavelmente não fui suficientemente explícito, os mesmos problemas ocorrem quando os testadores levantam defeitos, e cito "no cerne da história", o que leva aos mesmos problemas - nada é liberado.
Michael Michael
No meu caso, é mais a interpretação do @maple_shaft; não sendo tão desonesto em encontrar maneiras de quebrar o software, como relatando falhas no tratamento de casos explicitamente não suportados.
Ernest Friedman-Hill
1
@ ErnestFriedman-Hill Parece que você está descrevendo Requisitos Negativos e é isso que falta nos documentos de requisitos funcionais. Um requisito negativo é uma declaração explícita sobre o que um sistema NÃO fará e pode ser tão aceitável quanto os requisitos regulares. Se estes forem declarados, seus casos de teste contra Requisitos Negativos não serão válidos.
Maple_shaft