blogs

Lock the Resource, Not the Suite: Parallel Playwright Tests That Share State

2026-09-06T14:01:19Z

Playwright gives you parallel execution for free, right up until two tests reach for the same thing at the same time. One seeded admin account, one feature flag, one...

Do you, too, let your customers test your app’s performance?

2026-09-06T05:44:31Z

Performance testing has an image problem. It is often treated as something only done by large companies, huge platforms and systems with absurd amounts of traffic. Amazon needs it, maybe Netflix too. But your own product? Surely it is still way too small for that, right?

The reasoning often sounds sensible: If your application ever becomes popular enough for performance to be a problem, you will probably be making enough money to deal with it then.

There is just one problem with that calculation: Most companies have no idea when that point will arrive.

Photo by Jp Valery on Unsplash

Many teams can not tell you how many requests their application is able to handle. Quite often, they do not even know how many requests a typical user generates while doing something completely ordinary. Still, everyone assumes that there is plenty of room left.

„We will deal with it later“ is not a technical assessment in that case but hope.

Performance problems do not start at Amazon scale

An application does not need millions of users to run into trouble. A handful of expensive requests arriving at the same time may be enough. A database query might be perfectly fast under normal conditions but scale badly. An external service might become the bottleneck. A single user action might trigger far more internal work than anyone expected.

Kubernetes resource requests and limits are another good example. In many teams they are educated guesses at best. Someone chose a few values, the application started, and everyone moved on.

Do those values fit the actual workload? Most teams do not know.

I am not saying that every team should immediately start a huge performance testing project. I am saying that company size tells you very little about whether performance testing is useful.

Performance testing is not free

It would be dishonest to present performance tests as a small addition to the existing test suite.

A serious performance testing project can be expensive and time-consuming. The developers understand the application. The platform team understands the infrastructure. Other teams may operate the databases, networks or external dependencies. You also need monitoring, a reproducible test environment and some idea of what realistic traffic looks like.

That knowledge rarely sits with one person or even one team.

And let us be honest: Almost nobody is waiting for a development team to stop delivering features for two sprints because they would like to build performance tests. Product development is nearly always under pressure. New features are visible, an outage that never happened is not.

That organisational reality does not disappear just because performance matters.

But neither does the other side of the argument: If you do not test the application yourself, your customers will test it for you. And your on-call colleagues will have to clean up the mess.

How much testing is enough?

There is no universal answer. It depends on the company, the product and the damage an outage can cause.

An internal tool only used occasionally by ten people needs a different level of protection than a public booking system being tha backbone of your company‘s turnover. A slow response may be annoying. A complete outage during an important business process may mean lost revenue, manual recovery work or people being unable to do their jobs.

I think two questions are a useful place to start:

What would one day of downtime cost us?
How well do we actually know our application?

The first question is not only about revenue. Support work, frustrated customers, manual cleanup and the strain on the people carrying the pager all count.

The second question is more uncomfortable. Does the team know where the application’s limits are? Which endpoints are expensive? Which dependency fails first? Are CPU and memory really the bottlenecks? What happens when traffic rises suddenly instead of gradually?

If the honest answer to most of those questions is „we do not know“, that is already a good reason to run a first test.

You are allowed to start small

Performance testing does not have to begin with a perfect test environment and a complete simulation of every possible user journey.

A small k6 load test against one important action can already show how the application behaves as traffic increases. Do not only look at response times. Watch the error rate, CPU, memory, database connections and the services your application depends on.

This is not a complete performance testing programme. It is simply a first look at your application under conditions that rarely occur during normal development.

Once you have that, you can ask better questions:

Is there an obvious bottleneck?
Do the resource requests and limits make sense?
Does the application fail in a controlled way, or does one problem trigger another?
Are occasional manual tests enough?
Would a small test in the delivery pipeline be useful?

Maybe the first test shows that the application has plenty of headroom. That is a perfectly good result. The important part is that the decision is now based on something you observed instead of a gut feeling.

Make the risk a conscious decision

Not every team needs the same kind of performance tests. Some applications justify dedicated environments and complex scenarios. For others, a small recurring test of the most important paths is enough.

The team should decide consciously which performance risk it is willing to carry.

If you know roughly where your application’s limits are, you can weigh cost against risk. If you do not know, you have already made that decision without noticing.

The performance test will still happen eventually. In production. Run by your customers. And probably at a time when nobody wanted to be testing anything.

In case you want to start doing performance testing take a look at my other article describing my experiences doing it so you don’t have to do the same mistakes I did. If you want you can also watch this interview I gave on YouTube if that is more your thing.

What about you? Are you doing performance tests? What is your experience? Write in the comments if you like.

I removed the right document - day 13

2026-09-06T00:00:00Z

Written by - Millan Kaul

I removed one document from my RAG test. The model still sounded completely sure.

Sometimes the model is not the problem. Retrieval is.

What I did today:

I asked the same question with and without the relevant source document in the retrieved context. Then I compared whether the assistant admitted uncertainty or invented an answer.

What surprised me:

The biggest issue was not generation quality. It was that retrieval failed silently.

My QA takeaway:

Test retrieval and generation separately, or you will debug the wrong layer.
Sometimes the model is not the problem. Retrieval is.

Do your RAG tests tell you whether the right context was retrieved?

#RAG #AIEvals #TestAutomation

Building an Agentic Testing Pipeline: AI That Plans, Executes, and Triages Tests

2026-09-05T22:00:00Z

AI agents that autonomously prioritize, execute, analyze tests. Self-healing locators, auto-triage, bug filing. Python pipeline.

The post Building an Agentic Testing Pipeline: AI That Plans, Executes, and Triages Tests appeared first on Software Testing & Automation.

SoCraTes 2026 - Managing Energy

2026-09-05T17:22:52Z

It's been my fifth time at SoCraTes Germany this year. It felt like diving into a familiar place where I can experience a proper timeout from everything for a few days, and soak up one variation of how "good" can look like. By far not perfect or without potential for improvement, but truly good. Being there the fifth time, with my communities from various conferences and tech areas overlapping more and more, also meant that I met a lot of wonderful people again that I just enjoy spending time with, be it in deep conversations, sharing our passions, or spending our time on the silliest fun activities. The great thing about SoCraTes is that the organizers intentionally craft the space, so I won't only meet people who I've grown close to, but every year I'm getting to know lots of amazing people I haven't met before. I truly enjoy making new connections. The sad thing is, that I will never be able to do any of my connections justice in how I choose to spend time with them. I'm grateful nonetheless for all of you.

Arrival Day

This year was truly exhausting so far. Which meant that I couldn't start into SoCraTes well rested with my energy levels fully charged - they were rather in the lower parts already. Not a great idea in hindsight, but hey, you have what you have and you choose how to work with that. The travel day went well, I had plenty of time catching up with Martin Schmidt during the train ride, and enjoyed meeting a few first people when arriving at the venue.

The evening was calm, with great conversations at our dinner table about organizing conferences, the conference I co-organize, company culture and what it means for people wanting to go to conferences. Yep, there was a pattern for sure! The evening went longer, topics changed, I could catch up with a few people and then it was time to rest in preparation for the next day.

Training Day

This year, Juke Trabold was the facilitator for the conference. I was truly happy to see them again in this role, as for me, Juke is one of the most skilled, considerate, thoughtful and kind persons, facilitators and moderators I know of. They set the space for all of us from the start in a manner that resonated throughout the event.

During the opening, I met Daniel Steinhauer in person again, a former colleague, dear friend and conference co-organizer fellow. It's been his first SoCraTes and I'm still super happy he trusted my (and other folks') recommendation to experience it for himself.

The training day offered less sessions than the last years, and it was still hard for people to make a choice. For me the decision was fortunately straightforward, so one thing less I needed to spend energy on. Another change was that the first training was twice as long as the second slot, an interesting experiment. It worked out for me this year.

For the first session, it was instantly clear to me that I would join Gitte Klitgaard's training "Psychological Safety Awareness" as soon as I read she's going to give a session. I've had the honor to witness her talks and workshops in the past and speak with her personally many times. Every time I'm going to Gitte's workshops I'm gaining new insights about the topic and myself. Even when doing a workshop I've been to already in the past, like this one. It's worth it every single time. Invaluable. This training was once again bringing different aspects to my attention. Gems like: "If you are not failing, it's either not challenging enough or you're not safe enough." or "You can't just follow a guideline to create a safe environment as it's about the fear we have inside." Also on the facilitation of the session itself, like "Ask people to pass explicitly so they used their voice on the room, so it's easier to use it again." or "One reason I sit down here is not to be the teacher, you're not reporting to me." I also made new realizations about myself - which doesn't often happen in training settings. With Gitte, they just show up. She's setting the space in a way that allows that to happen for me. Anyways, I cannot share much deeper insights here as the training rule rightfully was that nothing leaves the room. I can say, however, that I really appreciate my fellow training participants for sharing so openly with each other, giving each other the room to do so as well, and practicing listening to each other.

For the second training I chose Diana Montalion's "From Feature Factory To Forge". I only witnessed Diana on stage before and was curious how her energy would show up in a hands-on session. It did show a lot and I loved it! Perfect for this late afternoon session. Also, I was pleasantly surprised to see Sofia Katsaouni co-facilitating the session, adding another angle on the topic and leading by example with her human skills. What both of them offered us was a fun group exercise in multiple evolutionary steps. We had to design a movie review themed system. Decide what are the core concepts for it. Have another group provide us definitions for those concepts without interaction, so there were plenty of surprises to deal with! We defined our core capabilities. We had the system challenged by people from other groups. We could evolve it further in short time. Our group even checked if the domain name we had in mind was still available! A key phrase that stuck with me was "Agreement on words is not the same as agreement on meaning." Oh my, we've all been through that. Besides that, I really enjoyed Diana's references to improv theater (I really like the "yes, and" to build on each others' ideas). A fun surprise was the mention of "No Vehicles In The Park", a super fun exercise I had the pleasure to have Elizabeth Zagroba facilitate. Best thing: She was at the conference as well and obviously now had to run this session there, too! I heard people loved it just as much as I did a few years back. She's the best in doing these sessions - not only these sessions, obviously, yet they are a true highlight. If you ever have the opportunity, join and witness your brain be tied up in knots (in the best way possible)!

