elearningsolutionstesting

Mastering Software Testing: A Comprehensive Syllabus

The post Template for Test Case Management appeared first on elearningsolutionstesting.

What Is Orthogonal Array Testing (OATS)?

varad — Sat, 21 Dec 2024 05:30:00 +0000

The orthogonal Array Testing technique is a statistical approach for testing pair-wise interactions. Most of the defects which I have observed are caused due to interaction and integration.

This interaction or integration can be within different objects, elements, options on a screen of the application, or configuration settings in a file. Such a combination of objects and elements results in the functioning of the application.

Some of the combinations are missed to test which thereby results in insufficient tests. Hence to cover the entire functionality in the testing scope with the correct amount of combinations to be tested, Orthogonal Array Testing is used.

This is a Combinational Test Technique that ensures that the complete functionality of an application is tested with a limited and proportionate amount of combinations under test without compromising on the quality of testing.

The beauty of this technique is that it maximizes the coverage by a comparatively lesser number of test cases. The pairs of parameters that are identified should be independent of each other. It’s a black box technique, so like other BB techniques; we don’t need to have the implementation knowledge of the system. The point here is to identify the correct pair of input parameters.

There are many techniques of CTD, where the OATS (Orthogonal Array Testing Technique) is widely used.

Implementation Techniques of OATS

The Orthogonal Array Testing technique has the following steps:

#1) Decide the number of variables that will be tested for interaction. Map these variables to the factors of the array.

#2) Decide the maximum number of values that each independent variable will have. Map these values to the levels of the array.

#3) Find a suitable orthogonal array with the smallest number of runs. The number of runs can be derived from various websites. One such website is listed here.

#4) Map the factors and levels onto the array.

#5) Translate them into suitable Test Cases

#6) Look out for the leftover or special Test Cases (if any)

After performing the above steps, your Array will be ready for testing with all the possible combinations covered.

Advantages of Orthogonal Array Testing

This technique is beneficial when we have to test with a huge amount of data having many permutations and combinations.

Less number of Test conditions that require less implementation time.
Less Execution time.
Easy Analysis of Test conditions due to less number of Test conditions.
High coverage of codes.
Increased overall productivity and ensures that the quality test is performed.

Limitations of OATS

None of the testing techniques provides a guarantee of 100% coverage. Each technique has its way of selecting the test conditions. Along similar lines, there are some limitations to using this technique:

Testing will fail if we fail to identify the good pairs.
Probability of not identifying the most important combination which can result in losing a defect.
This technique will fail if we do not know the interactions between the pairs.
Applying only this technique will not ensure complete coverage.
It can find only those defects which arise due to pairs, as input parameters.

Conclusion

Orthogonal Array testing is a systematical and statistical way of testing pair-wise interactions. It is done by deriving small sets of test cases from a large number of scenarios and also by giving precedence to factors and levels that appear multiple times in the combinatorial outputs.

Orthogonal Array testing can be used in our day-to-day application testing by:

Forming systematic and statistical pair-wise combinations of factors across their levels.
Creating an optimized test suite with fewer test scenarios and generating negative test case optimization.
Detecting all single, double, and triple mode defects in the given input combinations.
Executing a concise set of tests and uncovering most of the bugs.

Now, as you have a clear understanding of the implementation of Orthogonal Array testing, you can easily implement it in your application or webpage which will cover all the aspects of the functionality of the application in a limited number of test cases.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post What Is Orthogonal Array Testing (OATS)? appeared first on elearningsolutionstesting.

What is Cross Browser Testing and How to Perform It: A Complete Guide

varad — Fri, 20 Dec 2024 05:30:00 +0000

If you’re a beginner, this post provides a comprehensive guide on how to do Cross Browser Testing.

Cross Browser Testing is a type of testing to verify if an application works across different browsers as expected and degrades effectively. It is the process to verify your application’s compatibility with different browsers.

Often, whenever I encounter an issue with a website and call technical support, they tell me to try with another browser. When it works, I end up feeling like a total idiot, since I earn my living working in the software industry.

I bet this has happened to all of you, hasn’t it? I always wonder ‘Why didn’t I think of that? As time went on, I gradually grasped the issue. As an end user, I have just found a bug because the website lacks extensive testing for cross-browser compatibility.

Table of Contents: [Show]

Techniques for Carrying Out Cross-Browser Testing

We might have noticed that some browsers do not properly display certain websites. We simply presumed the website was malfunctioning. However, as soon as you open it on a different browser, the website opens up just fine. Thus, this behavior explains the compatibility of a website with different browsers.

Recommended reading =>> Top 10 Browsers for PC

Each browser interprets the information on the website page differently. Thus, some browsers may lack the features that your website is trying to show and make your website look broken on that browser.

For example, as shown below, the errors in the signup forms are not the same on both browsers. Also, the text color, font, etc are different if you inspect.

With the advancement in technology, there are several options available for browsers, and it’s not just enough to make a website work on one browser.

Users should not be restricted from using any specific browser to access your application. Thus, it becomes necessary to test your website’s compatibility with different browsers. Some of the most commonly used browsers include Chrome, Safari, Firefox, Internet Explorer, etc.

I think you all have figured out the topic of today’s discussion – Cross Browser Testing.

As it is a general practice at STH, we are going to focus on the basics. We believe any concept will make sense when we ask the basic questions words around like- “What, why, how, who, when, where”.

Let’s do just that as we go ahead.

What is Cross Browser Testing

Cross-browser testing is simply what its name means, to test your website or application in multiple browsers and make sure that it works consistently as intended without any dependencies or compromise in quality. This applies to both web and mobile applications.

What kinds of applications undergo this? Customer-facing applications are the best choice. You might wonder “Aren’t all applications customer-facing?” Well, sure, they are. However, let us look at an example.

Application 1: An application developed for a company to internally keep track of its inventory.
Application 2: This is for the end-users to buy products from this company.

The best idea would be to test Application 2 for browser compatibility testing since it is impossible to control what browsers/platforms/versions the end-user is going to use.
If all computers internal to the company use Windows 8 machines with Chrome browser, then there is no need to look or test for anything else concerning Application 1.

Why is it Performed

For that matter, why is any kind of testing done? The following are some reasons:

To know what is wrong and be able to fix it.
Enhancing efficiency, user experience, and finally, business.
Be informed of any pitfalls.

But if we think specifically about the intent of cross-browser testing–It is twofold. It can be a rendition or appearance of the page in different browsers. Is it the same? Is it different? If one is better than the other, etc. The other reason is the functionality and its working. (Of course!)

Who Performs This Testing

Are you thinking, “There are a million browsers, versions, and platforms out there, which one to choose?”–This, thankfully, is a decision that is not the tester’s responsibility. The client, business analysis team, and marketing teams have a major role in this decision. Also, companies collect usage/traffic statistics to narrow down what browsers, environments, and devices are mostly in use.
The entire project team should have an invested interest, time, money, and infrastructure to support this endeavor.
The QA team can be involved in this process or it might be the design team who are keen on knowing how the application fares in multiple browsers.
Whether QA or any other team performs it, the design and development teams interpret the results and make the relevant changes.

How to Perform Cross-Browser Testing

First things first- is it done manually or using a tool?

People can surely do this manually. However, there are several machines, OSs, browsers, and machines. This leads to a lot of problems, multiple investments, and challenges.

Manual Method

In this case, a business identifies the browsers that the application must support. Testers then re-run the same test cases using different browsers to observe the application’s behavior and report bugs, if any.

In this type of testing, it is not possible to cover many browsers and also, the application might not be tested on major browser versions. Also, performing cross-browser checks manually is costly and time-consuming.

Automated Method

Cross-browser testing is running the same set of test cases multiple times on different browsers. This kind of repeated task is best suited for automation. Thus, it’s more cost and time-effective to perform this testing by using tools.

Lots of tools are available in the market to make this easier.

These tools can help us with one or all of the following, depending on the tool and the licensing types:

They provide a VPN (Virtual Private machine) using which you can connect to remote machines and check the working and rendition of your JAVA, AJAX, HTML, Flash, and other pages. Most of them are secure, but since you are submitting your information to a third party, some discretion is advised.
Screenshots are provided for the pages, and links are submitted to how they appear in multiple browsers. This is, of course, static.
Multiple browsers are synchronized regarding operations performed on one and the results are presented browser-wise.
Show the rendition of the page at multiple screen resolutions.
When encountering a problem, the team records a video or takes screenshots to transport the issue for further analysis.
Support is available for both web and mobile apps.
Private pages that require authentication to be accessed can also be tested.
Local and within a private network/firewall page can be tested too.

Recommended Tools

#1) BitBar

BitBar ensures you are providing your customers with the best web and mobile experience on the latest and most popular browsers and devices with their cloud-based real device lab. Easily run manual and exploratory tests across a range of real browsers, desktop, and mobile.

Ditch the hassle and allow BitBar to reduce the burden of cross-platform testing by offloading the setup, ongoing maintenance, and browser/device upgrades.

Features:

Automated testing across devices with unlimited users and testing.
Test the application before it gets deployed to production.
Execute tests on several real devices in parallel.
Many of the popular browsers are accessible.

#2) TestGrid

TestGrid public cloud offers a combination of real devices & browsers to help users test their mobile app and website on the cloud while getting a 100% real user experience. Now engage your testing and business teams to build and execute test cases without any prerequisites of programming knowledge.

Using TestGrid’s cross-browser testing capabilities, you can ensure your end users get the best user experience. While manual cross-browser testing requires time, TestGrid’s automated cross-browser testing allows you to build tests in a scriptless manner and have them run automatically across browsers in either parallel or sequence.

Features:

Run automated tests on a combination of hundreds of real devices & browsers.
Support for all the latest and legacy devices available at the time you need.
AI-based no-code automation generating selenium & appium-based code.
Performance testing helps optimize and improve your website.
Catch bugs and resolve them on the go with integrations like JIRA, Asana, Slack, and more.
Integrate with your favorite CI/CD tool for continuous testing.

#3) Selenium

Selenium is well known for the automated testing of web-based applications. Just by changing the browser to be used to run the test cases, selenium makes it very easy to run the same test cases multiple times using different browsers.

#4) BrowserStack

BrowserStack is a cloud-based web and mobile testing platform that enables testing applications across on-demand browsers, operating systems, and real mobile devices.

#5) Browserling

This live interactive service provides effortless testing for web developers and web designers. There are several browsers and operating systems. Browserling provides quick access to all the most popular browsers on well-known operating systems.

Features:

Live interactions with browsers.
Running real browsers on real computers.
Installation of the latest browsers.
Safe and secure browsing.
Flash, Java, and plugins are not required.

#6) LambdaTest

LambdaTest is a cloud-based cross-browser testing platform utilizing which user can perform automated & manual compatibility testing of their website or web app on a combination of over 2000 different browsers and operating systems.

Users can run Selenium automation tests on a scalable, secure, and reliable cloud-based Selenium grid and perform live interactive cross-browser testing of their public or locally hosted websites and web apps on the cloud.

When to Start This Testing

The time to start the Cross-Browser test depends completely on your testing methodology and your testing timeline.

This test can be performed:

#1) As soon as possible, start testing when any one page is ready for testing.

Test that page on each browser. Once the next page is ready, verify its functionality on various browsers. While it may require additional effort, fixing errors early in the life cycle is crucial. Fixing errors is a more cost-effective approach in this scenario.

#2) Once the application is complete, start testing when the application development is complete.

This will test the application on different browsers. The cost-effectiveness of fixing the errors may not match the above case, but it will still be valuable to address them before releasing the application to users.

#3) Once the application is released this is the least favored time to perform a cross-browser test for your application. But it’s better to do it than to not do it and let the end-users have a bad experience.

After the application is released for the end-users, this testing can be performed and bugs can be fixed as a part of the change requests in the application. However, this is costly and requires multiple deployments, depending on the bug fixes.

Rigorous cross-browser testing can only be done when the testing team members who know the tools do this testing. Business users or even developers can also do high level or checking of specific browsers.

This testing involves testing the application thoroughly using different browsers. Testing thoroughly includes functional and non-functional testing of the application.

In most companies, a product team has separate teams for functional and non-functional testing. Thus, this testing needs to be performed by the team(s) who is (are) responsible for functional and non-functional testing of the application.

For this testing, a tester needs the browsers on which the application needs to be tested.

These browsers can either be provided to the tester as:

Locally installed on the tester’s machine.
Virtual or other different machines that a tester has access to.
Tools that provide their browsers and their versions for testing.
On cloud – so that multiple testers can use the browsers as and when required.

This testing is independent of the deployment environment. Thus, it can be done in dev, test, QA, or even production environments depending upon the availability of the application in each of these environments.

What to Test

Base Functionality: Links, dialogues, menus etc.
Graphical User Interface: Look and feel of the application.
Response: How well the application responds to user actions.
Performance: Loading of pages within the allowed time frame.

If your application works well on one browser, that doesn’t imply that it will work well on the other browsers too. Thus, this testing helps you to ensure that an application runs on different browsers without any errors.

To identify what breaks are on which browser and to fix the website accordingly we need to perform this testing. If a browser is not at all supported, then the users can easily be informed about it.

To Summarize “How” to Cross-Browser Test

#1) Traffic statistics help determine which browsers to test.

#2) A detailed analysis should be done on the AUT (Application under test) itself to determine if all or some parts of the application have to undergo this. All should be tested on multiple browsers after considering costs and time. A good strategy is to perform 100% testing on one browser per platform and for the other just test the most critical/widely used functionality.

#3) Once the decision of “What” to test and “Where (browsers)” is made, infrastructure decisions are to be made (do we acquire tools or perform this manually, etc), considering the costs. Viability, risks, security concerns, people to be involved, time, acceptance criteria, and issue/defect fixing schedules/processes, etc. have to be addressed.

#4) Perform testing. Regular functional testing test cases can be used when validating the efficiency of the system. For look-and-feel/rendition, test cases are not necessary.

The operation I was talking about at the beginning of this article that failed for me was an online bank transfer. I logged into my bank account, chose the amount (one lakh), and tried to perform the transfer but a servlet error was showing up no matter how many times I tried.

If the transfer operation is chosen for browser compatibility testing, this is what the test script is going to look like.

Log in to your online bank account.
Select the account from which the transfer is to be done.
Enter the transfer amount: 100,000.
Select a payee and click “Transfer”.
Expected result: The transfer should be successful.
This will simply run on all the browsers chosen.

Again, please note that this does not look different from a functional test case. Please check this non-functional testing article for further information on this.

#5) Report the results back to the design team if they are not involved in the testing process. Changes follow.

When is the Best Time to Do This

Any kind of testing reaps the best benefits when done early on. Therefore, the industry recommendation is to start with it as soon as the page designs are available. But it can also be performed when the site is fully integrated and functional.

If you have missed the bus on performing the cross-browser test during the design, development, and QA phases, it can still be done while the application is in production. However, this is the costliest of all and risky too.

Where is browser compatibility testing performed?

Usually, the answer to this question would be one of the Dev/QA/Production environments. But for cross-browser checking, this is not definite and irrelevant. It can be done in any one or all of them.

Conclusion

A few points to note to conclude,

I’ve been a QA teacher for a while, so I know what’s coming next; the question is, will it be functional or non-functional testing? I believe it is neither and both. This is not to be confused with Cross-Platform testing, which tests your application across several systems such as Windows, Linux, and Mac.
However, the two must sometimes work together because some older browser versions are only compatible with older platform versions.
It is also a constant process, with software environments, browsers, and gadgets evolving on a regular basis.
To avoid unexpected surprises, browser testing should be incorporated to the repertory of regression suites.

Each sort of testing, including cross-browser testing, contributes to the overall quality of the application. Cross-browser testing ensures a uniform user experience across browsers and operating systems, resulting in a pleasant impression.

Fixing problems is cost-effective in the early stages of the development lifecycle, and the same is true for errors discovered during testing. This testing helps to improve your business, which leads to happy customers and a happy you!!

This is one another example of how the QA sector, or software testing, is multifaceted and has something for everyone to thrive at.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post What is Cross Browser Testing and How to Perform It: A Complete Guide appeared first on elearningsolutionstesting.

Cross-Browser Testing: A Complete Guide

varad — Thu, 19 Dec 2024 05:30:00 +0000

Cross-Browser Testing: A Complete Guide

This document offers a thorough tutorial on how to perform cross-browser testing for beginners.

Cross-browser testing is the process of determining whether a program works as intended and degrades effectively across multiple browsers. It is the process of determining whether your application functions properly across a range of browsers..

If I call technical support with a website issue, they usually tell me to try using a different browser. I work in the software industry, so when it works, I feel like a total idiot. You have all most likely gone through this, haven’t you? I’m always asking myself, “Why didn’t I consider that? As time went on, I realized the issue.

I just discovered a bug as an end user because the website hasn’t been thoroughly tested for cross-browser compatibility.

Table of Contents: [Show]

Techniques for Carrying Out Cross-Browser Testing

We may have observed that certain websites do not display correctly in some browsers. We just assumed that the website was broken.But the website loads perfectly when you access it in a different browser. As a result, this behavior explains why a website works with various browsers.

Top 10 Browser

For example, as shown below, the errors in the signup forms are not the same on both browsers. Also, the text color, font, etc are different if you inspect.

It is no longer sufficient to make a website run on a single browser because of the variety of browser options made possible by technological advancements.

Users shouldn’t be prevented from accessing your application with a particular browser. As a result, testing the compatibility of your website across several browsers becomes essential. Among the most widely used browsers are Internet Explorer, Firefox, Chrome, Safari, and others.

I believe everyone has figured out what we’re talking about today: cross-browser testing.

We will concentrate on the fundamentals because that is standard procedure at STH. We think that any idea will make sense if we address the fundamental questions, such as “What, why, how, who, when, and where.”

As we move forward, let’s do just that.

What is Cross Browser Testing

Simply said, cross-browser testing is the process of testing your application or website across a variety of browsers to ensure that it functions as intended across all of them without dependencies or sacrificing quality. This is true for both mobile and web applications.

Which apps are subjected to this? Applications that interact with customers are the greatest option. “Aren’t all applications customer-facing?” you may ask. Indeed, they are. But let’s examine one example.

Application 1: An application developed for a company to internally keep track of its inventory.
Application 2: This is for the end-users to buy products from this company.

The best idea would be to test Application 2 for browser compatibility testing since it is impossible to control what browsers/platforms/versions the end-user is going to use.
If all computers internal to the company use Windows 8 machines with Chrome browser, then there is no need to look or test for anything else concerning Application 1.

Why is it Performed

For that matter, why is any kind of testing done? The following are some reasons:

To know what is wrong and be able to fix it.
Enhancing efficiency, user experience, and finally, business.
Be informed of any pitfalls.

However, if we focus on the purpose of cross-browser testing, it is twofold. It could be a version or how the page looks in various browsers. Is it the same? Is it any different? whether one is superior to the other, etc. The functioning and operation are the other reasons. (Obviously!)

Who Performs This Testing

Are you wondering how to choose among the plethora of browsers, versions, and systems available?–Fortunately, the tester is not responsible for this choice. This choice is heavily influenced by the client, marketing teams, and business analysis team. Additionally, businesses gather traffic and usage data to determine which devices, environments, and browsers are most frequently used.
The entire project team should have an invested interest, time, money, and infrastructure to support this endeavor.
The QA team can be involved in this process or it might be the design team who are keen on knowing how the application fares in multiple browsers.
Whether QA or any other team performs it, the design and development teams interpret the results and make the relevant changes.

How to Perform Cross-Browser Testing

First things first- is it done manually or using a tool?

People can surely do this manually. However, there are several machines, OSs, browsers, and machines. This leads to a lot of problems, multiple investments, and challenges.

Manual Method

In this instance, a company determines which browsers the application needs to work with. Then, in order to see how the application behaves and report any errors, testers repeat the same test cases in several browsers.

Numerous browsers cannot be covered in this kind of testing, and the application may not be evaluated on the most popular browser versions. Additionally, manually conducting cross-browser checks is expensive and time-consuming.

Automated Method

Performing the same set of test cases repeatedly across various browsers is known as cross-browser testing. Automation is ideal for repetitive tasks like this. Therefore, adopting tools to conduct this testing is more economical and time-efficient.

There are many tools on the market to help with this.

These tools can help us with one or all of the following, depending on the tool and the licensing types:

They offer a Virtual Private Machine (VPN) that allows you to connect to distant computers and examine how your HTML, Flash, Java, AJAX, and other pages function and look. Although most of them are safe, you should exercise caution because you are giving your information to a third party.
Screenshots are provided for the pages, and links are submitted to how they appear in multiple browsers. This is, of course, static.
Multiple browsers are synchronized regarding operations performed on one and the results are presented browser-wise.
Show the rendition of the page at multiple screen resolutions.
When encountering a problem, the team records a video or takes screenshots to transport the issue for further analysis.
Support is available for both web and mobile apps.
Private pages that require authentication to be accessed can also be tested.
Local and within a private network/firewall page can be tested too.

Recommended Tools

#1) BitBar

With their cloud-based actual device lab, BitBar guarantees that you are giving your customers the greatest mobile and web experience on the newest and most widely used browsers and devices. Conduct exploratory and manual testing with ease on a variety of desktop and mobile devices and genuine browsers.

Ditch the hassle and allow BitBar to reduce the burden of cross-platform testing by offloading the setup, ongoing maintenance, and browser/device upgrades.

Features:

Automated testing across devices with unlimited users and testing.
Test the application before it gets deployed to production.
Execute tests on several real devices in parallel.
Many of the popular browsers are accessible.

=> Visit BitBar Website

#2) TestGrid

In order to let users test their mobile apps and websites on the cloud while obtaining an entirely authentic user experience, TestGrid Public Cloud provides a combination of genuine devices and browsers. Now, your business and testing teams can work together to create and run test cases without requiring any prior programming experience.

You can make sure your end users get the greatest possible experience by using TestGrid’s cross-browser testing features. TestGrid’s automated cross-browser testing lets you create tests without using any scripts and have them run automatically across browsers in parallel or sequential fashion, whereas manual cross-browser testing takes time.

Features:

Run automated tests on a combination of hundreds of real devices & browsers.
Support for all the latest and legacy devices available at the time you need.
AI-based no-code automation generating selenium & appium-based code.
Performance testing helps optimize and improve your website.
Catch bugs and resolve them on the go with integrations like JIRA, Asana, Slack, and more.
Integrate with your favorite CI/CD tool for continuous testing.

