Real Time Scenarios in Software Testing

Software Testing Real Time Scenarios, Manual Testing Job Responsibilities, Automated Testing Job Responsibilities, and Selenium Job Roles.

Real-Time Scenarios in Software Testing (Manual and Automated Testing)

1. Automated Test Case Scope is High than Manual Test Case.

2. Test Data is not mandatory for every Test Case.

3. Prepare Expected Test Result.

4. Conduct Positive and Negative Testing

5. Negative Testing is bigger than Positive Testing

6. Writing Exception Handling Code

7. Dynamic Test Data

8. Software Retirement

9. Update Test Case Template

10. Writing Automated Tests

11. Email Field Verification

12. Software ‘Test Execution is a mandatory task in both Formal Testing and Informal Testing.

13. In a Formal Testing Process, Test Lead defines the Test Environment setup, the Technical Support Team implements Test Environment, and Testers (Team members) verify the Test Environment.

14. No negative Test scenarios for some functionalities.

15. Trying to automate ‘Captcha’ Fields is not good, Manual Testing is best to test ‘Captcha'(verification code) fields.


1. Automated Test Case Scope is High than Manual Test Case

Generally, in a Manual Test Case, we insert/use one or two verification points only, because a human user can’t concentrate on multiple verification points at a time during Test Execution.

In an Automated Test Case/Test Script we can insert multiple verification points, Test Tool can concentrate on multiple verification points at a time during Test Execution because Test Tool is Software, It can concentrate on multiple tasks at a time.

So Automated Test Cases / Test Scripts scope is high than Manual Test Cases, Suppose if you want to automate 100 Manual Test Cases, 100 Automated Tests are not required using a few Automated Tests you can automate those Manual Test Cases.

2. Test Data is not mandatory for every Test Case

Input or Test Data is required for some Test Cases only, not required for all Test Cases, for ex: if you want to execute Login Test case, for that Login credentials (Username, Password) are required, Suppose you want verify particular element exists in a web page, for that no input is required.

3. Prepare Expected Test Result

Generally, we prepared Expected Result for Test cases using our Requirements, but if an expected result is related to Application design then we need to collect that expected result from Developers

Example:
i) After successful login to our application then we get some confirmation message
ii) After performing an operation then we can get some web page

Note: We have to collect those Confirmation messages, web page URLs from Developers.

4. Conduct Positive and Negative Testing

Completeness of Software Testing is Positive Testing and Negative Testing, we use valid input to conduct Positive Testing and invalid input for Negative Testing, suppose if there is no Test Data/Input for our Test Case then how to conduct Negative Testing? by using incorrect Expected Result we can conduct Negative Testing for those Test Cases.

5. Negative Testing is bigger than Positive Testing

We already disused that Completeness of Software Testing is Positive and Negative Testing, Suppose for valid input and operations our application is working fine, but what about handling the invalid input and invalid operations. It has to accept valid input and operations and prevent invalid and input and operations.

Generally Only one positive scenario for every functionality but multiple negative scenarios….
Example: Login Functionality
Valid Username and Valid password -Positive Scenario

Valid Username and Invalid Password -Negative Scenario-1
Invalid Username and Valid Password -Negative Scenario-2
Valid Username and Password Blank -Negative Scenario-3
Username Blank and Valid Password -Negative Scenario-4
Invalid Username and Invalid Password -Negative Scenario-5
Username Blank and Password Blank -Negative Scenario-6
Etc…

So Negative Testing is bigger than Positive Testing, We use Data Driven Testing for covering both Positive and Negative Testing, but we conduct Data Driven Testing for some important functionalities only, not for all.

6. Writing Exception Handling Code

We write Exception handling code in Automated Tests/Test Scripts in order to handle Run-time errors, generally pass or fail is the result status for a test case or test script but sometimes Automated Test shows Run-time errors, for error handling code is required.

How we know that Exceptions? by conducting dry runs (Sample Test Runs) we can locate Run-Time Errors.

7. Dynamic Test Data

Generally, we prepare Input / Test Data for Executing Test Cases,
Example:
Customer Registration Functionality,
Customer Name, Address, Email, Phone, etc…details

Login Functionality:
Username, Password

But for some fields we can’t prepare the Test data before the Test Execution, during Test execution-only we can prepare Test Data for some fields (Ex: Captcha (verification code).

Note: Nowadays we can find captcha fields in most of the account creating functionalities

8. Software Retirement

We Software Testers not always conduct Software Testing on new Applications, some times we conduct Testing on maintenance Applications, actually in the IT Industry 40% of Software Applications only new applications remaining are maintenance applications.

In Software Maintenance, we have two important categories,
i) Software Modifications
(Modifying existing Software with a new interface and some new features)

ii) Software Retirement
(Removing the old System and developing a new system for the same purpose /business operations, Ex: Desktop Application to Web Application, etc…)

Note: In the future we most of the time conduct Testing on Maintenance Applications

9. Update Test Case Template

Test Case Template may vary from one company to another, sometimes one project to another also, suppose short template for general projects and length template for complex projects like Financial etc…

As a Senior Test Engineer, you need to involve in this Updating Test case template depends on scope of the project. If we follow the Manual Testing process then we can update our company prescribed format(excel sheet) or if we are using any Test Tool for Test management then we can customize the Tool Test case template according to our project.

10. Writing Automated Tests

We need to follow Coding standards and guidelines to write Automated Tests/Test Scripts, In Computer Programming more than one way to achieve any task, select simple ways to write programs, and must follow the readability of the program even though the code size is increased.

Example:

(a>b) -It is a positive condition and easy to understand, but instead of this condition you can also write (b<a) or (! a<b) like conditions, but they are not simple to understand, so for identifying & writing verification points in Selenium or UFT try to follow guidelines.

11. Email Field Verification

We have Email field verification in most of the Registration forms, some applications check email format only, but some applications send conformation mail to our email and get our confirmation

12. Software ‘Test Execution is a mandatory task in both Formal Testing and Informal Testing.
13. In a Formal Testing Process, Test Lead defines the Test Environment setup, the Technical Support Team implements Test Environment, and Testers (Team members) verify the Test Environment.
14. No negative Test scenarios for some functionalities.
15. Trying to automate ‘Captcha’ Fields is not good, Manual Testing is best to test ‘Captcha'(verification code) fields.

 

Selenium Online Training

Selenium Tutorial for Beginners

SQL Step by Step Tutorial

Manual Testing Tutorial

Follow me on social media: