yourtestingbuddy@gmail.com – Page 9

Differences between the Alpha testing and Beta testing are:

August 18, 2022
by yourtestingbuddy@gmail.com

Sr. No.	Alpha Testing	Beta Testing
1.	Alpha testing performed by a team of highly skilled testers who are usually the internal employee of the organization.	Beta testing performed by clients or end-users in a real-time environment, who is not an employee of the organization.
2.	Alpha testing performed at the developer’s site; it always needs a testing environment or lab environment.	Beta testing doesn’t need any lab environment or the testing environment; it is performed at a client’s location or end-user of the product.
3.	Reliability or security testing not performed in-depth in alpha testing.	Reliability, security, and robustness checked during beta testing.
4.	Alpha testing involves both white box and black-box techniques.	Beta testing uses only black-box testing.
5.	Long execution cycles maybe require for alpha testing.	Only a few weeks are required for the execution of beta testing.
6.	Critical issues or fixes can be identified by developers immediately in alpha testing.	Most of the issues or feedback is collecting from the beta testing will be implemented for the future versions of the product.
7.	Alpha testing performed before the launch of the product into the market.	At the time of software product marketing.
8.	Alpha testing focuses on the product’s quality before going to beta testing.	Beta testing concentrates on the quality of the product, but gathers users input on the product and ensures that the product is ready for real-time users.
9.	Alpha testing performed nearly the end of the software development.	Beta testing is a final test before shipping a product to the customers.
10.	Alpha testing is conducting in the presence of developers and the absence of end-users.	Beta testing reversed of alpha testing.

Difference

Difference between verification and validation testing

August 18, 2022
by yourtestingbuddy@gmail.com

Verification	Validation
We check whether we are developing the right product or not.	We check whether the developed product is right.
Verification is also known as static testing.	Validation is also known as dynamic testing.
Verification includes different methods like Inspections, Reviews, and Walkthroughs.	Validation includes testing like functional testing, system testing, integration, and User acceptance testing.
It is a process of checking the work-products (not the final product) of a development cycle to decide whether the product meets the specified requirements.	It is a process of checking the software during or at the end of the development cycle to decide whether the software follow the specified business requirements.
Quality assurance comes under verification testing.	Quality control comes under validation testing.
The execution of code does not happen in the verification testing.	In validation testing, the execution of code happens.
In verification testing, we can find the bugs early in the development phase of the product.	In the validation testing, we can find those bugs, which are not caught in the verification process.
Verification testing is executed by the Quality assurance team to make sure that the product is developed according to customers’ requirements.	Validation testing is executed by the testing team to test the application.
Verification is done before the validation testing.	After verification testing, validation testing takes place.
In this type of testing, we can verify that the inputs follow the outputs or not.	In this type of testing, we can validate that the user accepts the product or not.

Difference

Difference between Load testing and Stress testing

August 18, 2022
by yourtestingbuddy@gmail.com

Load testing	Stress testing
Load testing is used to find the performance of the application by testing the database, networks, and website servers.	Stress testing is used to find the stability and response time of the given system.
Load testing helps the tester to identify the bottleneck and also able to tell the cause of bottlenecks before deployment to the production server.	Stress testing helps the tester to check the system capacity when number of users increased suddenly before the system failure or crashed.
This type of testing reproduced the load on any application and software.	It is used to figure out the robustness and stability of the application.
Load testing is used to test web-based and client-server types of application.	Stress testing tests suddenly increased traffic of the application.
WebLOAD, LoadView, LoadRunner, SmartMeter.io, and LoadUI NG Pro are some of the load testing tools which help us to perform load testing on the applications.	LoadRunner, JMeter, NeoLoad are some of the stress testing tools which help us to perform stress testing on the applications.
After doing the load testing on the application, the cost of failure may reduce, and the satisfaction of the customer is increased.	After doing Stress testing on the application, if the system got to fail, it will recover quickly by finding the breaking point early and also see where the system got crashed.
For example: if we have one scenario where the load is 100 users using the application at a 2.5\sec of goal time. And, the desired load is 100 user. This scenario got passed because the desired load is equal to the load, which satisfies the load testing condition.	For example: if we took the same scenario where the actual load of 100 users which are using the application at a 2.5\sec of goal time. When the desired load got increased by 200 users, and it will become 300. So now, 300 users using the application at 2.5\sec of goal time. It will pass because the desired load is greater than the load according to the stress testing condition.

Difference

Smoke Testing vs Sanity Testing

August 18, 2022
by yourtestingbuddy@gmail.com

The below comparison table enlightens the important differences between smoke testing and sanity testing in a quick manner:

S.No.	Comparison Basis	Smoke Testing	Sanity Testing
1	Test coverage	It is a broad approach to testing where all parts of the application are tested.	It is a narrow approach to testing where specific parts of the application are tested.
2	Measures	It measures the stability of the system by performing rigorous testing.	It measures the rationality of the system by performing rigorous testing.
3	Technique	Smoke testing can be either manual or automated.	Sanity testing can be done without test cases or scripts.
4	Executed by	It is performed by both testers and developers.	It is performed by only testers.
5	Purpose	Testing is done without getting into deep but whenever needed tester has to go into deep.	Sanity testing does not need to go into deep of the application.
6.	Performed at	Smoke testing is the first testing performed on the initial build.	Sanity testing is performed when the build is comparatively stable.
7	Documentation	Smoke testing is documented.	Sanity testing is not documented.
8	Used to	It is used to test End to End function of the application.	It is used to test only modified or defect fixed functions.
9	Subset	It is considered as a subset of acceptance testing.	It is considered as a subset of regression testing.

Uncategorized

Difference between Bug, Defect, Error, Fault & Failure

August 18, 2022
by yourtestingbuddy@gmail.com

In this section, we are going to discuss the difference between the Bug, Defect, Error, Fault & Failure as we understood that all the terms are used whenever the system or an application act abnormally.

Sometimes we call it an error and sometimes a bug or a defect and so on. In software testing, many of the new test engineers have confusion in using these terminologies.

Generally, we used these terms in the Software Development Life Cycle (SDLC) based on the phases. But there is a conflict in the usage of these terms.

In other words, we can say that in the era of software testing, the terms bugs, defects, error, fault, and failure come across every second of the day.

Skip Ad

But for a beginner or the inexperienced in this field, all these terminologies may seem synonyms. It became essential to understand each of these terms independently if the software doesn’t work as expected.

What is a bug?

In software testing, a bug is the informal name of defects, which means that software or application is not working as per the requirement. When we have some coding error, it leads a program to its breakdown, which is known as a bug. The test engineers use the terminology Bug.

If a QA (Quality Analyst) detect a bug, they can reproduce the bug and record it with the help of the bug report template.

What is a Defect?

When the application is not working as per the requirement is knows as defects. It is specified as the aberration from the actual and expected result of the application or software.

In other words, we can say that the bug announced by the programmer and inside the code is called a Defect.

What is Error?

The Problem in code leads to errors, which means that a mistake can occur due to the developer’s coding error as the developer misunderstood the requirement or the requirement was not defined correctly. The developers use the term error.

Bug vs Defect vs Error vs Fault vs Failure

What is Fault?

The fault may occur in software because it has not added the code for fault tolerance, making an application act up.

A fault may happen in a program because of the following reasons:

Lack of resources
An invalid step
Inappropriate data definition

What is Failure?

Many defects lead to the software’s failure, which means that a loss specifies a fatal issue in software/ application or in its module, which makes the system unresponsive or broken.

In other words, we can say that if an end-user detects an issue in the product, then that particular issue is called a failure.

Possibilities are there one defect that might lead to one failure or several failures.

For example, in a bank application if the Amount Transfer module is not working for end-users when the end-user tries to transfer money, submit button is not working. Hence, this is a failure.

The flow of the above terminologies are shown in the following image:

Bug Vs. Defect Vs. Error Vs. Fault Vs. Failure

We have listed some of the vital differences between bug, defect, error, fault, and failure in the below table.

