Let's say you're working on a coding project. You have been writing a bunch of code and staying up late at night to fix bugs. All this is part of the process before you release that software product.

Then you'll check your code to verify that it actually performs what it's been programmed to do. This is where software testing comes in.

This article will discuss the categories of Software Testing and the different types of testing developers most commonly use. You'll see that some of the tests are named for their function. So, when I say API test, I am referring to the tests carried out on the APIs consumed in your source code.

But before going further, let's make sure we know what we mean by Software Testing.

In simple terms, Software Testing is the process of checking the various aspects of a software product to validate the software’s specifications and make sure it's ready to use.

Objectives of Software Testing

From a single line code to a block of code, and even to the finished product, you test software to:

• check for defects and ensure that the product performs as specified
• make sure that the product meets market standards
• resolve any loopholes at the production stage
• prevent future malfunctions of the product

Characteristics of Software Testing

When you test your software, you want to make sure that your tests are:

• Practical
• Reliable
• Authentic
• Capable of finding errors
• Capable of checking the validity of your software

When Should You Test Your Software?

When you test your software will depend on what test you're wanting to perform.

You can test your software during the software development phase – that is, when writing the source code, as in the case of unit testing, API testing, and others.

You can also test after the software has been developed such as in User Interface (UI) Testing.

When Should Testing Stop?

You can stop testing your software when:

• All the necessary tests have been carried out efficiently
• Bugs in the source codes have been reduced to the barest minimum or eradicated
• Testers are done testing
• Product is fully secured against threats
• The product is released

Software Testing Methods

Now that you know what Software Testing means, how exactly is it done?

Software Testing is done based on two main methods:

1. Functional Testing
2. Non-functional Testing

The major difference between these categories of Software Testing is that Functional Testing tests the functionality of a software product while non-functional testing concentrates on the performance of the software product.

Functional Testing

Functional testing is the process of testing software to validate its usefulness with regard to its specifications.

In simple terms, it consists of various tests carried out on the software generally to verify its functionalities.

Functional testing helps the software team know if the software is working as required. Mind you, Functional Testing doesn't mean testing unit functions or modules.

Examples of Functional Testing

Unit Testing

In unit testing, you test individual units or functions of your software's source code. Unit testing can be done automatically or manually.

Automatic unit testing happens with human assistance while manual unit testing is actively done by humans.

The difference between these two methods is that the former is automated while the latter requires hard-coding.

The purpose of unit testing is to ensure that each unit component is working as expected.

API Testing

An application Programming Interface (or API) is a link between your program and an external source. So, if you want your program to do more than just what you code, you could employ the features of another program also. This is what consuming APIs is all about.

For instance, let's say that I want my application to have a map feature. Instead of coding one from the scratch, I could save myself some time and stress by using one of the readily available map APIs.

Using APIs, especially from external sources, comes with its pros and cons, though. And I bet you want to reduce the cons as much as possible. Well, this is why you need to test the API prior to product release.

When you consume a public or private API, while developing your software, you should check for the API's reliability, security, and effectiveness in your product prior to release.

Image representing API

UI (User interface) Testing

The User Interface is the channel of communication between the user and the software.

Every software product is developed with certain specifications for the User Interface. This means that the way the user interacts with the application is predetermined prior to developing the product.

In order to make sure that these specifications are met according to design, you can carry out tests on the UI – and this is known as UI Testing.

The UI Testing involves things like checking if the Sign-Up page is correctly accepting inputs, checking to see if the submit button is functional, and a host of other UI features.

Image of a Payment Page

Integration Testing

Putting components into groups for testing is known as integration testing. Integration testing involves checking how each separate component works together to achieve the common aim of the product.

For instance, in an e-commerce application, the integration tests can check how the Home page connects to the Carts page when the Cart menu is clicked.

The purpose of integration testing is to make sure that components are working in synchrony – that is, that component A works well with component B.

Image of two UI pages

Regression Testing

Software Development involves iteration, which often happens because of bugs in the source code.

After debugging your code, updating the software program, or making any other change to your code, you should test that software to validate its functionality. This testing is called Regression testing.

Examples of regression testing are corrective regression testing, selective regression testing, progressive regression testing, and others.

Non-functional or Performance Testing

Non-functional testing refers to the various tests carried out on a product to check its readiness for the market. Non-functional Tests go a step further to ensure the viability of a product and its worth.

