O relato é meio engraçado.
Um pai desafiou os dois filhos a contornarem o protetor de tela do Linux Mint e eles conseguiram ativando o teclado virtual e digitando - com o teclado real e virtual ao mesmo tempo - rápido o suficiente para provocar um problema na biblioteca que gera o teclado virtual na tela, levando o protetor de tela junto.
O bug foi corrigido há 3 dias no Mint e no Void e foi reportado ontem ao Arch.
Vish e que curioso! Qual a probabilidade de algo ser descoberto assim?!
Estranho mesmo
O autor do XScreenSaver (provavelmente um dos mais antigos protetores de tela para Linux e afins) voltou a fazer duras críticas depois da falha e relembrou que o GNOME violou a licença do programa dele tempos atrás, o que significa que os forks do GNOME também estão em violação.
Jawinski já tinha acusado os desenvolvedores dias atrás no Twitter. Na ocasião, ele havia se referido ao “gnome-screensaver” como um “lixo inseguro”.
Na verdade bug são descoberto na tentativa e erro.
Você só testa e nunca sabe de onde vai aparecer.
O que faz com que as chances de uma criança encontrar um bug seja a mesma de um adulto o que diferencia é a quantidade de teste feita que aumenta a chance.
Tipo não precisa saber logica só precisa testar.
É por isso que eu não procuro bug eu não tenho paciência de ficar testando infinitamente um software.
Mais tem pessoas em que isso é um passatempo.
Mas, encontrar e ainda assim “reportar” mesmo que acidentalmente a um adulto e esse adulto ainda por cima ter conhecimento de que se trata de um bug e levar isso adiante convenhamos que é algo muito específico se pensarmos em termos de probabilidade. Não é toda hora que algo do tipo acontece.
Você leu?
O pai pediu para eles desbloquear a tela foi ai que eles acho o bug.
Provavelmente o pai viu pergunto como eles fez e testo novamente e reporto.
Não necessariamente foi a criança que reporto tem que ler o contexto.
obs: parte em que eu coloquei em negrito na resposta dele
Pô, mas como o mundo está mudado, é assim que os pais brincam com os filhos hoje em dia? 
Isso ou foi “fuzz testing manual usando trabalho infantil”, como um dos comentários nos links do @knimer definiram.
É por isso que não uso bloqueio de tela, nem tela de login (prefiro login automático), nem teclado virtual, nem tenho crianças em casa 
Fiquei curioso para ver como o KDE fez o bloqueio de tela e pelo visto a implementação deles é um pouco mais robusta:
O protetor de tela é composto de duas janelas, o ksmserver (mais simples, gera uma tela preta) e o kscreenlocker_greet (mais complexo e propenso a bugs, que pergunta senha). Se o segundo travar, é reiniciado pelo primeiro (que mantém a tela preta); se o primeiro travar, o KDE todinho cai.
O projeto KDE é composto todo de software open source?
Tudo que o projeto KDE produz é open-source, até onde eu sei. Mas questão de depender do Qt (que é comercial, e originalmente era de código fechado) é polêmica desde que ele surgiu.
https://plus.diolinux.com.br/t/a-partir-de-amanha-a-qt-company-tornara-o-qt-5-15-lts-comercial/28888/
Para mudar do QT para outro recurso teria que refazer os códigos quase do zero?
Ou tem algum recurso que usa muitas linhas iguais?
E para usar o KDE eu teria que pagar licença para a QT Company ou só paga que desenvolve?
Basicamente. Muita coisa precisaria ser modificada. E o Qt é um mundo à parte, ou seja, escrever em C++ usando o Qt vai produzindo uma relação de dependência que não é fácil de quebrar. É como portar um software, vai demandar muito esforço.
Não precisa pagar para usar o KDE, ele é distribuído livremente, assim como o Qt. A questão da empresa é sobre releases LTS com suporte comercial, mas de qualquer forma, o Qt tem duplo-licenciamento e algumas partes dele são completamente GPL. O KDE tem um acordo que garante que a dependência não pode ser quebrada, se a detentora quiser fechar o código, o KDE pode fazer um fork.
Nem sempre, o que aconteceu aqui foi meio que um ‘teste de caixa preta’, existem técnicas como teste de unidade e teste de integração que não envolvem tentativa e erro mas sim testes bem definidos onde você sabe muito bem o comportamento esperado.
Qual o método usado pelas distro que é automático como chama?
A maioria usam estes métodos que falei, honestamente não só as distros, diversos softwares usam UT e IT, é algo meio comum em CI/CD. Mas claro existem outras formas de teste bem definidos, outros níveis que podem ser automatizados, até mesmo em alguma medida testes de aceitação do usuário podem ter sua gestão automatizada, um caso particular é a SUSE e o Fedora com openQA com uma abordagem mais direcionada a distribuições e programas como um todo.