Comparison basis	Bug	Defect	Error	Fault	Failure
Definition	It is an informal name specified to the defect.	The Defect is the difference between the actual outcomes and expected outputs.	An Error is a mistake made in the code; that’s why we cannot execute or compile code.	The Fault is a state that causes the software to fail to accomplish its essential function.	If the software has lots of defects, it leads to failure or causes failure.
Raised by	The Test Engineers submit the bug.	The Testers identify the defect. And it was also solved by the developer in the development phase or stage.	The Developers and automation test engineers raise the error.	Human mistakes cause fault.	The failure finds by the manual test engineer through the development cycle.
Different types	Different type of bugs are as follows:Logic bugsAlgorithmic bugsResource bugs	Different type of Defects are as follows: Based on priority:HighMediumLowAnd based on the severity:CriticalMajorMinorTrivial	Different type of Error is as below:Syntactic ErrorUser interface errorFlow control errorError handling errorCalculation errorHardware errorTesting Error	Different type of Fault are as follows:Business Logic FaultsFunctional and Logical FaultsFaulty GUIPerformance FaultsSecurity FaultsSoftware/ hardware fault	—–
Reasons behind	Following are reasons which may cause the bugs: Missing coding Wrong coding Extra coding	The below reason leads to the defects: Giving incorrect and wrong inputs. Dilemmas and errors in the outside behavior and inside structure and design. An error in coding or logic affects the software and causes it to breakdown or the failure.	The reasons for having an error are as follows: Errors in the code. The Mistake of some values. If a developer is unable to compile or run a program successfully. Confusions and issues in programming. Invalid login, loop, and syntax. Inconsistency between actual and expected outcomes. Blunders in design or requirement actions. Misperception in understanding the requirements of the application.	The reasons behind the fault are as follows: A Fault may occur by an improper step in the initial stage, process, or data definition. Inconsistency or issue in the program. An irregularity or loophole in the software that leads the software to perform improperly.	Following are some of the most important reasons behind the failure: Environmental condition System usage Users Human error
Way to prevent the reasons	Following are the way to stop the bugs: Test-driven development. Offer programming language support. Adjusting, advanced, and operative development procedures. Evaluating the code systematically.	With the help of the following, we can prevent the Defects: Implementing several innovative programming methods. Use of primary and correct software development techniques. Peer review It is executing consistent code reviews to evaluate its quality and correctness.	Below are ways to prevent the Errors: Enhance the software quality with system review and programming. Detect the issues and prepare a suitable mitigation plan. Validate the fixes and verify their quality and precision.	The fault can be prevented with the help of the following: Peer review. Assess the functional necessities of the software. Execute the detailed code analysis. Verify the correctness of software design and programming.	The way to prevent failure are as follows: Confirm re-testing. Review the requirements and revisit the specifications. Implement current protective techniques. Categorize and evaluate errors and issues.

Conclusion

After seeing all the significant differences between bug, defect, error, fault, and failure, we can say that the several issues and inconsistencies found throughout software are linked and dependent on each other.

All the above terminology affects and change different parts of the software and differ from one another massively. However, all these differences between bug, defect, errors, faults, and failures slow down the software’s excellence and performance.

Types of Testing

What is Regression Testing?

August 18, 2022
by yourtestingbuddy@gmail.com

Regression Testing is defined as a type of software testing to confirm that a recent program or code change has not adversely affected existing features. Regression Testing is nothing but a full or partial selection of already executed test cases which are re-executed to ensure existing functionalities work fine.

This testing is done to make sure that new code changes should not have side effects on the existing functionalities. It ensures that the old code still works once the latest code changes are done.

Need of Regression Testing

The Need of Regression Testing mainly arises whenever there is requirement to change the code and we need to test whether the modified code affects the other part of software application or not. Moreover, regression testing is needed, when a new feature is added to the software application and for defect fixing as well as performance issue fixing.

Example of Regression testing

Here we are going to take a case to define the regression testing efficiently:

Consider a product Y, in which one of the functionality is to trigger confirmation, acceptance, and dispatched emails. It also needs to be tested to ensure that the change in the code not affected them. Regressing testing does not depend on any programming language like Java, C++, C#, etc. This method is used to test the product for modifications or any updates done. It ensures that any change in a product does not affect the existing module of the product. Verify that the bugs fixed and the newly added features not created any problem in the previous working version of the Software.

When can we perform Regression Testing?

We do regression testing whenever the production code is modified.

We can perform regression testing in the following scenario, these are:

1. When new functionality added to the application.

Example:

A website has a login functionality which allows users to log in only with Email. Now providing a new feature to do login using Facebook.

2. When there is a Change Requirement.

Example:

Remember password removed from the login page which is applicable previously.

3. When the defect fixed

Example:

Assume login button is not working in a login page and a tester reports a bug stating that the login button is broken. Once the bug fixed by developers, tester tests it to make sure Login Button is working as per the expected result. Simultaneously, tester tests other functionality which is related to the login button.

4. When there is a performance issue fix

Example:

Loading of a home page takes 5 seconds, reducing the load time to 2 seconds.

5. When there is an environment change

Example:

When we update the database from MySql to Oracle.

How to perform Regression Testing?

The need for regression testing comes when software maintenance includes enhancements, error corrections, optimization, and deletion of existing features. These modifications may affect system functionality. Regression Testing becomes necessary in this case.

Regression testing can be performed using the following techniques:

1. Re-test All:

Re-Test is one of the approaches to do regression testing. In this approach, all the test case suits should be re-executed. Here we can define re-test as when a test fails, and we determine the cause of the failure is a software fault. The fault is reported, we can expect a new version of the software in which defect fixed. In this case, we will need to execute the test again to confirm that the fault fixed. This is known as re-testing. Some will refer to this as confirmation testing.

The re-test is very expensive, as it requires enormous time and resources.

2. Regression test Selection:

In this technique, a selected test-case suit will execute rather than an entire test-case suit.
The selected test case suits divided in two cases
1. Reusable Test cases.
2. Obsolete Test cases.
Reusable test cases can use in succeeding regression cycle.
Obsolete test cases can’t use in succeeding regression cycle.