Examples of Non-functional Testing

Volume Testing

The strength of every product lies in its ability to handle different volumes of data. Some software may not function with a large database. To avoid such breakage, you can do volume tests.

Volume test involves feeding a large database to the software to check its functionality based on the large volume of data. Testing your product on different volumes of data shows that your product can withstand more or fewer data at a given time.

Security Testing

In the world today, security is an important and much-discussed topic. Concerns range from physical security down to cyberspace – and everyone wants that assurance of safety when they are on the internet.

One of the issues you'll want to avoid as a software developer is threats to your application. You can perform security testing on your software product to check its level of vulnerability.

Security tests include authentication, authorization confidentiality, and other measures required to protect your software from risks and threats.

Where to put test files in a program folder

Your test files should be together in a test folder inside the root folder of your project. This is for easy navigation and integration into your project.

Conclusion

Now that you know the importance of testing in software development, you should make sure to write code that is error and bug-free when tested.

This will reduce the time you waste fixing bugs and will in turn make the product release date more achievable.

Lastly, be careful to put your test files in the same folder, especially for tests other than unit testing.

There are a ton of testing tools available to us, but not all of them test what someone actually experiences. How can we use Applitools to visually test our project and make sure it’s actually working right?

• What is Visual Regression Testing?
• What is Cypress?
• What is Applitools?
• What are we going to build?
• Step 0: Creating a new React application with Next.js
• Step 1: Installing and configuring Cypress in a Next.js app
• Step 2: Creating your first Cypress test in a Next.js app
• Step 3: Installing and configuring Applitools Eyes
• Step 4: Visual regression testing with Applitools Eyes

You can also check out my live stream from my Twitch channel where I walked through the entire process of setting up a new app and testing it with Cypress and Applitools.

And full disclosure, I recently accepted a job as a Developer Advocate with Applitools. But you can do this tutorial using its free tier, with no credit card required.

What is Visual Regression Testing?

Similar to most tests, Visual Regression Testing is a type of test that will run periodically and at various stages of a project’s lifecycle like on pull request or production deployment to make sure everything in the app is functioning properly.

What Visual Regression Testing does differently, though, is it directly compares visual snapshots of your project. It detects any changes in content, layout, or any other detail you’d like either by statically visiting a page or interacting with it to preview the result of that interaction.

What is Cypress?

Cypress is a JavaScript-based testing framework that we’ll use to run our test suite. It runs tests in the browser, allowing us to directly check the state of our project where people will actually use it.

The great thing about Cypress is it also provides the ability to interact with the page. For instance, if we want to test that someone using our app is able to log in, we can enter credentials and submit the login form, then check that the authentication process properly worked.

What is Applitools?

Applitools is a visual testing tool and automation platform that lets us visually compare our app at different points in time, giving us the ability to check if something changed or isn’t functioning properly.

While Applitools has a few different features we can take advantage of, we’re going to focus on using the Eyes API, which we’ll use to capture our snapshot and send it up to the Applitools dashboard.

What are we going to build?

While we can really run Cypress and Applitools on a variety of project types, we’re going to use Next.js to quickly spin up a new React application. This will allow us to focus on the testing tools rather than the app itself.

Once we have our app set up, we’ll install Cypress and Applitools so we can use them to run our visual regression testing.

Note: you’ll need to have an Applitools account in order to set up visual regression testing. You can sign up for a free account at applitools.com.

Step 0: Creating a new React application with Next.js

To get started, we’re going to use Create Next App to create a new Next.js app.

Once you’re in the directory that you want to create your new project in, inside of your terminal run:

npx create-next-app my-testing-app

Note: you can change the project name from my-testing-app to whatever you would like.

This will clone the default Next.js example from GitHub, install the dependencies, and immediately allow us to get productive with our testing tools.

Once it’s finished, navigate into your new project:

cd my-testing-app

Start your development server:

npm run dev

And now your site should be available at http://localhost:3000!

New Next.js App

Step 1: Installing and configuring Cypress in a Next.js app

Now that we have our app set up, we want to install Cypress so that we can use it to run our tests.

Back inside of our terminal, we can install Cypress with:

npm install cypress --save-dev

Here, we’re including the —save-dev flag, as we don’t need Cypress to run in the production version of our application, so we install it as a dev dependency.