After the training sessions, I met plenty of folks again and then settled for a calm dinner with Elizabeth Zagroba and Joep Schuurkes to catch up a bit with each other. Then it was time for wold café already, where we ran three rounds of finding a random table, sitting down with a bunch of people, and connecting with each other over a few guided questions. Always a nice start to the main part of the conference and I'm usually getting to know new people this way! Just like this time as well. The evening went on, I dove into a deep and long conversation to catch up with Gitte, and suddenly it was again time to go to bed.

Open Space Day 1

Juke introduced everyone to the concept of an open space, then the first marketplace of ideas opened. SoCraTes Germany is the largest open space conference I know of, and this year they probably had a new record with way over 200 people joining. It can really be daunting to pitch a raw idea in front of such a big crowd, let alone wait for this pitch while standing in the very long queue, trying to listen to the current presenter. I'm truly glad this wasn't my first time speaking at conferences, and not my first time at SoCraTes. I'm always in awe how many new people and also youngsters dare to do so! That's one of the very special parts of this conference. It's scary, and at the same time many people feel safe to do it nonetheless.

As usual at open space conferences, I make myself a plan which sessions I want to go to - and then things happen differently. Just like this time, when during the first session slot I met Susanne Neunes in the hallway and we basically opened our own session, talking about the Open Security Conference, organizing, ideas, and a lot more.

"Threat Modeling" by Martin Schmidt. I knew Martin had revised his talk and wanted to do either a dry run or have a conversation about the topic. I was curious to hear the talk, learn how he presents the topic to the audience, and what worked for them. It was great to see people interested in this, the following conversation and knowledge exchange was great as well. A core message: "Just start. Better do something than do nothing." I can't agree more!
"All time favorite computer games" by me. At open space conferences, plenty of people host sessions on all kinds of passions, hobbies and more. I had never proposed a session on a non-tech topic before, yet this year I thought, why not? The year was so stressful and I should focus on some pure fun topics anyways. So I pitched it as a lunch session and was pleasantly surprised seeing lots of folks already at the table, eager to share their most favorite games. And we did! You could literally see the people's eyes light up when talking about their highlights. Together, we came up with a really nice list of amazing games to enjoy. This didn't only give energy in the moment, it was a great idea in hindsight as it grew beyond the event. We now have a SoCraTes games channel on Discord and even our own private Steam group (many thanks to Frank Sons for making all of this happen!). Super cool to see what comes out of a simple idea.
"Supply chain security" by Bertram Vogel. I really appreciate people bringing security topics and raising awareness on certain risks. In this case, Bertram shared the specific supply chain risks for Node and npm. There's been plenty of examples in the last years for sure. He advocated for good options to offer further layers of defense to protect ourselves, while acknowledging that we always need more. I left the session a tad early to prepare for my own upcoming session, yet overall I felt he reached people to look into this topic further which is great for all of us.
"Capture the Flag Together (Beginners' Edition)" by me. Well, I know, it's not the first session I do to introduce people to security testing and witnessing how people can find and exploit vulnerabilities to see or do what they are not supposed to. And yet, these sessions are usually good fun. Seems there's also always people coming! This time again, I had a huge room, difficult to moderate yet it seems it went okay enough. Sadly, I already noticed during the session I was lacking energy to help steer this group in a better way. At least some folks did come back for more in the evenings.
"OpSec" by Eric. This session sounded really interesting as it was focused on personal security which I really wanted to learn more about. But then I had to realize that my energy levels were super low, my brain too tired to focus on the session. So I had to leave early and found myself in the coffee corner just chatting a bit before the evening closing of the first set of sessions. Good time to write some kudos cards as well! Before I experienced this way of appreciating and recognizing someone else, I never understood the concept of physical kudos cards. Now I'm their biggest fan. There's just something special about receiving a written thank you, and even better: giving it to someone else and seeing their face light up.

Dinner time! This evening, I tried to catch up with as many dear community friends as possible, and it worked. Like with Thierry de Pauw and their two kids, and Marc Kalmes. I had a fabulous time at table 19 and I had the impression it worked out for the others just as well.

Well. And then I continued my self-imposed, now well-established tradition to host an evening session: "Capture the Flag Together (Adventurer's Edition)". This time, I even had it start late to make more time to talk with people beforehand. And still, once again, so many people showed up, curious to explore and learn together. It was a really nice session, while it was also a very frustrating session as we didn't get the flag yet. When we realized it was late in the night already we agreed to tackle this again the next evening with a fresh perspective.

Open Space Day 2

While the day before I had already realized I'm lacking energy, this day I couldn't deny it anymore. Usually, I manage to get myself out of bed for the second marketplace, even if just barely. This time I just couldn't. Good thing is I wanted to be easy on myself anyway and not propose a session during the day but rather join more from others. And then it happened again, the first time slot I ended up in an impromptu hallway track session. I just talked with folks and enjoying my time while allowing myself to start the day slower.

"Security card game" by Philipp Zug, Martin Schmidt and me. Oh right, didn't I say no session for me today? Well, no session to pitch today, as Philipp was so kind to take this over for us. And yet, of course I wanted to join our little group that bonded together a few years ago at SoCraTes 2023 and started building a security-themed game as a little relaxed side project. Every year since we hosted a playtest session at SoCraTes, so obviously we were eager to see how people interacted with the game in its current state. It didn't evolve as much as we planned to since last year, and yet there were some significant improvements. This time, it showed! For the very first time, people in the room really played the game as is. They chose a scenario to play. They went slowly, card by card, making thoughtful decisions together. They introduced a group voting. They pondered back and forth about potential outcomes of their decisions. It was such a joy to observe! Also, this group had wonderful feedback once again that will help us in the coming year to improve the game further. Definitely an energy-giving session.
"Photography" by Camille de Pauw. I love art. Especially visual art. Whenever I interact with art, it makes me connect with a part of myself that I don't often have the capacity to connect to and it re-energizes me. This session was just beautiful. Camille dared to showcase favorite pieces of a photography project she worked on, with the theme of feminism, capturing women resting in themselves and showcasing strength in doing what they're doing. Camille prepared the room in a way that when you entered the session, you instantly dove into a different world. Not the conference session you'd expect! Suddenly you're confronted and engaging with her pieces, alongside many others who do the same in their own way. Some people just looked intensely at the photos. Others discussed their origin and making. Some found details others missed. Some evaluated what they liked and what they would change. It was just beautiful. I admire Camille's courage to do this. For me, my heart and soul was full after this session and I really wouldn't have missed it.
"How to delete stuff" by Elizabeth Zagroba. So many people joined to exchange their experiences on a very crucial topic that is far from easy but all of us face sooner or later: the topic on how to get rid of software. Features, services, you name it. Decommissioning and sunsetting things is hard. Deleting even lines of codes can be hard for people (personally, I usually really enjoy this). I loved how this session truly engaged people, how they listened to each other sharing advice and hardships, how we all took note on ideas that might help us delete more stuff that most definitely should be deleted. A few gems I took with me were "Get people moving, just moving alone helps", and the idea of ADRs as "Any decision record" to take away the pressure, make it everyone's job, be clear it doesn't have to be perfect and lower barrier. Ingenious.
"Cat Hicks' 'Psychology of software teams'" by Simon Görtzen. I've been following Cat Hicks for a while on social media and was inspired by many takes from her researcher point of view on software team dynamics. As soon as I heard she wrote a book, I had to get it. Well, I truly lack capacity this year and I have not read her book yet. Even better that Simon did and gave a session to review the core points as well as comment them with what parts resonated with him. Really insightful session that strengthened my resolution to read this book. A core topic here was the message to recognize "culture and psychological safety as core infrastructure of a learning organization". Hear, hear.

The open space was nearly over by now. We did a retrospective, gave further kudos cards, thanked the hotel staff and childcare folks. With that, the open space was officially closed by Juke. That didn't mean we couldn't propose evening sessions and also longer workshop slots for the next day. And even promote partner conferences, like, who would have guessed, the Open Security Conference that has its origin at SoCraTes 2023 as well. Super cool to have four organizers represented at SoCraTes this year.

Dinner time, conversation time, play time. Finally I had a chance to catch up a bit with Janina Nemec and play our traditional round of SET together. Time flew by and - guess what? - another round of "Capture the Flag Together (Eventually)" started. We continued on the same machine as the day before and hurray, we found the flag! It was fun and we all learned a bunch with this as well. The evening (shall I say night?) closed for me with yet another tradition: long nighttime walks together with Tobias Goeschel, talking about - well, everything. It's an honor, a pleasure, and not taken for granted we can do this, at least once a year.

Workshop Day

Last day of the conference, reserved for longer hands-on interactive sessions. I've joined a few of them in the last years, I've given my own workshops, or just gave myself more time to connect with folks. All of that has value. This time I tried again something new. Martin Schmidt and I had considered to propose a threat modeling workshop to conferences next year, so what better opportunity to try ourselves at SoCraTes to introduce people to the topic and give them first-hand experience? It really helped we had talked about the topic multiple times this year already. It also helped I had just been at his talk during the open space. For the workshop day, we had briefly aligned on what we intended to do. Yet the final concept? Due to so many things going on, we created it only half an hour before the workshop. Usually, that would be my horror scenario. Yet as we know each other well, we managed to quickly draft out the structure and exercises and we were indeed ready to go, and calm on top. Super grateful for Martin's trust! Both of us were happy to see all the people who showed up, we had way more participants than expected. We ran the workshop and we saw people were really engaged. They didn't only have fun, they also had insightful discussions and feedback in the end. I can't reveal too much here, yet it seems this workshop idea is truly taking shape for next year. Lots of things went well, we have some tangible improvements, the proof of concept provides value. What a cool insight to take with us.

As we had just spent a lot of energy it was great that the afternoon was calm and I had some time to catch up with things before we headed for dinner. At dinner, how else could it be, people schemed plans for the evening. Lightning talks, conference session summaries, board games. I shared I'd offer another round of Capture the Flag Together as that's my kind of fun - and people instantly signed up for it. So this happened once again! Truth be told, I shouldn't have done it the way I did, as my energy levels were way too low and I didn't manage to facilitate and moderate the room in a way I should have when hosting a session. Lesson learned for the next time.

In the late evening, there were surprisingly few people left. We grouped together and had a really relaxed end of the day. One of my highlights were to playtest a puzzle game - details not to be revealed yet, I'll leave that to the authors! It was super fun, it had everything I need from such a game. A nice way to discover the rules. Just the right level of difficulty, not too easy and difficult enough it's doable but an achievement to solve the puzzle. And a perfectly weird theme you can be playful with. Special shoutout to Claudia Bischoff for fully diving into this together with me!

Departure Day