=> Visit TestGrid Website

#3) Selenium

Selenium is widely recognized for its ability to automatically test web-based applications. Selenium makes it very simple to run the same test cases again using different browsers simply by switching the browser that is used to perform the test cases.

=>Visit Selenium Website

#4) BrowserStack

The cloud-based online and mobile testing platform BrowserStack makes it possible to test apps on real mobile devices, operating systems, and on-demand browsers..

=> Visit BrowserStack Website

#5) Browserling

For web developers and designers, this live interactive service makes testing simple. Numerous operating systems and browsers are available. All of the most widely used browsers on well-known operating systems are easily accessible through browserling.

Features:

Live interactions with browsers.
Running real browsers on real computers.
Installation of the latest browsers.
Safe and secure browsing.
Flash, Java, and plugins are not required.

=> Visit Browserling Website

#6) LambdaTest

With the help of LambdaTest, a cloud-based cross-browser testing tool, users can test their website or web application for compatibility across more than 2000 distinct operating systems and browsers both automatically and manually.

=> Visit LambdaTest Website

=> Further Reading:

When to Start This Testing

The time to start the Cross-Browser test depends completely on your testing methodology and your testing timeline.

This test can be performed:

#1) As soon as possible, start testing when any one page is ready for testing.

Check each browser’s version of that page. When the next page is prepared, check how it works in different browsers. Correcting mistakes early in the life cycle is essential, even though it could take more work. In this case, correcting mistakes is a more economical course of action.

#2) Once the application is complete, start testing when the application development is complete.

This testing involves testing the application thoroughly using different browsers. Testing thoroughly includes functional and non-functional testing of the application.

For this testing, a tester needs the browsers on which the application needs to be tested.

These browsers can either be provided to the tester as:

Locally installed on the tester’s machine.
Virtual or other different machines that a tester has access to.
Tools that provide their browsers and their versions for testing.
On cloud – so that multiple testers can use the browsers as and when required.

What to Test

Base Functionality: Links, dialogues, menus etc.
Graphical User Interface: Look and feel of the application.
Response: How well the application responds to user actions.
Performance: Loading of pages within the allowed time frame.

It is not a given that your application will function well on all browsers just because it functions well in one. As a result, thorough testing aids in making sure a program functions flawlessly across various browsers.

We must conduct this testing in order to determine which browsers break the site and to make the necessary corrections. The users can be readily informed if a browser is not supported at all.

To Summarize “How” to Cross-Browser Test

#1) Traffic statistics help determine which browsers to test.

#4) Perform testing. Regular functional testing test cases can be used when validating the efficiency of the system. For look-and-feel/rendition, test cases are not necessary.

An online bank transfer was the procedure I mentioned at the start of this essay that didn’t work out for me. After selecting the money (one lakh) and logging into my bank account, I attempted to make the transfer several times, but each time a servlet error appeared.

If the transfer operation is chosen for browser compatibility testing, this is what the test script is going to look like.

Log in to your online bank account.
Select the account from which the transfer is to be done.
Enter the transfer amount: 100,000.
Select a payee and click “Transfer”.
Expected result: The transfer should be successful.
This will simply run on all the browsers chosen.

Again, please note that this does not look different from a functional test case. Please check this non-functional testing article for further information on this.

#5) Report the results back to the design team if they are not involved in the testing process. Changes follow.

When is the Best Time to Do This

Where is browser compatibility testing performed?

Usually, the answer to this question would be one of the Dev/QA/Production environments. But for cross-browser checking, this is not definite and irrelevant. It can be done in any one or all of them.

Conclusion

A few points to note to conclude,

Having been a QA teacher for a while now, I can tell what’s coming next; the question is, is it functional and non-functional testing? I think it is neither and both.
It should not be confused with Cross-Platform testing, which involves testing your application in multiple target environments like Windows, Linux, Mac, etc. However, sometimes the two have to integrate as some older browser versions might only be compatible with older versions of the platforms.
It is also a continuous process, as software environments, browsers, and devices are evolving daily. To ensure there are no unpleasant surprises, this browser testing should be added to the repertoire of regression suites.

Every kind of testing, including cross-browser testing, contributes to the enhancement of the application’s quality. Cross-browser testing guarantees a uniform user experience across various operating systems and browsers, making a good first impression.

Early in the development lifecycle is a cost-effective time to fix errors, and this also holds true for faults discovered during testing. Your business will improve as a result of this testing, which will make you and your customers happy!

This is yet another testament to the concept that the QA field or software testing is a multi-dimensional field and there is something for everyone to excel in.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post Cross-Browser Testing: A Complete Guide appeared first on elearningsolutionstesting.

Web Application Testing Guide: How To Test A Website

varad — Wed, 18 Dec 2024 04:30:00 +0000

Complete Web Application Testing Guide: Learn How To Test A Website

We all have to agree that in today’s ever-changing and competitive world, the internet has become an integral part of our lives.

Most of us make our decisions by searching the information on the internet these days, hence hosting a website is no longer optional but mandatory for all kinds of businesses. This is the first step in becoming and staying relevant in the market.

Just having a website is not enough. An organization is needed to develop a website that is informative, accessible, and user-friendly. To maintain all these qualities, the website should be well tested, and this process of testing a website is known as web testing.

Table of Contents: [Show]

Web Application Testing: A Complete Guide

What is Web Testing?

Web testing is a software testing practice to test websites or web applications to find potential bugs before making them live.

A web-based system needs to be checked completely from end to end before it goes live for end users.

By performing website testing, an organization can make sure that the web-based system is functioning properly and can be accepted by real-time users.

UI design and functionality are the captains of website testing.

Recommended Website Testing Tools

#1) BitBar

Ditch the hassle and allow BitBar to reduce the burden of cross-platform testing by offloading the setup, ongoing maintenance, and browser/device upgrades.

#2) LoadNinja

LoadNinja lets you load test your web application with real browsers at scale, using test scripts that can be replayed immediately after recording, producing actionable browser-based performance data to isolate issues and debug errors in real-time.

Web Testing Checklists – How to Test a Website

Functionality Testing
Usability testing
Interface testing
Compatibility testing
Performance testing
Security testing

#1) Functionality Testing

Test for – all the links in web pages, database connections, forms used for submitting or getting information from the user in the web pages, Cookie testing, etc.

Check out all the links:

Test the outgoing links from all the pages to the specific domain under test.
Test all internal links.
Test links jumping on the same page.
Test links are used to send emails to admin or other users from web pages.
Test to see if there are any orphan pages.
Finally, link checking includes checking for broken links in all the above-mentioned links.

Test forms on all pages: Forms are an integral part of any website. Forms are used to receive information from users and interact with them. So what should be checked in these forms?

First, check all the validations in each field.
Check for default values in the fields.
Wrong inputs in the forms to the fields in the forms.
Options to create forms, if any, form deletes a view or modify the forms.

Let’s take an example of the search engine project I am working on. For this project, we have advertisers and affiliate signup steps. Each sign-up step is different but it’s dependent on the other steps.

So the signup flow should be executed correctly. There are different field validations like email Ids, User financial info validations, etc. All these validations should get checked for manual or automated web testing.

Cookie Testing: Cookies are small files stored on the user’s machine. This is basically used to maintain the session – mainly the login sessions. Test the application by enabling or disabling the cookies in your browser options.

Test if the cookies are encrypted before writing to the user machine. If you are testing session cookies (i.e. cookies that expire after the session ends) check for login sessions and user stats after the session ends. Check the effects on application security by deleting the cookies. (I will soon write a separate article on cookie testing as well)

Validate your HTML/CSS: If you are optimizing your site for Search engines then HTML/CSS validation is the most important one. Mainly validate the site for HTML syntax errors. Check if the site is crawlable to different search engines.

Database Testing: Data consistency is also very important in a web application. Check for data integrity and errors while you edit, delete, modify the form or perform any DB-related functionality.

Check if all the database queries are executed correctly, data is retrieved, and also updated correctly. More on database testing could be a load on DB, we will address this in web load or performance testing below.

In testing the functionality of the websites the following should be tested:

Links

Internal Links
External Links
Mail Links
Broken Links

Forms

Field validation
Error message for wrong input
Optional and Mandatory fields

Database: Testing will be done on database integrity.

#2) Usability Testing

Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.

Ease of learning
Navigation
Subjective user satisfaction
General Appearance

Test for Navigation:

Navigation means how a user surfs the web pages, different controls like buttons, boxes, or how the user uses the links on the pages to surf different pages.

Usability Testing includes the following:

The website should be easy to use.
The instructions provided should be very clear.
Check if the instructions provided are perfect to satisfy its purpose.
The main menu should be provided on each page.
It should be consistent enough.

Content Checking: Content should be logical and easy to understand. Check for spelling errors. The usage of dark colors annoys the users and should not be used in the site theme.

You can follow some standard colors that are used for web pages and content building. These are the commonly accepted standards like what I mentioned above about annoying colors, fonts, frames, etc.

The content should be meaningful. All the anchor text links should be working properly. Images should be placed properly in the proper sizes.

These are some of the basic important standards that should be followed in web development. Your task is to validate everything for UI testing.

Other user information for user help:

Like the search option, the sitemap also helps with files, etc. The sitemap should be available with all the links on websites with a proper tree view of navigation. Check for all the links on the sitemap.

The “Search in the site” option will help users to find content pages that they are looking for easily and quickly. These are all optional items and if present they should be validated.

#3) Interface Testing

For web testing, the server-side interface should be tested. This can be done by verifying that the communication is done properly. The compatibility of the server with software, hardware, network, and database should be tested.

The main interfaces are:

Web server and application server interface
Application server and Database server interface.

Check if all interactions between these servers are executed and errors are handled properly. If the database or web server returns an error message for any query by the application server then the application server should catch and display these error messages appropriately to the users.

Check what happens if the user interrupts any transaction in-between. Check what happens if the connection to the webserver is reset in between?

#4) Compatibility Testing

The compatibility of your website is a very important testing aspect.

See which compatibility test to be executed:

Browser compatibility
Operating system compatibility
Mobile Browsing
Printing options

Browser Compatibility: In my web-testing career, I have experienced this as the most influencing part of website testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with.

Your website code should be cross-browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.

Test web applications on different browsers like Internet Explorer, Firefox, Netscape Navigator, AOL, Safari, and Opera browsers with different versions.

OS Compatibility: Some functionality in your web application is that it may not be compatible with all operating systems. All new technologies used in web development like graphic designs and interface calls like different APIs may not be available in all Operating Systems.

Hence, test your web application on different operating systems like Windows, Unix, MAC, Linux, and Solaris with different OS flavors.

Mobile Browsing: We are in a new technology era. So in the future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile devices as well.

Printing Options: If you are giving page-printing options then make sure fonts, page alignment, page graphics, etc., are getting printed properly. Pages should fit the paper size or as per the size mentioned in the printing option.

#5) Performance Testing

The web application should sustain a heavy load.

Web performance testing should include:

Web Load Testing
Web Stress Testing

Test application performance at different internet connection speeds.

Web Load Testing: You need to test if many users are accessing or requesting the same page. Can the system sustain peak load time? The site should handle many simultaneous user requests, large input data from users, simultaneous connection to DB, heavy load on specific pages, etc.