Once that’s complete, we need a way to run Cypress from the command line. While we can navigate to Cypress itself, we can instead add a new script command, which will make it easier to run Cypress.

Inside of package.json, under scripts, add the following:

"cy:open": "cypress open"

Now, inside our terminal, we can run that script to open Cypress:

npm run cy:open

If this is the first time you’re running Cypress, it might take an extra second and install Cypress in your project.

Opening Cypress for the first time

Once finished, Cypress will open a new dialogue panel that will serve as your dashboard for running tests for your project.

You’ll also notice that Cypress lets you know they also added a new directory to your project at cypress. This includes example files that let you see how Cypress works and immediately get started.

To try this out, on the right side of the Cypress panel, click Run 19 integration specs.

Cypress will then open up a new browser and run through all of the example tests.

Next, we’ll add some of our own tests.

Follow along with the commit!

Step 2: Creating your first Cypress test in a Next.js app

Now that we can successfully run our tests, let’s try adding our own.

We don’t need really any of the tests that Cypress included in the examples, so let’s remove the entire integration/examples directory.

Then, create a new file under integration called home.spec.js and inside add the following:

/// <reference types="cypress" />

context('Home', () => {
  beforeEach(() => {
    cy.visit('http://localhost:3000');
  });

  it('should find the title of the homepage', () => {
    cy.get('h1').contains('Welcome');
  });
});

In the code above, we’re:

• First adding Cypress as a reference type, which allows Cypress to find the file and know that it should use it to run a test
• Creating a new context for our test and defining it as Home
• Telling Cypress that before each test, we want it to visit our homepage
• Defining a test that grabs the h1 and checks that it contains “Welcome”

If we now look back at Cypress, we’ll see that we only have that one Integration Test. If we click it and try to run the test, we’ll see that we actually get an error, as we never started up our development server, meaning it’s not available.

To fix this, we’re going to use a tool called start-server-and-test.

This package will do what the name implies, it will:

• Start our server based on the command we provide
• Run the tests that we provide
• Stop the server once complete

To add it, inside of our terminal let’s run:

npm install start-server-and-test --save-dev

Then, inside of our package.json file, we’re going to add another new command to the scripts object:

"test": "start-server-and-test dev 3000 cy:open"

Here, we’re telling start-server-and-test that we want to run the dev command to start our server, that it will be available at port 3000, and that we want to run the cy:open command after to run our tests.

And if we go back to our terminal and run:

npm run test

We’ll see that Cypress opens up like before. But if we now run our test, we can see that it successfully opens up our Next.js app and it sees the word “Welcome” inside of our h1!

Successfully running a test in Cypress

Follow along with the commit.

Step 3: Installing and configuring Applitools Eyes

With Cypress successfully running our tests, we can now hook into our tests and use Applitools to run visual regression testing on our project.

Before we dive in, make sure you have a free account set up over at Applitools, which we’ll need in order to set up an API key.

To get started, we’re going to need to install the Eyes library to our project.

In our terminal, we can run:

npm install @applitools/eyes-cypress --save-dev

Which will install the Cypress-specific SDK for Applitools Eyes.

Once that’s finished installing, we can run the Eyes setup script.

npx eyes-setup

This will go through the project and add the necessary configurations to Cypress to make Eyes work properly.

Finally, we’ll need to make our Applitools API key available whenever we run our tests.

To start, we need to find our API key in our Applitools account.

Inside the Applitools dashboard, select My API Key under the account dropdown.

Finding the Applitools API key

It will open a dialogue where you can select and copy your API key.

Copying the Applitools API key

You’ll want to save this API key for later when we run our tests.

Next, we’ll want to be able to set our API key. We can do this a few ways:

• Export the environment variable in our shell before running the tests
• Prepend the API key to the test command
• Add the API key to the applitools.config.js file
• Create an environment variable using dotenv and the cypres-dotenv package

For this demo, we’re going to run our test by prepending the API key to our command. This will allow us to quickly test this out.

To do this, any time we run a command like npm run test, we’re going to include our API key in front of it like:

APPLITOOLS_API_KEY="abcd1234" npm run test

Note: remember to replace the API key with your unique ID.

And now, we should be ready to add our first test.

Follow along with the commit!

Step 4: Visual regression testing with Applitools Eyes

We have Cypress and Applitools both configured and ready to go, meaning we can now add Applitools Eyes to visually test our app!

