softify.pro Flow — Testado pela COCO

Control. Clarity. Flow.

Todo o produto de software sério acaba por desenvolver um segundo produto por trás do produto.

Os clientes talvez nunca o vejam. Os visitantes talvez nunca saibam que existe. Mas os administradores, operadores, e programadores dependem dele todos os dias.

Para o softify.pro Flow, essa aplicação é a Administration — a consola operacional responsável por gerir utilizadores, funções, níveis de acesso, estados de autenticação, ambientes de base de dados, e outra configuração que mantém uma implementação do Flow sob controlo.

O seu ecrã de login carrega três palavras:
Control. Clarity. Flow.

Foram originalmente escolhidas para descrever a experiência que queríamos que os administradores tivessem ao operar o sistema.

Mas também descrevem surpreendentemente bem como acreditamos que o software deveria ser testado.

Isso tornou o softify.pro Flow — Administration um candidato óbvio para um teste real da COCO.

Não uma demonstração de laboratório.
Não uma coleção de botões isolados preparados especificamente para uma demo de IA.
Uma aplicação de secretária multiplataforma real com lógica de aplicação real, várias janelas, vários backends de base de dados, autenticação, permissões, localização, e estado suficiente para tornar regressões aparentemente pequenas difíceis de detetar manualmente.

Para a demonstração pública mostrada aqui, a COCO trabalhou exclusivamente com dados de demonstração gerados. A aplicação foi licenciada à empresa fictícia Presentation GmbH, e nenhuma informação de cliente de produção, credenciais, ou dados pessoais foram usados.

O objetivo era simples:
Deixar a COCO abordar a aplicação como um testador o faria, e determinar se o fluxo de trabalho administrativo completo ainda se comporta da forma que o software afirma.

O desafio

À primeira vista, testar uma aplicação de administração parece simples.

Abri-la.
Iniciar sessão.
Clicar em várias janelas.
Verificar se tudo parece correto.

Essa suposição muda rapidamente assim que a aplicação cresce.

O softify.pro Flow — Administration não é um único formulário estático. É uma coleção de vistas operacionais interligadas dentro de um único invólucro de aplicação.

Entre outras coisas, um administrador pode trabalhar com:

• contas de utilizador
• funções e níveis de acesso
• informação de autenticação
• estado de autenticação de dois fatores
• informação do sistema operativo
• informação de rede e IP
• configuração de base de dados
• opções de ordenação e apresentação
• seleção de idioma ao vivo
• informação de aplicação e licenciamento

A interface suporta atualmente onze idiomas. A aplicação também opera com backends de base de dados MySQL e PostgreSQL. Individualmente, nenhuma dessas funcionalidades representa um problema de teste invulgar.

A dificuldade vem das suas combinações.
Uma tabela de utilizadores pode funcionar corretamente em inglês mas mostrar um nome de coluna desatualizado em croata.
A ordenação pode funcionar corretamente enquanto ligada ao MySQL mas comportar-se de forma diferente após mudar para PostgreSQL.

Uma mudança de idioma pode atualizar a maioria dos elementos da interface deixando uma mensagem de estado por traduzir. A aplicação pode mudar de base de dados com sucesso mas preservar informação desatualizada da ligação anterior. Um novo lançamento pode introduzir uma funcionalidade enquanto a janela About ainda descreve a anterior. O programa não precisa de falhar para que qualquer uma destas situações seja uma regressão. Na verdade, alguns dos defeitos de software mais incómodos são precisamente aqueles onde tudo parece funcionar.

A aplicação inicia.
A janela abre.
O botão responde.
Mas algo por baixo já não está bem.
É por isso que o teste de regressão repetitivo importa.

E é também exatamente o tipo de trabalho em que os humanos se tornam cada vez piores depois de repetir a mesma sequência dezenas de vezes.

Porque o teste manual se torna dispendioso

Testar algo uma vez é fácil.
Testá-lo de forma fiável depois de cada lançamento relevante é diferente.

Considere apenas três dimensões: 11 idiomas de interface × 2 backends de base de dados × múltiplos fluxos de trabalho de aplicação.

O número de combinações cresce rapidamente.
Adicione diferentes funções de utilizador, estados de autenticação, comportamento de ordenação, alterações de configuração, e ambientes operacionais, e a matriz de testes torna-se demasiado grande para ser tratada como uma lista de verificação manual ocasional.

É aqui que o teste de regressão frequentemente começa a erodir.
Não deliberadamente.
Um prazo de lançamento aproxima-se.
Alguém lembra-se que a aplicação foi testada na semana passada.
Um programador verifica rapidamente o ecrã mais importante.

O alemão funciona.
O inglês funciona.
O MySQL funciona.
A suposição torna-se:
"O resto está provavelmente bem."

Geralmente está. Até ao lançamento em que não está.
A COCO existe em parte para remover essa suposição do processo.

O que a COCO realmente fez

A COCO iniciou o softify.pro Flow — Administration a partir de um estado de aplicação frio, sem depender de um ecrã previamente preparado ou de um fluxo de trabalho posicionado manualmente.

A primeira interação foi a mesma apresentada a um administrador humano: a janela de login.

A COCO identificou a interface de autenticação contendo:

• nome de utilizador
• palavra-passe
• código de autenticação de dois fatores

e a linha diretamente por baixo da identidade softify.pro Flow:
Control. Clarity. Flow.

A partir daí, a COCO continuou através de uma sessão de regressão definida. O objetivo não era simplesmente determinar se a aplicação podia ser aberta.

O objetivo era verificar se o estado da aplicação permanecia internamente consistente enquanto a COCO interagia com ela.

A autenticação é apenas o início

O teste de login é um dos candidatos mais óbvios para automação, mas a autenticação bem-sucedida por si só diz-nos muito pouco sobre o resto de uma aplicação administrativa.

Uma vez dentro, a COCO passou para o ambiente operacional real. Inspecionou a interface de administração de utilizadores e verificou que a informação esperada estava presente.

Isso incluiu dados como:

• nomes de utilizador
• palavras-passe mascaradas
• indicadores de 2FA
• funções atribuídas
• informação do sistema operativo
• endereços IP

A COCO depois interagiu com a tabela em vez de apenas a observar.
A lista de utilizadores foi ordenada por nome de utilizador.
A ordem resultante foi inspecionada.
A parte importante não foi se clicar no cabeçalho da coluna produziu alguma alteração visível.

A COCO verificou que o estado resultante da tabela correspondia à operação solicitada.

Essa distinção importa.
Um teste funcional pergunta:
"O botão respondeu?"

Um teste de regressão útil pergunta:
"A aplicação acabou no estado correto?"

Testar a fronteira da base de dados

O softify.pro Flow suporta mais do que um backend de base de dados.

Isso torna a mudança de base de dados uma fronteira de regressão especialmente importante.
A COCO mudou o backend ativo de MySQL para PostgreSQL.

Após a mudança, inspecionou novamente a informação de utilizadores.
O teste procurava mais do que uma ligação bem-sucedida.
Verificou se a aplicação continuava a apresentar os registos esperados e se a informação mostrada através da interface permanecia consistente.

A COCO depois voltou a mudar de novo.


Este tipo de transição é fácil de subestimar.
A interface de utilizador pode permanecer visualmente idêntica enquanto a camada de armazenamento por baixo muda completamente.
Da perspetiva de um administrador, essa transição deveria parecer quase aborrecida.
Os mesmos utilizadores deveriam continuar a ser compreensíveis.
As mesmas funções deveriam continuar a fazer sentido.

O mesmo comportamento de interface deveria continuar a aplicar-se.

Essa continuidade aparentemente sem incidentes é exatamente o que precisa de ser provado.

Onze idiomas, um estado de aplicação

A localização é outra área onde o teste superficial é particularmente perigoso.

