EuroSTAR Conference

Europe's Best Software Testing Conference

Exploratory Testing

How Functional & Visual Testing Ensures Customer Satisfaction

by

Thanks to SmartBear for providing us with this blog post.

E-commerce businesses lose 35% of their revenue due to poor user experience, according to Amazon Web Services, or about $1.4 trillion annually. On the other hand, UX Planet found that every dollar spent on improving UX/UI will return $10 to $100 – especially for software-as-a-service (SaaS) businesses with sticky business models.

Let’s examine why customer experience matters and how you can leverage functional and visual testing to eliminate errors.

Customer experience is critical to the success of any business – but especially software businesses. Here are some ways to minimize the odds of an error reaching customers and impacting their experience.

Why Customer Experience Matters

The customer experience is essential to the success of any business. For example, if a clothing retailer doesn’t stock the right products or has unhelpful employees, their sales will undoubtedly suffer.

However, customer experience is even more critical in online businesses where competition is fierce. With e-commerce and software-as-a-service giants constantly fine-tuning performance and testing new features, consumers have high expectations for usability, performance, customer service, and feature development velocity.

Just consider some of these statistics:

  • A 0.1-second improvement in site speed leads to an 8.4% increase in e-commerce conversions and a 9.2% increase in average order value. (Deloitte)
  • 70% of customers abandon purchases because of a bad user experience. And 67% of customers claim unpleasant experiences as a reason for churn. (Intechnic)
  • 62% of customers say they share bad experiences with others. (Intechnic)

You can choose from several ways to improve the customer experience, including collecting product feedback, improving website performance, and investing in customer success. For example, many organizations track net promoter scores (NPS) or other metrics to assess customer sentiment and then take action to improve specific business areas.

However, there’s little doubt that errors and exceptions are some of the most egregious factors influencing the customer experience. After all, nobody will trust you if your product doesn’t work correctly. And even the stickiest customers will churn if they experience too many problems.

You can avoid these errors by investing in testing solutions and implementing a few best practices.

Functional Test vs. Visual Testing

Most software businesses use functional tests to ensure that errors don’t impact the customer experience. For example, these tests may attempt to register a new user and check that the user successfully appears in a database. And by automating these tests, it’s easy to ensure that code changes or additions don’t introduce errors in existing code.

While simulators and emulators provide a spot-check, real devices power the most reliable function tests. Cloud-based device farms can help scale tests across different devices, operating systems, and browsers, providing a cheaper and easier alternative to in-house device farms. And you can use tools like Appium to maintain automation.

But, of course, there are limitations to functional tests. For example, functional tests might verify that a sign-in form is working, but a CSS error might render it invisible to some users (e.g., a mistake in a media query). As a result, the functional test would pass with flying colors, but the customer experience would suffer a fatal blow.

The most common way to avoid these problems involves manual testing. For instance, a QA engineer might sign on to a device (or a device cloud instance) and go through common workflows to identify visual errors. But obviously, that’s an expensive and time-consuming process – especially for large applications with many workflows.

Visual testing can help overcome these challenges with the help of artificial intelligence. As part of a test automation process, visual testing tools can automatically take screenshots across various devices and compare the image to historical snapshots to detect changes. Then, your QA team only has to spot-check significant changes.

How BitBar and VisualTest Improve UX

BitBar and VisualTest can help you ensure a robust customer experience by catching functional and visual regressions as part of your test automation process. Using device clouds at their core, they run both functional and visual tests across thousands of real devices to produce the most accurate picture of your application’s status.

BitBar’s device cloud can help you run automated functional tests in parallel across browsers and devices. For example, you can upload a mobile app and existing Appium tests to BitBar Cloud and execute them on your existing CI/CD using a REST API. Similarly, you can add Selenium test scripts and test web applications in just a few clicks.

BitBar makes it easy to review test sessions across different devices. Source: BitBar

VisualTest adds – you guessed it – visual tests to these capabilities. Using AI technology, the platform quickly confirms that your app looks how you and your customers expect. For example, you can add a short piece of code to your tests to take screenshots with an identifier, and the platform will automatically identify and report visual regressions.

If you find a regression, you can also use BitBar to reproduce the issue on an actual device in the cloud. That way, developers can diagnose problems more quickly without diving into logs or trying to find and configure physical devices. Similarly, QA teams can use BitBar’s devices to conduct other ad hoc tests to confirm fixes or verify functionality.