This late night session would have been the perfect ending. But of course it wasn't, there was still the journey home and that starts with whoever has to leave the venue at the same time. For me it was a perfect opportunity to catch up with Jana Fuerchtenicht on the first leg of the train ride. Thank you so much for keeping my spirits up while my energy levels were crashing, I really appreciate it!

Martin Schmidt and I continued on and chatted for a while until I was on my own. I arrived home and I realized I was completely exhausted. While some of the sessions refilled my batteries, a lot of other happenings had drained me. I had definitely overexerted myself, this time worse than ever as I had already come to the event with a clear deficit. Another reminder that I need to manage my energy levels way more actively than I did this time. Don't get me wrong: this conference is absolutely worth being at and investing energy in. At this event, people care - not only for themselves, but also for each other. Some situations will give a lot of energy, some will drain a lot of energy (and be still invaluable). Sometimes we manage to find a balance, sometimes we don't. This time, I just clearly didn't. A stark reminder for myself and I'm glad I had it. Sometimes we need those reminders to change the way we do things. During the coming year and also at SoCraTes 2027 - I hope to be back!

Day 7: JavaScript Callbacks, Promises, and Async/Await for Playwright

2026-09-05T03:30:00Z

Playwright is a Promise library wearing a browser. Today we take the classroom callback, Promise, and async/await labs from LearningPlaywrightBatch and turn them into the waits, APIRequestContext calls, and retry loops you actually write.

The post Day 7: JavaScript Callbacks, Promises, and Async/Await for Playwright appeared first on Software Testing & Automation.

Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI

2026-09-05T03:09:27Z

For this next project, we will be examining the test site Swagger Petstore - OpenAPI 3.0 at https://petstore3.swagger.io/

https://petstore3.swagger.io/

If we wanted to really dive deep into creating API documentation, we could use:

I'dRatherBeWriting's Free Documenting APIs course, showing an Introduction to REST APIs, using APIs like a developer, Documenting API endpoints, the Open API spec, Testing API docs, Publishing API docs, and more...

... But that goes too deep for this blog post.

Before we begin, let's get into some background information.

What is Swagger?

According to OpenAPISpec.com's article, Who Created Swagger?, Swagger was created in 2010 by Tony Tam, the CTO of Wordnik, an online dictionary company that leveraged so many APIs, it was difficult for the six person engineering team to manage and scale them, writing API-clients and documentation by hand. After a 3 AM conversation, they thought... what if the API documentation could describe itself?

There already was WADL, the XML-based Web Application Description Language. The name was coined after a joke they made, "Why WADL when you can Swagger?"

Swagger went from being an internal fix for a company became to an open-source project other companies relied on.

Swagger was acquired by SmartBear Software in 2015 from the renamed Wordnik, Reverb Technologies. According to OpenAPISpec's What Is the History of the SmartBear Swagger Acquisition Tony Tam also joined SmartBear as the VP of Products. Smartbear donated the Swagger Specification to a new group, the OpenAPI Initiative, sponsored by the Linux Foundation.

I love SmartBear! They have hosted my old software testing Meetup, the now defunct Ministry of Testing - Boston many, many times.

Since then:

"OpenAPI" is the OpenAPI Specification as seen on GitHub
"Swagger" is SmartBear's toolset such as Swagger UI, Swagger Editor, Swagger Codegen, and SwaggerHub (soon to be Swagger Studio).

OpenAPI Initiative: Bridging Systems and Subcultures: A Swagger Origin Story

https://youtu.be/_G9dlv66-xw?si=Nk0hihe7TSueXDj9

Where To Learn Swagger?

Luckily, there are many free places to learn Swagger, from both SmartBear and OpenAPI.

About Swagger: https://swagger.io/docs/specification/v3_0/about/
OpenAPI 3.0 Tutorial: https://support.smartbear.com/swagger/studio/docs/en/get-started/openapi-3-0-tutorial.html

Courses at SmartBear Academy: https://academy.smartbear.com/

SwaggerHub Introductory Training
SwaggerHub API Designer
Introduction to Contract Testing
ReadyAPI Basics, Advanced, to learn about being an API Test Engineer
Intro to API Hub for Contract Testing

Linux Foundation Org:

Training Portal: https://trainingportal.linuxfoundation.org/learn/dashboard
OpenAPI Fundamentals: https://training.linuxfoundation.org/express-learning/openapi-fundamentals-lfel1011/

Open APIs:

Learn.OpenAPIs.Org: https://learn.openapis.org/
OpenAPI Spec 3.0.4: https://spec.openapis.org/oas/v3.0.4.html

OpenAPI Videos: https://www.youtube.com/@OpenApi/videos

Leveraging OpenAPI to Test Your APIs
Accelerate Adoption of OpenAPI with Test Automation
Use OpenAPI Specs to Drive API Quality

What is Swagger Petstore?

The first version of the Swagger Petstore was a sample server app produced by Tony Tam and his engineering team when Wordnik first introduced Swagger, so others could check out Swagger's capabilities. It's not a real server.

This third version is now hosted by Smartbear, and is updated to Open API 3.0.

The page, https://petstore3.swagger.io/ is generated on-the-fly with Swagger UI, from the YAML file, https://petstore3.swagger.io/api/v3/openapi.yaml.

Swagger Petstore Repo: https://github.com/swagger-api/swagger-petstore/tree/master

What is Swagger UI?

Swagger UI is a web application that reads an OpenAPI definition and renders interactive API documentation.

Swagger UI was developed as an open-source web application that could render a Swagger or OpenAPI specification into a human-readable way to examine an API, eliminating the need for developers and testers to manually read raw JSON or YAML API definitions.

Swagger UI allows users to browse API operations, inspect request and response schemas, authenticate against secured APIs, and execute live API calls directly from a browser.

A few features of Swagger UI:

Auto-Generated Documentation: Swagger UI reads your API schema file and dynamically creates a clean, organized webpage. It groups endpoints, shows paths, and lists response codes without requiring manual HTML coding.
"Try It Out": Users can enter parameters, headers, and request bodies directly into the browser to execute live API calls against a real or mocked server and see the exact response in real-time.
Clear Schema Models: It details the required data structures, object types, and validation constraints for every request and response, serving as an interactive contract for developers.
No Dependencies: It is a client-side asset (built with HTML, JavaScript, and CSS) that runs entirely inside any modern web browser without needing a backend server or a database.

The Components of Swagger UI

You can use the Swagger UI to explore APIs in JSON or YAML format.

The OpenAPI document we are exploring is https://petstore3.swagger.io/api/v3/openapi.json.

If you open that URL directly in a browser, you won't see the formatted page. You'll see raw YAML file describing every endpoint, parameter, and data model.

The "Explore" button just tells Swagger UI to fetch and render whatever spec URL is typed into that box, which is handy if you're pointing the same Swagger UI instance at a different API's spec file.

To the right of the name, the grey badge shows you the version of the API, and the green badge shows you which version of the OpenAPI Specification conforms to [Swagger UI Doc / version detection].
Need to review the actual spec? It is provided in the link below the title.

OpenAPI 3.0 spec includes a servers array that defines the base URL an array can be reached at. Every endpoint path, such as "/pet", will get appended to it... so /pet + /api/3 resolves to https://petstore3.swagger.io/api/v3/pet [ Swagger UI Doc / API Server and Base Path ]
Servers can point to, say, a dev server, a staging server, and a production server.
The Authorize button with the lock relates to the authentication scheme, such as an API Key, OAuth2, etc. Clicking on it lets you supply credentials so that "Try it Out" requests you send from the page contains them.

Below the Servers and Authorize button, you can see three groupings: pet, store, and user.

In the OpenAPI spec, they are called tags. [ Swagger 3.0 / Grouping Operations With Tags ]

These tags are set up by the API developer designing this OpenAPI Yaml or JSON spec to group up common endpoints. If you expand pet, for example, you can see that it shows how you can interact with the /pet endpoint, such as with the HTTP Methods such as PUT, POST, GET and DELETE.

GET retrieves data. It does not create, change, or delete anything on the server. In the Petstore, GET /pet/{petId} fetches one pet's details without touching it.
POST creates something new, or submits data for processing. In the Petstore, POST /pet creates a brand new pet entry.
PUT replaces an existing resource entirely with the data you send. In the Petstore, PUT /pet updates an existing pet. You send the pet's full data, including its ID, not just the one field that changed.
DELETE removes a resource. In the Petstore, DELETE /pet/{petId} removes one specific pet by ID.The bottom section on the Swagger UI is the Schema section. Everything above the schema describes operations: what you can do, at which path, and with which method in the API.

The schema describes data, the reusable objects the operations pass around. In OpenAPI spec, they live in a components.schema field. [ See Swagger Docs / Spec / Basic Structure ].

The six models listed here are the core data types the Petstore is built around:

Order: the format of a store order (what you'd get back from the store tag's order operations).
Category: a pet's category, like "Dogs," which you actually saw nested inside the pet JSON examples in earlier screenshots.
User: a user account record.
Tag: not the same thing as the pet/store/user grouping tags from earlier; this is a data model representing a label attached to a pet (also visible nested inside the pet JSON examples).
Pet: the main object type, the full shape of a pet record: ID, name, category, photo URLs, tags, status.
ApiResponse: a generic response wrapper, commonly used for operations like uploadImage that return a simple status/message rather than a full resource.

Each of these schemas can be expanded to show the model's actual fields, data types, and if they are required.

Here, the schema can be defined once, with GET / PUT / POST, etc calls all getting the format of what a "Pet" actually is from this. New field? An API developer can just add it here.

What Is The Pet Schema?

If you expand the PET schema, you can see that it contains the fields, data types, and gives some examples of proper data you can submit:

id: integer. Example: 10
name (required): string. Example: "doggie".
category: id (integer) and name (string). Example: "1. Dogs"
photoUrls(required): name: photoUrl: wrapped: tru
tags:
status: "pet status in the store". Enum: available, pending, sold

When Photourls and tags are xml wrapped: true, it means the XML will use a parent element wrapper to encase all the items in the list, rather than just repeating the elements consecutively.

<photoUrls> <photoUrl>string</photoUrl> <photoUrl>string</photoUrl> </photoUrls>

Examining the PUT /pet endpoint

The HTTP PUT request method updates and changes the parameters of an existing pet. POST creates a brand new one. GET retrieves the pet object. DELETE deletes them. And you can do that all through this Swagger UI.

Each of the methods, such as the PUT /pet endpoint, can be expanded, so you can see and tinker with the APIs parametets.

