What’s Special About Testing Salesforce? - Chapter 2

‍

So, we've talked your ear off about why you should test on chapter 1. By now, you might be wondering, “How do I test Salesforce when things are constantly evolving?” 

‍

Well we thought you might ask that! (Yep, add “mind reader” to our resume.)

‍

From MuleSoft to Commerce Cloud to Customer 360, the Salesforce of today is a robust amalgamation of several powerful platforms. But with great power comes great responsibility, or in this case, a ton of dependencies. Beyond just the Salesforce ecosystem, many enterprises integrate their Salesforce setup with a variety of other data sources and systems in their tech stack. Salesforce is easy to customize and extend — yet, here's the kicker: too much modification can brew a storm of complexity. And as we all know, with great complexity often comes a great loss in quality. 

‍

Unlike traditional on-premise applications, Salesforce thrives in a complex web of layers and third-party integrations. This makes end-to-end testing a challenge for QA teams to execute for several reasons:

• Salesforce Doesn’t Exist in a Vacuum: Connections to other apps and platforms like AppExchange, SAP, and ServiceNow necessitate meticulous end-to-end testing to ensure each integration works as it should. A single break in any business process can result in costly downtimes and even costlier fixes.
• Frequent Platform Upgrades: Here's the good news: Salesforce doesn't shy away from innovation, releasing new features multiple times a year. The flip side? Each update can potentially disrupt your existing setup, meaning you need to constantly retest your applications and business processes to adapt.
• Dynamic Content in Salesforce Apps: Heavily customized apps within the Salesforce ecosystem—think CPQ, nCino, Veeva, and the like—come packed with complex technical elements like shadow DOMs and IFrames. Testing these requires a specific set of skills to ensure accuracy and functionality.
• High Configurability: Salesforce’s ecosystem is a paradise for low coders, empowering even the most non-technical users to customize everything from custom objects to multilingual page layouts. More customization, however, means more layers of complexity in testing.

Let’s go into these in a little more detail.

The Complexity of Salesforce Customization

Many Salesforce enthusiasts might tell you that the platform is so user-friendly and customizable that it hardly needs testing — it should just work, right? After all, it's mostly configuration, point and click. It's not like it's "real" coding.

‍

Hold up, not so fast! 

‍

While Salesforce does boast ease of customization, which is a huge selling point, it's precisely this ease that can lead to over-customization. Newcomers to Salesforce often dive headfirst into the vast sea of customization options, tweaking every possible setting. However, they soon realize that more isn't always better — simplicity often trumps complexity, especially when usability begins to decline.

‍

The real kicker, though, is how these customizations intertwine. Dubbed "The Happy Soup" internally at Salesforce, this mixture resembles a culinary soup where various ingredients blend, sometimes unpredictably. Each customization doesn't just sit in isolation –– it potentially interacts with countless other processes and applications that depend on it.

‍

Consider this: a well-intentioned admin tweaks a setting to streamline the sales process, unaware that this same setting is crucial for support operations. The ease of making such changes can unwittingly disrupt other critical processes. So, how do we safeguard against these mishaps?

‍

Testing is key. It allows us to identify when a seemingly minor change throws a wrench in the works. But testing alone isn't the panacea — it's merely one crucial ingredient in a broader recipe for success. Effective development practices begin with meticulous planning and a thorough impact and dependency analysis — think of it as preventative medicine for your Salesforce environment.

Managing Salesforce Seasonal Releases

One of Salesforce's magical features is its seasonal updates. Thrice a year—Spring, Summer, and Winter—Salesforce evolves, potentially enhancing your investment significantly over time. 

‍

Ever wondered why there's no Fall release? Perhaps "Fall" sounds a bit too close to "crash," or maybe it's just an opportunity for everyone to enjoy the season's colors — a question for another day!

‍

Salesforce rigorously tests its updates to ensure they don't disrupt existing functionalities. Their commitment to backward compatibility is impressive, with support for each API version extending over a decade. However, no matter how comprehensive Salesforce's internal testing might be, the unique blend of customizations and integrations each organization applies—your particular "Happy Soup"—means that some impacts might slip through the cracks.

‍

To counter this, Salesforce provides a sandbox preview of the next version well ahead of its official release. This foresight allows organizations to test their custom setups and ensure that everything continues to function smoothly post-update. Despite Salesforce's best efforts, the unpredictable nature of how new metadata might interact with your custom configurations necessitates thorough testing on your part.