Best of all, these tools easily integrate into existing CI/CD workflows and your overall development process. You can even combine them with TestComplete to enable non-technical individuals to create robust tests for web and mobile applications. Or, you can use CucumberStudio to enhance your test coverage and generate living documentation.

The Bottom Line

An excellent customer experience is essential to the success of every software business. As a result, it’s a good idea to invest in top-notch testing tools to spot visual and functional errors before they reach customers. BitBar and VisualTest make implementing robust automated functional and visual testing alongside your CI/CD processes easy.

Sign up for a free trial of BitBar and a free trial of VisualTest today!

Author

Jessica Manheimer

Jessica Manheimer is a Product Marketing Manager with SmartBear specializing on UI test products with an explicit focus on BitBar.

Jessica has over 8 years of experience delivering technical solutions to customers and crafting content to support product launches.

SmartBear is an EXPO Gold partner at EuroSTAR 2023, join us in Antwerp

Should You Focus on Unit Versus End-to-End Tests?

by

Thanks to Subject7 for providing us with this blog post.

A common question is how much of each type of testing should I do. And to answer how much, how many, or what ratios, we need a way to count and compare types of tests. A small unit test might take a minute or two to write and 10 milliseconds to run; a small end-to-end test might take a half-hour to create and a minute to run. When it takes a tester to create one end-to-end test, a programmer might create several unit tests.

Does that satisfy the pyramid’s requirements of a broad base? Or are we just comparing apples to oranges?

Talking to the people who kicked around the original ideas, we can conclude that the intent was one of focus: The team should focus on the unit tests more than the higher-level tests. In other words, they should build a solid foundation first.

Matrix measurement and output


These ideas are conceptual advice, but they are not very practical. To figure out the ratio, we would need to measure the number of minutes people spend on activities at various levels, then compare high-functioning teams to low-functioning, and then eliminate other independent variables.

However, the reality is that no one does this sort of measurement at the industry scale. In his landmark paper Software Engineering Metrics: What Do They Measure and How Do We Know?, Cem Kaner suggests we have so little agreement on what words mean – is the build maintainer a developer? A tester? What about user experience specialists? Kaner argues that comparisons like figuring out a developer-to-tester ratio make little sense. Even with a survey of every company, the metrics would reflect an average of all the people who responded to the survey. Companies with an external API as a main product would undoubtedly have a different ideal ratio from those that do electronic data interchange (EDI) as a business. Likewise, software as a service (SaaS) companies, like GitHub or Atlassian (who makes Jira), will have a different approach from insurance companies and banks that do data processing.

With that in mind, the question becomes less about the “right” industry-standard number for each type of test or even the right number for your company. Instead, the question is, “should our team be doing more or less of each type of testing?”

Unit tests tend to find low-level, isolated problems and provide incredibly fast feedback to the programmer. Integration and API tests find problems gluing together components, often due to misunderstanding the protocol — how the information is transferred. End-to-end tests exercise the entire system, ensuring the complete flow works for the customer.

Challenges faced by teams.


It is tempting to get the data you need from a Scrum retrospective. But people in Scrum retrospectives tend to focus on a single incident or something that has happened only a few times. We want an objective assessment that looks at what has happened over time, not what people experienced in the past two weeks.

Instead of a retrospective, we suggest looking at bugs found recently. That includes bugs found in testing and later by customers after they escape to production. This evaluation includes quantitative data and qualitative data from reading the bug reports, particularly for impact.

When we’ve done this, we’ve gone back somewhere between a month and six months and pulled the bugs that qualify into a spreadsheet, with a column for the root cause and another for where the defect should have been found. Most recently we’ve just looked at the last hundred bugs. If your team does a “zero-known-bug” policy and doesn’t write them up but fixes them, you might need to write down what you find for two to four weeks.

One team we worked with recently had a great number of user interface bugs that were based on regressions — that is, a change in one piece of the code had unintended consequences in a different area of the code that seemed to be unrelated. It was a mobile application, and the screens used shared code libraries. The changes were visual and mainly concerned with the look and feel of elements like text boxes and combo boxes.

Another team had mobile application problems that showed up mostly when testing with real devices, such as a sticky scroll on an iPhone or changes in screen design that did not render properly when the screen resolution changed for various devices. This was an e-commerce application for a luxury brand, and as it turned out, iOS represented an extremely large percentage of actual dollars spent on checkout.
None of these bugs would have been caught by unit tests. In these cases, the focus clearly needed to shift to more user interface and end-to-end tests.