Our app doesn’t have a lot of functionality yet., so we can start off with a basic check that makes sure our homepage looks the way it’s supposed to each time our tests run.

To start, inside of our cypres/integrations/home.spec.js file, let’s add the following right below our existing it statement:

it('should verify the homepage looks as expected', () => {
  cy.eyesOpen({
    appName: 'My App',
    testName: 'Homepage Check',
  });

  cy.eyesCheckWindow({
    tag: 'App Window',
    target: 'window',
    fully: true
  });

  cy.eyesClose();
});

Here’s what we’re doing here:

• First, we’re “opening the eyes” of Applitools, which will prepare the Eyes functionality to check our app
• Next, we’re running a check on the window of our application, essentially capturing a screenshot of our app and sending it to Applitools
• Finally, we “close the eyes” of Applitools, letting Eyes know that we’re running our checks

Now, if we run our test command and start our test:

APPLITOOLS_API_KEY="abcd1234" npm run test

We can see that Cypress runs our new test case which doesn’t appear that it’s doing anything inside of our browser, but shows a passing indicator.

Successfully ran an Applitools Eyes check in Cypress

Now, if we go back to our Applitools dashboard:

First snapshot in Applitools

We can see that we have a new “run” titled Homepage Check (which we specified in the code) which shows that it passed with a snapshot of our app.

Now, having this screenshot alone isn’t what makes this powerful. From now on, any time we run this test, Applitools will compare our app against this original snapshot and let us know if anything changed.

To test this out, we’re going to change the color of title of our page. This might seem like a simple change, but style changes can be more challenging for tools like Cypress alone to detect an issue, which is where Applitools Eyes will shine with its snapshot comparison.

Inside of styles/Home.module.css file, let’s add the following to the .title class:

color: #ddd;

Next.js app with light gray title

While we may not have intentionally made a change like this in practice, this could have happened if we were changing styles that cascade to our title. This makes our title hard to read, but that makes this perfect for a test case.

Now, let’s run our tests again:

APPLITOOLS_API_KEY="abcd1234" npm run test

But this time, we can see that our test fails!

Cypress throwing an error with the Applitools Eyes check

Our Applitools test fails because it states that “Eyes-Cypress detected diffs or errors during execution of visual tests”.

If we look inside of our Applitools dashboard:

Change detected in text of app title in Applitools Eyes

We can see that we now have an “Unresolved” run where Applitools shows us the differences on the page, which in our case, is the "Welcome to" part of our title.

This is super useful when working on projects where it can be challenging to test every single page or type of page in an app. We can make sure that if anything changes or breaks, it will immediately get flagged in Applitools.

From here, if we’re happy with color change, we can accept the new version of our app.

Accept or reject changes in Applitools Eyes

Otherwise we can reject it and let our team know that it needs to be fixed.

Follow along with the commit!

What’s next?

Between Cypress and Applitools, we have a lot of things we can do to make sure that our app is behaving the way we want it to.

Most of the time when we’re building an app, we’re building that app so people can interact with it.

Using Cypress, we can click on different parts of the page, changing the state of the page, then run a check with Applitools Eyes to make sure it’s functioning the way we expect it to.

We can also have Cypress run on different browsers to make sure our app is working properly everywhere someone is trying to use it!

Here’s a problem I’ve encountered over and over again during my 5 years as a UX designer at Melbourne agencies: no budget.

“We would love to do user testing, but we can’t afford it.”

It can be hard to sell user experience design. Especially when you’re working with a small or medium-sized business with a modest website budget. Every dollar is a fight, and spending 25% of the budget on “just talking to people” can be a hard sell.

People outside our field often seem to think talking to users is a waste of money. Well, let’s entertain that premise. Given that one of a UX designer’s core skills is empathy, let’s make an effort to see things from these outsiders’ perspective.

The way to view this challenge is not to ignore user testing (or whatever else it might be that you don’t have the budget for). It’s to explore ways to get around these constraints.

If you show value to your clients through work that had zero budget, well, you’ve just earned yourself a budget.

“Design is easy. Getting people to give a shit about design is what’s hard.” — Tim Evans, head of UX at My Local Broker

So, in this series, I’m going to share some tips and tricks I’ve learned along the way to help you get great results with little to no budget. I’ll use a popular design framework to base it on. I’ll take you through the steps required to get some great insights, while not spending very much of your website’s budget.

