(do ciclo da história do testador )Olá pessoal. Como você deve ter notado, a intensidade do lançamento de cursos no OTUS aumenta a cada mês, e em março existem especialmente muitos deles. Hoje queremos coincidir com o lançamento do curso
"Automação de testes na web" , que começa em meados de março. Boa leitura.
Ainda vejo muitos testadores que falam sobre o número de bugs e vulnerabilidades encontrados, como uma medida do sucesso dos testes. Recentemente, vi um ponto de vista diferente, que afirmava que a essência está na qualidade dos erros, mas não na quantidade. No entanto, com esta medida, também vale a pena ter cuidado. Agora vamos falar sobre isso.
A idéia principal é que o método de teste seja determinado pelo tipo de erro que você precisa encontrar.
Eu já falei sobre alguns aspectos do tópico de hoje no início da
conversa sobre caça de bugs . Não quero me repetir, então tentarei ser breve. Formalizarei minha tese de pensamentos e em relação à equipe em que trabalho.
O que é importante para mim no teste é o impacto nos usuários para que eles tomem as decisões corretas mais rapidamente. Para fazer isso, você deve usar um loop de feedback rígido para reduzir o tempo entre os desenvolvedores cometerem um erro e, posteriormente, corrigi-lo. Esses erros são áreas em que várias qualidades - comportamento, desempenho, segurança, usabilidade etc. - ausente ou piorada.
Definitivamente, isso não é medido pelo número de erros encontrados, mas a natureza do erro desempenha um papel. Minha tarefa é encontrar erros que mais ameaçam a integridade e a qualidade do desenvolvimento. Provavelmente, isso pode ser atribuído à "qualidade" dos erros, ou seja, esses erros são ainda mais importantes quanto mais ameaçam a integridade.
A chave para a correção eficaz de erros, na minha opinião, é encontrar esses erros o mais rápido possível, idealmente assim que eles aparecerem. Embora, do meu ponto de vista, até a "qualidade do erro" esteja longe de ser a medida mais alta.
Damos tanta importância à qualidade do erro, mas será que o número deles é geralmente insignificante?
De fato, o número de erros é importante se você estiver muito concentrado em reduzir a quantidade de tempo para procurá-los. Digamos que o sistema tenha 10 bugs críticos. E eu rapidamente encontrei dois deles, e é muito legal! Dois erros críticos foram encontrados antes da introdução do produto. Mas não encontrei outros antes da implantação. Isso significa que 8 erros críticos não foram encontrados. Nesse caso, o número de erros é uma medida fundamental, mesmo que não o tenhamos entendido naquele momento.
É importante pensar de uma maneira um pouco diferente. O número de erros ou a sua qualidade não são tão importantes quanto os mecanismos pelos quais ocorrem e, consequentemente, os mecanismos para sua busca. Há muitas opções disponíveis:
- Mecanismos que são bons em encontrar bugs, mas que funcionam por muito tempo;
- Mecanismos que acham mal os erros, mas funcionam muito rapidamente;
- Mecanismos “inclinados” a perceber bugs de um certo tipo, mas ao mesmo tempo não ver outros;
- Mecanismos que não são muito populares entre os testadores, mas realmente funcionam e não os utilizam, porque ninguém sabe sobre eles na equipe, e é por isso que o que pode ser encontrado continua a ser encontrado;
- Mecanismos que podem funcionar bem e rapidamente, capazes de encontrar muitos erros, mas a resposta deles é tão imprecisa que as pessoas não podem tomar decisões com base em seus resultados.
O foco nesses aspectos, não menos do que em outros conhecidos, é importante porque ajuda a contornar alguns problemas que surgem tradicionalmente. Por exemplo, aqueles em que você executou uma centena de testes, mas não encontrou um único bug. E isso pode ser bom, mas apenas se realmente não houver erros. Mas se eles existirem, isso será ruim se os métodos de teste aplicados não puderem identificá-los. Ou, na situação em que executo vários testes, encontro erros menores, ignorando os mais difíceis.
Minha equipe e eu devemos tomar certas decisões com base nos testes realizados. Isso significa que devemos acreditar no que os resultados dos testes nos dizem, portanto, devemos confiar inicialmente nos métodos de detecção implementados nesses testes.
Alguns métodos de detecção vêm dos próprios testes, grosso modo, do que eles estão procurando e como eles estão procurando. Outros métodos de detecção devem ser inerentes ao próprio ambiente e testabilidade, que definimos para determinar o quão provável e possível, em princípio, que os testes causem um erro, se existir.
No final de meus breves pensamentos, quero enfatizar que não determino o sucesso dos testes por nenhum fator específico. Mas se você ainda deseja determinar isso de alguma forma, não deve determinar o número de erros e vulnerabilidades encontrados e não a qualidade desses erros, mas a capacidade específica dos mecanismos de teste para detectá-los.
Eu descobri que os testadores inexperientes, depois de ler esta nota, não verão uma diferença significativa entre a ideia de detectar habilidades e os resultados obtidos após destacar essas características. Quanto aos especialistas, eles devem diferenciá-los extremamente.
Sendo capaz de entender e formular essa diferença, os testadores podem ir além das diferenças inúteis (apenas a opinião do autor) entre "verificação" e "teste" e, em vez disso, criar um entendimento construtivo dos métodos de detecção, humanos e automatizados, que permitem testes para ajudar as pessoas a tomar melhores decisões mais rapidamente.
Aqui está um material aparentemente simples, mas bastante útil. De acordo com a tradição estabelecida, aguardamos seus comentários e convidamos você para
um webinar aberto , que será realizado em 11 de março por
Mikhail Samoilov , a principal ferramenta de automação de testes do Grupo-IB.