‍

Quick Start Action: Don't just take it for granted. Leverage the release preview sandbox to run through your automated tests — or, if you're still building your test library, at least perform manual smoke testing on your most critical processes.

Testing ISV App Upgrades

‍

If your organization utilizes Salesforce, like many others, you likely have at least a couple of apps from the AppExchange — often, at least one Independent Software Vendor (ISV) app plays a critical role in your business processes. The flexibility of ISV apps is crucial but comes with its own set of challenges, especially when it comes to upgrades.

‍

ISV Partners can push upgrades to their customers at any time, although most have found out the hard way that they should only do this in coordination with their customers. 

‍

Uncoordinated upgrades can lead to disruptions and conflicts with existing customizations — lessons learned the hard way. For instance, one of the authors previously worked with an ISV partner that managed more than 10 managed packages in a single app. Each package required updates in a specific sequence to ensure the whole application continued to function correctly.

‍

Typically, customers prefer not to have upgrades pushed directly to their production environments without prior testing. They often request that upgrades be first implemented in a test sandbox. This practice allows them to validate that the new version does not disrupt their current operations. Once the upgrade is vetted in the sandbox environment, a scheduled window is agreed upon for the upgrade to be pushed to production, accommodating the unique configurations—or "Happy Soup"—of each customer.

‍

You might wonder why such extensive testing is necessary for a platform celebrated for its low-code environment. Despite the ease of use and configuration that Salesforce provides, the underlying complexity of integrated systems means that even minor changes can have unforeseen consequences. Testing is not just about checking functionality –– it’s about ensuring stability across an interconnected ecosystem.

‍

The process described here underscores the importance of a proactive approach. Even when an ISV has thoroughly tested an upgrade on their end, the unique nature of your Salesforce instance—shaped by customizations and specific data configurations—demands that you conduct your own tests. This approach significantly mitigates risks associated with integrating new software versions, ensuring that they mesh well with your system without causing disruptions or data integrity issues.

‍

Testing ISV app upgrades before rolling them into production isn't just a best practice — it's a critical safeguard to maintain operational continuity and maximize the ROI of your Salesforce investments.

Low Code Challenges Testing Salesforce

‍

Salesforce’s platform offers an array of customizations, some of which have historical roots and are no longer available to new customers. These historical features set the stage for understanding some of the challenges you will face.

Page Layouts

Back in the early 2000s, adding custom fields, tweaking field labels, and renaming tabs were hailed as groundbreaking feats in cloud computing. 

‍

Then came custom objects and Web Tabs. (Be still my beating heart!)

‍

Over time, the simple drop-down evolved into a sophisticated Picklist, followed by the introduction of Dependent Picklists. This development allowed users to change the list items of one picklist based on the selection of another. While this feature added powerful capabilities, it also complicated Salesforce testing. Now, testers had to confirm that these dependent lists were populated correctly. Additionally, these weren't just simple HTML drop-down controls anymore, which meant traditional functional testing tools often struggled to handle them effectively.

‍

If you explore all the customization options available for "simple" page layouts today, you'll find extensive capabilities accessible via simple point-and-click. Pages can be divided into sections, contain multiple related lists and include customizations within those lists. Fields can be made mandatory directly in edit mode, and now, in-line editing is also possible.

‍

So many things to test. So little time!

‍

S-Controls 

‍

Around 2003, Salesforce realized that not all use cases could be addressed with just point-and-click. Enter S-Controls, enabling customer-generated automation using Javascript right on the page. This flexibility was great, but it also meant there was new "Code Behind" page components to test. Though S-Controls have been phased out, their replacement technologies still require thorough Salesforce testing of the underlying code.

‍

VisualForce 

‍

After developing Apex around 2005-6, Salesforce replaced S-Controls with something beefier. They wanted to call it Aura, but since the name lacked the word 'Force,' it became VisualForce. These pages faced similar challenges to S-Controls, needing extensive testing of the code behind them — whether it's Javascript or Apex, it doesn't matter. This is a staple across all visual frameworks in Salesforce.

‍

Visualforce pages are here to stay, and so is the need for a robust Salesforce implementation testing regime to keep them running smoothly.

‍

Lightning Strikes!

‍