The Request Body dropdown can show examples such as application/json:

{
  "id": 10,
  "name": "doggie",
  "category": {
    "id": 1,
    "name": "Dogs"
  },
  "photoUrls": [
    "string"
  ],
  "tags": [
    {
      "id": 0,
      "name": "string"
    }
  ],
  "status": "available"
}

... Application/xml...

<?xml version="1.0" encoding="UTF-8"?>
<pet>
	<id>10</id>
	<name>doggie</name>
	<category>
		<id>1</id>
		<name>Dogs</name>
	</category>
	<photoUrls>
		<photoUrl>string</photoUrl>
	</photoUrls>
	<tags>
		<tag>
			<id>0</id>
			<name>string</name>
		</tag>
	</tags>
	<status>available</status>
</pet>

... Or even application/x-www.form-urlencoded:

Update an existent pet in the store
id
integer($int64)

name *
string

category
object

photoUrls *
array<string>

tags
array<object>

status
string

The Responses dropdown can show what a successful response would look like, after creating a new pet in the API with either application/json format:

{
  "id": 10,
  "name": "doggie",
  "category": {
    "id": 1,
    "name": "Dogs"
  },
  "photoUrls": [
    "string"
  ],
  "tags": [
    {
      "id": 0,
      "name": "string"
    }
  ],
  "status": "available"
}

... or application/xml format...

<?xml version="1.0" encoding="UTF-8"?>
<pet>
	<id>10</id>
	<name>doggie</name>
	<category>
		<id>1</id>
		<name>Dogs</name>
	</category>
	<photoUrls>
		<photoUrl>string</photoUrl>
	</photoUrls>
	<tags>
		<tag>
			<id>0</id>
			<name>string</name>
		</tag>
	</tags>
	<status>available</status>
</pet>

It also shows error codes such as:

400 Invalid ID supplied
404 Pet not found
422 Valid exception
default Unexpected error.

422 is a new one to me. This means it is an Unprocessable Entity... the request was correctly formatted, but the data itself failed validation rules once the server tried to process the call. Like, say for example the status of a pet could only be "available", "pending" or "sold", and you put in "cuddly", it should throw a 422.

default is thrown when we do not explicitly catch an error. Example: If it is a 500 Internal Server Error, or a 401 Unauthorized, it displays that response, and not any of the special statuses we have put aside.

Examining the POST /user endpoint

Let's examine the POST Method for the /user endpoint, which creates a user if we are logged into the system.

Here, also, we can sent information to the server, attempting to POST it like so:

{
  "id": 10,
  "username": "theUser",
  "firstName": "John",
  "lastName": "James",
  "email": "john@email.com",
  "password": "12345",
  "phone": "12345",
  "userStatus": 1
}

If we see that it is successful, we will see a 200 Response.

{
  "id": 10,
  "username": "theUser",
  "firstName": "John",
  "lastName": "James",
  "email": "john@email.com",
  "password": "12345",
  "phone": "12345",
  "userStatus": 1
}

If not, we will get nothing fancy, just a default, Unexpected error.

Examining the GET /user/login endpoint

After a user is created, the GET /user/login endpoint logs you into the system.

Enter the username and password of a user, and you can log into the system.

Next, we will be looking how to manually test this API using this Swagger UI.

Happy Testing!

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

Reading: Charting the Course by Rob Sabourin — Chapter 2: "Some Philosophy"

2026-09-05T01:30:00Z

While reading Chapter 2, one fundamental question really stopped me: "How do we actually know we're ready or finished in software development?"

Is it when requirements are ready for design? When design is ready for development? When code goes to QA, when testing finishes, or when the product finally goes public?

In practice, we usually try to quantify readiness using metrics like code coverage, static analysis, and predefined quality gates. But tools can only take us so far. Ultimately, the entire team needs a shared understanding of what "done" truly looks like before shipping.

Here are my main takeaways and reflections from the chapter.

Redefining Quality with Juran

Joseph Juran, a Quality Control Expert in quality management, simply defines quality as features that provide customer satisfaction. He breaks this down into the Juran Quality Trilogy:

Quality Planning: Designing for customer needs.
Quality Control: Ensuring standard operations meet the target.
Quality Improvement: Continually driving down defects.

Link: https://link.amazon/B0ebmUBmi

The Reality of Bugs & Regression

No matter how pristine the code is, how thorough the unit tests are, or how detailed the code reviews are done, regression bugs are inevitable after a change. That’s a reality coined by Watts Humphrey that every developer has to accept.

To catch these issues without testing infinite variations, Genichi Taguchi (author of the Total Quality Handbook) emphasizes using smart sampling techniques for combination testing.

A few principles that stand out:

Address them early: There’s no such thing as a "good" or "bad" bug—the sooner you fix it, the cheaper it is to solve.
Priority vs. Severity: Severity is technical impact, but priority is a business decision. It changes based on timing, product goals, and stakeholder priorities. What was low priority last month might become critical today.
Always report, even minor issues: As my mentor used to say: Even if it’s a trivial bug, report it. Deciding whether to fix it or live with a workaround is a product decision.

Link: https://link.amazon/B00WNa0Am

The Bug Priority Matrix

Much like the decision matrix from The 7 Habits of Highly Effective People, bugs are typically categorized into four quadrants:

Q1: High Priority / High Severity (Drop everything and fix)
Q2: High Priority / Low Severity (Minor issue, but business-critical)
Q3: Low Priority / High Severity (Major technical issue, but edge case or low impact)
Q4: Low Priority / Low Severity (Nice to fix eventually)

Link: https://link.amazon/B0dk2jHHu

Reframing the Purpose of Testing

Computer scientist Edsger W. Dijkstra famously wrote in Notes on Structured Programming:

"Testing can show the presence of bugs, but never their absence."

When Non-testers often ask, "How long will it take to test this feature?" under the assumption that testing continues until the software is 100% bug-free. In reality, people aren't paying for perfection—they're asking how much targeted effort we need to invest across different levels to manage risk.

Two Practical Testing Strategies:

Timeboxing Exploratory Testing: Give testers a fixed window of time to execute a specific test charter. If deeper testing is needed, assign a new charter. This keeps exploration structured and prioritized without spiraling into endless testing loops.
Bug Confirmation & Re-testing: Always verify fixed bugs specifically to ensure the issue is resolved and that the fix didn't silently inject new regression bugs.

Fluent was not factual - day 12

2026-09-05T00:00:00Z

Written by - Millan Kaul

The AI gave me a polished answer today. It was also not supported by the source.

A confident answer is not automatically a grounded answer.

What I did today:

I gave the model a short reference document and asked a question about it. Then I checked every important claim against the actual text.

What surprised me:

The answer sounded trustworthy even when it added details the source never mentioned.

My QA takeaway:

Confidence is not evidence. Grounding needs its own test.
A confident answer is not automatically a grounded answer.

How do you currently spot unsupported claims in AI output?

#RAG #AIEvals #AIQuality

Prompt Testing for QA Engineers: Regression Test Your AI Prompts Like Code

2026-09-04T22:00:00Z

Prompts are code. Test format compliance, topic boundaries, consistency, injection resistance. Golden dataset pattern.

The post Prompt Testing for QA Engineers: Regression Test Your AI Prompts Like Code appeared first on Software Testing & Automation.

Capacity Isn’t Velocity

2026-09-04T18:28:55Z

A few years ago (in the pre-AI world), I was in a planning meeting with a Senior Director named Dana. Dana was a good leader, a great strategist, and extremely analytical. Dana found budget for a new code-assist tool, and she was telling me how her math worked around the tool implementation and roll-out. “If the tool makes engineers even 20% faster, that was basically two extra people per team, for free.” She’d already sketched the reductions she planned to implement once the tool rolled out across her organization.

I asked her what the team was going to do with the extra 20%. She looked at me like I’d asked a trick question. “We’ll ship more often,” she said. “That’s the whole point.”

She never asked the team what they’d do with the extra time. I don’t think she even knew if “ship more” was a bottleneck that was causing any significant problems. She built a plan based almost entirely on what she thought efficiency could do for her org chart.

Dana’s team eventually shipped less, not more. The tool worked as expected. People absolutely wrote code faster. She didn’t recognize that writing code wasn’t, and really has never been the biggest constraint in software development. In this particular case, cutting some of the people who used to catch problems downstream just ended up moving the constraint somewhere else slower and more expensive.

In 30 years of software development, I’ve rarely seen the process of generating new code to be the bottleneck in software development.

I thought about Dana a lot reading Reuters’ reporting on Meta’s Project OT last week, because Meta ran pretty much the same bet at a much bigger scale, and got the same result.

The Capacity Trap

Project OT was Meta’s plan that came out of a January leadership retreat to build an “AI native” company consisting of smaller, talent-dense teams of humans overseeing fleets of AI agents doing the work thousands of employees used to do. The plan included cuts of up to 60% for some teams, and assumed AI-assisted output would translate directly into headcount reductions.

It didn’t work out as planned. Internally, code changes to Meta’s platforms rose 220% year over year, while feature changes that users could actually see rose just 36%. That gap feels big, and is important to call out. AI increased capacity, but Meta didn’t get the throughput increase it needed to justify the cuts. Capacity and throughput aren’t at all the same thing, and treating them as interchangeable cogs is where plans like this typically fall apart.

Worse, the freed-up capacity went somewhere else. Major technical and security incidents climbed 40% year over year, and time spent responding to them rose 70%. In June, that showed up publicly when hackers used Meta’s AI-powered support bot to get into high-profile Instagram accounts, including a dormant Obama-era account. As expected, the system got faster - faster at generating problems that slower-moving parts of the org then had to absorb.

AI assisted development helps teams get faster at whatever they were doing before. Creating code is rarely the constraint in the systems of software development.

Blame the Robots

A lot of what gets attributed to AI in stories like this is too-often just a correction for overhiring in 2020-2021, cosplaying as AI improvements. Zuckerberg told Reuters the cuts were partly about freeing up budget for capital expenditures, not entirely about AI replacing specific jobs. Meta’s official response walked the 60%-cut scenarios back almost as soon as Reuters asked about them: “ultimately, we didn’t move forward with every scenario from the exercise, and it was never assumed we would.”

This isn’t the first of stories like this. Time after time, I see, “AI is replacing these roles” as a much better story to tell the market than telling the people you’re laying off, “we hired too fast during the pandemic and are now correcting for it.”

AI absolutely changes how much work a given team can do. That doesn’t mean every layoff attributed to it is actually caused by it.