Web Stress Testing: Generally stress means stretching the system beyond its specified limits. Web stress testing is performed to break the site by giving stress and it’s checked as to how the system reacts to stress and how it recovers from crashes. Stress is generally given to input fields, login, and sign-up areas.

During the web performance test, testing website functionality on different operating systems and different hardware platforms is checked for software and hardware memory leakage errors.

Performance testing can be applied to understand the website’s scalability or to benchmark the performance in the environment of third-party products such as servers and middleware for potential purchases.

Connection Speed: Tested on various networks like Dial-Up, ISDN, etc.

Load

What is the no. of users per time?
Check for peak loads and how the system behaves.
Large amount of data accessed by the user.

Stress

Continuous Load
Performance of memory, CPU, file handling, etc.

#6) Security Testing

The following are some of the test cases for web security testing:

Test by pasting the internal URL directly into the browser address bar without login. Internal pages should not open.
If you are logged in using a username and password and browsing internal pages, then try changing URL options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the URL site ID parameter to a different site ID that is not related to the logged-in user. Access should be denied for this user to view other people’s stats.
Try using invalid inputs in input fields like login username, password, input text boxes, etc. Check the system’s reaction to all invalid inputs.
Web directories and files should not be accessible directly unless they are given the download option.
Test the CAPTCHA to automate script logins.
Test if SSL is used for security measures. If used, the proper message should get displayed when users switch from non-secure HTTP:// pages to secure HTTPS:// pages and vice versa.
All transactions, error messages, and security breach attempts should be logged in log files somewhere on the webserver.

The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.

Network Scanning
Vulnerability Scanning
Password Cracking
Log Review
Integrity Checkers
Virus Detection

Types of Web Testing

A website is classified into about 20 types. All of these are shrinking under static and dynamic types. Among them let’s discuss 4 types and their testing methods in a detailed manner. Before that, I just want to bullet those types.

Simple static website testing
Dynamic web application testing
E-commerce website testing
Mobile website testing

#1) Simple Static Website

A simple static website will display the same content for all visitors who are visiting the website at different times. It is also known as an informational website. On a static website, only developers can make changes that too in code only. This type of website will not have any major functionalities and it purely depends on UI design.

Testing a simple static website is very easy, you have to consider only a few things while testing. Some of them are mentioned below:

Points to Remember:

#1) Testing the GUI design is a must because a static website purely depends on it. You need to compare the approved PSD files with the web page developed. Check if all the elements in the design are present on the actual page.

#2) The other part of GUI design is to check the font size, font style, spacing, and color everything has been reproduced.

The image below explains the spacing alignment issue in the desktop view of a website.

#3) Secondly, you need to check the links (page links) to see whether it is working properly or not. Also, find out if there is a broken link?

#4) Verify the spelling and content in all web pages by comparing the content given by the client.

#5) In some cases the image will not display properly, it may break or sometimes the image gets duplicated, and wrong images may display. It has to be checked keenly. Because for a static website, only content and images will give lives.

#6) Check the scroll bar carefully, and in my experience, I have faced issues with the scrollbar. The issue you will face is unwanted scrolling appearing or scrolls getting hidden (it may hide the content). The above issues are applicable to both horizontal and vertical scrolls.

#7) If there is a contact form check it is working properly by sending some dummy messages.

Things to check on the contact form are:

Is the message being sent properly and a successful message appearing?
Check if the email received to the concerned person is in the proper format as designed.
Check email should not land in spam as junk mail?
If a reply email trigger is activated then check whether the sender receives the email.

#8) Check whether it is an error-free web page and validate it with the W3 validator or other related software.

#9) Some common website testing check points:

Check if the favicon is present on the tab bar.
URL should contain the correct page title.
If copyright information is there, it should be displayed.
If there is a contact form, Captcha is a must. [It prevents junk email].
Check the loading speed of the website. [A static website should not take much time for loading]. If a gif image is used while loading then track its functionality.

Apart from these, there are huge things that have to be tested at the backend of every website such as system testing, security testing, interface testing, compatibility testing, performance testing, etc.

For this, you need to have technical knowledge. In a simple static website, you will not find more functionalities if there you need to do functionality testing too.

#2) Dynamic Web Application [CMS Website]

This is the type where the user can update and change their website content regularly. From here I am going to use the word “web application testing” instead of dynamic website testing. The web application is a combination of front-end and back-end programming.

The front-end will be HTML and CSS whereas the back-end uses programming languages like PHP, JavaScript, ASP, etc. With this backend, users/clients can add or change the content on the website.

Testing a web application is not as easy as testing a static website but not much more difficult than testing an e-commerce website. Functionality testing is the most important thing to be performed while testing a web application. The web application may contain much-complicated functionality so the tester needs to be very careful while testing.

There are two different types of web applications there, one is that no action will be carried out by the user on the front-end (i.e. only back-end changes will reflect on the front-end), the other is the end-user will work on the front-end itself (for example login, signup, newsletter subscription, and other similar actions). So testing should be done accordingly.

Points to Remember:

The points I mentioned in static website testing are to be included while testing a web application also. In addition to that, the following things are to be noted.

#1) In the GUI section, the tooltip is compulsory for all fields and buttons, field alignment (spacing) should be done properly, disabled field/ buttons should be greyed out, fields/ buttons should be in standard format as in SRS, error message should be displayed if something goes wrong, the pop-up message should only display at the center of the web page, a drop-down menu should not be truncated.

Tab shortcut key should work in all fields and more.

#2) In the functionality section, if your web application is having login or sign-up functionality then check the mandatory field validation, form validation (i.e. number fields should only accept numbers and not alphabets), and character restrictions on fields (i.e. only these many characters can be entered).

Special characters and negative number restrictions on fields, testing the email functionality, testing the document upload (i.e. only specified document type can be uploaded), timeout functionality, sorting functionality, JavaScript is working on compatible browsers, etc. should be tested.

#3) When coming to the back-end functionality section, test image uploading for broken images, whether text entering in the fields is working or not. The back-end update should reflect front-end and database testing (i.e., whether you can add new fields or delete unwanted fields) and all these things are to be performed.

Performance is not much necessary for a web application (dynamic website) since it has very little content. If you need you can do it with the tools with which you are familiar. Pick up some standard online performance tools if you want to do simple performance testing.

#3) E-commerce Website

An e-commerce website is somewhat complicated when compared to the above two. The tester needs to be very cautious while testing an e-commerce site. There is a huge amount of things to be checked on e-commerce sites out of them, I just covered some of the issues I experienced with e-commerce website testing.

In the GUI section, you need to check all the features as in SRS and the same with the functionality. The functionality will be almost the same for all commercial websites.

Functionality-wise you need to check all pages such as the main page (which includes featured products, special offers display, log-in details, search functionality), product detail page, category page, placing an order, payment gateway everything that has to be tested.

Points to Remember:

#1) Check if the shopping cart is getting updated when you buy or increase the quantity. Check this functionality in all pages and circumstances.

#2) Check if special coupons and offers are applied to correct orders and you see whether the discounted price is displayed or not.

[This image explains free shipping and how it is applied in the payment section]

#3) Sometimes while updating a single product it will get multiplied by considering the number of variations in the product. So check whether the single product is displayed and its variations are displayed correctly. (I faced this problem)

#4) Check if the filter option is working exactly. If filtering is been done, based on the category & pricing chosen?

#5) While signing up, super validation should be done. Only new users can sign up.

#6) If an existing user, added a product to the shopping basket, the wish list section during their previous login should be saved and displayed during the next login too.

#7) Compare products should work by comparing the products based on some specifications assigned in the back-end.

#8) Check whether the Currency converter is working fine. Based on the country chosen, the currency converter should display the relevant price and tax rates.

[On choosing the language Currency will be converted, here USD is meant to be the default]

#9) Generally many Plug-ins are used in an e-commerce (WordPress & similar) website. The plug-in installation may conflict with or affect any other major functionality. So follow up with the plug-ins installation and its usage.

#10) Check whether the social sharing option is working on the individual product or not.

#11) Shipping cost should be generated based on the region selected. Also check the tax rate generation. (It may cause some legal problems, during the end-users purchase).

In this image Shipping and tax rates are calculated for the French region.

#12) Payment gateway should only work if valid card details are given. Validation should apply to the Card number and CCV code number. [It is better to keep validation on the card number field itself].

#13) Email generation on each and every process during purchase should happen (sign up, product ordering, payment successful, order canceled, order received and other email triggers if any).

#14) Check the live chat with some dumpy emails.

Note: Generally, e-commerce websites will not be developed for mobile compatibility and when coming to the mobile version an app will be generated. In some cases, they will not create an app instead a mobile compatible website will be created. In such cases, you need to check carefully to see if there are any missing functionality and UI deviations.

These are some of the issues I faced and noted while testing an e-commerce website. Apart from this, you need to check all the general things related to an e-commerce website.

#4) Mobile Website

First of all, let’s be clear about the mobile website. Generally, people think both a mobile website and a mobile application to be the same, but in reality, a mobile website is developed with HTML pages and can be viewed only with an internet connection.

But the mobile app is nothing but an application that can be downloaded and used later without an internet connection. Here many of us get confused and raise a question: What is the difference between a mobile website & responsive website?

A responsive website means making the content fit into the mobile device size instead of creating a version whereas a mobile website is creating a new version that is not a reflection desktop version. On the mobile website, you will have limited pages, and unwanted functionalities will be removed here.

Testing a mobile website is somewhat tedious rather than other types of websites. It will have separate designs and you need to be careful while testing the functionalities.

Points to Remember:

Important points to consider while testing a mobile website:

Usually, we will use an emulator for testing a mobile website and we can get ideal results but I always prefer you to test on real devices. I have faced many issues when I tested in real devices [Especially apple devices]. Real device specifications may conflict with the web pages developed.

The image explains simulator testing and the backline issue appearing in it.

GUI & usability testing are more important as it is not the reflection of the desktop version.
Performance is another important factor to be considered for mobile website testing. Performance-related issues can be tracked when you test in real devices.
Check whether browsing normal web links from mobile is getting triggered by a mobile link.
Check page scrolling, page navigation, text truncation, etc. on the mobile website.

Best Web Testing Tools

There are a wide range of testing tools that are available for web app testing.

Points to be Considered While Testing a Website

The websites are essentially client/server applications – with web servers and ‘browser’ clients.

Consideration should be given to the interactions between HTML pages, TCP/IP communications, Internet connections, firewalls, applications that run on web pages (such as applets, JavaScript, plug-in applications), and applications that run on the server-side (such as CGI scripts, database interfaces, logging applications, dynamic page generators, asp, etc).

Additionally, there are a wide variety of servers and browsers with various versions of each. They include small but sometimes significant differences between them in terms of variations in connection speeds, rapidly changing technologies, and multiple standards & protocols. The end result of which testing for websites can become a major ongoing effort.

Sample Test Scenarios for Testing Applications on the Web

A few other considerations to be included while testing a website are given below.

