Web Applications: Why They Are Relevant And How To Test Them Manually

In the past, internet use was primarily based on websites that provided content and graphics. Today, the world has moved forward, which is why we should distinguish not only websites but also applications created by programmers and developers: web, mobile, desktop. 

Today we want to cover the topic of web applications in the context of testing them manually. Considering aspects – like the buzzwordy User Experience – that they bring, as well as their responsiveness. We’ll cover basics that you have to take into account at the very beginning of your testing journey. Also, we’ll show you some great examples from applications like Cloud Admin (one of Scalac’s clients). 

Why web apps? Slack is a web app. Trello is a web app. Google Docs. Gmail. Even Twitter. Do you need more arguments?

Now let’s see what exactly you’ll learn in this blog post:

• Difference between web, mobile and desktop applications
• What are UX and UI?
• How to test 

What is the difference between mobile/web/desktop applications?

Desktop applications

A desktop application is a computer program that we create for a specific operating system, and its use requires installation on a given hardware. Although desktop applications may seem outdated, they work only when there is a  high level of security of any stored data, preferably located on an internal server, and which only the employees of a specific company have access to. 

Mobile applications

On the other hand, mobile applications are designed for use on smartphones and tablets. They are created for the needs of specific operating systems (Android, iOS), and they also require installation.

Web applications

Internet applications, otherwise known as web applications, stand out from the others. These are computer programs that operate on a server, communicating with the computer’s host via a computer network, using a web browser for this purpose. Unlike mobile and desktop applications, the web application does not require installation on a computer, although Internet access is required.

Why are web applications still important nowadays?

The most popular type of application is mobile apps. This is because users can use them anywhere, provided they have internet access and a smartphone. Consequently, a lot of people don’t need to buy computers. Phones have now become our pocket computers. Nevertheless, there are still users who prefer or have to use web applications.

For example, web applications are often preferred when it comes to:

• bank transfers
• buying tickets (train, plane, cinema)
• booking  hotels 
• watching videos (bigger screen)
• work  (the largest number of users)

Another aspect worth mentioning is that the group that prefers web to mobile applications are elderly people. It’s easier for them because the app is more intuitive on a computer and they can zoom in to see all the contents of a website. 

Another argument supporting web applications is that not all applications have mobile apps, so sometimes users don’t really have any choice. 

Finally, as we have all probably experienced in the past – websites often don’t look great on mobile browsers and some websites simply recommend using it only on a computer browser. 

What are UX/UI And How To Test Them in a Web Application? 

First off, you should know the difference between UX and UI in web applications:

UI – User Interface

At the most basic level, At the most basic level, the user interface (UI) is the series of screens, pages, and visual elements—like buttons and icons—that enable a person to interact with a product or service.

UX – User Experience

User experience design is a concept that has many dimensions. It includes a whole range of different disciplines such as interaction design, information architecture, visual design, usability, and human-computer interaction. 

UX is the process of designing (digital or physical) products that are useful, easy to use, and easy to interact with. It’s about enhancing the experience that people have with your product and making sure they find value in what you’re providing.

In general, UX answers the question: “how can we improve a given product in terms of usability services for the application user?”

Why UI/UX is so important in testing 

If you start testing a web application, you should be prepared to step into the shoes of a  user who is using the app for the very first time. And you need to pay attention to design on the website. It’s always a good idea to base your ideas on previous experience of other apps that are considered to be user-friendly – and use them as a benchmark for the app you’re testing. 

Business perspective 

The purpose of UX in a business environment is to discover the individual personal characteristics of target groups of given products or services). Based on the information collected, the product or service can be matched to the characteristics of average users in order to facilitate and improve communication, thereby making the product more intuitive and more pleasant to use. There are thousands of similar apps on the market – and we all know the general success of an application might come down to differences in user experience. As testers, our ultimate goal is to make the app as good as possible and help our clients achieve these business goals. 

Testing Web Applications: Usability Tests 

It’s always a good idea to carry out usability tests if you have the option. Preparing a usability test involves carefully creating a scenario or a realistic situation in which a person performs a list of tasks using the product, while observers verify the accuracy of the tests and take notes. Such a test scenario may consist of several test cases. 

