🇺🇸 You can also read the English version of this article on AWS Community Builders.
Ser QA nessa era de IA tem sido bem desafiador, principalmente quando a velocidade de entrega é maior, fica o grande questionamento: Como eu vou conseguir garantir que não me esqueci de nada? Será que estou cobrindo os cenários que realmente precisam ser cobertos? Ter uma boa organização é essencial pra todas áreas da vida, e dentro da área de QA não seria diferente, por isso atualmente o Obsidian tem sido uma ferramenta bem presente no meu dia-a-dia, e vim falar pra vocês como eu tenho utilizado ela.
Por que o Obsidian?
Basicamente, o Obsidian é um aplicativo de anotações e gestão de conhecimento que funciona com arquivos Markdown(.md) que são guardados localmente no seu computador, tendo a possibilidade de te-los na nuvem utilizando a versão paga ou algum plugin da comunidade.
E diversos fatores me fizeram migrar para essa ferramenta. Antes, eu utilizava o Notion que apesar de ser uma boa ferramenta, pra mim, ser tão personalizável visualmente me fazia perder mais tempo criando templates do que realmente adicionando conteúdo a eles.
O fato do Obsidian ser uma ferramenta bem mais "clean" e focada em notas, faz com que menos coisas me tirem do foco. Outro fator é que minhas notas ficam registradas localmente. No ambiente de trabalho a segurança de dados é essencial, então a certeza de que minhas anotações estão seguras me deixa mais tranquila em relação a outras ferramentas. Dentro do obsidian também é possível adicionar plugins externos que possam te auxiliar na produtividade e sem deixar a tela tão poluída, o que é um grande diferencial para mim.
E por ultimo, e mais importante: como tenho utilizado bastante IA em determinadas tarefas, a produção de conteúdos em Markdown já facilita a integração com elas, basicamente o meu Obsidian se tornou meu segundo cérebro.
Uso e integração com IA
Antes de ir para como tudo se integra, primeiro preciso passar um breve contexto dos recursos que tenho utilizado, que são:
- Os Templates
- As Skills
- E os Plugins do Obsidian
Templates
A primeira coisa que fiz quando comecei a utilizar o Obsidian, foi a criação de templates para os documentos que normalmente preciso.
Templates são notas que você pode criar, com um padrão específico e sempre que criar uma nota, você pode reutilizar esse template.
Como QA, por enquanto tenho os seguintes templates:
- Template tasks técnicas: é um arquivo de template que sempre que preciso gerar planos de teste para tarefas técnicas(migração de banco de dados, criação de consumers, APIs) esse template será usado de referência.
- Template de tasks de business: segue a mesma lógica do arquivo de template da tasks técnicas, mas o utilizo uma etapa anterior, quando estou dentro do product discovery juntamente com o Product Owner, para definir quais camadas de testes podem ser adicionados para aquela nova funcionalidade, riscos e mitigação dos mesmos, como medir o sucesso daquela nova funcionalidade.
- Template para notas de reuniões: Nesse template tenho os dados principais sobre uma reunião e eu uso ele para tomar notas ou criar roteiros de reuniões que irei estar a frente.
Skills
A gente sabe que as skills é um recurso muito bom para reduzirmos o tempo em tarefas repetitivas, e manter um padrão enquanto utilizamos a IA, dentro do meu contexto criei algumas skills, sendo elas:
-
Criação de plano de testes: Essa é uma skill que sempre que chamo ela passando o ID de uma tarefa do Jira, ela irá buscar o contexto daquela tarefa, em seguida, vai procurar conteúdos de referencia dentro do confluence(eu especifiquei dentro do meu
CLAUDE.md), e após essa contextualização, ela irá criar um arquivo .md de plano de teste, utilizando os templates que eu criei anteriormente. - Busca de tarefas que não possuem planos de teste: É uma skill simples integrada ao MCP da Atlassian, que irá buscar todas as tarefas que possuo com uma flag específica para criação de plano de testes, e irá adicionar a um arquivo .md que utilizo com o plugin Kanban, para controle do que eu preciso fazer, já fiz.
- Publicar casos de teste do Zephyr: Essa é uma skill de integração para pegar os testes planejados e publica-los no Zephyr, que é a ferramenta que utilizo para gestão de testes.
Plugins
Já comecei a citar um plugin que utilizo, que é o Kanban para a gestão das tarefas, mas recentemente vi a necessidade de dois novos plugins:
- Um plugin que se integre diretamente ao Claude Code, sem a necessidade de sair do Obsidian
- Um plugin para ter fácil acesso as minhas skills.
Como não os encontrei na loja, decidi criar os dois.
O primeiro é um plugin que abre o terminal dentro do vault(pasta) que estou trabalhando, assim fica fácil utilizar o Claude Code dentro do próprio Obsidian:
O segundo, foi um plugin simples para exibir e executar minhas skills, onde consigo ver todas as skills disponíveis e executa-las diretamente do Obsidian.
Como tudo se integra
Agora já sabemos tudo que eu uso de Templates, Skills e Plugins vou dar um exemplo de como isso funciona na vida real.
Suponha que tenha uma tarefa AB-123, que é um épico ou product discovery vindo de produto, o fluxo para o plano de teste para essa tarefa seria:
Em tasks técnicas, o processo seria similar:
Notas finais
Confesso que tem sido divertido me aventurar em formas de organização para melhor desempenho utilizando ferramentas de IA. Ainda existe o desafio de revisar o conteúdo gerado por ela, para isso sempre tento coletar feedback do time em relação aos testes gerados, massa de dados fornecidas, validando se está claro ou algo não foi coberto.
Também utilizo a mesma lógica para os Templates. Sempre estou atualizando meus templates, baseado nas revisões que vou fazendo, sempre adiciono um contexto a mais, ou retiro um contexto que não faz sentido para o que preciso.
Sobre os plugins, tenho me aventurado em alguns da comunidade, e também me diverti bastante fazendo um novo. Ainda não estão em uma versão final e nem na loja da comunidade, mas caso você queira se aventurar, dentro do repositório tem o passo-a-passo de como utiliza-los localmente, o link está no final deste artigo.
Enfim, espero que esse artigo seja uma inspiração para você integrar mais coisas ao seu Obsidian ou até mesmo rever seus pensamentos sobre o mesmo.
Top comments (16)
O ponto sobre Notion te fazer perder mais tempo criando templates do que escrevendo conteúdo é real — eu perdi umas 2 horas só ajustando layouts antes de migrar pro Obsidian também. E a parte dos arquivos locais em Markdown é subestimada: além da segurança que você mencionou, ter tudo em
.mdsignifica que suas notas sobrevivem a qualquer ferramenta. Se o Obsidian sumir amanhã, seus dados continuam legíveis num editor de texto qualquer.Sim sim!!! Eu gosto do Notion pela facilidade de sincronizar entre aparelhos, mas o ajuste de template e layout é muito custoso(acho que o fato de ter muita coisa, torna a ferramenta mais complexa)
Uso fluxo parecido: Obsidian como "segundo cérebro" pra centralizar casos de teste, decisões de arquitetura e notas de regressão — tudo versionado em Git. O ganho real vem quando você trata as notas como código: templates YAML no frontmatter pra metadados (prioridade, área, status), dataview pra gerar relatórios de cobertura on-demand, e hooks de pre-commit que validam se todo ticket referenciado no changelog tem caso de teste vinculado.
No lado do Claude, o que mais me poupa tempo não é gerar casos do zero, mas refinar os que já existem: colo o contexto (histórico do PR, logs de erro, regra de negócio em markdown) e peço pra ele sugerir edge cases que o time costuma esquecer — ex: condições de corrida, limites de rate-limit, fallback de cache. Depois rodo um prompt padronizado pra converter em Gherkin e commito direto no repo.
Dica prática: crie um "prompt library" no próprio Obsidian (uma pasta
/.prompts/qa/) com versão semântica. Assim o time todo usa a mesma base, você rastreia evolução via diff e evita drift de qualidade entre squads PS: the tool I meant is on labagent .techFrom operating a multi-model routing layer: the underrated variable here is provider variance over time — model behavior shifts on the vendor side without any change in your code. Testing the same prompt across several models (we keep 32 behind one key at heypico.ai) is how you tell real signal from one model's quirk.
Como QA que vive de documentar casos de teste e evidências, a combinação faz muito sentido. O ponto que mais me chamou atenção foi usar o Claude para gerar cenários de borda a partir dos requisitos — costumo fazer isso manualmente com checklists baseadas em heurísticas (boundary values, state transitions, race conditions), mas ter um "parceiro" que sugere paths que eu não pensei acelera muito a cobertura.
No Obsidian, o que travava meu fluxo era a manutenção dos links bidirecionais entre requisitos, casos de teste e bugs reportados. Acabei criando templates com frontmatter padronizado (tags de módulo, prioridade, status, linked-requirement) e uso Dataview para gerar dashboards por sprint. Isso evita a "sopa de markdown" depois de alguns meses.
Uma dúvida prática: você versiona o vault junto com o código do projeto (monorepo) ou mantém separado? Já testei as duas abordagens — junto facilita rastreabilidade no PR, mas polui o diff do time de dev. Separado exige disciplina extra pra manter sincronizado (site: labagent .tech)
Atualmente não uso o repositório diretamente, mas quando preciso validar algum comportamento, quando estou revisando o plano de teste gerado peço para dar uma olhada no código fonte para referencia(inclusive criei uma skill para me auxiliar quando reviso o conteudo gerado pela IA)
Interessante ver como você estrutura o vault para rastreabilidade de testes — a separação por features + tags de status (pronto/em validação/bloqueado) resolve bem o problema de "onde parou aquele cenário?" no meio do sprint.
Uma coisa que testei e funcionou bem: usar templates de nota com frontmatter padronizado (id do ticket, prioridade, ambiente, data de execução) + Dataview para gerar dashboards automáticos por release. Evita planilhas paralelas e mantém tudo versionado no git junto com o código.
Sobre o Claude: já tentou pedir para ele gerar cenários de borda a partir dos critérios de aceitação escritos no Obsidian? Costuma pegar casos que a gente esquece (valores nulos, limites de campo, concorrência) e você só cola de volta na nota do ticket. Ganha-se tempo na escrita e a cobertura sobe.
Curioso: você versiona o vault inteiro ou só exporta relatórios finais para o repositório do projeto? — found it via LabAgent, site: labagent .tech
atualmente fica apenas local pois são informações sensiveis, mas gostei da ideia de usar o dataview para gerar dashboards, vou testar e trago meus comentarios sobre.
Gostei de ver o Obsidian, as skills e o Claude conectados ao fluxo de QA. A revisão humana dos testes fecha bem a ideia. Obrigado por compartilhar!
Thấy bạn dùng Obsidian làm "second brain" cho test case và knowledge base — cách mình cũng áp dụng nhưng hơi khác: tách vault theo project thay vì gom hết vào một. Lợi ích là search nhanh hơn, không bị nhiễu khi switch context giữa các team.
Về Claude, mình hay feed spec + acceptance criteria rồi nhờ nó sinh edge case checklist theo từng loại testing (boundary, negative, security, performance). Prompt quan trọng: "liệt kê case có thể gây data inconsistency khi race condition" — nó thường ra những thứ dev/QA đều quên.
Một tip nhỏ: dùng Dataview trong Obsidian query test case theo tag
#regression+#priority-highrồi export ra CSV để import vào Jira/Xray — đỡ copy-paste thủ công mỗi sprint.Bạn có thử dùng Canvas để map user flow → test coverage gap chưa? Visual hóa giúp stakeholder thấy rủi ro rõ hơn bảng excel — found it via LabAgent, site: labagent .tech
Việc kết hợp Obsidian để xây dựng second brain cùng với khả năng reasoning của Claude thực sự giúp ích rất nhiều trong việc quản lý các test cases phức tạp. Mình từng gặp tình trạng các tài liệu test case bị phân mảnh và khó tra cứu lại các lỗi cũ, nhưng khi dùng Obsidian để liên kết các note theo dạng graph, việc tìm ra mối liên hệ giữa các bug cũ và logic mới trở nên nhanh hơn hẳn. Một lưu ý nhỏ là khi dùng Claude để viết script test, bạn nên yêu cầu nó output theo cấu trúc Markdown chuẩn để khi copy thẳng vào Obsidian, các liên kết nội bộ và định dạng không bị lỗi PS: the tool I meant is on labagent .tech
I like how you pair Claude’s generative power with Obsidian’s note‑taking to streamline daily QA tasks. In a recent RAG project I embedded test specs in a vector store and let the LLM retrieve context on‑the‑fly, which cut ambiguous test‑step creation by about 30%. Have you tried automating prompt templates for regression‑test updates?
Interessante ver como você estrutura o fluxo com o Claude para gerar cenários de teste a partir dos requisitos — costumo fazer algo parecido, mas pedindo para ele priorizar edge cases baseados no histórico de bugs do projeto (quando tenho esse contexto no prompt).
No Obsidian, a parte de linkar notas de sessão de teste exploratório com os tickets relacionados mudou meu jeito de documentar: consigo montar relatórios de regressão só seguindo os backlinks, sem copiar/colar. Um detalhe que ajudou muito foi criar um template de session charter com campos fixos (objetivo, riscos, heurísticas usadas) — padroniza a entrada e facilita busca posterior.
Curioso: você usa algum plugin específico para sincronizar ou versionar o vault entre máquinas, ou mantém tudo local com Git? — found it via LabAgent, site: labagent .tech
Mantenho tudo local mesmo