3. Prioritization of test cases:

Prioritize the test case depending on business impact, critical and frequently functionality used. Selection of test cases will reduce the regression test suite.

What are the Regression Testing tools?

Regression Testing is a vital part of the QA process; while performing the regression we may face the below challenges:

Time Consuming
Regression Testing consumes a lot of time to complete. Regression testing involves existing tests again, so testers are not excited to re-run the test.
Complex
Regression Testing is complex as well when there is a need to update any product; lists of the test are also increasing.
Communicating business rule
Regression Testing ensures the existing product features are still in working order. Communication about regression testing with a non-technical leader can be a difficult task. The executive wants to see the product move forward and making a considerable time investment in regression testing to ensure existing functionality working can be hard.
Identify Impact Area
Test Cases Increases Release by Release
Less Resources
No Accuracy
Repetitive Task
Monotonous Job

Regression testing process

The regression testing process can be performed across the builds and the releases.

Regression testing across the builds

Whenever the bug fixed, we retest the Bug, and if there is any dependent module, we go for a Regression Testing.

For example, How we perform the regression testing if we have different builds as Build 1, Build 2, and Build 3, which having different scenarios.

Build1

Firstly the client will provide the business needs.
Then the development team starts developing the features.
After that, the testing team will start writing the test cases; for example, they write 900 test cases for the release#1 of the product.
And then, they will start implementing the test cases.
Once the product is released, the customer performs one round of acceptance testing.
And in the end, the product is moved to the production server.

Build2

Now, the customer asks for 3-4 extra (new) features to be added and also provides the requirements for the new features.
The development team starts developing new features.
After that, the testing team will start writing the test case for the new features, and they write about 150 new test cases. Therefore, the total number of the test case written is 1050 for both the releases.
Now the testing team starts testing the new features using 150 new test cases.
Once it is done, they will begin testing the old features with the help of 900 test cases to verify that adding the new feature has damaged the old features or not.
Here, testing the old features is known as Regression Testing.
Once all the features (New and Old) have been tested, the product is handed over to the customer, and then the customer will do the acceptance testing.
Once the acceptance testing is done, the product is moved to the production server.

Build3

After the second release, the customer wants to remove one of the features like Sales.
Then he/she will delete all the test cases which are belonging to the sales module (about 120 test cases).
And then, test the other feature for verifying that if all the other features are working fine after removing the sales module test cases, and this process is done under the regression testing.

Note:

Testing the stable features to ensure that it is broken because of the changes. Here changes imply that the modification, addition, bug fixing, or the deletion.
Re-execution of the same test cases in the different builds or releases is to ensure that changes (modification, addition, bug fixing, or the deletion) are not introducing bugs in stable features.

Regression testing across the release

The regression testing process starts whenever there is a new Release for same project because the new feature may affect the old elements in the previous releases.

To understand the regression testing process, we will follow the below steps:

Step1

There is no regression testing in Release#1 because there is no modification happen in the Release#1 as the release is new itself.

Step2

The concept of Regression testing starts from Release#2 when the customer gives some new requirements.

Step3

After getting the new requirements (modifying features) first, they (the developers and test engineers) will understand the needs before going to the impact analysis.

Step4

After understanding the new requirements, we will perform one round of impact analysis to avoid the major risk, but here the question arises who will do the Impact analysis?

Step5

The impact analysis is done by the customer based on their business knowledge, the developer based on their coding knowledge, and most importantly, it is done by the test engineer because they have the product knowledge.

Note: If a single person does, he/she may not cover all the impact areas, so we include all persons so that we may cover a maximum impact area, and Impact Analysis should be done at the early stages of the releases.

Step6

Once we are done with the impact area, then the developer will prepare the impact area (document), and the customer will also prepare the impact area document so that we can achieve the maximum coverage of impact analysis.

Step7

After completing the impact analysis, the developer, the customer, and the test engineer will send the Reports# of the impact area documents to the Test Lead. And in the meantime, the test engineer and the developer are busy working on the new test case.

Step8

Once the Test lead gets the Reports#, he/she will consolidate the reports and stored in the test case requirement repository for the release#1.

Note: Test case Repository: Here, we will save all the test case of releases.

Step9

After that, the Test Lead will take the help of RTM and pick the necessary regression test case from the test case repository, and those files will be placed in the Regression Test Suite.

Note:

The test lead will store the regression test case in the regression test suite for no further confusion.
Regression test suite: Here, we will save all the impact area test documents.
Regression Test Cases: These are the test cases of the old releases text document which need to be re-executed as we can see in the below image:

Step10