Visualforce and Page Layouts, key components of the Classic page architecture, had their merits but also their limitations. Salesforce, always pushing for maximum flexibility, realized a more robust solution was needed. 

‍

Enter Lightning, a dynamic design system allowing builders to create to their heart's content. After a few years of refinement, Lightning now provides a robust foundation for Salesforce customers and ISV partners to develop powerful applications. Moving forward, all new development should harness the power of Lightning.

‍

This innovation brought its complexities, of course. Surprise, surprise, surprise! 

‍

Time for a brief geek-out: deep in the metaphorical Gotham City, there lurks a "gangster" known as the Shadow DOM!

All kidding aside, the Shadow DOM is a browser technology enabling developers to build encapsulated DOM trees for web components. This tech allows for components with their own HTML, CSS, and JavaScript, shielded from the main document DOM. It’s particularly beneficial in Salesforce as it prevents internal component conflicts.

‍

Testing tools like Selenium, which depend on the DOM, often struggle with the Shadow DOM because it's quite opaque. Tools that utilize human-readable labels fare better. 

‍

And here's a quick tip: the DOM isn’t set in stone. It evolves, sometimes weekly, without the stability guaranteed from one release to the next, adding a layer of unpredictability to any test reliant on the DOM.

‍

Finally, let's spotlight a couple of notable features of Lightning pages: Global Controls and Pop-ups. Global Controls are omnipresent, adjusting per page with varying customization options — an aspect you'll want to familiarize yourself with for effective testing. Pop-ups offer dynamic user interaction but aren't always visible, requiring targeted testing strategies to ensure they function as intended.

‍

ISV Pages

‍

Most Salesforce ISVs appreciate the advantages of using Lightning for their page designs. However, numerous companies opt for frameworks like Angular and other libraries to craft their user interfaces. This approach is typically favored when there's substantial shared functionality across various systems, making it simpler to manage a single codebase.

‍

Adopting these alternative design systems introduces unique testing challenges, as they can behave unpredictably compared to traditional Lightning pages. 

‍

This adds yet another layer of complexity — oh, the joys of integration!

Automations

Automations are all about boosting user productivity by, well, automating those repetitive tasks. They help ensure nothing gets missed and can guide users through complex multi-step processes — so they don’t have to sweat the details or even know what comes next.

‍

Automations in Salesforce come in various forms, each with its own set of challenges. Let's dive into a few examples to understand what to watch out for.

‍

Flow

‍

Salesforce's Flow is an impressively sophisticated point-and-click tool that allows admins to automate complex processes effortlessly — no coding required. It features something called Page Flows, where admins can set up step-by-step user interactions through form-based workflows. These flows can dynamically branch based on user responses, adding a layer of interactivity and decision-making.

‍

Flows can also call out to code along the way. Updates to the database can trigger Apex, which is covered below. So testing flows is often more complex than testing a simple feature. It can be more like an end-to-end test.

‍

Apex Triggers

‍

At the heart of Salesforce's robust platform are its data-driven capabilities, such as Apex Triggers. These triggers are small pieces of code that activate when data is inserted, updated, or deleted in the database. They're essential for real-time data processing, allowing updates to fields, creation of new records or even syncing with external systems. The options are endless. 

‍

Testing these triggers is crucial — they're the backbone that ensures smooth operation and integrity of your Salesforce environment.

‍

Approval Processes

‍

Approvals are a staple in the realm of Salesforce automation, streamlining decision-making workflows crucial for maintaining data integrity and enforcing business rules. Salesforce offers a spectrum of automated approval processes to suit various organizational needs:

‍

Approval Processes: Salesforce's standard approval processes allow administrators to define a sequence of steps that a record goes through for approval. Configurable to include multiple approvers and conditional branching, they can automate actions based on the outcomes of the approval or rejection. For instance, expense reports exceeding a certain threshold can trigger additional steps for approval, ensuring no dollar is misspent without scrutiny.

‍

Workflow Rules: Traditionally used for tasks like updating fields and sending email alerts, workflow rules can also kick-start approval processes under specific conditions, automating approvals based on precise record changes or criteria.

‍

Process Builder: An evolution of workflow rules, Process Builder supports intricate, multi-step automations. It’s not just about approvals –– it also manages updates and notifications linked to the approval status, offering a more dynamic automation toolkit.

‍