Another data point comes from looking at how often testers are waiting for a fix, how long that wait is, and if the problem could reasonably have been found by end-to-end tests. Waiting is one of the seven wastes of the Toyota Production System. In software, we tend to “paper over” waiting by having people work on other tasks, but the wait (and delay) is still there. Gathering data for this problem can be as simple as going to the daily standup and getting a list of stories (and bugs) the testers are waiting for, then working backward to see if end-to-end tests would have found those defects or if unit tests could have found them.

Prevention is better than cure.


Bugs that escape production can be a little trickier. In some cases, the team needs additional end-to-end tests. In others, the problem was a lack of creativity and freedom within the testers — “Nobody thought to test that,” or in some cases, “We thought to test that, but the setup was hard, and the programmer said it could never happen.”

The classic question, “Why didn’t QA find that bug?” is really unproductive here. Instead, the questions are “Can this bug reoccur?” and, if so, “How should we shift the test effort to find the defect?”

For one team we worked with, the bugs that escaped to production were relatively unique: a configuration flag was left pointing to test.companyname.com when an API was called, or a database indexer ran for too long and caused all requests from the database to block. These were big problems but relatively rare, best addressed by policy and procedure.

Certainly, a test running on test.companynname.com could never find that problem. In other cases, the issues in production were infrastructure-based and could have been found by making the change in a test environment, then running the end-to-end tests against that environment.

A final question to consider is how many of the crucial defects that are discovered are through exercising the entire system (often regressions), and how many are limited to new feature development. Many new feature bugs would imply the need for better exploratory testing and, perhaps, more unit tests. You would need to dig into the details.

End-to-end and GUI tests provide value when the workflow breaks. If testers spend a great deal of time dead in the water waiting for bug fixes, it’s likely time for more end-to-end testing. On the other hand, we’ve worked with teams where the first build simply did not work at all, and the simplest combination of inputs rendered an error. In that case, focusing on unit tests, or at least programmer-testing might be best.

Starting points to quality testing at speed


Here’s a place to start: Is the code quality on the first build delivered to test “good enough?” If not, then is the problem one of insufficient regression testing? Or do the issues stem from new features?

If the problem is insufficient regression testing, analyze whether the issues could be found by end-to-end testing. Test the login, search, create a new page, and create a profile — errors that block the flow of work might be findable by end-to-end testing. Other problems, like a sticky scroll, might require more engineering work to build better code. If the problem is new feature development, examine whether the programmers should do more unit tests or better check their work before passing it off.
These questions don’t provide a percentage or ratio, but they can help set expectations for change.

On a full delivery team of 10 or more developers, analysts, and testers, the next step will likely take someone half-time to work on the area that needs emphasis. Often programmers feel like they need permission to do more unit tests (or write end-to-end tests themselves), while testers feel like they need permission to beef up the regression-check automation. Insisting on obtaining this permission will slow down the pace of delivery.

Still, if the heavier concentration on unit testing was buggy, and those bugs delayed release, a heavier emphasis on end-to-end testing may result in less back-and-forth and better quality in less total time. Think of this as reducing the big, ugly delays by investing in a little more end-to-end testing. You may even end up going faster. That is a win.

Author

Payam Fard – Co-Founder Subject7

Payam has over 20 years of experience in the software development and process automation industries, spanning both federal and commercial sectors.  During his career, he recognized one of the main challenges of test automation – the mismatch between the technical experience of testing teams and the complex test automation solutions that existed in the market. 

He co-founded Subject7 with the intent of developing a comprehensive test automation solution that would empower business and non-technical users to deliver sophisticated and scalable automation without the need for any programming experience. At Subject7, he has focused on ensuring the success of early customers and evangelizing the benefits of codeless technologies for the test automation industry. 

Prior to Subject7, Payam spent his career developing large-scale business applications for federal agencies, working for SAIC, CSC, Raytheon, and Hughes Network Systems.  He obtained B.S. and M.S. degrees in Computer Science from the University of Maryland and an MBA from The Johns Hopkins University.

Subject7 is an EXPO Gold partner at EuroSTAR 2023, join us in Antwerp

Exploratory testing in agile

by

Thanks to Xray for providing us with this blog post.

The purpose of exploratory testing is to learn how a particular area of your testing is working while using your skills as a tester to offer insightful input to your team. Through exploratory testing, you can ensure that all bugs are detected, and developers can fix them in time for the product release.

