The Bug Escape Rate is a critical quality metric in software testing that measures the effectiveness of the software testing process before a product release. The bug escape rate is the percentage or ratio of defects that were missed by the team(s) and subsequently discovered by end-users or customers in a production environment after the software has been deployed. It is typically calculated when we divide the number of bug found after release (escaped bugs) by the total number of bugs found (escaped bugs + bugs found before release) and multiply by 100. So if the team found 100 bugs, but after deploying to production customers report 10 additional bugs, the escape rate would be calculated as: (10 escaped defects) / (100 detected defects + 10 escaped defects) = 9%. Having a low escape rate is the primary goal. A low number indicates that the testing efforts were effective and successfully caught most defects before the public release. High escape rate suggests major issues with our processes, such as insufficient test coverage, incorrect testing environments, poor test prioritization, or a lack of focus on critical user paths. In essence, the escape rate tells you how many bugs slipped past testing.

A Compact Disc (CD) is a digital optical disc data storage format that was co-developed by Philips and Sony to store and play digital audio recordings. In terms of data capacity, standard CDs can hold up to 700 MB of data or roughly 80 minutes of uncompressed audio. The mechanism for storing data works in a way that the microscopic "pits" and "lands" on a reflective layer, which a laser beam inside the CD player reads. Unlike vinyl or cassette tapes, CDs are non-contact media, meaning the quality does not degrade with each playback. Over time, CDs got supplemented by DVDs and Blu-ray disks, which are similar in appearance but with larger capacity, and can store video content of much higher quality. The rise of the internet, streaming, online gaming, etc., all contributed to the decline in the use of CDs. 

A Floppy Disk (or diskette) is a legacy magnetic storage medium that was the standard for moving and backing up computer data from the 1970s through the late 1990s. It consists of a thin, flexible ("floppy") magnetic disk sealed inside a protective plastic enclosure. Unlike the CD, which uses lasers, a floppy disk works by using a mechanical arm with a magnetic head to read and write data directly onto the spinning surface. The most widely known floppy disk was the 3.5” one. While floppy disks were revolutionary for being rewritable and portable, they were eventually replaced by CDs and USB drives for several reasons:  Low Capacity: As files (like photos and software) grew in size, the 1.44 MB limit became too small  Fragility: The magnetic surface was easily damaged by dust, magnets, or heat.  Slow Speed: Data transfer was significantly slower than optical or flash storage.  Despite being obsolete in modern computing, the 3.5-inch floppy disk lives on globally as the universal "Save" icon in almost every software application.

The Three Amigos is a collaborative approach used in Behavior-Driven Development (BDD) to make sure everyone on a project has a shared understanding of a feature before any code is written. It brings together three distinct perspectives to bridge the gap between business requirements and technical implementation. The three unique perspectives The "Three Amigos" typically represents three roles (though it can be more than three people):  The business (Product Owner/Business Analyst):  Focus: What problem are we solving? What is the value?  Role: Defines the "What" and provides the requirements. The developer:  Focus: How will we build this? What are the technical constraints? Role: Discusses implementation and technical feasibility. The tester:  Focus: What could go wrong? What about the edge cases?  Role: Ensures the feature is verifiable and "breaks" the logic early.  How does it work? Instead of a long document, the Amigos meet for a short session (often 15–30 minutes) to discuss a specific user story.  Scenario Mapping: They turn requirements into concrete examples.  Gherkin Syntax: These examples are often written in the Given/When/Then format.  The Goal: By the end of the meeting, the team should have a set of clear, unambiguous "Acceptance Criteria" that serve as both the guide for development and the blueprint for automated tests.  Key benefits  Prevents rework: Issues are caught during the conversation rather than during the testing phase.  Shared understanding: Eliminates the "that's not what I meant" friction between departments.  Living documentation: The output (the scenarios) becomes a readable record of how the system is supposed to behave.  The outcome: The Three Amigos turn a vague idea into a "DoR" (the Definition of Ready), meaning the developers can start coding with total clarity, which significantly reduces the chance of a wrong understanding of the actual requirements. 

Domain-Driven Design (DDD) is a development approach that prioritizes the business domain over the technical implementation. It aims to manage complexity by making sure that the code accurately reflects the business needs. DDD is divided into two levels of design: strategic and tactical.The big picture (strategic) level focuses on how different parts of large systems relate to one another. DDD introduces the term “Ubiquitous Language,” which means that developers and domain experts use the same terminology for both conversations and coding. This means that there is no need to translate the business requirements to code and vice versa. The next big concept, at the strategic level, is the bounded context. The bounded context is a boundary around a specific part of the system (e.g, “Registration” vs “Checkout”), inside a boundary, terms have a specific unified meaning. DD also uses diagrams, such as the Context Map, which illustrates how Bounded Contexts interact with each other.The tactical level represents the building blocks, inside a given bounded context. We have entities that are objects with unique IDs that stay the same evening if their data changes. A user can edit their order, but the order ID should remain the same. Next, we have value objects, which are defined only by their attributes; there are no IDs here, and value objects are immutable. Another important terms are the aggregates, which represent a cluster of related entities and value objects that get treated as a single unit. We also have repositories, which are tools used to retrieve and save aggregate data, for example, abstracting away the database interaction. Lastly, we have domain events, which can be seen as notifications that something happened, such as a customer placing an order.The aid of DDD is to prevent the “Big Ball of Mud” architecture, which is hard to manage, and it forces the developers to model the software based on how the business actually functions.

