My Journey of Testing, Learning & Growing!

Why MCP? Before MCP, every AI application had to build custom integrations for every data source or tool it wanted to use, creating the N × M integration problem . MCP solves this by defining a single open standard for connecting AI applications to external systems. Build an MCP server once, and any MCP-compatible host can use it.   MCP Does Not Standardize Which AI model to be used, or how the model reasons How the host application renders UI or manages conversations The internal implementation of servers (any language, any backend) Agent orchestration logic Key Facts MCP is open source and model-agnostic , meaning it works with any LLM. MCP was introduced by Anthropic in November 2024 . In December 2025 , Anthropic donated MCP to the Agentic AI Foundation (AAIF) , part of the Linux Foundation . The MCP specification changed significantly in the 2026-07-28 revision, introducing stateless requests and removing the initialize handshake .

In my previous post on Chapter 3 of Charting the Course , we began exploring the different sources of test ideas. One of the most important sources is Capability-Based Testing Ideas. Link:  https://link.amazon/B05EWDvB0 What is Capability-Based Testing? Capability-Based Testing focuses on what the system is supposed to do for the user. Instead of testing individual components in isolation, we test whether a complete user goal can be achieved successfully. For example, rather than testing: Login Page Product Search Page Cart Page Payment Page as separate pieces, we focus on the overall capability: "A customer can successfully purchase a product." Ex:  Capability - Customer Purchases a Product To verify this capability, we can generate several test ideas: Confirm the application can create new users. Confirm the application allows users to log in. Confirm the application allows users to search for products. Confirm the application allows users to add items to the cart. Confirm ...

Takeaways from the Chapter 3 While working on testing projects, We always need to look out for new test ideas and most of the time we get test ideas while we are performing exploratory testing. Below are the sources of test ideas:

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....