Exploratory testing is important and should be a component of your testing strategy since it helps you evaluate your tests’ efficacy, identifies code inconsistencies, and removes bottlenecks where defects are most likely to lurk.

In this post, our solution architect Sérgio Freire gives you the best tips on how to do exploratory testing in an agile environment.

Working in an Agile context

At the start of a product or one of its releases, we assume that we know everything there is to know about the product. However, there are often many unknowns and assumptions.

Agile comes as a way to deal with the complexity and unknowns around the whole software development and delivery process. When working in an Agile context, the software is delivered in small batches, known as iterations.

The idea is to reduce the batch of work and learn with small experiments. So, instead of working for a long time on a complex feature, we iterate on it by collecting feedback, learning, and incorporating our findings.

All this means that many changes are due to these iterations driven by our findings and feedback.

Exploratory Testing and Agile

The following model called the “Learning Lollipop model” (created by Sergio Freire), tries to highlight what happens during exploratory testing.

It’s a way to frame exploratory testing where we “taste” our product/product ideas (like tasting a lollipop), starting with questions that will give us ideas for designing testing experiments that we execute and then analyze. From this process, we learn. In turn, that will raise additional questions that will trigger new ideas for test experiments. While we do so, we walk in the unknown lake that contains all possible usages of our product. The more we explore, the more we find.

Using an example, let’s first try to see how these actually work well together. Say we are working in a system with a set of features, aiming to add a new feature using an Agile approach.

From a testing perspective, what we had (i.e., how the system behaved) should be covered by a set of checks, using test automation scripts as much as possible. This will allow us to collect almost immediate feedback from the CI pipeline(s).

We cannot simply retest everything from the past “by hand.” We also know that test automation scripts are fallible because they will always be limited to testing what they’re hardcoded to check; however, they give us a good starting point.

Whenever iterating on a new feature, we know that we don’t know much about it beforehand; that’s why we’re iterating it, after all. Usually, we’re dealing with a rough user story and not an extensive, highly detailed requirement.

Therefore, we need to test our initial ideas for the user story and depict areas/risks we should have in mind. Many questions will come, at the start, during, and after the implementation. All these can become ideas for test charters that we can explore with Exploratory Testing sessions.

Remember that in an Agile context, changes are frequent, and risks also change very dynamically.

Exploratory Testing is a great fit in Agile, as it is extremely flexible and doesn’t require upfront preparation (as happens with manual scripted test cases). It also uses information from previous sessions to drive new testing sessions. Therefore, it adapts to changes as it doesn’t assume a certain state and expected results for the system.

Tips for exploratory testing

Exploratory testing mockups.

Perform exploratory testing sessions on early mockups, internally and with users. This can be quite helpful to optimize flow problems, for example, and highlight the most valuable ones. You can also apply exploratory testing during your design sprints.

Discuss upfront with the team possible charters for your exploratory testing session.

During regular meetings (e.g., standups, planning), discuss with the team the test charters (i.e., the questions you aim to answer during testing). It’s a good moment to talk about risks and have insights from different team members, giving ideas for further exploration.

It’s always a good time to perform an exploratory testing session.

Whether you’re adopting waterfall or Agile, it’s always a good moment to perform some exploratory testing. We will never know everything about our product/system and its context, but we can further improve our understanding by conducting exploratory testing sessions. There are many quality attributes we can look at, for example. Consider aspects that concern your team, users, and business, and use that to drive new sessions. Taking some time to explore is investing in knowledge so that we can then work towards incorporating that feedback and improving our product/system.

Use exploratory testing to highlight ideas for test automation scripts.

Features should come with code, including unit and integration level tests and even system tests if appropriate. Whenever performing exploratory testing, one of the outputs can be ideas for test automation scripts. During exploratory testing, we may find flows, impacts, and edge cases, for example, that, due to their relevance, should be covered by “automated tests.”

This applies to the waterfall and Agile projects and will allow us to improve test coverage addressed by test automation and hopefully gain more time to focus on other tasks (e.g., further exploration, fixing problems, etc.).

Perform exploratory testing on the feature branches or the PRs.

If your team uses feature branches while features are being implemented, you can and should test. This means working with developers to improve the feature iteratively. You may perform an exploratory testing session around a certain risk, quality attribute, or subset of that feature at a given moment. You can also perform a session when the PR is ready for review; if you tested while it was implemented, then this moment will eventually be more of a high-level type of charter.

Perform exploratory testing after merging branches.