Flow: Salesforce Flow: For those who dare to dive deeper, Salesforce Flow crafts complex decision-making processes that involve user interactions. It orchestrates approval steps, adjusts dynamically to user inputs and handles diverse outcomes, making it ideal for scenarios that blend automated processing with hands-on decision points.

‍

Dynamic Approval Routing: Sometimes, the path of approval needs to flex based on the data at hand. Using Apex code or Salesforce Flow, this method allows for dynamic determination of approvers, such as routing discount approvals to different managers based on the amount or region.

‍

Third-Party AppExchange Tools: The Salesforce AppExchange is a treasure trove of enhancements, including tools that offer advanced functionalities like parallel and matrix approvals. These can be integrated seamlessly into Salesforce, providing capabilities that extend beyond what's baked into the platform.

‍

Transitioning from Process Builder and Workflow Rules

‍

Heads up! Salesforce is phasing out Process Builder and Workflow Rules, nudging users towards Salesforce Flow, which offers a more potent, flexible automation environment. Though there’s no official sunset date yet, the shift is inevitable. Salesforce encourages transitioning to Flow sooner rather than later, promising that new features will beef up Flow, not its predecessors. 

‍

Long-standing users with systems entrenched in the older tools face a choice: evolve and adopt Flow or maintain and test their existing, soon-to-be-legacy automations.

‍

Lightning Components

‍

Salesforce Lightning Components are a powerful tool for building interactive and dynamic user interfaces on the Salesforce platform. Beyond merely enhancing the UI, Lightning Components are pivotal in automating and streamlining processes, thus enriching user interactions across the board. Here are some innovative ways Lightning Components facilitate automation:

‍

User-Driven Actions: Designed to react to user inputs, Lightning Components can automate tasks such as updating related records or performing calculations instantly when data is entered or a button is clicked, minimizing manual intervention and speeding up operations.

‍

Dynamic Data Handling: These components excel in managing data dynamically –– they can retrieve, display and update information based on specific criteria or inputs. This functionality is particularly useful for integrating real-time data from external APIs or adjusting form options based on previous user selections.

‍

Integration with Salesforce Flows: For more complex automation scenarios, Lightning Components can be seamlessly integrated with Salesforce Flows. This combination allows for sophisticated workflows where the component serves as a user interface, guiding the flow of automated steps and decisions.

‍

Event-Driven Automation: Lightning Components can be programmed to respond to application or platform events, triggering automation sequences when certain data changes or system updates occur, ensuring responsiveness and real-time actionability.

‍

Custom Controllers with Apex: Utilizing custom Apex controllers, Lightning Components can execute complex server-side logic, enabling them to handle extensive data operations, perform transactional processes or integrate with external systems, thereby automating advanced functionalities.

‍

Scheduled Refresh and Updates: To maintain data freshness, components can be set to automatically refresh their data at predetermined intervals or in response to specific events, keeping the displayed data current without manual refreshes and adding a layer of complexity to testing due to the timed nature of the updates.

‍

Interactive Dashboards and Reports: Lightning Components can be used to develop interactive dashboards that auto-update and display relevant information based on user interactions or other criteria. This capability not only automates the delivery of insights but also enhances decision-making processes across the organization.

‍

Conditional Rendering and Actions: These components can dynamically alter the rendering of UI elements and initiate actions based on the state of the data or user permissions, automating the visibility and functionality of interface components to tailor the user experience effectively. Again, this is a particular challenge for testing as you must ensure that the user permissions are set properly for the testing user.

‍

For developers and administrators aiming to harness the power of Lightning Components for automation, Salesforce offers comprehensive documentation, best practices, design patterns and integration techniques through its extensive developer guides. Additionally, resources like the Salesforce Developer Forums and Trailhead provide invaluable learning paths for building and utilizing Lightning Components effectively.

‍

Batch Apex and Scheduled Jobs

‍

Batch Apex in Salesforce is a powerful tool within Salesforce designed to handle large data operations that exceed normal processing limits. It enables the segmentation of jobs into manageable chunks, each processed independently, making it indispensable for tasks such as data cleansing, intricate calculations, and substantial updates or deletions involving massive volumes of records. These capabilities prevent the system from exceeding Salesforce's processing limits for a single transaction.

‍

Common Applications of Batch Apex:

• Data migration and large data volume manipulation.
• Scheduled maintenance tasks, such as data archiving or cleanup.
• Complex calculations that need to be performed on large datasets.
• Integration with external systems where data needs to be processed in batches.

As you might imagine, the fact that this process operates on chunks of data makes it a challenge to test.

‍

Scheduled Jobs streamline recurring tasks by automating their execution at predefined intervals, thereby enhancing efficiency and consistency. Salesforce supports various types of scheduled jobs through tools like Apex scheduling, Process Builder, and the more dynamic Salesforce Flow.

‍

Types of Scheduled Jobs:

• Apex Scheduled Jobs: Execute tasks coded in Apex that are triggered based on defined schedules.
• Declarative Scheduled Jobs: Utilize Salesforce's declarative tools such as Process Builder and Flow to automate tasks without the need for detailed coding.

These automated processes are vital for routine tasks such as data updates, sending emails, generating reports, and other custom processes that must operate on a regular cycle, ensuring that manual intervention is minimized and operational efficiency is maximized.

‍

For organizations leveraging Salesforce, understanding and implementing Batch Apex and scheduled jobs are crucial for maintaining data integrity, ensuring timely operations, and optimizing the Salesforce environment to meet complex business needs effectively.

‍

Einstein Automate

‍

Salesforce Einstein Automate is an advanced suite within the Salesforce platform, crafted to enhance and streamline business processes through automation and artificial intelligence. This suite is pivotal for automating complex business functions like customer onboarding, service case routing and management, and optimizing sales processes.

‍

Key Components of Salesforce Einstein Automate:

• Flow Orchestrator: Simplifies the creation of complex workflows, enhancing process efficiency.
• MuleSoft Composer for Salesforce: Facilitates seamless integration of apps and data.
• Einstein Next Best Action: Provides AI-driven recommendations for the next steps in user interactions.
• Robotic Process Automation (RPA): Automates repetitive tasks, reducing the need for manual input.
• AI-Enhanced Bots and Virtual Agents: Engages with users in real-time, providing intelligent responses and support.

Testing these automation tools within Einstein Automate presents unique challenges, particularly with AI-driven components like Einstein Next Best Action. These tools often rely heavily on the specific data within the testing organization (test org), and their outputs can be non-deterministic. This means the results may vary, making consistent testing critical to ensure reliability and effectiveness in live environments.

‍

Understanding and implementing these components effectively allows businesses to leverage the full potential of AI within Salesforce, driving efficiency and enhancing user experiences across various touchpoints.

‍

Integrations

‍

Integrations are commonplace in Salesforce setups, often involving external systems. These integrations range from simple API calls to retrieve data, to embedding UI from another platform into Salesforce's workflow. They can activate processes in those external systems or trigger different processes within Salesforce itself.

‍

This introduces a layer of complexity that must be carefully managed to ensure everything functions as expected in Salesforce. The integration of external systems, especially via API, can significantly enhance Salesforce's capabilities but requires thorough testing to ensure reliability and performance.

Data Model

Salesforce excels at providing for customizing the data model. In fact, the earliest customizations were focused on updating the data model, so these capabilities are among the oldest in the platform. 

‍

Custom Fields and Objects

‍

In the page layout section above we mentioned custom fields and objects from a UI perspective, but this is only one way that they manifest themselves in apps. 

‍

Earlier, we discussed custom fields and objects from a UI perspective, but these elements manifest in apps beyond just user interface interactions. Salesforce provides a comprehensive Data API, allowing access to any object and field, which may impact system behavior through automation or conditional Lightning Components. This complexity means that tests must directly access these fields to determine the expected behavior of applications accurately.

‍

Salesforce Connect 

‍

One of Salesforce's most potent tools for integrating external data is Salesforce Connect. It utilizes external objects, similar to standard Salesforce objects but residing outside the Salesforce environment. This data is accessed on-demand via OData protocols or custom Apex adapters, ensuring real-time data retrieval. Integrating with external databases, web services and legacy systems, Salesforce Connect adds a layer of complexity to test management due to the reduced control over external data sources.

‍

Impact of RBAC and Sharing

‍

Role-Based Access Control (RBAC) is a fundamental aspect of a Salesforce application, determining user access through profiles and permission sets. The role hierarchy and sharing rules can dynamically change access, significantly impacting testing.

‍