After that, when the test engineer has done working on the new test cases, the test lead will assign the regression test case to the test engineer.

Step11

When all the regression test cases and the new features are stable and pass, then check the impact area using the test case until it is durable for old features plus the new features, and then it will be handed over to the customer.

Types of Regression Testing

The different types of Regression Testing are as follows:

Unit Regression Testing [URT]
Regional Regression Testing[RRT]
Full or Complete Regression Testing [FRT]

Unit Regression Testing [URT]

In this, we are going to test only the changed unit, not the impact area, because it may affect the components of the same module.

Example1

In the below application, and in the first build, the developer develops the Search button that accepts 1-15 characters. Then the test engineer tests the Search button with the help of the test case design technique.

Now, the client does some modification in the requirement and also requests that the Search button can accept the 1-35 characters. The test engineer will test only the Search button to verify that it takes 1-35 characters and does not check any further feature of the first build.

Example2

Here, we have Build B001, and a defect is identified, and the report is delivered to the developer. The developer will fix the bug and sends along with some new features which are developed in the second Build B002. After that, the test engineer will test only after the defect is fixed.

The test engineer will identify that clicking on the Submit button goes to the blank page.
And it is a defect, and it is sent to the developer for fixing it.
When the new build comes along with the bug fixes, the test engineer will test only the Submit button.
And here, we are not going to check other features of the first build and move to test the new features and sent in the second build.
We are sure that fixing the Submitbutton is not going to affect the other features, so we test only the fixed bug.

Therefore, we can say that by testing only the changed feature is called the Unit Regression Testing.

Regional Regression testing [RRT]

In this, we are going to test the modification along with the impact area or regions, are called the Regional Regression testing. Here, we are testing the impact area because if there are dependable modules, it will affect the other modules also.

For example:

In the below image as we can see that we have four different modules, such as Module A, Module B, Module C, and Module D, which are provided by the developers for the testing during the first build. Now, the test engineer will identify the bugs in Module D. The bug report is sent to the developers, and the development team fixes those defects and sends the second build.

In the second build, the previous defects are fixed. Now the test engineer understands that the bug fixing in Module D has impacted some features in Module A and Module C. Hence, the test engineer first tests the Module D where the bug has been fixed and then checks the impact areas in Module A and Module C. Therefore, this testing is known as Regional regression testing.

While performing the regional regression testing, we may face the below problem:

Problem:

In the first build, the client sends some modification in requirement and also wants to add new features in the product. The needs are sent to both the teams, i.e., development and testing.

After getting the requirements, the development team starts doing the modification and also develops the new features based on the needs.

Now, the test lead sends mail to the clients and asks them that all are the impact areas that will be affected after the necessary modification have been done. Therefore, the customer will get an idea, which all features are needed to be tested again. And he/she will also send a mail to the development team to know which all areas in the application will be affected as a result of the changes and additions of new features.

And similarly, the customer sends a mail to the testing team for a list of impact areas. Hence, the test lead will collect the impact list from the client, development team, and the testing team as well.

This Impact list is sent to all the test engineers who look at the list and check if their features are modified and if yes, then they do regional regression testing. The impact areas and modified areas are all tested by the respective engineers. Every test engineer tests only their features that could have been affected as a result of the modification.

The problem with this above approach is that the test lead may not get the whole idea of the impact areas because the development team and the client may not have so much time to revert his/her mails.

Solution

To resolve the above problem, we will follow the below process:

When a new build comes along with the latest features and bug fixes, the testing team will arrange the meeting where they will talk about if their features are affecting because of the above modification. Therefore, they will do one round of Impact Analysis and generate the Impact List. In this particular list, the test engineer tries to enclose the maximum probable impact areas, which also decreases the chance of getting the defects.

When a new build comes, the testing team will follow the below procedure:

They will do smoke testing to check the basic functionality of an application.
Then they will test new features.
After that, they will check the changed features.
Once they are done with checking the changed features, the test engineer will re-test the bugs.
And then they will check the impact area by performing the regional regression testing.

Disadvantage of using Unit and Regional Regression testing

Following are some of the drawbacks of using unit and Regional regression testing:

We may miss some impact area.
It is possible that we may identify the wrong impact area.

Note: We can say that the major work we do on the regional regression testing will lead us to get more number of defects. But, if we will perform the same dedication to work on the full regressing testing, we will get less number of defects. Therefore, we can determine here that enhancement in the testing effort will not help us to get more defects.

Full Regression testing [FRT]

During the second and the third release of the product, the client asks for adding 3-4 new features, and also some defects need to be fixed from the previous release. Then the testing team will do the Impact Analysis and identify that the above modification will lead us to test the entire product.

Therefore, we can say that testing the modified features and all the remaining (old) features is called the Full Regression testing.