Merges sometimes produce unexpected results. Even though the feature branch may (should) include automated tests, there can be unexpected consequences, so scheduling an exploratory testing session can help uncover them.

Involve developers and other roles in exploratory testing.

Besides testers, getting others on board for exploratory testing can provide additional perspective. At the same time, foster a quality centric culture where team members can improve quality from the start in the future.

Pairing with a developer, with the PO, with a designer is a good practice to understand not just the system from different angles but also what different stakeholders expect from it; besides, it’s an excellent mid/long-term investment towards better quality.

Don’t limit exploratory testing to non-regression.

Even whenever automated regression tests may cover existing features, it’s a good practice to perform exploratory testing also for regression testing if you have the opportunity to. Test automation can cover the essentials, but we know many things escape these tests as they will always be limited in number and scope. Looking back at your previous features with your eyes wide open may depict problems added meanwhile and problems that you didn’t have the opportunity to uncover.

Exploratory test your test automation.

Look at your existing test automation and explore it to look for problems (it’s also code, isn’t it?). Look also for problems in scope, concurrency, and relevance. Look at your existing test automation logs, as they may provide valuable information or expose too much or too little information.

Exploratory test using tools to augment testing and gain efficiency.

Tools are used to perform certain tasks with efficiency and consistency. In exploratory testing, tools are used to augment the tester’s capabilities, not to replace the tester. An exploratory tester will easily use tools to facilitate API requests and assist with performance testing. With tools, an exploratory tester can be more efficient and cover quality aspects that otherwise would be hard or even impossible to tackle.

Exploratory test looking for gaps and opportunities to improve the value.

While testing, we look for problems that affect the quality and, therefore, the value as seen by different stakeholders. Testing is about understanding how the system works connected with expectations from all these different stakeholders. In this sense, testing is also about finding opportunities to increase the value. During exploratory testing, and using our knowledge and background, we can depict ways of improving the value of our products. Maybe that can be about framing the feature slightly differently, trying out a new form or interaction.

Bringing some agility with Exploratory Testing to waterfall projects

For organizations working on waterfall-based projects, testing mostly occurs after features have already been implemented. We know that if this happens, then the cost of fixing problems increases considerably.

Usually, there are initial requirements that drive implementation. These highly detailed specifications are not immune to problems; on the contrary: they can be built on top of many assumptions and lack actual user feedback.

We know that requirements, and specifications, in general, are incomplete, ambiguous, sometimes contradictory, and easily get outdated.

As exploratory testers, we can use not only requirements and other documents as the source for our tests; we also understand the context of our product, know about similar products, and know of known heuristics that can help us expose problems through test tracking and reporting. We also have our background that we can use to expose risks and impacts that otherwise could escape traditional testing.

In waterfall projects, we can use Exploratory Testing to help us:

  • Uncover problems, risks, and gaps that we couldn’t predict beforehand as they were not identified in the requirements/specifications.
  • Introduce testing while the feature is being implemented and thus refine it before it’s too late.
  • Complement traditional approaches, such as manual scripted test cases, with exploratory testing to go beyond the obvious and expose problems that we could otherwise miss.

Unleash your testing potential with Exploratory Testing

Exploratory testing promotes innovation instead of scripted testing that is centered around specified test cases and attempting to complete a fixed number of tests per day. Exploratory testing encourages us to act role play as the end-user and detects more realistic bugs.

Exploratory testing is highly helpful in agile environments and has several advantages, as seen above. QA teams can successfully use this testing strategy for their own success in the agile development process by knowing its benefits and using reliable test management software like the Xray Exploratory App.

Author

Sérgio Freire, Head of Solution Architecture & Testing Advocacy at Xray

Sergio Freire is a solution architect and testing advocate, working closely with many teams worldwide from distinct yet highly demanding sectors (Automotive, Health, and Telco among others) to help them achieve great, high-quality, testable products. 

By understanding how organizations work, their needs, context and background, processes and quality can be improved, while development and testing can “merge” towards a common goal: provide the best product that stakeholders need.

Xray is an EXPO Platinum partner at EuroSTAR 2023, join us in Antwerp

Introduction to Exploratory Testing

by

Exploratory Testing

Although test automation is the biggest trend in software testing right now, only focusing your strategy on automation isn’t going to guarantee you a fool-proof QA process.

By diversifying your testing strategy with different methods, you’ll be able to cover more ground (i.e. untested code)  and more unexpected discrepancies to your code and product.

