Get best of the week

Livro "Como testar no Google" - versão eletrônica gratuita

imagemOlá, habrozhiteli!

O livro descreve o teste de produtos de software no Google: como os processos são organizados, como as equipes são organizadas, quais técnicas são usadas, quem é responsável pela qualidade. Os princípios nos quais o teste do Google se baseia aplicam-se a projetos e empresas de qualquer tamanho. Os próprios autores do livro trabalharam nos produtos do Google, criando ferramentas de teste, personalizando processos e realizando testes diretamente.

O livro é destinado a profissionais da indústria de desenvolvimento de software: especialistas em teste, programadores, gerentes.

Excerto. Redução de risco


Raramente é possível eliminar completamente os riscos. Dirigimos um carro, embora isso seja perigoso, mas precisamos começar a trabalhar? Em geral, a possibilidade de um acidente não significa que isso aconteça e, provavelmente, nada de terrível acontecerá. Por quê? Porque, por nossas ações, reduzimos o risco possível. Por exemplo, não dirigimos embriagados e não dirigimos em condições de visibilidade insuficiente. Assim, reduzimos riscos.

No desenvolvimento de produtos de software, a coisa mais simples é evitar áreas de risco: quanto menos código, menos risco. Mas, além de usar o "machado e machado", podemos fazer muito mais para reduzir os riscos:

  • , , .
  • -, , .
  • , .
  • .
  • , . , .

A solução específica depende das características da aplicação, das expectativas do usuário em relação à sua segurança e confiabilidade. Como testadores, é claro que podemos estar envolvidos no processo de redução de riscos, mas certamente estamos envolvidos no processo de identificá-los. Começamos priorizando os recursos marcados em vermelho na tabela. Queremos testar para reduzir riscos. Isso é importante: se você não pode testar tudo, primeiro teste o mais importante. E o mais importante é que está mais exposto aos riscos mais graves.

Em alguns projetos, são os testadores que perguntam sobre a disponibilidade do produto para lançamento. Basta que um bom testador olhe para o mapa de calor para determinar se ainda vale a pena guardar o produto no forno ou se é hora de servi-lo na mesa. Se estamos falando sobre o lançamento de um Google Labs experimental, a presença de zonas de risco vermelhas não é tão significativa, se não estiver relacionada à segurança, é claro. E se esse for o lançamento de uma nova versão do Gmail, mesmo as zonas amarelas são um sério perigo. Uma gradação de cores tão simples é clara para todos, até para os principais gerentes.

As preocupações com os riscos diminuem com o tempo e o grande volume de testes bem-sucedidos é um bom sinal de que os riscos estão em um nível aceitável. Aqui nos beneficiamos de vincular casos de teste a recursos individuais de produtos e, em seguida, a atributos e componentes na tabela de riscos. A "análise ACC" é ideal para este caso, e é por isso que criamos essa ferramenta exatamente assim.

Plano de teste de prescrição de James Whittaker em dez minutos


, , . , , — ? , , . Google, , -. , , : «», « » — « » ( ). ’, , - , .

— . -, , — , , ( ), , , . : , ,
?

- , , , . , — . : ?

- , - . . : -.

, : - . - , .

, . : . , , .
-, .

. : « , - ». , , . , , , , .

, , , (Google Docs, App Engine, Talk Video . .), .

, ACC-. , . — , — . , . - — . , , .

’, - . . ,
- .

, . , . 80% . ? , , ? , (, , ) . , , .

. -!


O Google Test Analytics toma como base os critérios de avaliação de risco descritos acima ("muito raro", "raramente", "às vezes", "frequentemente"). Especificamente, não queremos transformar a análise de risco em uma tarefa difícil, caso contrário ela não será concluída. Não estamos interessados ​​nos detalhes matemáticos exatos, porque os números significam pouco. É suficiente saber que "A" é mais arriscado que "B", não prestando atenção à importância exata dos riscos. O simples conhecimento de qual oportunidade é mais arriscada que outra permitirá que o gerente de teste distribua com mais eficiência o trabalho dos testadores. E pessoas como Patrick Copeland podem facilmente decidir quantos testadores atribuir a cada equipe de desenvolvimento. A compreensão dos riscos beneficia toda a empresa.