.Microservices architecture is the opposite of the Monolith approach to software architecture. Instead of having the whole system built within one huge codebase, the microservices approach breaks the system down by business function. Each service runs on its own and is (usually communicates with other microservices through APIs. Microservices are decoupled, meaning that each service can be developed, deployed, and scaled without affecting the others. Each microservice should be specialized to solve one specific problem; for example, a payment microservice should only handle payment transactions. This approach also uses independent databases to enforce isolation, where each microservice owns its own data. The microservices approach is also tech-agnostic, which means that different services can be developed in different programming languages and still communicate with each other. This architecture philosophy uses several helper tools to keep things running. The first one is the API gateway, which represents a single point of entry, making sure requests are sent to the right service. Service discovery is there to help services find each other's network location. Next thing is the load balancers, which serve to distribute traffic so no single service gets overwhelmed. Lastly, we got message brokers which allow services to talk to each other asynchronously; if your developers use Kafka or RabbitMQ, these would be examples of message brokers. The microservices approach can offer high scalability, faster development, and better fault isolation. The downside is the increase of operational complexity and more difficult debugging; this means that a small and simple product won’t benefit from this approach, whereas a large and complex system will.

Machine Learning (ML) is a subset of Artificial Intelligence that allows computers to “learn” from data. Ordinarily, in programming, we provide data and the expected output, and the machine does the work. In ML, it's a bit different; its goal is generalization, that is, training a model so it can use data it has never seen before and make a fairly accurate description. For ML to work, we need large collections of data. This data is then prepared/cleaned so the machine can read it - like turning text into binary numbers. Next comes the training, the algorithm analyzes the data in order to find patterns, for example, like in spam detection. The machine “learns” by being trained with a large dataset, and at the end, we can use unknown data to get results. ML can be supervised, unsupervised, and refined. Real-world examples of machine learning are the suggestions you see on platforms like YouTube or Netflix, the facial recognition feature on your phone, and language translation tools. In a nutshell, machines are much faster than humans in recognizing repeating patterns, and ML can be very useful, or very harmful, depending on how it’s used.

SCRUM is an Agile framework that focuses on iterative and incremental development, unlike Waterfall, where sticking to the plan is a must, SCRUM tries to be more flexible and adaptive. Its core pillars are transparency, inspection, and adaptation. SCRUM mentions three roles: the Product Owner who prioritizes the backlog, the SCRUM Master who facilitates the processes and coaches the team on Agile, and the Developers, the cross-functional team that does the technical work.The SCRUM team takes their work out of the product backlog, which is a list of features that need to be developed or worked on. Whatever gets taken from the product backlog to be worked on goes to the sprint backlog, which is a list of tasks being worked on in the current iteration cycle. Increment in SCRUM represents the done portion of the product that is produced during the sprint - the average sprint lasts two weeks, but it can be shorter or longer.Lastly, SCRUM comes with a few of its own events or ceremonies. The sprint is the heart of SCRUM, lasting a few weeks. At the beginning, it starts with the Sprint Planning meeting, where it's decided what will be worked on during the next sprint. There are also daily scrum meetings (stand-ups), which are usually 15 minutes (or less) and serve to make sure the team is in sync and that any blockers are identified and tackled. At the end of a Sprint, there is a review meeting where the work completed in the finished sprint is presented to the stakeholders. The last event is the retrospective, which is used by the team to reflect on what can be improved for the future.

A/B testing, also known as split testing, is a simple but useful methodology used to compare two versions of a webpage, app feature, email, or other asset to determine which one performs better against a defined business goal. In principle, we have two distinct versions, A (the control, or original) and B (the variant, or modified version), which are shown to two similarly sized and demographically matched segments of users simultaneously. The Goal is to statistically analyze which version drives better results for a specific metric (the Conversion Goal), such as a higher click-through rate (CTR), more sign-ups or purchases (especially important in e-commerce) and lower bounce rate - to have less customers abandoning your site. The Process of A/B testing is as follows: traffic is split 50/50 (or some other defined ratio) between Version A and Version B. Data is collected over a set period until a statistically significant difference is observed, allowing the team to conclude that one version is superior. In summary, it is an experimentation process used to make data-driven decisions about design and content optimization.

Behavior-Driven Development (BDD) is an agile software development methodology that improves communication and collaboration between technical and non-technical team members by focusing on system behavior from the user's perspective, rather than on the technical aspects of the implementation. Focus on Behavior and Outcomes: BDD shifts the focus from writing tests for implementation details to defining and testing the desired behavior and business outcomes of the application as seen by the user. Improved Collaboration: It encourages continuous communication and shared understanding among all stakeholders—developers, testers (QA), and business representatives (e.g., Product Owner)—often referred to as the "Three Amigos." Ubiquitous Language (Gherkin): BDD uses a simple, structured, natural language (often called Gherkin) to write executable specifications (scenarios) that serve as both documentation and automated tests. Given-When-Then Structure: Behavioral scenarios are typically written using this clear, conversational template: Given a pre-condition or initial context. When an event or action occurs. Then an expected outcome or result is verified. Executable Specifications: These human-readable specifications are directly linked to code that can be automatically executed, meaning the documentation always stays synchronized with the actual system behavior, serving as living documentation.  Extension of TDD: BDD is considered a refinement and evolution of Test-DrivenDevelopment (TDD) and Acceptance Test-Driven Development (ATDD), applying its principles to a higher level of abstraction focused on business value.

Recognise your true value as a tester, navigate salary negotiations with confidence, and make the most of benefits beyond pay

There was a post on social media where people were asked to describe their job as poorly as possible. I said I basically click things and pester people with questions! How would you describe you...