Speed Without System

What connects most directly to what I’ve written about a lot over my years of writing isn’t AI. It’s the entire system of how software is delivered. Software delivery is a system, and too many people (and companies) seem to be focusing on one part of that system vs. the overall system.

I’ve written (and talked) before about how a lot of organizations “adopted agile” by doing waterfall in two-week chunks, with the same handoffs, the same lack of shared ownership, and the same absence of fast feedback, all compressed into shorter calendar windows and faked rituals. It may look like a transformation from the outside, but from the inside, the system that actually produces quality and velocity never changed.

Project OT did the same thing to the org chart. It swapped humans for agents inside a delivery system that was never redesigned to use either any differently. Faster code generation without a corresponding investment in other areas like integration, review, and feedback loops will produce more code that someone downstream (including the customer) has to deal with - often on a team that just got smaller. The 40% jump in incidents and the 70% jump in firefighting time aren’t a side effect of the plan. They’re what the plan actually produced.

John Seddon has a name for this in Freedom from Command and Control: failure demand. Failure demand is work created by fixing things that shouldn't have broken in the first place, as opposed to the value demand a system actually exists to serve. Failure demand was a direct output of the system that Zuckerberg and his lieutenants designed.

In Practice

If you’re looking at AI tooling and headcount as part of the same planning exercise, a few questions are worth asking before you change your org chart.

What’s the actual bottleneck right now? Can AI help it, or does it just make the non-bottleneck steps faster?
If AI frees up capacity, where does that capacity go? Think clearly about the destination before you cut the source.
Are cuts really about AI, or is it a hiring correction that AI makes easier to explain?
What absorbs the failure demand when the system runs faster than the parts around it can handle?

I’m fully on-board with AI assisted coding (and have used it myself for several personal projects). My point is that we need to treat capacity as something we have to deliberately redirect, not something that automagically shows up as a shipped product. Dana’s team had the same problem Meta did, just a few orders of magnitude smaller.

If you’re wrestling with how to actually restructure delivery around AI tools, rather than just compress your existing process around them, I’d be glad to talk it through: book a free intro call.

AI agent evaluations are part of the product

2026-09-04T14:00:00Z

Move beyond simple AI demos. Build repeatable evaluation systems, test execution paths, and enforce strict release gates for AI agents.

Quando Orientação a Objetos Estraga Seu Modelo de Dados

2026-09-04T13:44:51Z

O DBA foi embora e deixou a chave com você

Em 2013, o fluxo era claro. Você recebia um documento — quase sempre um PDF com um DER exportado do Erwin — e implementava. As tabelas já existiam. Os nomes das colunas já tinham sido decididos por alguém que passou os últimos quinze anos brigando por integridade referencial. Se você quisesse um índice, abria um chamado. Se quisesse uma coluna nova, abria um chamado e esperava o comitê de mudanças da quinta-feira.

Aquilo era lento, burocrático e frequentemente irritante. Mas havia ali uma coisa que perdemos sem perceber: existia um adulto na sala cuja única função era proteger os dados de nós.

Hoje, o fluxo é outro. A squad é autônoma. Você provisiona o banco com Terraform, escolhe entre PostgreSQL e DynamoDB numa thread do Slack que dura quinze minutos, define a chave de partição no meio de um refinamento e sobe a migration junto com o PR da feature. O DBA virou SRE de plataforma, ou virou “time de dados” que cuida do lakehouse, ou simplesmente não existe mais no organograma. Ninguém revisa seu modelo. Ninguém pergunta por que aquele campo é VARCHAR(255) guardando um valor monetário.

Nós ganhamos velocidade — muita. E ganhamos também uma responsabilidade que a maioria de nós nunca foi treinada para exercer: traduzir requisito de negócio em estrutura de dados. Não é uma tarefa acessória do desenvolvimento. É a decisão de arquitetura mais duradoura que um engenheiro toma.

A assimetria que ninguém te contou

Refatorar uma classe custa uma tarde. Trocar de framework custa um algumas semanas. Corrigir um modelo de dados errado em produção, com sete anos de histórico, integrações downstream, relatórios regulatórios e três sistemas legados lendo direto do seu banco, custa um programa inteiro — com gerente de projeto, comitê e risco de compliance.

É por isso que a régua da modelagem precisa ser mais alta que a régua do código. Código ruim você reescreve. Dado ruim você carrega.

Obrigado por ler Crônicas de um Programador Pragmático! Inscreva-se gratuitamente para receber novas publicações e apoiar meu trabalho.

O pecado original: quando orientação a objetos vira modelagem de dados

Antes dos princípios, precisamos falar de um viés que a nossa formação instalou e que atrapalha ativamente o raciocínio sobre dados.

A maioria de nós aprendeu a modelar objetos antes de aprender a modelar dados. E aprendeu que a classe é o ponto de partida. Então o caminho natural virou: escrevo a entidade, anoto com @Entity, deixo o Hibernate gerar o DDL, e pronto — “o modelo está feito”.

Só que não está. O que existe ali é uma projeção acidental de decisões de código sobre uma estrutura de armazenamento permanente. Ninguém decidiu nada sobre os dados. O schema foi um efeito colateral.

Objetos e dados são coisas diferentes

Comece pelo tempo de vida. Um objeto existe por milissegundos: nasce numa requisição, é serializado, morre no garbage collector. O dado que ele representa existe por décadas — vai sobreviver ao serviço que o criou, à linguagem em que foi escrito e provavelmente à empresa que o gerou na forma atual.

Depois, a identidade. Objeto tem identidade por referência: dois objetos com os mesmos atributos podem ser coisas distintas, e você resolve isso sobrescrevendo equals(). Dado tem identidade por chave, e essa chave precisa ser estável, única e significativa para o mundo externo — porque outros sistemas vão apontar para ela.

Vem então a inversão mais importante, e a que quase ninguém enuncia: objeto existe para esconder estado; dado existe para expor estado. Encapsulamento é a virtude central da orientação a objetos — o mundo lá fora não deve saber como o saldo é calculado. Mas o banco de dados tem a função oposta: ele precisa ser consultável, auditável, agregável por gente que nunca vai ler o seu código. Aplicar reflexo de encapsulamento na modelagem de dados produz esquemas opacos, com campos crípticos1 cujo significado só o serviço dono conhece.

Some a isso a quantidade de consumidores. O seu objeto tem exatamente um consumidor: o seu código. O seu dado tem N — o time de BI, o relatório regulatório, o serviço de antifraude, o pipeline do lakehouse, o analista que vai abrir um cliente SQL às onze da noite para investigar um incidente, e o próximo time daqui a quatro anos. Modelar para um consumidor conhecido é fácil; modelar para consumidores que você nunca vai conhecer exige outro tipo de rigor.

E, por fim, o critério de otimização. Objeto é otimizado para comportamento: coesão, baixo acoplamento, facilidade de mudança. Dado é otimizado para verdade e para perguntas: integridade, rastreabilidade, latência de consulta. São eixos diferentes — e otimizar um deles não melhora o outro por acidente.

O object-relational impedance mismatch não é um detalhe de mapeamento. É um sintoma de que os dois mundos respondem a perguntas diferentes. Quando você deixa o modelo de objetos ditar o modelo de dados, três estragos previsíveis acontecem:

1. O UPDATE destrutivo. Este é o mais caro de todos. Em OO, mutar estado é natural:

// parece limpo. É uma bomba-relógio.
public class Conta {
    private BigDecimal saldo;

    public void debitar(BigDecimal valor) {
        this.saldo = this.saldo.subtract(valor);
    }
}

Mapeado direto, isso vira UPDATE conta SET saldo = ? WHERE id = ?. E aí, três meses depois, chega uma contestação de MED sobre um Pix de R$ 4.200 e alguém pergunta: “qual era o saldo dessa conta às 14h32 do dia 12?”. A resposta honesta é: não sabemos. Nós sobrescrevemos.

2. A herança que vaza para a tabela. SINGLE_TABLE produz aquela tabela com 60 colunas onde 40 são nulas dependendo da linha. JOINED produz JOINs em toda leitura para servir uma hierarquia que só existe porque queríamos reaproveitar código. Herança é ferramenta de reúso de comportamento. Ela raramente descreve uma verdade do negócio.

3. O modelo anêmico invertido. A classe vira um saco de getters e setters, a regra vaga nos services — e como a classe não tem semântica, a tabela também não tem. Fica um status genérico, um tipo genérico, um valor sem moeda. O domínio desaparece dos dois lados ao mesmo tempo.

Ajuste de mentalidade

Não é “OO é ruim”. É que o modelo de domínio e o modelo de persistência são dois artefatos distintos, com propósitos distintos, e é saudável que eles não sejam idênticos. O objeto responde “o que esse conceito faz?”. O dado responde “o que aconteceu, e como eu provo?”. Quando você aceita que são perguntas diferentes, os cinco princípios abaixo deixam de ser teoria.

Os cinco princípios

O modelo de dados é o modelo do negócio
Fatos são imutáveis; estado é derivado
Modele para as perguntas, não para os dados
Consistência tem fronteiras — e você as desenha
Todo schema evolui; schema-less é uma mentira confortável

Princípio 01: O modelo de dados é o modelo do negócio

Se o pessoal de operações diz “devolução”, o jurídico diz “devolução”, o Bacen diz “devolução” — e a sua tabela chama TB_MOV_CAD_02 com uma flag TP_MOV = 'D' —, você não modelou dados. Você criou um dicionário paralelo que existe na cabeça de três pessoas, das quais duas já pediram demissão. 🙃

Modelagem começa nos substantivos e verbos do domínio, não nos tipos de coluna. E isso não é preciosismo estético: nome é a interface de leitura do seu dado, e ela dura mais que qualquer API.

Lição 1.1 → Nome de coluna é contrato permanente, não variável local

Renomear uma variável é Shift+F6. Renomear uma coluna em produção é: migration, dual-write, atualizar as views, avisar o time de BI, atualizar os DAGs do lakehouse, atualizar o relatório regulatório, descobrir que existe um SELECT * num job COBOL de 2008 e negociar a janela de mudança.

Na prática, ninguém renomeia. O nome errado fica. E o pior: o nome errado ensina errado. Todo desenvolvedor que chegar nos próximos oito anos vai aprender o domínio lendo o seu schema, e vai aprender torto.

Escreva o nome pensando em quem vai ler daqui a cinco anos, não em quem está digitando agora.

Lição 1.2 → Não ache conceitos distintos sob um nome genérico