When we perform Full Regression testing?

We will perform the FRT when we have the following conditions:

When the modification is happening in the source file of the product. For example, JVM is the root file of the JAVA application, and if any change is going to happen in JVM, then the entire JAVA program will be tested.
When we have to perform n-number of changes.

Note:

The regional regression testing is the ideal approach of regression testing, but the issue is, we may miss lots of defects while performing the Regional Regression testing.

And here we are going to solve this issue with the help of the following approach:

When the application is given for the testing, the test engineer will test the first 10-14 cycle, and will do the RRT.
Then for the 15th cycle, we do FRT. And again, for the next 10-15 cycle, we do Regional regression testing, and for the 31th cycle, we do the full regression testing, and we will continue like this.
But for the last ten cycle of the release, we will perform only complete regression testing.

Therefore, if we follow the above approach, we can get more defects.

The drawback of doing regression testing manually repeatedly:

Productivity will decrease.
It is a difficult job to do.
There is no consistency in test execution.
And the test execution time is also increased.

Hence, we will go for the automation to get over with these issues; when we have n-number of the regression test cycle, we will go for the automation regression testing process.

Automated Regression testing process

Generally we go for the automation whenever there are multiple releases or multiple regression cycle or there is the repetitive task.

The automation regression testing process can be done in the following steps:

Note1:

The process of testing the application by using some tools is known as automation testing.

Suppose if we take one sample example of a Login module, then how we can perform the regression testing.

Here, the Login can be done in two ways, which are as follows:

Manually: In this, we will perform regression only one and twice.

Automation: In this, we will do the automation multiple times as we have to write the test scripts and do the execution.

Note2: In real-time, if we have faced some issues such as:

Issues	Handle by
New features	Manual test engineer
Regressing testing features	Automation test engineer
Remaining ( 110 feature + Release#1)	Manual test engineer

Step1

When the new release starts, we don’t go for the automation because there is no concept of regression testing and regression test case as we understood this in the above process.

Step2

When the new release and the enhancement starts, we have two teams, i.e., manual team and the automation team.

Step3

The manual team will go through the requirements and also identify the impact area and hand over the requirement test suite to the automation team.

Step4

Now, the manual team starts working on the new features, and the automation team will start developing the test script and also start automating the test case, which means that the regression test cases will be converted into the test script.

Step5

Before they (automation team) start automating the test case, they will also analyze which all cases can be automated or not.

Step6

Based on the analysis, they will start the automation i.e., converting every regression test cases into the test script.

Step7

During this process, they will take help of the Regression cases because they don’t have product knowledge as well as the tool and the application.

Step8

Once the test script is ready, they will start the execution of these scripts on the new application [old feature]. Since, the test script is written with the help of the regression feature or the old feature.

Step9

Once the execution is completed, we get a different status like Pass/fail.

Step10

If the status is failed, which means it needs to be re-confirmed manually, and if the Bug exists, then it will report to the concerned developer. When the developer fixes that bug, the Bug needs to be re-tested along with the Impact area by the manual test engineer, and also the script needs to be re-executed by the automation test engineer.

Step11

This process goes on until all the new features, and the regression feature will be passed.

Benefits of doing regression testing by the automation testing:

Accuracy always exists because the task is done by the tools and tools never get bored or tired.
The test script can be re-used across multiple releases.
Batch execution is possible using the automation i.e.; all the written test scripts can be executed parallel or simultaneously.
Even though the number of regression test case increase release per release, and we don’t have to increase the automation resource since some regression case are already automated from the previous release.
It is a time-saving process because the execution is always faster than the manual method.

How to select test cases for regression testing?

It was found from industry inspection. The several defects reported by the customer were due to last-minute bug fixes. These creating side effects and hence selecting the Test Case for regression testing is an art, not an easy task.

Regression test can be done by:

A test case which has frequent defects
Functionalities which are more visible to users.
Test cases verify the core features of the product.
All integration test cases
All complex test cases
Boundary value test cases
A sample of successful test cases
Failure of test cases

Regression testing tools

If Software undergoes frequent changes, regression testing costs also increase. In those cases, manual execution of test cases increases test execution time as well as costs. In that case, automation testing is the best choice. The duration of automation depends on the number of test cases that remain reusable for successive regression cycles.

Following are the essential tools used for regression testing:

Selenium

Selenium is an open-source tool. This tool used for automated testing of a web application. For browser-based regression testing, selenium used. Selenium used for UI level regression test for web-based application.

Ranorex Studio

All in one regression test automation for desktop, web, and mobile apps with built-in Selenium Web Driver. Ranorex Studio includes full IDE plus tools for codeless automation.

Quick Test Professional (QTP)

QTP is an automated testing tool used for Regression and Functional Testing. It is a Data-Driven, keyword-based tool. It used VBScript language for automation. If we open the QTP tool, we see the three buttons which are Record, Play and Stop. These buttons help to record every click and action performed on the computer system. It records the actions and play it back.

Rational Functional Tester (RTF)

Rational functional tester is a Java tool used to automate the test cases of software applications. RTF used for automating regression test cases, and it also integrates with the rational functional tester.

For more information about regression and automation testing tools refer to the below link:

What are the Regression Testing and Configuration Management?

Configuration Management in the regression testing becomes imperative in Agile Environments, where a code is continuously modified. To ensure a valid regression test, we must follow the steps:

Changes are not allowed in the code during the regression testing phase.
A regression test case must be unaffected developer changes.
The database used for regression testing must be isolated; changes are not allowed in the database.

What are the differences between Retesting and Regression Testing?

Re-testing Testing means testing the functionality or bug again to ensure the code fixed. If not set, defects need not be re-opened. If fixed, the defect closed.

Re-testing is a type of testing which performed to check the test-cases that were unsuccessful in the final execution are successfully pass after the defects repaired.

Regression Testing means testing the software application when it undergoes a code change to ensure that new code has not affected other parts of the Software.

Regression testing is a type of testing executed to check whether a code has not changed the existing functionality of the application.

Differences between the Re-testing and Regression Testing are as follows:

Re-testing	Regression Testing
Re-testing is performed to ensure that the test cases that are failed in the final execution are passing after the defects fixed.	Regression Testing is done to confirm whether the code change has not affected the existing features.
Re-Testing works on defect fixes.	The purpose of regression testing is to ensure that the code changes adversely not affect the existing functionality.
Defect verification is the part of the Retesting.	Regression testing does not include defect verification
The priority of Retesting is higher than Regression Testing, so it is done before the Regression Testing.	Based on the project type and availability of resources, regression testing can be parallel to Retesting.
Re-Test is a planned Testing.	Regression testing is a generic Testing.
We cannot automate the test-cases for Retesting.	We can do automation for regression testing; manual testing could be expensive and time-consuming.
Re-testing is for failed test-cases.	Regression testing is for passed Test-cases.
Re-testing make sure that the original fault is corrected.	Regression testing checks for unexpected side effect.
Retesting executes defects with the same data and the same environment with different input with a new build.	Regression testing is when there is a modification or changes become mandatory in an existing project.
Re-testing cannot do before start testing.	Regression testing can obtain test cases from the functional specification, user tutorials and manuals, and defects reports in regards to the corrected problem.

What are the advantages of Regression Testing?

Advantages of Regression Testing are:

Regression Testing increases the product’s quality.
It ensures that any bug fix or changes do not impact the existing functionality of the product.
Automation tools can be used for regression testing.
It makes sure the issues fixed do not occur again.

What are the disadvantages of Regression Testing?

There are several advantages of Regression Testing though there are disadvantages as well.

Regression Testing should be done for small changes in the code because even a slight change in the code can create issues in the existing functionality.
If in case automation is not used in the project for testing, it will time consuming and tedious task to execute the test again and again.

Conclusion

Regression Testing is one of the essential aspects as it helps to deliver a quality product which saves organizations time and money. It helps to provide a quality product by making sure that any change in the code does not affect the existing functionality.

For automating the regression test cases, there are several automation tools available. A tool should have the ability to update the test suite as the regression test suit needs to be updated frequently.

Uncategorized

How to Handle alerts in Selenium?

April 29, 2022
by yourtestingbuddy@gmail.com

We can handle alerts in Selenium webdriver by using the Alert interface. An alert can be of three types – a prompt which allows the user to input text, a normal alert and a confirmation alert.

By default, the webdriver can only access the main page, once an alert comes up, the method switchTo().alert() is used to shift the focus webdriver control to the alert.

A normal alert is shown below −

A confirmation alert is shown below −

A prompt alert is shown below −

To accept an alert (to click on the OK button in alert), the method switchTo().alert().accept() is used. To dismiss an alert (to click on the Cancel button in alert), the method switchTo().alert().dismiss() is used.

To extract the alert text, the method switchTo().alert().getText() is used. To input text inside a confirmation alert, the method switchTo().alert().sendKeys() is used.

The text to be entered is passed as a parameter to the sendKeys method.

package RK1.Building_a_selenium_project;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import java.util.concurrent.TimeUnit;
import org.openqa.selenium.Alert;
public class AlertHandle{
   public static void main(String[] args) {
      System.setProperty("webdriver.chrome.driver",
         "F:\\Work Environment\\MyProject\\chromedriver.exe");
      WebDriver driver = new ChromeDriver();
      //implicit wait
      driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
      //URL launch
      driver.get("https://the-internet.herokuapp.com/javascript_alerts");
      // identify element
      WebElement c=driver.findElement(By.xpath("//button[text()='Click for JS Prompt']"));
      c.click();
      //shift to alert
      Alert a = driver.switchTo().alert();
      //get alert text
      String s = a.getText();
      System.out.println("Alert text is: " + s);
      //input text to alert
      a.sendKeys("Selenium");
      //dismiss alert
      a.dismiss();
      c.click();
      //accept alert
      a.accept();
      driver.quit();
   }
}

Automation Testing

Screenshot of a particular element with Python Selenium and…

April 29, 2022
by yourtestingbuddy@gmail.com

import openpyxl
from selenium import webdriver
#configure workbook path
b = openpyxl.load_workbook("F:\\Data1.xlsx")
#get active sheet
sht = b.active
#get cell address of email within active sheet
e = sht.cell (row = 2, column = 1)
#get cell address of password within active sheet
p = sht.cell (row = 2, column = 2)
#get values
email = e.value
passw = p.value
#set chromodriver.exe path
driver = webdriver.Chrome(executable_path="F:\\Work Environment\\MyProject\\chromedriver.exe")
driver.implicitly_wait(0.5)
#launch URL
driver.get("https://www.facebook.com/")
#identify element
l = driver.find_element_by_id("email")
#enter email obtained from excel
l.send_keys(email)
l.screenshot("screenshot_text.png")
m = driver.find_element_by_id("pass")
#enter password obtained from excel
m.send_keys(passw)
m.screenshot("screenshot_text2.png")
#get values entered
s = l.get_attribute("value")
t = m.get_attribute("value")
print("Email is: ")
print(s)
print("Password is: ")
print(t)
#browser quit
driver.quit()

Automation Testing

How to automate gmail login process using selenium webdriver…

January 19, 2022
by yourtestingbuddy@gmail.com

We can automate the Gmail login process using Selenium webdriver in Java. To perform this task, first we have to launch the Gmail login page and locate the email, password and other elements with the findElement method and then perform actions on them.

Let us have the look at the Gmail login page −

Code Implementation

package RK1.Building_a_selenium_project;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import java.util.concurrent.TimeUnit;
import org.openqa.selenium.By;

public class GmailLogin {

	public static void main(String[] args) {
		System.setProperty("webdriver.chrome.driver", "F:\\Work Environment\\MyProject\\QA_Round\\chromedriver.exe");
	      WebDriver driver = new ChromeDriver();
	      //implicit wait
	      driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
	      //URL launch
	      driver.get("https://accounts.google.com/signin");
	      //identify email
	      WebElement l = driver
	      .findElement(By.name("identifier"));
	      l.sendKeys("abc@gmail.com");
	      WebElement b = driver
	      .findElement(By.className("VfPpkd-LgbsSe"));
	      b.click();
	      //identify password
	      WebElement p = driver
	      .findElement(By.name("password"));
	      p.sendKeys("123456");
	      b.click();
	      //close browser
	      driver.close();
	   }
	}

Automation Testing

How to automate instagram login page using java in…

January 19, 2022
by yourtestingbuddy@gmail.com

We can automate Instagram login page with Selenium webdriver in Java. To achieve this, first we have to launch the Instagram login page and identify the elements like email, password and login with the findElement method and interact with them.

Let us have the look at the Instagram login page −

Code Implementation

package RK1.Building_a_selenium_project;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import java.util.concurrent.TimeUnit;
import org.openqa.selenium.By;

public class InstaLogin {

	public static void main(String[] args) {
		System.setProperty("webdriver.chrome.driver", "F:\\Work Environment\\MyProject\\QA_Round\\chromedriver.exe");
	      WebDriver driver = new ChromeDriver();
	      //implicit wait
	      driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);
	      //URL launch
	      driver.get("https://www.instagram.com/");
	      //identify username
	      WebElement l = driver
	      . findElement(By.name("username"));
	      l.sendKeys("test@gmail.com");
	      //identify password
	      WebElement p = driver
	      .findElement(By.name("password"));
	      p.sendKeys("test123");
	      WebElement b = driver
	      .findElement(By.className("Igw0E"));
	      b.click();
	      //obtain value entered for username
	      String s = l.getAttribute("value");
	      System.out.println("Value entered for username: " + s);
	      //quit browser
	      driver.quit();
	   }
	}

Output:

Starting ChromeDriver 97.0.4692.71 (adefa7837d02a07a604c1e6eff0b3a09422ab88d-refs/branch-heads/4692@{#1247}) on port 13129
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
Jan 19, 2022 11:39:02 PM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: W3C
Value entered for username: test@gmail.com