What is the expected load on the server (e.g., number of hits per unit time)?
What kind of performance is required under each load condition (such as web server response time, and database query response times)?
What kind of tools will be required for performance testing (such as web load testing tools, other tools already in-house that can be adapted, web robot downloading tools, etc.)?
Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they be using? Are they intra-organizations (thus likely with high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
What kind of performance is expected from the client-side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
Will downtime for server and content maintenance/upgrades be allowed? If so, then how much?
What kind of security (firewalls, encryption, passwords, etc.) will be required and what is it expected to do? How can it be tested?
How reliable are the site’s internet connections required to be? How does that affect the backup system and redundant connection requirements and testing?
What process will be required to manage updates to the website’s content?
What are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
What HTML specifications will be adhered to? How strictly? What variations will be allowed for targeted browsers?
Will there be any standard requirements for page appearance and/or graphics throughout a site or parts of a site??
How will internal and external links be validated and updated? And how often? will it happen?
Can testing be done on the production system, or will a separate test system be required?
What are browser caching, variations in browser option settings, dial-up connection variability, and real-world internet ‘traffic congestion’ problems to be accounted for in testing?
How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
How are CGI programs, applets, JavaScript, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Pages should be 3-5 screens max unless the content is highly focused on a single topic. If larger, provide internal links within the page.
The page layout and design elements should be consistent throughout the site so that it’s clear to the user that they are still on the site.
Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser type.
All pages should have links external to the page; there should be no dead-end pages.
The page owner, revision date, and a link to a contact person or organization should be included on each page.

Web Testing FAQs

Below mentioned should be the various questions coming to a tester’s mind while thinking of a website that is already developed and can be exposed to the public:

Is the website functioning as expected?
Will the end-user find the website easy to browse?
Is the website accessible on different devices possessed by end-users?
Is the website secure enough?
Is the website performance up to the mark?
Is the data entered on a website stored accurately and if it persist across sessions?
Is the website integrated well with other interfaces in the workflow?
Will the website perform as expected even after going live?

To answer these questions, different testing techniques have been identified that can be used to test a web application.

Let’s take an example of an e-commerce website that has been recently released to the QA team for testing.

We’ll go through each one of the above-specified questions in detail to understand the scope of the test and see how website testing can be performed.

#1) Is the website functioning as expected?

To confirm that the website is functioning well, QA needs to perform functional testing. During functional testing, different features of an application need to be validated against the requirements mentioned in the functional specification document.

Below are a few generic scenarios a QA is expected to cover while performing functional testing of any website even if they are not mentioned in functional specifications:

User navigates to different pages of the website and completes the end-to-end workflow
If the user can select/deselect checkboxes
If the user can select values from the Dropdown fields
If the user can select/deselect Radio buttons
Different navigation buttons like Submit, Next, Upload, etc. buttons are working well
Calendars are loading properly and allowing the user to select a date
Calculations are happening as implemented
Search functionality is working if any
Correct Information display
Various internal & external links to other pages
Correct Tab Order of the fields on web pages
Mandatory and Optional fields should be verified for positive and negative inputs
Default values for each web field should be verified
Email functionality is implemented for some action on the website

It’s important for websites to be compatible with search engines. Hence, we should review websites for HTML syntax correctness, format & compliance standards like WS-I, ISO & ECMA.

Considering cookies, which are used to maintain login sessions, the website should be tested by enabling/disabling cookies or by using the mismatched domain. Testing can also be performed across sessions by resetting cookies to bring browsers back to the vanilla state.

QA should also validate that website cookies are always stored locally in an encrypted format.

Considering our e-commerce website, there are various links like Men’s Fashion, Women’s Fashion, Kid’s Fashion, Home Accessories, Electronic Appliances, Books, Movies & Music, etc. available on a web page, it should be clicked on and verified if the user navigates to the expected page.

Similarly, different functionalities like Login, Signup, Search Options, Filters, Sort Order, Add to Cart, etc. should be verified on different web pages like Login Page, Sign up Page, Product Details Page, Shopping Cart, Order Review, Payment, etc. The website should be checked for session/cookie management like session expiration, session storage, etc.

#2) Will the end-user find the website easy to browse?

Usability testing has to be performed to measure the website’s ease of use for an end-user in the context of accessibility, searchability, usefulness, etc.

Below mentioned are a few of the test scenarios that should be verified while performing usability testing for a website:

Website content should be informative, structured, and linked logically so that users can understand it easily
Web page controls should be easy for users to navigate
The website should have Help & Instruction documents uploaded
The website should have a Search feature for end-user convenience
Access to/from the Main menu to all pages should be there
Website content should be verified for any spelling mistakes
The website should follow defined guidelines in the context of background colors, patterns, styles, fonts, image placements, frames, borders, etc.
The website should be accustomed to the translation feature considering the fact that it can be accessed by users from different nations with different languages, currencies, etc.

A few tools that can be used to perform usability testing are User Zoom and Reflector.

An e-commerce website should be customer-friendly, easy to navigate, and attention-grabbing. All web pages should be verified for accessibility, fonts, styling, images, spelling mistakes, and product-relevant information. A website should be equipped with relevant help documents and customer support facilities.

Considering the increase in touchscreen-based interfaces, we need to validate the accessibility of both key inputs and touch screen inputs. Similarly, images and website content should be validated for usability on different screen sizes (mobiles, laptops, tabs, etc.).

#3) Is the website accessible on different devices possessed by end-users?

Assuming that our website can be accessed by a range of users with a different set of devices, we need to ensure that the website runs well on all of them without any glitches.

To ensure the same, website compatibility checks should be done which comes with Compatibility Testing. During the compatibility testing of a website, it is ensured that the website runs well on different browsers, Operating Systems & Devices like laptops, mobile phones, tablets, printers, etc.

Browser Compatibility (Cross Browser Testing): The website should work well with different browsers like Microsoft Internet Explorer, Microsoft Edge, Firefox, Google Chrome, Safari, and Opera. All active versions of these browsers should be verified with different browser features turned ON/OFF.

Also, while performing cross-browser testing, QA should also check for optimal website performance across browsers.

Operating System Compatibility (Cross Platform Testing): In order to identify potential user experience issues, a website should be tested on various platforms like Windows, Linux, and Unix.MAC, Solaris, etc. in order to be sure of the OS compatibility.

Device Compatibility (Cross-Device Testing): A website can be browsed through different devices like laptops, mobiles, tablets, etc. with different OS available like iOS, Android, Windows, etc. Hence, testing should be performed on the devices to cover the below scenarios.

Website screen size should be adjustable as per the device
A device should be screen rotation featured
The website should not show up any loading issues on different devices with different network speeds
Verify the website behavior when the device is in/out of network range
Verify the website behavior on low CPU and Memory to support different form factors

For an e-commerce website, the compatibility check is one of the most important testing types. The customer base will be large and will access our website from different browsers, operating systems & devices.

Considering mobile platforms are becoming popular, we should ensure website load on small form factor under acceptable load time. It is also important to validate the use of different network speeds to ensure it is usable for all customers.

#4) Is the website secure enough?

Security testing is performed to uncover vulnerabilities in a system and ensure a website is secured.

Below is a checklist that can be verified while performing security testing:

The website should only be accessible to authenticated users
Website users should only be able to perform the tasks for which they are authorized
The website should be verified for CAPTCHA fields for user identification
Browser security settings should be verified while moving from secure to insecure pages
Web Server protection should be there for inaccessible web directories or files
Ensure restricted files should not be downloaded without appropriate access
Sessions that got inactive should automatically get killed after a certain period of time
All invalid and unauthorized attempts by end-users or intermittent system errors/failures should get logged for analysis purposes

Tools like Vulnerability Management, Veracode, and SQL Map can be used to perform security testing of your website.

As part of security testing, an e-commerce website should be validated for

Website Access Controls
No leakage in the user’s personal information
Secured Payment Methods

#5) Is the website performance up to the mark?

A website’s performance can be tested. It will assess an application’s behavior under a range of workload scenarios, including a realistic scenario. If the system goes live without doing performance tests, it may encounter challenges such as slow operation or poor usability, which will most likely have an impact on brand image and market sales.

A website can be tested against load & stress.

Below given is the checklist for web performance testing:

Website behavior should be observed under normal and peak load conditions
The website’s performance should be examined by measuring response time, speed, scalability, and resource utilization
Proper RCA (root cause analysis) should be done with a solution if the system breaks down or gets unstable at any point in time
Network latency issues should be identified if any

An e-commerce website should be tested thoroughly using a set of simulated users during normal as well as peak load conditions which can be during ‘Sale Season’.

During the sale, users accessing the website will multiply. Also, website behavior should be examined while multiple concurrent users are accessing the same items or performing the same actions (like transactions or placing orders) on the website.

There are various tools available in the market for performance testing. A few of them are LoadRunner, WinRunner, Silk Performer, JMeter, etc.

#6) Is the data entered on a website stored accurately and persist across sessions?

The database is one of the critical components of a web application that holds the complete information entered through a website. Hence, to ensure that the correct user data is getting saved in database tables without any manipulation and to maintain data integrity verification should be performed.

Verify data consistency across user interfaces i.e. Website UI and Database
Verify that DB tables are updating properly whenever insert/update/delete actions are performed by a website application
Verify the response time of technical queries and fine-tune them if required
Check for DB connectivity and access permissions

As a QA team member testing an e-commerce website, you can perform the below activities and validate the changes each time in the corresponding database tables. This will ensure that the website UI and DB are consistent.

Placing an Order for a product
Canceling Product
Opt to Exchange Products
Opt to Return Product

#7) Is the website integrated well with other interfaces in the workflow?

Interface level testing is performed to ensure that the website interacts smoothly with various interfaces such as the web server and database server.

During interface testing, the tester must ensure that application requests are properly routed to the database and that the correct information is displayed to the client as output. A webserver should not throw denial exceptions at any moment, and the database should always be in sync with the application.

#8) Will the website perform as expected even after going live?

Once a product moves into a production environment, a regular inspection should be done to keep a check on quality control.

Below are scenarios that can be considered while verifying the product in production:

Web application tests should be executed periodically and test logs should be saved as proof of Service Level Agreement (SLA) compliant
Auto-scaling systems and load balancers should be checked if in place and functioning
Keep a check on the end-user experience and try to uncover defects or malicious attacks that typically go unnoticed during QA testing
Monitor product response time during peak loads
Execute edge-level test cases in real-time to identify network failures, connection failures, or interruptions by an unexpected call

Conclusion

I created this extensive instruction after years of evaluating many websites.

I hope this post helps you understand the various aspects of web application testing. Next time you sit down to design a test strategy for your website, remember to validate factors other than the website’s functionality.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post Web Application Testing Guide: How To Test A Website appeared first on elearningsolutionstesting.

The Best Online Software Testing QA Training Course

varad — Tue, 17 Dec 2024 04:30:00 +0000

Hi companions, as all of you know, we generally endeavor to offer back the information that we gain from our encounters to the testing club. To expand similar way of thinking, we are concocting a more organized educational plan as a Product testing course.

It will incorporate all that there is to be aware for you to turn into an ideal Programming Analyzer. This product testing QA instructional class is planned by working experts such that, throughout the span of 40+ hours it will advance from acquainting you with the fundamentals of programming testing to cutting edge points like Programming setup the board, making a test plan, test assessments and so forth alongside presentation and knowledge of Robotization testing and devices like QTP and QC.

Table of Contents: [Show]

Who is this QA Software Testing Training Course for?

This software testing course is the perfect opportunity for all those who are looking for Software Testing (basics + advanced) training. If you are new to the IT field, want to increase your software testing knowledge, and want to pursue a career in Testing or if you want to make a career move from a different technology, this course is just for you. See course details below.

In this course, we will teach you the most practical things required for you to get and survive a software testing job.

If you are a just college pass out, this is EXACTLY what you are looking for to open the doors for your dream career
If you are an experienced professional from ANY other field but wanted to be in IT, this course will help you make this switch smoothly
If you are an experienced testing professional, you will be amazed at the new things and advanced tactics you will learn to work efficiently and smartly in this field.

The Online QA Testing Course Benefits:

Syllabus: We came up with a unique list of topics that will help you gradually work your way into the testing world. It not just includes the traditional testing methodologies but will give you a glimpse of the ways of testing that are coming up.
Interactive: It is going to be completely interactive. Our aim is to make each class feel like a brainstorming session.
Practice sessions: With each topic, we will give you assignments in a way that you will get to apply the theory you learned immediately.
Communication improvement: We believe that a tester’s expertise should have a reach that is beyond the technical knowledge. Through this software testing course, we want to train you on how to be an over IT professional and not just a tester. Your verbal and written communication skills are going to be vastly improved through this course because we are going to interact on a regular basis.
Resume Support and Interview preparation: We will review your resume and let you know how you can make it more effective. We will not just give you a list of interview questions, we will go over them with you and make you job ready.
Support: Our Team is going to be available to you via email or the website for you to reach out to us

Course Content

Software Testing – Manual + Automation Basics Class – Training Plan

Week 1 – Topics

SDLC
V model
STLC
Different Kinds of testing
Test Planning

2 – Topics

Test documentation
Test Environment set up
Test data
Test cases
Entire Flow/Test Execution

3 – Topics

Test Reporting – Metrics
Defects
Traceability Matrix
UAT
Change Management and other miscellaneous topics

4 – Topics

GUI testing
Testing stand-alone applications
Automation introduction
Test Management tools
Other automation topics – buffer day for automation concepts

5 – Topics

How to Prepare a Professional Resume
How to Crack Software Testing Interview
Individual resume help, mock interviews and certification guidance.
Also if we could not complete anything in the four weeks- we will catch up here.

Why Enroll with SoftwareTestingHelp?

Course training by experienced working professionals who are passionate about software testing
Instructor-led LIVE training sessions
Course content designed by considering current software testing technology and the job market
Practical assignments at the end of every session
A practical learning experience with live project work and examples
The individual mock interview session
Job placement assistance with job alerts until you get your first job
Free eBooks and loads of software testing study material
Video recordings available to revise training
Assistance for selecting the best certification program based on your experience and educational background
Assistance for passing the ISTQB certification with our premium ISTQB question bank
Course completion certificate (on request)
All-time support for your questions

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post The Best Online Software Testing QA Training Course appeared first on elearningsolutionstesting.

What is Software Testing Life Cycle (STLC)?

varad — Mon, 16 Dec 2024 04:30:00 +0000

Software Testing:

In this tutorial, we discuss the Evolution of Software Testing, the Software Testing Life Cycle, and the various phases involved in STLC.

Table of Contents: [Show]

8 Phases of Software Testing Life Cycle (SLC)

The pattern and competency of testing are shifting. Testers are now expected to be more technical and process oriented. Testing is much more than just discovering defects; it has a broader scope and is necessary from the start of the project, even before the requirements are finalized.

Tests are also standardized. Just as software development has a lifetime, so does testing. In the next parts, I will discuss what a life cycle is and how it relates to software testing, and I will attempt to expound on it.

Let us start!

What is Lifecycle?

In layman’s terms, a lifecycle is the process of transitioning from one form to another. These alterations can occur to any tangible or intangible object.

Every entity has a life cycle that begins with its inception and ends with its retirement or demise. Similarly, software is an entity. Testing, like software development, consists of a series of stages that must be completed in a specific order.

The testing life cycle refers to the systematic and planned execution of testing activities.

What is the Software Testing Life Cycle (STLC)

The Software Testing Life Cycle (STLC) is a set of steps that must be completed in a specific order to ensure that quality objectives are met. Each activity in the STLC process is carried out in a planned and systematic manner, and each phase has its own set of goals and deliverables. The STLC process varies by organization, but the fundamentals remain the same.

Below are the phases of STLC:

Requirements phase
Planning Phase
Analysis phase
Design Phase
Implementation Phase
Execution Phase
Conclusion Phase
Closure Phase

#1. Requirement Phase:

During this phase of STLC, analyze and study the requirements. Have brainstorming sessions with other teams and try to find out whether the requirements are testable or not. This phase helps to identify the scope of the testing. If any feature is not testable, communicate it during this phase so that the mitigation strategy can be planned.

#2. Planning Phase:

In practical scenarios, Test planning is the first step of the testing process. In this phase, we identify the activities and resources that would help to meet the testing objectives. During planning, we also try to identify the metrics and the method of gathering and tracking those metrics.

On what basis the planning is done? Only requirements?

The answer is NO. Requirements do form one of the bases but 2 other very important factors influence test planning. These are:

– Test the strategy of the organization.
– Risk analysis / Risk Management and mitigation.

#3. Analysis Phase:

This STLC phase defines “WHAT” to be tested. We identify the test conditions through the requirements document, product risks, and other test bases. The test condition should be traceable back to the requirement.

Various factors affect the identification of test conditions:

– Levels and depth of testing
– The complexity of the product
– Product and project risks
– Software development life cycle involved.
– Test management
– Skills and knowledge of the team.
– Availability of the stakeholders.

We tought to attempt to record the test conditions in an itemized manner. For instance, for an online business web application, you can have a test condition as “Client ought to have the option to make an installment”. Or on the other hand you can detail it by saying “Client ought to have the option to make installment through NEFT, charge card, and Visa”.

The main benefit of composing the point by point test condition is that it expands the test inclusion since the experiments will be composed in light of the test condition, these subtleties will set off the composition of more definite experiments which will ultimately build the inclusion.

Also, identify the exit criteria of the testing, i.e. determine some conditions when you will stop the testing.

#4. Design Phase:

This phase defines “HOW” to test. This phase involves the following tasks:

– Detail the test condition. Break down the test conditions into multiple sub-conditions to increase coverage.
– Identify and get the test data
– Identify and set up the test environment.
– Create the requirement traceability metrics
– Create test coverage metrics.

#5. Implementation Phase:

The significant errand in this STLC stage is the production of point by point experiments. Focus on the experiments and furthermore distinguish which experiment will turn out to be important for the relapse suite. Prior to settling the experiment, It means quite a bit to survey it to guarantee the rightness of the experiments. Additionally, remember to remove the sign-from the experiments before the genuine execution begins.

Assuming that your venture includes robotization, distinguish the applicant experiments for computerization and continue with prearranging the experiments. Remember to audit them!

#6. Execution Phase:

As the name suggests, this is the Software Testing Life Cycle phase where the actual execution takes place. But before you start your execution, make sure that your entry criterion is met. Execute the test cases, and log defects in case of any discrepancy. Simultaneously fill your traceability metrics to track your progress.

#7. Conclusion Phase:

This STLC phase concentrates on the exit criteria and reporting. Depending on your project and stakeholders’ choice, you can decide on reporting whether you want to send out a daily report or a weekly report, etc.

There are different types of reports ( DSR – Daily status report, WSR – Weekly status reports) that you can send, but the important point is, that the content of the report changes and depends upon whom you are sending your reports.

If Project managers have a testing background then they are more interested in the technical aspect of the project, so include the technical things in your report ( number of test cases passed, failed, defects raised, severity 1 defects, etc.).

But if you are reporting to upper stakeholders, they might not be interested in the technical things so report to them about the risks that have been mitigated through the testing.

#8. Closure Phase:

Tasks for the closure activities include the following:

–Check for the finishing of the test. Whether all the experiments are executed or relieved intentionally. Check there is no seriousness 1 deformities opened.
Do examples learned gatherings and make an illustrations learned report. ( Incorporate what worked out positively, where are the extent of upgrades, and what can be moved along)

Conclusion

Let’s try to summarize the Software Testing Life Cycle (STLC) now!

S.No	Phase Name	Entry Criteria	Activities Performed	Deliverables
1	Requirements	Requirements specification document Application design document User acceptance criteria document	Do brainstorming of the requirements. Create a list of requirements and get your doubts clarified. Understand the feasibility of the requirements whether it is testable or not. If your project requires automation, do the automation feasibility study.	RUD ( Requirements understanding document. Testing feasibility report Automation feasibility report.
2	Planning	Updated requirements document. Test feasibility reports “ Automation feasibility report.	Define the scope of the project Do the risk analysis and prepare the risk mitigation plan. Perform test estimation. Determine the overall testing strategy and process. Identify the tools and resources and check for any training needs. Identify the environment.	Test Plan document. Risk mitigation document. Test estimation document.
3	Analysis	Updated requirements document Test Plan document Risk Document Test estimation document	Identify the detailed test conditions	Test conditions document.
4	Design	Updated requirements document Test conditions document	Detail out the test condition. Identify the test data Create the traceability metrics	Detailed test condition document Requirement traceability metrics Test coverage metrics
5	Implementation	Detailed test condition document	Create and review the test cases. Create and review the automation scripts. Identify the candidate test cases for regression and automation. Identify / create the test data Take sign off of the test cases and scripts.	Test cases Test scripts Test data
6	Execution	Test cases Test scripts	Execute the test cases Log bugs / defects in case of discrepancy Report the status	Test execution report Defect report Test log and Defect log Updated requirement traceability metrics
7	Conclusion	Updated test cases with results Test closure conditions	Provide the accurate figures and result of testing Identify the risks which are mitigated	Updated traceability metrics Test summary report Updated risk management report
8	Closure	Test closure condition Test summary report	Do the retrospective meting and understand the lessons learnt	Lessons learnt document Test matrices Test closure report.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post What is Software Testing Life Cycle (STLC)? appeared first on elearningsolutionstesting.

Live Project Bug Tracking, Test Metrics, and Test Sign off

varad — Sun, 15 Dec 2024 05:30:00 +0000

This is the concluding part of our “Software Testing training on a live project” series.

It is going to be about defects and also a few remaining topics that will mark the completion of the Test Execution phase of the STLC.

In the previous article, while Test Execution was going on, we encountered a situation where the expected result of the test case was not met. Also, we identified some unexpected behavior during Exploratory Testing.

What happens when we encounter these deviations?

We obviously have to record them and track them to make sure that these deviations get handled and eventually fixed on the AUT.

#1) These deviations are referred to as Defects/bugs/issues/incidents/errors/faults.

#2) All the following cases can be logged as defects

Missing requirements
Incorrectly working requirements
Extra requirements
Reference document inconsistencies
Environment-related issues
Enhancement suggestions

#3) Defect recording is mostly done in excel sheets or via the use of a Defect Management software/tool. For information on how to handle defects via tools, try using the following links:

HP ALM
Atlassian JIRA
Also, refer to this post for a list of the most popular Bug Tracking tools in the market.

Table of Contents: [Show]

How To Log The Defects Effectively

We will now try to see how to log the defects we encountered in the previous article in an excel sheet. As always, choosing a standard format or template is important.

Typically, the following columns are a part of the Defect Report:

Defect ID: For unique identification.
Defect Description: This is like a title to describe the issue briefly.
Module/section of the AUT: This is optional, just to add more clarity as to indicate the area of the AUT where the problem was encountered.
Steps to Reproduce: What is the exact sequence of operations to be performed on the AUT to recreate the bug are to be listed here. Also, if any input data is specific to the problem that information is to be entered as well.
Severity: To indicate the intensity of the issue and eventually the impact this might have on the functioning of the AUT. The guidelines on how to assign and what values to assign in this field can be found in the test plan document. So, please refer to the Test Plan document from article 3.
Status: Will be discussed further in the article.
Screenshot: A snapshot of the application to show the error when it happened.

These are some of the ‘must-have’ fields. This template can be expanded (E.g. to include the name of the tester who reported the issue) or contracted (For Example, the module name removed) as needed.

Following the above guidelines and using the template above, a sample Defect log/Report could look like this:

Sample Defect Report for OrangeHRM Live project:

Below is the sample Defect Report created in qTest Test Management tool: (Click on image to enlarge)

Defects are no good when we log them and keep them to ourselves. We will have to assign them in the right order to have the concerned teams act on them. The process – who to assign or what order to follow can also be found in the test plan document. It is mostly similar to (Click on image to enlarge)

Defect Cycle:

From the above process, it can be noted that bugs go through different people and different decisions in the process of being identified to fixed. To track and to establish transparency as to exactly what state a certain bug is at, a “Status” field is used in the bug report. The entire process is referred to as a “Bug life cycle”. For more information on all the statuses and their meanings, please refer to this Bug Life Cycle tutorial.

A Few Pointers While Bug Tracking

At the point when we are new to an innovative Group/Task/AUT, it is in every case best to examine the issue we experienced with a companion to ensure that how we might interpret what truly makes for a deformity is right or not.
To give all the data that is important to replicate the issue. A deformity that returns to a testing group with the status set as “insufficient data” doesn’t ponder decidedly us. Look at this post – How to get your all bugs settled with next to no ‘Invalid bug’ name.
Check in the event that a comparable issue was raised prior to making another one. ‘Copy’ issues are likewise terrible information for the QA group.
Assuming there is an issue, that surfaces arbitrarily and we don’t have the foggiest idea about the specific advances/circumstances in which we can reproduce the issue-raise the issue no different either way. At the gamble of the issue being set to “IrReproducible/insufficient data” – we actually need to ensure that we dealt with all potential glitches to the most ideal degree.
The general practice is that the QA group makes every one’s imperfections in a succeed sheet during a day and combines it toward the day’s end.

The Complete Defect Life Cycle

For our live project if we were to follow the defect life cycle for defect 1,

At the point when I (the analyzer) make it, its status is “New”. At the point when I allot it to the QA group captain, the status is still “New” however the proprietor is presently the QA lead.
The QA lead will survey the issue and on verifying that it is a legitimate issue, the issue is relegated to the Dev lead. At this stage, the status is “Relegated” and the proprietor is Dev lead.
The dev lead will then dole out this issue to a designer who will chip away at fixing this issue. The status will currently be “Work Underway” (or something almost identical with that impact), the proprietor is the designer.
For imperfection 1, the engineer can’t recreate the blunder, so he allots it back to the QA group and set the status as “Not ready to duplicate”.
On the other hand, in the event that the designer had the option to chip away at it and fix an issue, the status would be set to “settled” and the issue would be appointed back to the QA group.
QA group will then, at that point, get it, retest the issue and assuming it is fixed, will set the status to “Shut”. In the event that the issue actually exists, the status is set to “Return” and the cycle proceeds.
Contingent upon different circumstances, the status can be set as “Conceded”, “insufficient data”, “Copy”, “filling in as expected”, and so on by the designer.
This strategy for recording the imperfections, announcing and allotting them, overseeing them is one of the significant exercises performed by the QA colleagues during the test execution stage. This is finished consistently until a specific test cycle is finished.
When Cycle 1 is finished, the dev group will require a little while to solidify every one of the fixes and modify the code into the following rendition that will be utilized for the following cycle.
A similar interaction again go on for cycle 2 too. Toward the finish of the cycle, quite possibly there could in any case be a few issues “Open” or unfixed in the application.
At this stage-do we actually go on with Cycle 3? If indeed, when will we quit testing?

Exit Criteria for the OrangeHRM Live Project Testing

This is where we utilize what we would call the “Leave Measures”. This is pre-characterized in the Test Plan record. It is basically as the agenda that will decide if we finish up the testing after cycle 2 or go for another cycle. It seems to be, the underneath when finished up thinking about a few speculative responses to the accompanying inquiries concerning, OrangeHRM project:

At the point when we take a gander at the above agenda, there are measurements and close down referenced there that we have not examined before. Allow us to discuss them now.

Test Metrics

We have laid out that during the Test Execution stage, reports are conveyed to the wide range of various task colleagues to give a reasonable thought regarding what’s going on in the QA Execution stage. This data means a lot to everybody to get approval about the general nature of the eventual outcome.

Envision I report that 10 experiments breezed through or 100 assessment cases were executed-these numbers are just crude information and don’t give an excellent viewpoint about how things are going on.

Measurements assume a crucial part in filling this hole. Measurements are in straightforward words, savvy numbers that the testing group gathers and keeps up with. For Instance, assuming I expressed 90% of the experiments passed, it checks out than saying 150 experiments passed. Isn’t it?

There are various types of Measurements gathered during the test execution stage. What measurements precisely are to be gathered and kept up with for what timeframes this data can be found in the test plan record.

The following are the most commonly collected test metrics for most projects:

Pass Percentage of the Test cases
Defects density
Critical Defects percentage
Defects, Severity wise number

Check out the Status Report attached to this article to see how these metrics are used.

Test Sign Off /Completion Report

As we need to advise every one of the partners that testing has started, it is likewise the QA group’s obligation to tell everybody that testing has been finished and share the outcomes. In this way, normally an email is sent from the QA group (generally the Leader/QA Supervisor) giving a sign that the QA group has approved the item joining the experimental outcomes and the rundown of open/known issues.has signed off on the product attaching the test results and the list of open/known issues.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post Live Project Bug Tracking, Test Metrics, and Test Sign off appeared first on elearningsolutionstesting.

How to Review SRS Document and Create Test Scenarios

varad — Sat, 14 Dec 2024 05:30:00 +0000

This is the second tutorial in the “Free Online Software Testing Training on a Live Project” series. If you are new here, please go to the first introduction tutorial: End to End Software Testing Training on a Live Project.

Let us now take a detailed look at how an SRS walkthrough works, what we need to identify from this phase, what pre-steps we need to take before we begin, what obstacles we may face, and so on.

SDLC’s Design Phase:

The “Design” phase of the SDLC is when the functional requirements are transformed into technical specifics.
This process involves the development, design, environmental, and data teams.
This process often produces a Technical Design Document (TDD).

The SRS document serves as both an input for the TDD and a starting point for the QA team to work on the project’s QA part, which is to examine the SRS and determine the test objectives.

http://www.elearningsolutionstesting.inTable of Contents: [Show]

What Is An SRS Review?

SRS is a record that is made by the improvement group in a joint effort with Business Experts and climate/information groups. Regularly, this record once concluded will be imparted to the QA group through a gathering where a definite walkthrough is organized.

At times, for a generally existing application, we probably won’t require a proper gathering and somebody directing us through this record. We could have the important data to do this without anyone else.

SRS survey is only going through the utilitarian necessities particular archive and attempting to comprehend what the objective application will be like.

The proper organization and an example were imparted to you all in the past article. It doesn’t be guaranteed to imply that all SRSs will be archived that way precisely. Continuously, the structure is optional to the substance.

A few groups will simply decide to compose a bulleted show, a few groups will incorporate use cases, a few groups will incorporate example screen captures (like the report we had) and some portray the subtleties in sections.

Pre-Steps To Software Requirements Specification Review

Step #1) Documents go through multiple revisions, so make sure we have the right version of the referenced document, the SRS.

Step #2) Establish guidelines on what is expected at the end of the review from each team member. In other words, decide on what deliverables are expected from this step – typically, the output of this step is to identify the test scenarios. Test scenarios are nothing but one line pointers of ‘what to test’ for certain functionality.

Step #3) Also establish guidelines on how this deliverable is to be presented- I mean, the template.

Step #4) Decide on whether each member of the team is going to work on the entire document or divide it among themselves. It is highly recommended that everyone reads everything because that will prevent knowledge concentration with certain team members.

But in case of a huge project, with the SRS documents running close to 1000 pages, the approach of breaking up the document module wise and assigning to individual team members is most practical.

Step #5) SRS review also helps in better understanding if there are any specific prerequisites required for the testing of the software.

Step #6) As a byproduct, a list of queries where some functionality is difficult to understand or if more information needs to be incorporated into functional requirements or if mistakes are made in SRS are identified.

What do we need to get started?

The correct version of the SRS document
Clear instructions on who is going to work on what and how much time have they got.
A template to create Test Scenarios.
Other information on- who to contact in case of a question or who to report in case of a documentation inconsistency

Who would provide this information?

Group leads are for the most part answerable for giving every one of the things recorded in the segment above. Notwithstanding, colleagues’ bits of feedbacks are generally significant for the outcome of this whole undertaking.

Group leads frequently ask-What sort of sources of info? Couldn’t it be smarter to relegate a specific module to somebody intrigued by it than to a not? colleague? Couldn’t it be good to settle on the deadline in view of the group’s perspective than push a choice on them? Likewise, for the outcome of an undertaking, layouts are significant.

When in doubt, layouts have a higher pace of proficiency when they are custom-made to the particular group’s accommodation and solace. It ought to, thusly, be noticed that group leads more than anything are colleagues. Getting your group locally available on the everyday choices is urgent for the smooth running of the task.

Is Template Required For Test Scenarios?

Why a template for test scenarios – isn’t it enough if we just make a list?

It sure is. Nonetheless, programming projects are not ‘one-man’ shows. They include cooperation.

Envision a group of 4-in the event that every last one of them chooses to survey one module of the product prerequisites determination each. Colleague A has made a rundown on a piece of paper. 2 utilized a succeed sheet. Colleague 3 utilized a notebook. Colleague 4 utilized a word doc. How would we solidify practically everything accomplished for the task by the day’s end?

Likewise, how might we conclude which one is the norm and how might we get out whatever is correct and what’s not on the off chance that we didn’t make the guidelines, regardless?

That is what template is: A set of guidelines and an agreed format for uniformity and concurrence for the entire team.

How to create a template for QA Test Scenarios?

Templates don’t have to be complicated or inflexible.

All they need to be are an efficient mechanism to create a useful testing artifact. Something simple like the one we see below:

The header of this template contains the space required to capture basic information about the project, the current document, and the referenced document.

The table below will let us create Test Scenarios. The columns included are:

Column #1) Test Scenario ID
Every entity in our testing process has to be uniquely identifiable. So, every test scenario has to be assigned an ID. The rules to follow while assigning this ID have to be defined.

For the sake of this article we are going to follow the naming convention as TS(prefix that stands for Test Scenario) followed by ‘_’, module name MI(My Info module of the Orange HRM project) followed by ‘_’ and then the subsection (For Example, MIM for My Info Module, P for photograph and so on)followed by a serial number. An example would be: “TS_MI_MIM_01”.

Column #2) Requirement
It helps that when we create a test scenario we should be able to map it back to the section of the SRS document where we picked it from. If the requirements have IDs we could use that. If not section numbers or even page numbers of the SRS document from where we identified a testable requirement will do.

Column #3) Test Scenario description
A one-liner specifying ‘what to test’. We would also refer to it as the test objective.

Column #4) Importance
This is to give an idea about how important certain functionality is for the AUT. Values like high, medium and low can be assigned to this field. You could also choose a point system, like 1-5, 5 being most important, 1 being less important. Whatever the value this field can take, it has to be pre-decided.

Column #5) No. of Test cases
A rough estimate on how many individual test cases we might end up writing that one test scenario. For Example, To test the login- we include these situations: Correct username and password. Correct username and wrong password. Correct password and wrong username. So, validating the login functionality will result in 3 test cases.

Note: You can expand this template or remove the fields as you see fit.

For example, you can add “Reviewed by” in the header or remove the date of creation, etc. Also in the table, you can include a field “Created by” to designate the tester responsible for a certain test scenario or remove the “No. of Test cases” column. The choice is yours. Go with what works best for the entire team.

Let us now review our Orange HRM SRS Document and create the Test Scenarios

Pro Tip: check out the table of contents in the SRS sample we provided in 1st tutorials to get a good idea of how any document is going to flow and how much of work it might involve.

Section 1 is the purpose of the document. No testable requirements there.

Section 2.1: Project Overview- Audience- no testable requirements there either.

Section 2.2: Hardware and Hosting- This section is talking about how the Orange HRM site is going to be hosted. Now, is this information important to us testers? The answer is Yes and No. Yes, because when we test we need to have an environment that is similar to the real-time environment.

This gives us an idea of how it needs to be. No, because, it is not a testable requirement- a kind of prerequisite for the testing to happen.

Section 3: There is a login screen here and the details of the type of account we need to have to enter the site. This is a testable requirement. So it needs to be a part of our Test scenarios.

Please see the test scenarios document where test scenarios for a few sections of the SRS have been added. For practice, please add the rest of the scenarios in a similar manner. However, I am going right to section 4 of the document.

Section 4: Aesthetic/HTML Requirements and Guidelines- This section best explains how some requirements might not make sense to the test team at the time of the SRS review, but the team should make a note of them as testable requirements all the same.

How to test them and if we need specific set up/any team’s help to validate it are details we might not know at this point in time. But making them a part of our testing scope is the first step to ensure that we do not miss them.

Sample Test Scenarios for OrangeHRM Application: (click to enlarge image)

=> Please refer and download the Test Scenarios document for more information.

Some Important Observations Regarding SRS Review

#1) No information is to be left uncovered.
#2) Perform feasibility analysis on whether a certain requirement is correct or not and also if it can be tested or not.
#3) Unless a separate performance/security or any other form of test teams exist- it is our job to make sure that all nonfunctional requirements have to be taken into consideration.
#4) Not all information is targeted at the testers, so it is important to understand what to note and what not.
#5) The importance and no. of test cases for a test scenario need not be accurate and can be filled in with an approximate value or can be left empty.

To sum up, SRS review results in:

Test Scenarios list
Review Results – Documentation/Requirement errors found by statically going through/verifying the SRS document
A list of Questions for better understanding- in case of any
The preliminary idea of how the test environment is supposed to be like
Test scope identification and a rough idea on how many test cases we might end up having- so how much time we need for documentation and eventually execution.

Important points to note:

#1) Test scenarios are not external deliverables (not shared with Business Analysts or Dev teams) but are important for internal QA consumption. They are our first step towards a 100% test coverage goal. Test scenarios once complete undergo a peer review and once that is done, they are all consolidated.

For more details on how QA documents are reviewed, check out the article: How to Perform Test Documentation Reviews in 6 Simple Steps.

#2) We could use a test management tool like HP ALM or qTest to create the test scenarios. However, the Test scenarios creation in real-time is a manual activity. In my opinion, it is more convenient manually. Since it is step 1 we do not need to bring out the big guns yet. Simple excel sheets are the best way to go about it.

The next step to this series is that – we will work on creating test cases and get further into the test designing phase. Before that, we will also get into – What test planning is? Where it fits into the entire QA project? As always, work with us for the best results.

YOU MAY BE INTERESTED IN

Mastering Software Testing: A Comprehensive Syllabus

The post How to Review SRS Document and Create Test Scenarios appeared first on elearningsolutionstesting.

Test Execution In Software Testing

varad — Fri, 13 Dec 2024 05:30:00 +0000

Exact Process And Plan To Execute Test Cases With Real Examples.

Today, in our Software Testing mini training course, we are progressing into the last stage of the STLC, which is the Test Execution.

You can check out the list of all tutorials posted in this free QA training series on this page: End to End software testing training on a live project.

Test Execution is, without doubt, the most important and ‘happening’ phase in the STLC and also the entire development lifecycle. The reason is – every team/team member’s contribution and work gets validated here:

Has the Business Analyst interpreted the requirements correctly?

Has the development team translated the business requirements to functional requirements and eventually to code correctly?
Has the data architect and DBAs designed the right back-end systems?

Well, test execution is where all the answers to these questions would be found. That does make us, QAs the heroes of the entire software building process, doesn’t it?

Test Execution is also the “Test” part of the SDLC.

Once the test cases are written, shared with the BAs and Dev team, reviewed by them, changes are notified to the QA team (if any), the QA team makes necessary amends- Test design phase is complete. Now getting the Test cases ready does not mean we can initiate the test run. We need to have the application ready as well among other things.

Table of Contents: [Show]

Test Execution Guidelines

Let us now make a list of all things that are important to understanding the Test Execution phase:

#1) The build (the code that is written by the dev team is packaged into what is referred to a build- this is nothing but an installable piece of software (AUT), ready to be deployed to QA environment.) being deployed (in other words, installed and made available) to the QA environment is one of the most important aspects that needs to happen for the Test Execution to start.

#2) Test Execution happens in the QA environment. To make sure that the dev team’s work on the code is not in the same place, where the QA team is testing, the general practice is to have a dedicated Dev and QA environment. (There is also a production environment to host the live application).

This is basically to preserve the integrity of the application at various stages in the SDLC lifecycle. Otherwise, ideally, all 3 environments are identical in nature.

#3) Test team size is not constant from the beginning of the project. When the Test Plan is initiated the team might just have a Team lead. During the test design phase, a few testers come on board. Test Execution is the phase when the team is at its maximum size.

#4) Test Execution also happens in at least 2 cycles (3 in some projects). Typically in each cycle, all the test cases (the entire test suite) will be executed. The objective of the first cycle is to identify any blocking, critical defects, and most of the high defects.

The objective of the second cycle is to identify remaining high and medium defects, correct gaps in the scripts and obtain results.

#5) Test Execution phase consists of- Executing the Test scripts + Test script maintenance (correct gaps in the scripts) + Reporting (defects, status, metrics, etc.) Therefore, when planning this phase schedules and efforts should be estimated taking into consideration all these aspects and not just the script execution.

#6) After the Test script being done and the AUT is deployed – and before the Test execution begins, there is an intermediary step. This is called the “Test Readiness Review (TRR)”. This is a sort of transitional step that will end the test designing phase and ease us into the test execution.

For information on this step and a sample “Test Readiness Review checklist”, check out this link: Software testing Checklist

#7) In addition to the TRR, there are few more additional checks before we ensure that we can go ahead with accepting the current build that is deployed in the QA environment for test execution.

Those are the Smoke and Sanity tests. Detailed information on what these are is at: What is Smoke and Sanity Test?

#8) Upon successful completion of TRR, Smoke and Sanity tests, the test cycle officially begins.

#9) Exploratory Testing would be carried out once the build is ready for testing. The purpose of this test is to make sure critical defects are removed before the next levels of testing can start. This exploratory testing is carried out in the application without any test scripts and documentation. It also helps in getting familiar with the AUT.

#10) Just like the other phases of the STLC, the work is divided among team members in the Test Execution phase also. The division might be based on module wise or test case count wise or anything else that might make sense.

#11) The primary outcome of the test execution phase is in the form of reports primarily i.e. Defect Report and Test Execution Status report. The detailed process for reporting can be found at Test Executions reports.

New Columns In Test Cases Document

The Test Case document now gets to be expanded with the following two columns – Status and Actual result.

(Note: For live project Test Execution, we have added and updated these columns with test execution results in the test cases spreadsheet provided for download below)

#1) Status Column

Test Execution is nothing but, using the test steps on the AUT, supplying the test data(as identified in the test case document) and observing the behavior of the AUT to see if it satisfies the expected result or not.

If the expected result is not met, it can be construed as a defect. And the status of the test case becomes “Fail” and if the expected result is met, the status is “Pass”. If the test case cannot be executed because of any reasons (an existing defect or environment not supporting) the status would be “Blocked”.

The status of a test case that is yet to be run can be set to No run/unexecuted or can be left empty.

For a test case with multiple steps, if a certain step’s (in the middle of the test case steps) expected result is not met, the test case status can be set to “Fail” right there and the next steps need not be executed.
The status “Fail” can be indicated in red color, if you would like to draw attention to it immediately.

#2) Actual Result Column

Here we analyzers can keep what the deviation in the normal outcome is. At the point when the normal outcome is met (or an experiment whose status is “Pass”) this field can be left vacant. Since, in the event that the normal outcome is met it implies the genuine result=expected result, and that implies changing it in the genuine outcome section will be a reiteration and overt repetitiveness.

A screenshot of the deviation can be attached to this column for enhanced clarity of what the problem is.

Test Execution Results For OrangeHRM Live Project

Let us now get OrangeHRM and carry out the test execution based on the above guidelines listed.

Here are a few points to note:

The lengthy experiment layout.
Exploratory testing as shown is to be completed without test scripts. So kindly go ahead and test the application in lined up as you see fit.
Because of the restrictions that we have in introducing the live undertaking as lucid substance just a restricted measure of experiments/usefulness of the OrangeHRM application is displayed in the example Test Execution layout. Once more, kindly feel to chip away at something else for the most viable experience.
The Mental stability and Smoke test suites are additionally added to the report, to give you a thought regarding what sort of experiments are considered for these stages.
Abandons are not logged at this point, despite the fact that the situation with some experiments is set to “Fall flat”. This is on the grounds that logging the deformities is the following generally significant/ordinarily dealt with a part of our life as analyzers. In this way, we need to manage it exhaustively in the following article.

Test Cases with Execution Results:

It Contains – Test cases execution result, Smoke tests, Sanity tests, Exploratory test – spreadsheets

Lastly, if a Test Management tool was used for creating and maintaining the test case, the same can be used for test execution as well. The use of a tool makes reporting easier, but otherwise, the process of running the test cases is the same. Please check out this article to get an idea of how to use HP ALM for Test Case Execution.

(Click on the image for an enlarged view)

This brings us to the end of another interesting segment of the testing process. In the next and last article of this free online Software Testing QA training mini-course, we will look into defects in detail; wrap up topics like “when to stop testing”, metrics and QA sign off.

YOU MAY BE INTERESTED IN