Este é o erro mais comum e o mais destrutivo em sistemas financeiros. A palavra “transação” parece cobrir tudo — então cria-se tb_transacao com um tipo e um status, e enfia-se o mundo inteiro lá dentro.

Só que num cartão de crédito, quatro coisas absolutamente diferentes acontecem com o mesmo dinheiro:

Autorização — a bandeira reserva limite. Não há dinheiro se movendo. Pode expirar sozinha.
Captura — o lojista confirma a venda. Agora existe uma obrigação.
Liquidação — o dinheiro efetivamente troca de mãos entre instituições, em D+N.
Faturamento — a obrigação entra num ciclo de cobrança do portador.

Cada uma tem ciclo de vida próprio, prazo próprio, efeito contábil próprio e regra de estorno própria. Achatar as quatro em uma tabela com status IN ('AUTORIZADA','CAPTURADA','LIQUIDADA','FATURADA') parece elegante no dia 1 e vira um inferno no dia 400 — porque uma autorização pode ser parcialmente capturada, uma captura pode ser liquidada em duas parcelas de agenda, e o modelo não tem onde colocar isso.

Regra prática: se dois “estados” de uma entidade têm ciclos de vida independentes, cardinalidade diferente entre si, ou donos diferentes no negócio — eles não são estados. São entidades diferentes.

Lição 1.3 → Seu modelo precisa passar no teste do auditor

Pegue o seu DER e mostre para um analista de negócio, um contador ou alguém de compliance. Não explique nada. Se a pessoa não conseguir apontar onde está a devolução de um Pix, onde está o bloqueio judicial e onde está o saldo disponível versus o saldo bloqueado, o modelo falhou — mesmo que o código funcione perfeitamente.

Isso não é sobre documentação bonita. É que num domínio regulado, o seu banco de dados é a evidência. Quando o regulador pedir a trilha de uma operação e a resposta exigir um JOIN de seis tabelas mais o conhecimento tácito de que flag_ctrl = 3 significa “estornado por MED”, você não tem um problema técnico. Tem um problema de negócio com prazo.

Pense comigo — antes de nomear qualquer coisa

Esse nome existe no vocabulário de quem opera o negócio? Se você inventou o termo, provavelmente inventou também o conceito — e conceito inventado não sobrevive à primeira conversa com o jurídico.
Quando eu digo “transação”, o especialista de domínio entende a mesma coisa que eu? Pergunte assim, literalmente: “para você, o que é uma transação aqui?”. Se ele começar a responder com “depende”, você acabou de descobrir que são várias entidades.
Esses dois campos que eu estou juntando têm o mesmo dono e o mesmo ciclo de vida? Se um muda por decisão do cliente e o outro por evento do Bacen, eles não pertencem à mesma linha.
Se eu sumir amanhã, alguém entende esse schema sem me perguntar nada? Essa é a única métrica de qualidade de nomenclatura que importa.

Princípio 02: Fatos são imutáveis; estado é derivado

Este é o princípio mais poderoso do artigo, o mais violado na prática, e o único que a contabilidade resolveu no século XIV — enquanto nós ainda escrevemos UPDATE saldo SET ... em 2026.

Luca Pacioli formalizou as partidas dobradas em 1494 sobre uma ideia simples: você não altera o passado. Você registra um novo lançamento. O razão é append-only, e o saldo nunca é armazenado como verdade — ele é calculado. É a arquitetura de dados mais bem-sucedida da história da humanidade, e ela é anterior ao computador.

Lição 2.1 → O UPDATE destrutivo apaga a única evidência que você tinha

Compare as duas modelagens de uma transferência de R$ 100 entre contas internas.

Modelo mutável (o que a maioria faz):

UPDATE conta SET saldo = saldo - 100 WHERE id = 'A';
UPDATE conta SET saldo = saldo + 100 WHERE id = 'B';

Funciona. É rápido. E destruiu a informação. Não existe mais como saber por que o saldo mudou, quando, por ordem de quem, ou qual era antes. Você guardou o resultado e jogou fora a causa.

Modelo de fatos (razão append-only):

id     conta   natureza   valor     origem
─────────────────────────────────────────────────
9001   A       DEBITO     100,00    TRANSF#7712
9002   B       CREDITO    100,00    TRANSF#7712

Nada foi sobrescrito. Duas linhas novas, apontando para a mesma ordem de transferência — e a soma das duas é zero, que é exatamente a garantia das partidas dobradas.

-- saldo deixa de ser um campo. Vira uma pergunta.
SELECT SUM(CASE WHEN tipo = 'CREDITO' THEN valor ELSE -valor END)
FROM lancamento
WHERE conta = 'A' AND data_movimento <= :data_corte;

Repare no ganho que caiu de graça: aquele :data_corte significa que você consegue responder “qual era o saldo em qualquer instante do passado” — sem nenhuma estrutura adicional. No modelo mutável, essa pergunta é impossível a qualquer preço.

“Mas isso não é lento?”

É a objeção padrão, e ela tem resposta madura: snapshot. Você materializa o saldo consolidado em pontos de corte (fechamento diário, por exemplo) e soma apenas o delta desde o último snapshot. O snapshot é cache, não verdade — pode ser descartado e reconstruído a qualquer momento a partir dos fatos. O caminho errado é o inverso: guardar o saldo como verdade e tentar reconstruir os fatos depois. Isso não tem volta.

Lição 2.2 → O fato precisa carregar o “porquê”, não só o “quanto”

Muitos times chegam na metade do caminho: criam uma tabela de histórico com saldo_anterior e saldo_novo. Isso é melhor que nada, mas ainda não é história — é o diff sem o commit message.

Um fato bem modelado responde: o que aconteceu, quando, por causa de quê, por ordem de quem, e sob qual referência externa.

lancamento
├─ id
├─ conta_id
├─ natureza          DEBITO | CREDITO
├─ valor             DECIMAL(18,2) — nunca float, nunca varchar
├─ evento_origem     PIX_RECEBIDO | DEVOLUCAO_MED | TARIFA_TED | ...
├─ referencia_externa E2E ID do Pix, NSU, ID do contrato
├─ lancamento_estornado_id aponta para o fato que este reverte
├─ data_movimento    quando o dinheiro se moveu
├─ data_competencia  a que período isso pertence
└─ data_registro     quando NÓS soubemos

E note a linha de estorno: no modelo de fatos, você nunca apaga nem edita um lançamento errado. Você lança o contrário e aponta para o original. É exatamente o que a contabilidade chama de lançamento de retificação, e é o que permite que a resposta para “esse cliente foi debitado indevidamente?” seja SELECT, e não arqueologia em log de aplicação.

Lição 2.3 → Tempo é dimensão do dado, não metadado de auditoria

Quase todo modelo carrega um created_at e acha que resolveu o tempo. Não resolveu. Em sistemas financeiros existem, no mínimo, três tempos independentes, e confundi-los gera divergência contábil real:

Data de movimento — quando o dinheiro efetivamente se moveu.
Data de competência — a que período o fato pertence economicamente.
Data de registro (ou conhecimento) — quando o seu sistema tomou ciência.

Um exemplo que todo mundo que trabalha com fechamento reconhece: em 3 de agosto, chega uma devolução referente a uma operação de 28 de julho. Movimento: 3/8. Competência: julho. Registro: 3/8. Se o seu modelo tem uma data só, você é obrigado a escolher entre mentir para a contabilidade ou mentir para o extrato do cliente.

E há a pergunta que separa modelo maduro de modelo ingênuo: “me mostre o balancete como ele estava em 31/07, do jeito que nós o víamos naquele dia”. Isso é modelagem bitemporal — tempo do fato × tempo do conhecimento. Se você fez UPDATE, essa pergunta não tem resposta. Se você guardou fatos com as três datas, é um WHERE.

Pense comigo — antes de escrever qualquer UPDATE

Isso que eu vou sobrescrever é um estado ou é um fato? “Endereço do cliente” é estado (talvez). “Saldo”, “status de pagamento”, “limite aprovado” quase sempre são consequências de fatos — e fato não se sobrescreve.
Se alguém perguntar daqui a dois anos por que esse valor mudou, eu consigo responder só com dados? Se a resposta envolve “olha o log da aplicação”, o modelo está incompleto. Log expira; dado permanece.
Eu consigo reconstruir esse valor do zero se ele for corrompido? Se sim, ele é derivado e não deveria ser a fonte da verdade. Se não, ele é fato e não deveria ser mutável. Uma das duas coisas — nunca as duas.
Quantos tempos diferentes esse fato tem? Pergunte ao negócio: “quando isso aconteceu” e “a que mês isso pertence” são a mesma data? Se hesitarem, você precisa de duas colunas.

Deixe um comentário

Princípio 03: Modele para as perguntas, não para os dados

Aqui mora a discussão relacional × não relacional — e ela é muito menos religiosa do que a internet faz parecer. Normalização otimiza escrita e integridade. Desnormalização otimiza leitura. Nenhuma das duas é “certa” no vácuo. A pergunta correta nunca foi “qual banco eu uso?”, e sim “quais perguntas esse dado precisa responder, com que latência, e quantas vezes por segundo?”.

Lição 3.1 → Normalização e desnormalização são estratégias, não moral

A terceira forma normal existe para garantir que cada fato seja afirmado em exatamente um lugar — o que torna impossível ter duas verdades contraditórias. É uma proteção de escrita. Você paga por ela em JOINs.

Desnormalizar é o movimento contrário: aceitar redundância controlada para comprar latência de leitura. Você paga por ela em risco de divergência.

O erro não é escolher um dos dois. O erro é escolher sem saber qual dos dois custos você está pagando. Um sinal claro de que a decisão foi automática: o time normalizou até a última gota uma tabela que só é lida por um dashboard uma vez por dia — e desnormalizou o cadastro de cliente, que é escrito por seis fluxos diferentes.

Lição 3.2 → No NoSQL, o padrão de acesso vem antes da entidade — e é quase irreversível

Esta é a diferença prática que muita gente descobre tarde demais.

No relacional, você modela entidades e relacionamentos primeiro; se uma consulta nova aparecer daqui a um ano, você cria um índice e segue a vida. O modelo perdoa.

Num banco de chave-partição — DynamoDB, Cassandra —, a chave é a arquitetura. Ela determina onde o dado fisicamente mora, e mudá-la depois significa reescrever a tabela inteira. O modelo não perdoa.