A análise de risco é um campo científico independente, respeitado em muitos setores. Usamos uma versão simplificada da metodologia, mas isso não nos impede de nos interessar por novas pesquisas, a fim de melhorar nossa abordagem aos testes. Se você quiser saber mais sobre a análise de riscos, comece com o artigo "Gerenciamento de riscos" na Wikipedia.

O GTA ajuda a identificar riscos e os testes ajudam a reduzi-los. O testador serve como intermediário nesse processo. Ele pode executar testes internos em algumas das áreas mais arriscadas ou desenvolver tarefas e desenvolvedores em testes para que eles adicionem testes de regressão. Existem outras ferramentas em seu arsenal: pesquisar testes, atrair usuários internos e beta e a força da comunidade externa.

É de responsabilidade do testador conhecer todas as áreas em risco. Ele deve tentar reduzir os riscos da maneira que estiver sujeita a ele. Aqui estão algumas recomendações que consideramos úteis para lidar com riscos.

  1. Para os recursos mais arriscados e os pares atributo / componente marcados em vermelho, escreva um conjunto de histórias de usuários, casos de uso ou um guia de teste. No Google, a responsabilidade pelas oportunidades mais arriscadas é do testador. Ele pode coordenar seu trabalho com colegas, usar ferramentas diferentes, mas a responsabilidade pessoal ainda é dele.
  2. , . , GTA? ? ? . , , .
  3. , / , , . .
  4. — . , . , . , : «!», . , .
  5. , . , , . , « ?» « ?». Google , , .
  6. 6 , , , . ! .




, . , , , .

, , - . - , , , . , , . , , .

, , . -, - — !

— . - . — . Google , . -: Google Documents — , .

, , , . — .

Não teremos muito problema com oportunidades de baixo risco. Podemos decidir que escrever casos de teste para essas áreas é muito caro. Em vez disso, podemos limitar-nos a testes de pesquisa ou a crowdsource. Para gerenciar o trabalho dos testadores da comunidade externa, geralmente usamos o conceito de tours - estas são instruções de alto nível para testes de pesquisa. Simplificando, essa abordagem fornece ao seu pedido os detalhes necessários. Por exemplo, perguntando à comunidade: “Passe um tour pela FedEx por esse conjunto de recursos” - obteremos um resultado muito melhor do que simplesmente dar o aplicativo e esperar o melhor. Determinamos imediatamente os recursos que precisam ser testados e fornecemos instruções sobre como fazer isso.

Crowdsourcing




— . , , - ! , . . ?

, , . , , — , , -. , Chromium, . , , . , .

( ) — . , , . , , ? — .

, , , . , : -1000 , : Chrome, : 1 = 1000 20 = 50 . .

, , , . , , . Chrome, , , ( « Chrome»). . , . « , » , .

- — Google: , , . , . , , , (, uTest). .

Portanto, a força da análise do ACC é que obtemos uma lista de recursos do produto que podem ser classificados por risco e atribuídos a diferentes artistas. Os testadores que trabalham no mesmo projeto podem receber conjuntos diferentes de recursos de teste. Usuários internos, participantes de "vinte por cento", testadores, testadores da comunidade, desenvolvedores, desenvolvedores em testes receberão suas listas de recursos e, para a alegria do testador, áreas importantes serão cobertas com menos sobreposições do que se simplesmente entregássemos o aplicativo para testando para todos.

O trabalho do testador, diferentemente do trabalho do desenvolvedor no teste, não termina com a entrada do produto.

» Baixe epub e pdf

More articles:


All Articles