This is a critical part of testing salesforce. When your test “logs in” to Salesforce, it does so through a user. Tests are run with a role and profile assigned to that user which determines what they can see and access. A test may work perfectly well when the test author is running it, especially if they have View All Data or Modify All Data as many developers do. But the User’s Access Rights may be different from the test author and therefore behave differently.

‍

Einstein AI

‍

As previously touched upon in the Einstein Automate discussion, the complexities of AI extend beyond mere automations. AI tools, including those within Salesforce's Einstein AI, often yield non-deterministic results — a common trait across many AI-based systems.

‍

When testing these non-deterministic systems, it's crucial to understand that the outcomes of a test may vary from one run to another. This variability means that relying solely on straightforward value checks in your test cases will be insufficient. Instead, alternative validation methods are necessary to accommodate the unpredictable nature of AI outputs. This ensures that even when data or interface elements exhibit variability, the integrity and accuracy of your testing remain robust.

Sandbox Environments

‍

Salesforce Sandboxes serve as isolated testing environments that allow developers, administrators, and testers to work with copies of their production data and metadata safely. These environments are essential for development, testing, training and experimentation, ensuring that changes do not impact the live production environment.

‍

Types of Sandboxes in Salesforce:

1. Full Copy Sandbox: This is the most comprehensive type, including all data from the production org. It's primarily used as a staging environment to mirror production, ensuring that any deployments to production are flawless. It's also used for extensive final release testing and training purposes.
2. Partial Copy Sandbox: Provides a complete copy of all metadata but only a sample of production data, managed through templates. This setup is less costly than a full copy and is ideal for testing since it represents all applications and functionalities accurately without the high data volume.
3. Developer Sandbox: Designed for individual developers, this environment contains limited data capacity and is used primarily for functional and unit testing of specific features or changes.
4. Developer Pro Sandbox: Similar to the Developer Sandbox but with slightly more data capacity, accommodating small teams or more complex development tasks.

Each sandbox type is tailored to different testing and development needs, from full-scale integration and user acceptance testing in Full and Partial Copy Sandboxes to specific feature testing in Developer and Developer Pro environments.

‍

By understanding the specific capabilities and limitations of each type of sandbox, teams can optimize their development and testing strategies to ensure robust, reliable applications without risking production stability.

‍

Sandbox Data Hygiene

‍

The data in sandboxes may be refreshed on a periodic basis, meaning data is copied from the associated production environment into the sandbox. A Full Copy sandbox is large enough to hold a full copy of all the production data. If it didn’t, you would start to question the name, right? Partial Copy, Developer, and Developer Pro sandboxes only hold a subset of the data in production. The developer versions hold significantly less.

‍

What is Sandbox Data Hygiene? It involves managing the differences in data and metadata in the sandbox compared to the production environment it's based on and the adjacent environments in the pipeline. This becomes critically important to the proper execution of tests, especially when AI and Machine Learning are involved. We will discuss test data management more thoroughly in Chapter 7, but for now, we will mention two very important points about sandbox data:

1. Sandbox Drift: These environments are living, breathing entities. Their contents do not remain static over time. Even a full copy sandbox, which has just been refreshed, tends to drift away from production over time, which can impact your tests.
2. Personally Identifiable Information and Company Confidential Information: When your team operates in these lower environments, they typically have greater access than they do in Production environments. Therefore, data copied to lower environments should be purged of any sensitive data. Ideally, you will use a data migration tool to obfuscate any sensitive data when it is loaded from Production. At the end of the day, you are looking for data that is representative of production for testing purposes.

Takeaways

‍

Congratulations if you've made it this far into the chapter. For those of you who skipped straight here, pretend you didn't see that!

‍

By now, you should have a deeper understanding of the complexities involved in Salesforce testing. Salesforce has evolved into a robust platform, incorporating a vast array of features and functionalities over the years. Long-time users will recognize many elements discussed in this chapter.

‍

As you embark on or continue your testing journey, you might find it prudent to tackle the technical debt and modernize old solutions by removing deprecated features. This strategy not only streamlines your process but also minimizes the testing scenarios — making your testing efforts a bit more straightforward. Remember the old saying: "If it ain’t broke, don’t fix it." Well, this is not always the case. 

‍

Looking ahead, the next chapter will dive into the various types of testing available. If you thought testing was a one-trick pony, hold onto your hats — it's going to be a wild ride!