This way, you can check the entire scope of the functionality. One of the goals is to check how people perform assumed tasks. It’s surprising how different this can be from what we had assumed. Having this kind of information enables us to better test the application, and to adjust the design to the real needs and – more importantly – habits of our users

Source: https://uxdesign.cc/

Testing Web Applications: A/B Tests

Source: https://www.optimonk.com/

A/B testing consists of creating two variants of a site that differ in only one element and then analyzing which of the variants is more effective.

Which elements can be changed to check which version of the website is better? 

• CTA buttons (different color, copy, size)
• Location of the buttons
• Size of the pictures
• Page headers
• Website links
• Headlines
• Animations
• Different product card layouts
• Less complicated checkout
• Homepage layout
• Customer reviews
• Number of fields in forms
• And probably everything else that may come to your mind 

A/B versions of the website can then be sent to the Business, Marketing, and QA teams. They can then choose a better, more intuitive, and more user-friendly version, and with the biggest endorsements. Or – in the case of Business or Marketing – whichever brings better traffic and converts better.

If your website has a lot of visitors, you can upload an alternative version of the website (there are also tools that will help with that). This will let you collect information about the number of clicks on particular elements – so you can clearly see which version/element of the website is more effective. You can also send a short survey about the new website design to users. If there’s one thing you should know at the beginning of your testing journey it’s that there’s no better source of knowledge about users than users themselves.

Examples of A/B tests:

Source: Youtube

Source: Wikipedia

Testing Web Applications: Web Responsive Design

This is all about designing a website so that its layout adapts automatically to the size of any browser window in which it is displayed. No matter if it’s a browser on a computer, smartphone, or tablet. A website created with this technique will be  almost universal: it will display well on large or small screens

As a QA’s we should do a few UX/UI tests to find the differences between mobile/web apps

Examples of web responsive design

Example 1 – HireHelp (Scalac’s Internal Application)

full-screen mode on the computer:

Pay attention to the menu on the left, and the 2 buttons on the right. Now narrow the screen and note the changes.

• The logo of the app has changed to a hamburger menu 
• The menu has only icons, no names
• The 2 buttons on the right are fitted to the smaller screen (change of position)

We can open the menu to show the names of the tabs:

Now the background is greyed and the menu is more visible. So the website still looks good and remains fully functional.

Example 2: Scalac.io website

full-screen mode on the computer:

Scalac website on iPhone 8:


The first difference you should notice is that on the computer the header font is bold (Best Scala hAkkers). The mobile screen would be too small to use a bold font – the headline would take all of the screens.

On the computer (web app) we have a bigger screen, so the browser can display all of the menu tabs. On the phone (in this case iPhone) the menu tabs are all hidden in the menu button (hamburger). When a user clicks on it, the menu will appear:


Let’s check some other components of the website. 

On the computer, we can see 3 tables that are situated horizontally;

On the iPhone, we have these tables arranged vertically;

There is also an additional button to go back to the top of the website. This is especially helpful when the website is long because the user doesn’t have to scroll up manually which can be quite irritating. 

Applications Lacking the “Web responsive design” 

Now, let’s have a look at a website that’s lacking web responsive design. On the computer, our table looks good:

Unfortunately, on a mobile, some elements are partly invisible, and the table is hard to read. The user has to move from left to right if he or she wants to read something from the table. This section of the website is recommended only for browsers on a computer.


A good solution for this situation is to create a different app for mobile or implement web responsive design. But, as I pointed out earlier,  not everyone needs to have mobile apps, sometimes owners of a product don’t really need a mobile version.

To sum up – our mission when testing a website on different devices is to check all of the components (buttons, text, images, tables, animations, etc.) in various resolutions and check if all of the features are working properly. It’s also good practice to deliver feedback to the Project Manager about any different approaches or changes that may be required to boost the usability of the elements, structure, and features. 

Now you know how to test the visual part of web applications, let’s move on to the functionalities.

Testing Web Applications: Different Devices 