Exploratory Testing should be a part of your testing strategy because it will test the effectiveness of your existing tests, discover code discrepancies, and alleviate bottlenecks where bugs hide the most.

In this post, QA Software Engineer, Pekka Pönkänen, tells us how he effectively performs Exploratory Testing and his advice on making the most of your sessions.

Why Exploratory Testing is important

In 2018 I walked the length of Japan, and one of my goals for the trip was to explore the country and its rich culture. During the trip, I decided to walk in different routes other than just following Google Maps, and as a result of that I had many exciting adventures. Undoubtedly, without having the curiosity to explore, I would have missed many unique places and interesting conversations with locals.

I firmly believe that in order to find new ways of seeing and experiencing the world,  you need to be brave and curious about the unknown. The same goes for software testing. Always following the same paths, or tests, will get you expected results. On the contrary, if you go on an exploratory session of your application, you’ll be amazed to discover just how many bugs could be hiding or how much you can improve the functionality for the user.

If you want to try Exploratory Testing yourself, consider this your starting point.

What exactly is Exploratory Testing?

The term “Exploratory Testing” means that you are exploring the application and how it performs after different actions.

To truly understand the concept, it is essential to dig deeper into the roots of the terminology. The term “Exploratory Testing” was introduced in 1984 by Cem Kaner.

“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work…”

James Bach’s 2003 paper, “Exploratory Testing Explained”

Through exploratory testing, your goal is to find out how a specific area of an application is working while using your skillset to provide valuable feedback to your team. You want to find the nastiest bugs under the hood and make sure that nothing critical or dangerous can happen in the app.

Preparing for Exploratory Testing

Before starting the testing run itself, it’s good to have tools to write down ideas, bugs, and defects. Personally, I like classic pen and paper and bug-tracking software to write down thoughts and plans for the future. During the run, you will see application logs, automation ideas, new approaches for new testing runs, and bugs that need to be fixed. Having good software that captures images, videos, and notes can be very helpful in centralizing your findings and sharing your insights with your team.

Keep in mind that your notes do not need to be the most delicate piece of art. What’s important is that you can gather a small story around it for your teammates or stakeholders after the session. I have heard very successful use cases with testers doing mind mapping during exploratory testing. Having this visual aid in the process can be valuable to build off of your ideas and create themes.

Identify your goal

The first thing to get started in exploratory testing is to define what to test. It can be a known bottleneck, possible risk, new feature, or an area which has a lot of bugs.

As a software tester, you may know the places to look, and the development team can define the areas which need more attention. When planning the testing, remember not to make it broad so that you don’t lose focus. Here are a few examples to get you started:

What to do:

  • Explore catalog page with a screen reader to verify page accessibility
  • Explore login process with iOS gestures to verify that functionality is accessible

These tasks can be timeboxed and can be done in one session and short enough to be focused.

On the other hand, you don’t want to choose a task that has too many options or paths to follow. The best way is to keep it simple and focus on smaller tasks.

What not to do:

  • Explore all possible mobile security issues to the system to discover any security-related threat

Once you’ve identified your goal and prepared your tools, here are the steps you can follow to complete an Exploratory Testing session:

1. Prep your session

After selecting an area to explore, design the test session. Once you know what to explore, you’ll get a flood of ideas about how to test different aspects — make sure to keep track of everything that comes to mind so you have a solid plan before you start testing. Write down your mission and prepare the notes about the way you want to proceed.

2. Setup the testing environment

Check that you have all credentials and access to enter the testing environment. Testing is pleasurable when you can focus on the testing itself, and when you don’t need to worry about usernames or unreachable servers.

3. Timebox and execute

Depending on the task, open the suitable logs, and monitor tools to log your actions during testing. Application logs are crucial to provide valuable information when things go wrong. While executing, keep your objective in mind, write notes, be systematic, collect info, gather ideas for the next sessions, and most importantly learn and explore your product.

Exploratory testing is more of a mindset than a framework

Exploratory testing is in fact a skill which is developing all the time while your skillset as a tester is evolving. The beauty of testing is that you never get bored of it because there is always room for improvement. Be curious about the application, try different approaches to execute testing, learn about your software, and share the knowledge.

At the end of the day, software development is a team sport!

Inform others about the state, risks, and any other concerns. Share your mind map as well as any evidence that you collected like videos, images and notes. You don’t have to have all of the answers, but sharing them with your team will also help others discover themes and insights which you wouldn’t have known otherwise.

——————————————————————————————–

Author:

Xray Contributing Writer | QA Engineer