The Design Process

In order to set the scene for this, there has to be a process. A method behind the madness. Personally, I prefer to shoot for the stars then strip back. Map out your ideal process, then look at what you’re really trying to achieve with each step. Get beyond the ‘what’ you are doing to the ‘why’ you are doing it — you’ll find that there’s plenty of ways to achieve the one goal.

There are plenty of great processes out there, but context is incredibly important. Choose a process that’s close to what you require. Then feel free to improvise upon it until it suits your project’s needs.

For the purposes of this article, I’m going to loosely base my process on IDEO’s circular design methodology, which you can read much more about here.

_Circular design method — read more on the [IDEO website](https://www.circulardesignguide.com/methods" rel="noopener" target="blank" title=")

It’s worth noting that while I’m referring to this design process, a key methodology I’m employing throughout is that of Lean UX. Jeff Gothelf and Josh Seiden’s excellent book is well worth a read to get an idea of what I really mean by this, but my interpretation of Lean UX in this context is really “do as little as you can to validate your ideas.”

Why? It’ll save you time and money in the long run.

In this first article, I’ll be looking at step one: understand.

How to Understand

OK, you’ve got a new client. You’ve got a new website to create. Life is good. The first thing you need to do is start understanding why the client came to you. Usually this begins with a kick off meeting. My advice here is to make this as much of a one way meeting as possible. It should almost feel like you’re conducting an interview with your new client.

A word of warning: if it’s a small business and you’re dealing with a Director, there can be a tendency to go off track a bit. The person you’re talking to is usually used to selling their business, and you might start to get more of a sales pitch than a true insight. As with any other user interview, you’ll need to use all your skills to try and keep the interview on point and drill in to get some deeper insights to the business, which will make your long term job a whole lot easier.

I’d also strongly recommend recording this meeting to come back to later. Keeping minutes always helps, but a recording is much better to come back to.

As part of this meeting, or possibly even before, it’s also a great time to get as many details as you can from the client. Collect Google Analytics details (gold dust!), get logins for their existing CMS, try to get the FTP access, anything really related to their existing website.

OK — not all that easy. Image from quickmeme.com

OK, this stuff isn’t actually that easy. There can be old agencies involved, bad relationships, among other things. Be prepared to wait for this stuff, but make sure you follow it up. Multiple times. This process is not fun, but it’s critical as it’s the difference between starting with zero and starting with something tangible.

Analytics Mode

OK, now your armed with some analytics data. This is a start. You can look in there, start to do your analysis — where are people going on the site, where are we losing them, how are they getting there. The picture is starting to be built in your head. While you’ll want to spend a good deal of time analyzing this data, it’s also a good idea, very early on, to improve the analytics on the site. Try to buy yourself another month’s worth of data, once you’ve got some access yourself.

Why is this? Well, you can get deeper. While a lot of websites will have analytics installed, they won’t all have things like event tracking or goals setup. Personally, I like to track everything as an event. Every button click on the page, should be an event. This is fairly easy to implement, especially if you are using Google Tag Manager. Which leads me to my next point…

Learn how to use Google Tag Manager.

This makes your life easier. You can add multiple snippets of code in one place, and reduce your reliance on developers. Even for those of us comfortable with FTP, the less time we spend in FTP, the more time we can spend analyzing and producing insights — what we are paid to do.

With Google Tag Manager, you can very easily add more tracking codes to your website, for other useful tools. A favorite tool of mine to add at this stage is Hotjar. Hotjar does have a paid tier for extra insights (which is awesome if you can afford it), but it’s free version you can install on your website, through Google Tag Manager, and it’ll do a lot for no cost.

If you need to find out how to do something in tag manager, here are some excellent resources:

Simo Ahava’s blog (for more advanced ideas)
Google Tag Manager Academy (getting started)

There are tons of great resources out there on the web, so if you are keen on it make sure and have a Google!

Why use Hotjar?

• You can get screen recordings of people using the website
• You can produce heat maps of popular pages (just like Crazy Egg, but free)
• You can install free, short surveys on the website

Hotjar does more than that (funnels, for example) but those three features I find useful in every web project. It’s still analytics, and has to be taken as that (numbers alone don’t tell us everything), but it lets us get a bit deeper than the pure numbers we see in Google Analytics. We are on the path to understanding behaviours with Hotjar.

A particularly useful tool is the poll. If you have a a couple of nagging questions, a poll can really help out. It’s not going to uncover any really deep and meaningful insights, but may help point you in the right direction.

Here’s a good example question: “what’s more important to you — better content or more ways of accessing content?”

You can’t take the answer as gospel, but if you see 100 responses for one answer and zero for the other — you’ve got a great insight and a place to start for testing.

Hotjar Home Page

Talking to Real People

OK. Google Analytics is a tick. You’ve got some heat maps coming through, you’ve watched people navigate through the website and you’ve started to get some responses on a poll. The next thing you need to do before you can get the tools out — is talk to real people.

Now this can be the hard bit. If I look at the past projects I’ve done, which step of my ideal workflow is missing the most? This step. That’s because it can be hard. But it doesn’t have to be. In an ideal world, we recruit users using some kind of outsourcing service, where they do all the work for us, the users show up at our door and we talk to them. But that costs a lot of money.

What we can do however is use what we have available to us. There’s a few ways of doing this.

Online user testing

I’ve got in the habit of using Peek (usertesting.com’s free sibling) for every project I work on. You get 3 free tests a month.

Sometimes these tests are, well, useless. It’s the wrong demographic, they don’t get the service they are looking at, and frankly it’s a waste of time. But it’s free and only takes 5 minutes of your time.

_Try out [peek.usertesting.com](http://peek.usertesting.com" rel="noopener" target="blank" title=")

Most of the time I run these tests, I pull out at least one useful insight. Maybe it’s that the CTA isn’t clear — which may explain the low click through rate in analytics. Or maybe it’s a user on a Windows OS I’ve never seen the website on before, and I notice a font hasn’t loaded correctly. There’s a good chance you’ll get at least one useful insight every time you run one of these tests. They are free, I say it’s a no brainer.

The next option up from this is to of course use usertesting.com. They offer online remote user testing at $50 per test. You can specify some demographics, which should help reduce the amount of “useless” tests and the tests run quite a bit longer than the free tests. I’ve always had success with these online tests, but there’s definitely something about being in the room with somebody as they are testing.

This is a good cheap alternative to “real” user testing, and is particularly useful as your time is only required in the setting up of the tests, and you can then watch them at any later time that suits (like when you don’t have to be present for the testing).

Guerilla user testing

So what’s better than getting real people online at $50 a pop? How about real people, in real life at $4 a pop? Yes, it’s possible.

The scene of our last Guerrilla session — pro tip: pick somewhere with delicious baked goods to celebrate when you’re done!

Guerrilla user testing is not the easiest thing to do. Not everybody has the confidence to approach random people in a coffee shop (or bakery!) and ask them to sit down for 5 minutes. But you can get around this, and there’s definitely no better way of testing the site than with real people in person.

If you don’t fancy approaching people yourself, team up with someone who is more comfortable. What we’ve found in our experimenting with this testing is that people are generally very happy to sit down when you’re paying for their coffee. In fact, so happy that they are often very nice to you and very positive about what you are showing them — which is another problem you have to combat.

This kind of testing is an art, but if you want to be a good experience designer, it’s an art worth practicing and getting better at. It won’t be perfect the first time you try it (speaking from experience), but it will get better every time you do it. And even when it’s not perfect, you’ll dig out insights.

There’s plenty of literature to read on this topic, although I think there’s probably a lack of a great super practical guide out there. You can nevertheless do what we have done: learn by doing.

Start by reading Steve Krug’s ‘Rocket Surgery Made Easy’ and then reading the articles below:

• The Art of Guerilla Usability Testing on UX Booth
• 7 Step Guide to Guerrilla Testing on Userbrain

I’ve been working with some of my colleagues to find a great way to collect these insights and share to our wider team, so if you are interested in learning more about this, hit me up via e-mail! :)

Understanding — Done

Once you’ve done some testing — online or “in real life” (be thankful I didn’t use the acronym) — you’re ready to start analyzing all of the data that you’ve got and defining what the problem you’re trying to solve is.

At this stage you should have plenty of hard data from analytics, some behavioral data from Hotjar, and you’ll have a bit of a feel for what people are thinking or feeling as they use the website or application through your user testing.

That means you’re ready to move onto the next stage, of sifting through, organizing all the data you have and defining the problem. That’s coming up in part 2 of this series! :)