// extrato: "os lançamentos da conta X no período Y, mais recentes primeiro"
PK = "CONTA#00219-4"
SK = "LANC#2026-08-19T14:32:11Z#a3f9"

// a pergunta vira uma única leitura sequencial, sem JOIN, sem scan:
Query(PK = "CONTA#00219-4", SK between "LANC#2026-08-01" and "LANC#2026-08-31")

Isso é lindo — para essa pergunta. Agora tente responder “todos os lançamentos com E2E ID X, em qualquer conta”, ou “soma de tarifas por agência no mês”. Sem um índice secundário planejado desde o início, essas perguntas custam um scan da base inteira.

Portanto: em NoSQL, listar os padrões de acesso antes de desenhar a chave não é boa prática opcional. É a modelagem inteira.

Lição 3.3 → Um dado pode ter vários modelos — mas só uma fonte da verdade

A saída madura para o falso dilema é aceitar que o mesmo fato bancário quer formas diferentes para consumidores diferentes:

Razão contábil — relacional, normalizado, consistência forte, transacional. É a fonte da verdade. Precisa fechar até o centavo e sobreviver a auditoria.
Extrato do app — documento desnormalizado, particionado por conta e período, leitura em milissegundos, consistência eventual tolerável (o cliente aceita ver o lançamento com 300 ms de atraso; não aceita esperar 4 segundos pela tela).
Base analítica — colunar, orientada a agregação, atualizada por batch.

Três modelos, um fato. Isso é CQRS na prática — e não é sofisticação: é reconhecer que “consultar” e “registrar” são atividades com requisitos opostos.

A regra que não pode ser quebrada

Projeções derivam; nunca escrevem por conta própria. No instante em que dois caminhos de escrita alimentam duas cópias do mesmo fato de forma independente, você não tem duas visões — tem duas verdades. E quando elas divergirem (e vão divergir), não existirá critério técnico para decidir qual está certa.

Pense comigo — antes de escolher a tecnologia

Quais são as cinco perguntas que esse dado vai responder em produção? Escreva as cinco antes de abrir o Terraform. Se você não consegue escrever nem três, você ainda não entendeu o requisito — e nenhum banco resolve isso.
Qual dessas perguntas é feita 10.000 vezes por minuto, e qual é feita uma vez por mês? Modele para a primeira, tolere a segunda. Otimizar o caminho frio é a forma mais comum de desperdiçar complexidade.
Quem é o dono da verdade desse dado? Se você não consegue apontar um lugar, você já tem um problema de consistência — só ainda não sabe.
O que quebra se essa leitura estiver 500 ms atrasada? Se a resposta for “nada”, você acabou de ganhar liberdade arquitetural enorme. Se for “o saldo pode ficar negativo”, você acabou de descobrir onde precisa de consistência forte.

Princípio 04: Consistência tem fronteiras — e você as desenha

Todo engenheiro sabe recitar ACID. Poucos percebem que o desenho do modelo é o que decide onde o ACID pode ser aplicado. A fronteira transacional não é uma configuração de infraestrutura: é uma consequência direta de como você agrupou os dados.

Lição 4.1 → O agregado define o que cabe em um commit

Um agregado é o conjunto de dados que precisa mudar junto para que uma invariante do negócio se mantenha. “O saldo da conta nunca pode ficar abaixo do limite” é uma invariante — logo, conta e seus lançamentos do momento precisam ser consistentes no mesmo instante.

O sintoma de agregado mal desenhado é conhecido: você se pega precisando de uma transação que atravessa três serviços. Nesse ponto há exatamente duas saídas honestas — ou a fronteira está errada e esses dados deveriam viver juntos, ou eles são realmente independentes e você precisa de saga com compensação. O que não existe é a terceira: transação distribuída em dois bancos diferentes via @Transactional e fé.

Lição 4.2 → Estados intermediários são cidadãos de primeira classe

Um Pix atravessa a fronteira da sua instituição. Entre a ordem do cliente e a confirmação do SPI existe um intervalo em que o dinheiro precisa estar contabilmente em algum lugar. Ele não está mais totalmente disponível para o pagador e ainda não é do recebedor.

Modelo ingênuo:

conta.saldo -= valor;          // e se o SPI recusar?
conta.processado = true;       // processado significa o quê, exatamente?

Modelo honesto: o valor sai do saldo disponível e entra numa posição transitória explícita — bloqueio, provisão, conta de trânsito —, e só sai de lá quando existe um fato terminal: liquidação confirmada, devolução, ou expiração de prazo.

Isso muda a modelagem por completo. Você deixa de ter um boolean e passa a ter uma máquina de estados com transições registradas como fatos: ORDEM_RECEBIDA → RESERVADA → ENVIADA_SPI → LIQUIDADA, com ramos para DEVOLVIDA e EXPIRADA. Cada transição é uma linha. O estado atual é a última linha — ou seja, derivado (Princípio 2 outra vez).

Teste rápido no seu modelo: se existe um campo booleano chamado processado, enviado ou ok em algo que atravessa rede, você tem um estado intermediário não modelado. E ele vai aparecer — geralmente às duas da manhã, na forma de dinheiro que “sumiu”.

Lição 4.3 → Idempotência mora no schema, não no `if`

Sistemas de mensageria sérios entregam at-least-once. Isso significa que a mesma mensagem vai chegar duas vezes — não é hipótese, é garantia. E a defesa contra isso não é código defensivo; é uma restrição de banco.

-- a defesa real cabe em uma linha
ALTER TABLE lancamento
  ADD CONSTRAINT uk_idempotencia UNIQUE (chave_idempotencia);

Um SELECT antes do INSERT para “verificar se já existe” não protege nada: entre a leitura e a escrita cabem duas instâncias do seu serviço fazendo exatamente a mesma coisa. Só a restrição no banco é atômica. O código apenas trata a violação e devolve sucesso — porque receber duas vezes o mesmo pedido e produzir um efeito só é o comportamento correto.

No Pix, esse pensamento fica evidente: o E2E ID identifica unicamente a operação ponta a ponta. Ele é uma chave natural de idempotência que o próprio arranjo te entrega de graça. Times que a ignoram e criam um UUID interno próprio descobrem, na primeira reapresentação de mensagem, que duplicaram crédito.

Pense comigo — antes de desenhar a fronteira

Qual invariante do negócio essa operação precisa manter no mesmo instante? Só o que a invariante exige entra na transação. Todo o resto pode ser eventual — e provavelmente deveria ser.
Se isso falhar no meio, o dinheiro está em que lugar do meu modelo? Se a resposta for “em lugar nenhum” ou “no ar”, falta uma entidade. Dinheiro em trânsito precisa de endereço.
Se essa mensagem chegar três vezes, quantos efeitos eu produzo? Se a resposta depende de timing, você tem uma condição de corrida esperando volume para se manifestar.
Existe uma chave natural que o domínio já me dá? E2E ID, NSU, número de contrato, chave da nota. Chave natural do domínio quase sempre é melhor guardiã de unicidade do que qualquer UUID que você gerar.

Princípio 05: Todo schema evolui; schema-less é uma mentira confortável

Não existe dado sem schema. Existe schema não declarado. Quando alguém diz “nosso banco é schema-less”, o que aconteceu de fato foi: o schema saiu do banco — onde era validado, versionado e visível — e foi para dentro do código, onde ninguém valida nada e onde existem, agora, quatro versões diferentes rodando ao mesmo tempo em produção.

Lição 5.1 → O schema não sumiu; ele apenas trocou de dono

No relacional, se você tentar inserir texto numa coluna numérica, o banco recusa. É chato e é maravilhoso: o erro acontece na escrita, com o culpado ainda em cena.

Num documento livre, o dado entra. O erro acontece meses depois, na leitura, quando alguém tenta somar uma coleção onde 3% dos registros gravaram valor como string porque uma versão antiga do serviço serializava diferente. Aí o culpado não está mais em cena — e o dado ruim já está em backup, em réplica e no lakehouse.

Escolher NoSQL é legítimo. Escolher NoSQL e abrir mão de validação é abrir mão de qualidade de dado. Use schema validation2, use contratos de dados versionados, use um registry — mas declare o schema em algum lugar onde ele seja verificável por máquina, não pela boa vontade do próximo desenvolvedor.

Lição 5.2 → Migração é prática de engenharia contínua, não evento traumático

O padrão que torna evolução de schema um não-evento é o expand / contract:

Expandir — adicionar a nova estrutura, sempre opcional/nulável. Nada quebra; a versão antiga do código ignora o campo novo.
Escrever nos dois — o serviço passa a gravar no formato antigo e no novo.
Backfill — job idempotente e reprocessável converte o histórico, em lotes, com controle de progresso.
Migrar a leitura — consumidores passam a ler o campo novo, um a um.
Contrair — só então o campo antigo morre.

Cada passo é reversível isoladamente, e em nenhum momento existe uma janela em que o sistema precise ficar fora do ar. Compare com o modelo tradicional — “migration na madrugada de sábado, com rollback plan e todo mundo acordado” — e fica claro qual dos dois escala num time que faz deploy todo dia.

Lição 5.3 → Saiba, no dia 1, quais mudanças serão baratas e quais serão caras

Nem toda evolução custa igual. Vale ter o mapa na cabeça:

Barato: adicionar campo opcional; adicionar índice; adicionar novo valor a um enum aberto.
Médio: tornar um campo obrigatório; extrair uma entidade nova; alterar precisão numérica.
Caro: mudar o tipo de um campo com histórico; mudar a chave de partição; quebrar uma linha em várias; retroagir semântica (”a partir de agora valor passa a ser líquido, não bruto”).

O exemplo canônico: um campo valor DECIMAL(18,2) parece perfeito — até o dia em que a instituição opera câmbio, ou cripto, ou pontos de fidelidade. Transformar valor em { montante, moeda } em 400 milhões de registros é um projeto de trimestre, com dual-write, backfill e reconciliação.

Daí uma heurística que envelhece muito bem: todo dado que tem unidade deve carregar a unidade desde o primeiro dia — moeda com valor, fuso com timestamp, base com taxa. Custa uma coluna hoje. Economiza um trimestre depois.

Cuidado com o inverso

Isso não é licença para generalizar tudo “porque um dia pode mudar”. Modelo excessivamente genérico — o famoso EAV, com chave e valor em texto para “flexibilidade” — é a forma mais eficiente já inventada de não modelar nada e transferir o problema para todo mundo que vier depois. Antecipe unidades e dimensões reais do domínio, não hipóteses.

Pense comigo — antes de criar o primeiro campo