É relativamente fácil verificar que uma aplicação pode iniciar noutro idioma.
É muito mais valioso verificar o que acontece quando o idioma muda enquanto a aplicação já está a correr e a manter estado.

A COCO mudou o idioma da interface ao vivo.

A sessão incluiu transições entre idiomas como:
Alemão → Inglês → Croata
enquanto a vista de administração permanecia ativa.

A COCO observou se os elementos de interface mudavam corretamente no lugar:

• cabeçalhos de tabela
• controlos
• botões
• etiquetas
• mensagens de estado

A tabela subjacente e o estado da aplicação também tiveram de sobreviver a essa transição.
Isto importa porque o software multilingue consiste em mais do que strings traduzidas.
As mudanças de idioma podem expor:

• recursos esquecidos
• etiquetas desatualizadas
• problemas de layout
• mensagens de estado por traduzir
• problemas de codificação
• reinicializações de estado
• problemas de recriação de controlos

Uma janela que parece correta quando iniciada diretamente em croata pode ainda comportar-se incorretamente quando o utilizador muda de alemão para croata durante uma sessão ativa.

Essa é a diferença entre verificar uma captura de ecrã e testar um fluxo de trabalho.

Restaurar o estado da aplicação

A COCO subsequentemente restaurou a configuração de ordenação predefinida da aplicação.

Novamente, o teste não terminou com o próprio clique.

A ordem resultante e a confirmação apresentada através da área de estado da aplicação foram avaliadas. Este tipo de verificação pode parecer insignificante comparado com testar autenticação ou acesso à base de dados.

Não é.

As aplicações empresariais acumulam centenas de pequenas transições de estado como estas.
Os utilizadores dependem delas sem pensar conscientemente sobre elas.
O software parece fiável precisamente porque essas interações permanecem previsíveis.
O teste de regressão existe para proteger essa previsibilidade.

Testar a informação em torno do software

A COCO também abriu o diálogo About da aplicação.

Porquê testar uma janela About?

Porque a documentação de software começa dentro do próprio software.
O número de versão, descrição de funcionalidades, e informação de licenciamento apresentados ao operador deveriam corresponder à aplicação que está realmente a correr.

Uma aplicação pode funcionar perfeitamente enquanto ainda apresenta informação de versão desatualizada ou descreve capacidades que já não correspondem ao lançamento.

Isso não faz falhar uma base de dados.
Faz algo mais subtil:
reduz a confiança.

Para software empresarial, a precisão operacional inclui estes detalhes aparentemente pequenos. A COCO portanto verificou-os também.

Control.

A primeira palavra no slogan do softify.pro Flow é também o primeiro princípio do ambiente de teste.

Control significa saber o que está a ser testado, contra que estado, e com que dados.

A demonstração pública da COCO não usa registos de produção de clientes.

Funciona com dados de demonstração deliberadamente preparados cujo estado esperado é conhecido.

Isso torna os resultados reprodutíveis.

Também significa que as diferenças entre execuções de teste podem ser investigadas em vez de explicadas como alterações aleatórias nos dados de produção.

Mais importante ainda, a COCO é concebida como um sistema de testes de IA auto-hospedado.

Evidência de testes, capturas de ecrã da aplicação, e informação de fluxo de trabalho interno podem permanecer dentro de infraestrutura sob o próprio controlo do cliente ou operador em vez de serem enviadas por defeito para um serviço de cloud de terceiros não relacionado.

Para aplicações de negócio internas, isso não é apenas uma preferência de infraestrutura. Pode ser parte do próprio requisito de teste.

Clarity.

A automação não é particularmente útil se o seu resultado final for: FAILED
seguido de centenas de linhas de output técnico que alguém tem de reconstruir manualmente antes de compreender o que aconteceu.

A COCO é concebida para preservar um rasto de evidência compreensível.

O relatório descreve:

• o que foi testado
• que interação ocorreu
• em que sequência aconteceu
• o que a COCO observou
• que estado era esperado
• onde o comportamento diferiu quando algo falhou