If you don’t have any physical phones/tablets you can use, Xcode or Android studio can simulate phones (recommended more for mobile apps than websites) or use the web responsive design mode in your browser:

You can also use it inside browsers:
Google Chrome: click right mouse button -> choose “inspect” -> in the tools click the icon of the phone:

You can choose phones from the list, or type your custom screen resolution

Mozilla Firefox: open the hamburger menu -> web developer -> responsive design mode

Just as in Google Chrome, you can choose the kind of phone or type in your customized resolution. Additionally, In Firefox, there’s an option to simulate a phone with a slow internet connection. 

 
Testing Web Applications: Login And Register Unit

Nowadays it’s hard to find an application without a user account. The reason is that it’s good for product owners because they can collect data on their users, and use it to prepare customized offers. It’s also good for users because they have their own settings and data saved. No need for setting up everything from scratch every time you launch the app. 

Now I want to show you how to test the login and register unit. As an example, I’m going to use the Cloud Admin app https://www.cloudadmin.io/. (One of Scalac’s clients).

Open the register screen; https://www.cloudadmin.io/register

Pay attention to the structure:
– ‘email’ field (greyed example with email structure)
– ‘Password’ field (greyed example)
– ‘Sign up’ button
– ‘I agree terms’ checkbox
– ‘Register’ button
– ‘Connect with Flexential’ (external API) button

Test case 1 (sad path): Try to sign up without any data

– Click the “sign up” button keeping the fields empty. The app should give a response error, and the fields should be checked in red (this is important information for users, showing them which fields have been wrongly filled).
If it’s working correctly:

Test case 2 (sad path): Try to sign up with a bad email structure:

– In ‘email’ type: this_is_test
– In ‘password’ type: 1234

– In ‘confirm password’ type: 1234
– Click on the checkbox with terms
– Click the ‘sign up’ button

The app should respond to 3 errors:

1. The Email field should be checked in red with the information; “Please enter a valid email address.”
2. The Password field should be checked in red with the information; “Password must be at least 6 characters long.” Now we know – the password has to have 6 characters minimum
3. The confirm password field should be checked in red because the password is too short.
   All of the structures should work correctly

Test case 3 (sad path): Try to sign up with a good email structure, and different passwords in the fields

– In ‘email’ type: [email protected]
– In the ‘password’ type: 123456

– In ‘confirm password’ type: 678901
– Click on the checkbox with terms
– Click the ‘sign up’ button

The app should respond with the error message “passwords do not match” if it’s working correctly.

Test case 4 (sad path): Try to sign up without checking to agree to terms:

• In ‘email’ type: [email protected]
• In the ‘password’ type: 123456
• In ‘confirm password’ type: 123456
• Click the ‘sign up’ button
  
  The app should respond with the error message “You have to agree to all terms to continue.” if it’s working correctly.

Test case 5 (sad path): Try to sign up with all of the correct data:

• In ‘email’ type: [email protected]
• In the ‘password’ type: 123456
• In ‘confirm password’ type: 123456
• Click on the checkbox with terms
• Click the ‘sign up’ button
  
  The user should be logged in automatically after registering:
  
  
  

Test case 6 (sad path): Try to sign up with an email of an already existing user (create this user earlier)

– In ‘email’ type: [email protected]
– In the ‘password’ type: 123456

– In ‘confirm password’ type: 123456
– Click on the checkbox with terms
– Click the ‘sign up’ button

The app should respond with the error message “The email is already in use. Log in” if it is working correctly.

To sum up test cases:

I have shown you some tests for the register unit:

1. empty data
2. bad email structure
3. bad passwords
4. not selected terms
5. happy path to register
6. existing user

It seems obvious in points 1 and 6  that it won’t work but I have had cases in projects where these tests have actually passed. So please don’t ignore them. A good practice is to create test case documentation because the register and login features are repeatable in other applications, and you will then have a checklist ready to use in the future. There are sometimes more or fewer fields, but the structure is usually similar.
In the login unit there will be very similar tests because there are only 3 elements: email, password, login button So your homework could be to create some tests for the login ;)