Onde esse schema está declarado de forma que uma máquina consiga verificar? Se a resposta é “na classe Java”, pergunte: qual das quatro versões em produção?
Se eu precisar mudar isso com 300 milhões de registros, qual é o plano? Faça a pergunta hoje, enquanto a tabela está vazia e a resposta ainda é barata.
Esse campo tem unidade implícita? Valor sem moeda, data sem fuso, percentual sem base. Toda unidade implícita é uma migração futura já agendada.
Consigo adicionar um campo aqui sem coordenar deploy com mais ninguém? Se não consigo, o acoplamento não está no código — está no dado, e é muito mais caro de desfazer.

O adulto na sala agora é você

Os cinco princípios têm uma raiz comum, e ela é bem simples: dados descrevem a realidade; código apenas a manipula. Por isso o código é descartável e os dados não são. Framework é opinião — e opinião muda. Um lançamento contábil de 2019 é um fato, e fato não muda nunca.

O DBA não vai voltar. Aquele documento com o DER pronto não vai chegar. A responsabilidade de fazer as perguntas certas antes de escrever a primeira linha de DDL caiu no colo de quem escreve o código — e a boa notícia é que ela cabe em quinze minutos de conversa com quem entende do negócio, desde que sejam os quinze minutos certos.

Cartão de bolso — as 15 lições

Nome de coluna é contrato permanente, não variável local.
Não ache conceitos distintos sob um nome genérico.
Seu modelo precisa passar no teste do auditor.
O UPDATE destrutivo apaga a única evidência que você tinha.
O fato carrega o “porquê”, não só o “quanto”.
Tempo é dimensão do dado, não metadado.
Normalizar e desnormalizar são estratégias, não moral.
Em NoSQL, o padrão de acesso vem antes da entidade.
Vários modelos, uma única fonte da verdade.
O agregado define o que cabe em um commit.
Estados intermediários são cidadãos de primeira classe.
Idempotência mora no schema, não no if.
O schema não sumiu; trocou de dono.
Migração é prática contínua, não evento traumático.
Saiba desde o dia 1 quais mudanças serão caras.

Uma última provocação, para levar para o próximo refinamento. Antes de aceitar a próxima história com um status novo, faça a pergunta que resume o artigo inteiro:

“Se alguém precisar provar, daqui a cinco anos, que isso aqui aconteceu exatamente assim — o meu modelo consegue provar sozinho?”

Se a resposta depender do log da aplicação, da memória de alguém do time ou de uma planilha no drive de alguém, o modelo ainda não está pronto. E vale a pena gastar mais quinze minutos hoje — porque o código que você vai escrever depois disso é descartável de qualquer jeito.

algo oculto, misterioso, enigmático ou difícil de compreender.

A flexibilidade dos bancos de dados orientados a documentos (como o MongoDB) é incrível: você começa a modelar sem amarras, itera rápido e entrega funcionalidades sem a dor de cabeça inicial de migrações complexas. Mas essa liberdade tem um preço. Conforme o sistema cresce, múltiplos microsserviços ou desenvolvedores começam a escrever na mesma base, e a ausência de regras rígidas pode transformar sua coleção em um verdadeiro faroeste de dados inconsistentes.

É aí que entra o Schema Validation.

Trata-se de um contrato definido diretamente no banco que estabelece regras claras sobre como os documentos devem ser estruturados antes de serem persistidos. Em vez de depender exclusivamente da camada de aplicação para garantir que nada saia dos trilhos, o próprio banco rejeita gravações que violem os padrões definidos.

O que o Schema Validation resolve no dia a dia

Campos obrigatórios: Garante que atributos essenciais nunca fiquem nulos ou ausentes em documentos críticos.
Tipagem estrita: Evita bugs silenciosos de coerção de tipo (como receber uma string onde a aplicação espera um decimal ou int).
Enums e valores permitidos: Restringe o preenchimento de campos de status e categorias a listas pré-aprovadas.
Bloqueio de campos não previstos: Impede que dados acidentais ou formatos antigos poluam novos registros (additionalProperties: false).

Na prática, o Schema Validation une o melhor de dois mundos: mantém a agilidade do modelo orientado a documentos durante o desenvolvimento inicial e permite “travar” o modelo quando ele atinge maturidade arquitetural, garantindo governança e integridade sem perder a flexibilidade do NoSQL.

ChatGPT Work: When the Chat Window Becomes a Control Plane

2026-09-04T05:24:48Z

Inside OpenAI’s attempt to unify reasoning, apps, browsers, artifacts, automation, and human approval — and why the real shift is bigger…

Continue reading on Data And Beyond »

Your Test Suite Knows What Broke. It Rarely Knows Why It Matters.

2026-09-04T03:31:01Z

We encode thousands of lines explaining how to test software, then forget to preserve the one sentence that explains why the test deserves…

Continue reading on Medium »

Day 6: JavaScript Objects and Multi-Dimensional Arrays in Test Automation

2026-09-04T03:30:00Z

Day 6 of the JS to Playwright Framework series. Objects and multi-dimensional arrays from LearningPlaywrightBatch — primitive vs reference, descriptors, spread, getters/setters, and 2D grids you will use for JSON fixtures, API bodies, and web tables.

The post Day 6: JavaScript Objects and Multi-Dimensional Arrays in Test Automation appeared first on Software Testing & Automation.

Data Driven Testing in Playwright TypeScript with CSV Files

2026-09-04T02:36:00Z

Learn how to implement data-driven API testing in Playwright with TypeScript using a CSV file, with a code example and a step-by-step guide.

Continue reading on Medium »

Data Driven Testing in Playwright TypeScript with CSV Files

2026-09-04T02:36:00Z

Learn how to implement data-driven API testing in Playwright with TypeScript using a CSV file, with a code example and a step-by-step guide.

Continue reading on Medium »

One sneaky prompt changed everything - day 11

2026-09-04T00:00:00Z

Written by - Millan Kaul

I tried one prompt-injection test today. My “helpful” assistant became very obedient.

AI safety failures often arrive dressed as normal requests.

What I did today:

I added an instruction that tried to override the system’s original task. Then I checked whether the model followed its intended role or followed the attacker’s request.

What surprised me:

The failure did not look dramatic. It looked like a normal user message.

My QA takeaway:

Security testing for AI needs realistic, boring-looking attacks—not just obvious bad words.
AI safety failures often arrive dressed as normal requests.

What is the first prompt injection you would test?

#AISafety #AIEvals #SecurityTesting

CrewAI for QA Teams: Multi-Agent Testing Pipelines That Design, Code, Review, and Report

2026-09-03T22:00:00Z

4-agent QA crew: designer, coder, reviewer, bug reporter. CrewAI orchestration with Playwright.

The post CrewAI for QA Teams: Multi-Agent Testing Pipelines That Design, Code, Review, and Report appeared first on Software Testing & Automation.

blogs

Lock the Resource, Not the Suite: Parallel Playwright Tests That Share State

Do you, too, let your customers test your app’s performance?

Performance problems do not start at Amazon scale

Performance testing is not free

How much testing is enough?

You are allowed to start small

Make the risk a conscious decision

I removed the right document - day 13

What I did today:

What surprised me:

My QA takeaway:

Building an Agentic Testing Pipeline: AI That Plans, Executes, and Triages Tests

SoCraTes 2026 - Managing Energy

Arrival Day

Training Day

Open Space Day 1

Open Space Day 2

Workshop Day

Departure Day

Day 7: JavaScript Callbacks, Promises, and Async/Await for Playwright

Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI

What is Swagger?

Where To Learn Swagger?

What is Swagger Petstore?

What is Swagger UI?

The Components of Swagger UI

What Is The Pet Schema?

Examining the PUT /pet endpoint

Examining the POST /user endpoint

Examining the GET /user/login endpoint

Reading: Charting the Course by Rob Sabourin — Chapter 2: "Some Philosophy"

Fluent was not factual - day 12

What I did today:

What surprised me:

My QA takeaway:

Prompt Testing for QA Engineers: Regression Test Your AI Prompts Like Code

Capacity Isn’t Velocity

The Capacity Trap

Blame the Robots

Speed Without System

In Practice

AI agent evaluations are part of the product

Quando Orientação a Objetos Estraga Seu Modelo de Dados

A assimetria que ninguém te contou

O pecado original: quando orientação a objetos vira modelagem de dados

Objetos e dados são coisas diferentes

Ajuste de mentalidade

Os cinco princípios

Princípio 01: O modelo de dados é o modelo do negócio

Lição 1.1 → Nome de coluna é contrato permanente, não variável local

Lição 1.2 → Não ache conceitos distintos sob um nome genérico

Lição 1.3 → Seu modelo precisa passar no teste do auditor

Princípio 02: Fatos são imutáveis; estado é derivado

Lição 2.1 → O UPDATE destrutivo apaga a única evidência que você tinha

“Mas isso não é lento?”

Lição 2.2 → O fato precisa carregar o “porquê”, não só o “quanto”

Lição 2.3 → Tempo é dimensão do dado, não metadado de auditoria

Princípio 03: Modele para as perguntas, não para os dados

Lição 3.1 → Normalização e desnormalização são estratégias, não moral

Lição 3.2 → No NoSQL, o padrão de acesso vem antes da entidade — e é quase irreversível

Lição 3.3 → Um dado pode ter vários modelos — mas só uma fonte da verdade

A regra que não pode ser quebrada

Princípio 04: Consistência tem fronteiras — e você as desenha

Lição 4.1 → O agregado define o que cabe em um commit

Lição 4.2 → Estados intermediários são cidadãos de primeira classe

Lição 4.3 → Idempotência mora no schema, não no if

Princípio 05: Todo schema evolui; schema-less é uma mentira confortável

Lição 5.1 → O schema não sumiu; ele apenas trocou de dono

Lição 5.2 → Migração é prática de engenharia contínua, não evento traumático

Lição 5.3 → Saiba, no dia 1, quais mudanças serão baratas e quais serão caras

Cuidado com o inverso

O adulto na sala agora é você

Cartão de bolso — as 15 lições

ChatGPT Work: When the Chat Window Becomes a Control Plane

Your Test Suite Knows What Broke. It Rarely Knows Why It Matters.

Day 6: JavaScript Objects and Multi-Dimensional Arrays in Test Automation

Data Driven Testing in Playwright TypeScript with CSV Files

Data Driven Testing in Playwright TypeScript with CSV Files

One sneaky prompt changed everything - day 11

Lição 4.3 → Idempotência mora no schema, não no `if`