Capturas de ecrã e evidência de execução podem acompanhar essa sequência.
O objetivo não é esconder detalhe técnico.

É tornar o resultado compreensível antes de alguém ter de abrir um debugger.

Um engenheiro deveria conseguir responder:
O que aconteceu? antes de perguntar:
Onde no código aconteceu?

Essa distinção encurta dramaticamente a investigação quando surge uma regressão.

Flow.

A automação tradicional de UI frequentemente pensa em elementos.

Encontrar seletor.
Clicar em seletor.
Encontrar outro seletor.
Verificar valor.

Essa abordagem continua útil, mas as aplicações não são experienciadas como coleções de seletores.

As pessoas experienciam fluxos.

Iniciar sessão.
Abrir administração.
Encontrar um utilizador.
Mudar uma definição.
Mudar de base de dados.
Mudar de idioma.
Verificar o resultado.

Continuar a trabalhar.

A COCO por isso trata a sequência como um processo em vez de uma coleção aleatória de controlos.

Segue o que o utilizador está a tentar realizar e avalia a aplicação em contexto.

Isso torna-se especialmente valioso ao testar software de negócio real, porque as falhas ocorrem frequentemente entre ecrãs ou entre estados, não dentro de um botão individual.

Um fluxo de trabalho logístico pode conter uma encomenda, reserva de stock, operação de picking, guia de remessa, e confirmação de envio.
Cada ecrã individual pode parecer correto enquanto o processo completo está errado.
O mesmo princípio aplica-se aqui numa escala menor.
A janela de administração não é o produto.

O fluxo de trabalho através dela é.

Evidência em vez de suposição

Um dos trabalhos mais importantes da COCO não é clicar. É lembrar o que aconteceu.
O teste de regressão humano frequentemente termina com uma afirmação como:
"Testei e tudo parecia bem."

Isso pode ser completamente preciso.
Mas várias semanas depois, quando surge um problema, as perguntas úteis são diferentes:

• Que lançamento foi testado?
• Que base de dados?
• Que idioma?
• Que estado de utilizador?
• O que aconteceu antes do problema?
• O que exatamente era visível?

Por que ordem foram executadas as ações?
As execuções de teste da COCO são concebidas para deixar evidência para trás.

Isso transforma um resultado de teste de uma opinião em algo que pode ser inspecionado. Uma execução bem-sucedida torna-se, por isso, também útil.
Estabelece um estado de referência conhecido contra o qual comportamento posterior pode ser comparado.

A COCO não é a decisora

Há uma fronteira importante na forma como usamos IA para testes de software.
A COCO não pretende substituir a responsabilidade de engenharia.

Não decide o que uma regra de negócio deveria ser.

Testa o comportamento em relação a cenários, requisitos, e expectativas definidos para a aplicação. Para decisões sensíveis envolvendo permissões, preços, inventário, transações financeiras, ou outros estados de negócio críticos, a definição de comportamento correto permanece uma responsabilidade humana.

Essa distinção importa.
A IA é excelente a repetir um teste detalhado sem perder concentração. É excelente a recolher evidência.
Pode inspecionar ecrãs, comparar comportamento esperado e observado, e explicar discrepâncias. Mas o negócio continua a definir o que correto significa.

A COCO torna essa definição testável.

O teste que ninguém quer repetir

Há uma razão simples pela qual a automação acrescenta valor aqui.
Um testador humano pode absolutamente realizar esta sessão de regressão.
O primeiro idioma recebe atenção total.
Provavelmente o segundo também.
Depois outro.
Depois outro.
O MySQL já foi verificado.
O PostgreSQL ainda precisa de ser verificado.
O teste de ordenação já foi executado várias vezes.
O diálogo About não mudou há meses.

É sexta-feira à tarde.

E a atenção humana faz o que a atenção humana naturalmente faz. Começa a otimizar.
A COCO não. No espírito da própria COCO:

• Não me aborreço de clicar no mesmo botão em onze idiomas. Não salto a passagem do PostgreSQL porque é sexta-feira à tarde. Não assumo que a ordem de ordenação se manteve porque funcionou no lançamento anterior.

Para a COCO, cada sessão de regressão pode ser tratada como se fosse a primeira. Isso não é inteligência a substituir um testador humano.
É automação a proteger o testador humano da parte do teste onde a atenção humana é menos valiosa.

De testes repetitivos a evidência de engenharia

O propósito maior da COCO não é maximizar o número de ações automatizadas.
Mil cliques automatizados não têm significado se ninguém entende o que provam. O resultado útil é confiança apoiada por evidência.

Para o softify.pro Flow, isso significa conseguir dizer que um lançamento foi verificado nas áreas operacionais que importam:

• autenticação
• administração de utilizadores
• funções e informação de acesso
• estado de autenticação de dois fatores
• comportamento de ordenação
• operação MySQL
• operação PostgreSQL
• localização ao vivo
• feedback de estado
• informação de aplicação
• informação de licenciamento

e que o resultado é preservado numa forma que pode ser revista posteriormente. O mesmo princípio escala muito para além desta aplicação.
Um processo de login pode ser testado desta forma.
Um fluxo de trabalho de reserva pode ser testado desta forma.
Um processo logístico pode ser testado desta forma.
Uma aplicação de secretária multiplataforma pode ser testada desta forma.
Os ecrãs mudam.
As regras de negócio mudam.
O princípio não muda:
defina o fluxo de trabalho esperado, execute-o consistentemente, recolha evidência, e torne o resultado compreensível.

Porque testamos o nosso próprio software com a COCO

Há outra razão pela qual o softify.pro Flow importa como um caso de estudo da COCO.

É o nosso próprio software.
Isso remove a distância confortável que por vezes existe entre uma demonstração de tecnologia e as pessoas que a demonstram.

Se a COCO se destina a testar software empresarial, tem de ser suficientemente útil para confiarmos nela com software que nós próprios realmente desenvolvemos e lançamos.

O Flow portanto atua tanto como produto como campo de prova.
Novas capacidades de teste podem ser exercitadas contra uma aplicação real.
Comportamento inesperado pode expor fraquezas na aplicação, no plano de teste, ou na própria COCO.

Cada lado melhora o outro.
Esse ciclo de feedback é muito mais valioso do que construir demonstrações artificiais concebidas apenas para ter sucesso. Um sistema de testes não deveria parecer convincente porque a demonstração foi fácil.
Deveria tornar-se convincente porque continua a encontrar as pequenas coisas que os humanos eventualmente parariam de verificar.

O resultado

O softify.pro Flow — Administration tem agora um processo de regressão documentado e repetível que a COCO pode executar antes de lançamentos relevantes.

O teste abrange ambos os ambientes de base de dados suportados e a interface de onze idiomas da aplicação, enquanto segue a aplicação como um administrador a usaria em vez de tratar cada ecrã como um alvo de teste isolado.

A COCO produz um rasto de evidência mostrando o que foi testado, o que foi observado, e em que ordem a sessão ocorreu.

Essa evidência pode permanecer controlada localmente.
Os programadores ganham um ponto de partida reprodutível quando algo muda.
Os testadores humanos passam menos tempo a repetir interações previsíveis e mais tempo a investigar as situações que genuinamente requerem julgamento.

E o softify.pro Flow recebe algo mais valioso do que um indicador verde de PASS.

Recebe evidência de que a experiência prometida no seu ecrã de login continua a existir depois de o código por baixo mudar.

Control. Saiba o que está a ser testado e mantenha o ambiente sob controlo.

Clarity. Compreenda o que aconteceu sem reconstruir um registo de automação opaco.

Flow. Teste a aplicação como um processo que as pessoas realmente usam.

Control. Clarity. Flow.

Foi escrito para o software.
Acabou por descrever igualmente bem a filosofia de testes por trás dele.