Testing Web Applications: Test Fields With Data

In applications, we often have a lot of fields with no validations (users can type whatever kinds of characters they wish ). For example, in surveys or questionnaires. Let me show you some test cases to test these kinds of fields:

Test case 1: 

Leave field empty

Test case 2:

Add only space keys

Test case 3:

Add small letters

Test case 4:

Add big letters

Test case 5:

Type numbers

Test case 5: 

Type special characters

Test case 6:

Add a mix of letters, numbers and special characters

Test case 7:
Add an emoji icon 

Test case 8:

test the upper limit string of the characters (for example app enable up to 80 characters)
– more than 80 characters

– less than 80 characters

– up to 80 characters

Test case 9:
test the minimum limit string of characters(for example the app requires minimum 4 characters)
– less than 4 characters
– 4 characters
– more than 4 characters

Just as in register/login, a good practice is also to create test cases for these tests so you can use them again in other projects 

Testing Web Applications: Calendar feature

This functionality can be found in all kinds of web applications:

• schools: when you want to enroll
• employment: in HR apps 
• Insurance: If you want to compare insurance offers
• And many more. It’s important to test this feature because if it doesn’t work correctly, users could have a problem with filling in information to submit papers for studies, fill in CV information in an employer app, buy insurance, etc
  
  So let’s focus a little on this calendar feature:

After clicking on the start date the calendar opens. The user can also type in the date using a keyboard. Let’s go a bit deeper into this feature:

•  There’s no option to change the year using a button. After clicking on the arrows, the app changes only the month, so we should report this because if a user wants to choose May 2017, he has to click the “back” arrow lots of times.
• In this calendar, the dates use the U.S. calendar structure: month/day/year

After choosing the start/end day there is an “x” button to clear all of the data. This is important because a user can type a new date using a keyboard after clearing everything. Don’t forget about this functionality in the calendar feature ;)

Let’s do some tests :)

Test case 1 (sad path): Choose a later start date than the end date

Choose from the calendar start date: 05/25/2020                  
Choose from the calendar end date: 05/15/2020
The application shouldn’t allow the user to set the start date later than the end date

Test case 2 (sad path): Try to type day more than allowed in the calendar (32 or more)

In start date type: 05/50/2020
In end date type: 05/60/2020

The application shouldn’t allow the user to set the date later than 31

Test case 2 (sad path): Try to type a month more than allowed in the calendar (13 or more)

In the start date type: 13/02/2020
In the end date type: 05/60/2020
The application shouldn’t allow the user to set the month more than 12

Test case 3 (sad path): Type year only with 2 digits

In the start date type: 01/01/01
In the end date type: 01/02/01

In the app, a year should be 4 digits minimum

Test case 4 (sad path): Try to choose the same start date as the end date

Choose from the calendar start date: 05/10/2020                  
Try to choose from the calendar end date: 05/10/2020

The application shouldn’t allow a user to choose the same date. The app suggests choosing as the ‘end date’ the next day instead of the same as the ‘start day’.

Test case 5 (happy path): Choose start/end date from the calendar where the end date is a later date

Choose from the calendar start date: 05/15/2020
Choose from the calendar end date: 05/20/2020

Test case 6 (happy path): type start/end date from the calendar where the end date is a later date

Type the start date: 05/15/2020
Typ the end date: 05/20/2020

Now you know how to test a calendar feature. But did you spot the bug? ;)
Look at the second, third, and fourth screen on the calendar. There is no “x” button to clear the date. It needs to be added. So report it :)

Summary

In this article, I wanted to share with you some information about web applications and illustrate some test cases you can use in your projects. These are the basics, but as you know, well-tested basics are the key to success.

If you’re interested in articles about testing you might also like:

• Performance Testing
• Rest Assured API Testing Tutorial. How To Use Rest Assured With Java And Scala.
• HOW WE MADE MANUAL TESTING OF 590 TIMEZONES IN 2 DAYS POSSIBLE
• Testing for mobile apps
• What is HTTP protocol? Introduction to HTTP for Testers