Manual Testing Overview
Definition: Manual testing is a process of manually executing testcases without using automation tools to ensure software behaves as expected.
Key Concepts:
Test Plan: Document outlining the scope, approach, resources, and schedule of testing activities.
Test Case: A set of conditions or variables used to determine if a system meets requirements.
Bug/Defect: Any flaw or imperfection in the software.
Types of Testing:
Unit Testing: Testing individual components for proper operation.
Integration Testing: Ensuring combined components function together.
System Testing: Validating the entire system's compliance with requirements.
Acceptance Testing: Verifying if the system meets business requirements.
Steps in Manual Testing:
Requirement Analysis: Understanding the requirements and identifying testable elements.
Test Planning: Defining objectives, strategies, and schedules.
TestCase Development: Designing detailed testcases.
Environment Setup: Preparing the test environment.
Test Execution: Running testcases and logging defects.
Test Closure: Analyzing test completion criteria and ensuring all tests are executed.
Pros and Cons:
Pros:
Detects usability and user interface issues.
Flexible for short-term projects.
No initial investment in automation tools.
Cons:
Time-consuming and labor-intensive.
Less reliable and prone to human error.
Not suitable for repetitive tasks.
What is Software Testing?
- Software Testing is a part of Software development process.it is an activity to detect and identify the defects in the software. The object is to release quality product to the client.
Software Quality:
- Quality: It is defined as justification of all the requirements of a customer in a product.
Note: Quality is not defined in the product, it is defined in the customer’s mind.
- Quality software is reasonably
- Bug-free
-Delivered on time
-Within budget.
-Meets requirements and/or expectations.
-Maintainable.
Why do we need testing?
· Ensure that software is bug free.
· Ensure that system meets customer requirements and software specifications.
· Ensure that system meets end user expectations.
· Fixing the bugs identified after release is more expensive.
Why the Software has bugs normally?
· Miscommunication or No communication.
· Software complexity.
· Programming errors.
· Changing requirements.
· Lack of skilled Testers.
Note: The goal of a software tester is to find bugs, find them as early as possible, and make
Sure, they get fixed
Software Testing:
It is process to test an application to find out error in it. Checking the software is OK. The goal of software tester to find bug. Verifying and Validating that a software or Application is bug free.
What to test in now a day’s Application?
1. Functional Testing
2. UI(User Interface) Testing
3. Usability Testing
4. Compatibility Testing
5. Security Testing
6. Load Testing
7. Performance Testing
Manual Testing:
If we check either functional or Non-functional by the operating the application manually it’s called manual Testing. It is recommended for Small project which need to be one time software, school management software, small mobile gaming application.
Automation Testing:
Making Testing process automated using the tools Selenium, QTP, load runner etc.., are called Automation Testing. Automation Testing is recommended long term support project’s like Banking, E-commerce etc.,
v Error: Any Incorrect human action that produces a problem in the system is called an error.
v Defect/Bug: Deviation from the expected behavior to the actual behavior of the system is called is defect.
v Failure: The Deviation identified by end-user while using the system is called a failure.
Why a Software Application will have defects?
The following of the major reason for having defects in any software applications.
- Wrong Requirements
- Wrong Design
- Wrong coding.
Cost of fixing the defects?
To resolve a defect which is acquired to wrong coding takes less time and cost where are to resolve a defect which is acquired to wrong requirements will increase the time and cost.
To minimize the cost of fixing defect’s Testing should be carried out live from the beginning.
Verification:It is a process of checking are we developing right product or not.
Validation: It is a process of checking the developed product is right or not.
+ve Testing:
It is Test functionality it a positive perception to confirm whether the functionality is working. As per the requirements or not. Then it is called +ve Testing.
-ve Testing:
It is a Test functionality in a Negative perception to find defect benefit called -ve Testing.
Quality Assurance (QA): Quality Control (QC):
- It is a process step by the organization. - It is a quality check after developing product.
- It is a preventive activity. - It is a corrective activity.
Testing belongs to Quality Control. It is a part of Quality Assurance.
Role of a Tester?
1. Understanding project/client Requirements.
2. Preparing TestScenarios
3. Preparing TestCases
4. Executing TestCases
5. Finding defects & Report Developer
6. Conduct Re-testing
7. Conduct Regression Testing
8. Developing Automation Scripts
9. Executing Automation Scripts.
Software Development Life Cycle (SDLC)
SDLC will explain various stages involve in developing a project
SDLC Models:
A SDLC models will explain how various implementation activity carried out in developing a project. The most popular SDLC models are
1. Waterfall model
2. V-model
3. Agile model
Waterfall Model:
Waterfall model is prefer for developing a small projects where the requirements are very clear. As requirements are clear chances of making a mistake during developments would be less. Testing is carried out after the development is only validation.
V Model:
V-Model is prefer for developing small project’s where the requirements are not clear. Like medical treatment system, Aeroplane navigation system, as requirements are not clear chances of making mistake during development would be high. So to find the mistakes are early stages testing is carried out live life from the requirements both are verification & validation.
Verification/Static Testing:
It is a process of checking are we developing the right project or not It's called Verification.This verification is carried out by conducting following reviews:
1. Requirement Reviews by Business Analyst
2. Design Reviews by System Architect
3. Code Reviews by Developer
4. Testcase Reviews by Tester
Validation/Dynamic Testing:
Checking whether the developed code and developed application are working as expected or not it’s called Validation. This carried out at four levels:
1. Unit Testing
2. Integration Testing
3. System Testing
4. UAT(User Acceptance Testing).
White Box Testing:
Testing carried out on the Source code by developers to confirm the developed code is producing the right output is called White Box Testing.
White Box Testing = Unit Testing + Integration Testing
Black Box Testing:
Testing conducted on the developed application by the tester also by end user to confirm the developed product is working as expected or not it is called Black Box Testing
Black Box Testing = System Testing + UAT
System Testing:
Validating Functional requirements and Nonfunctional requirements in an End user point of you is called System Testing.
Functional Testing Types
Smoke Testing/ Sanity Testing:
It is a kind of a small rug test or quick test carried out on the given application to decided verify to ready for testing or not. It is called Smoke Testing/Sanity Testing.
A quick test carried out on the beginning version ver1, ver2, ver3., unstable version to decide whether they are stable condition or not it’s called Smoke Testing.
Whether as the same quick test carried out on the later version Build21, Build22, Build23., stable version. It is called Sanity Testing.
The objective of Smoke Testing to make a decision whether the given application is testable or not identify the defect.
Formal Testing:
If a test a software application by following proper testing procedure and proper documentation then it’s called formal testing.
Ad hoc Testing:
If a test a Software application without following proper testing procedures, then it’s called Ad hoc Testing.
Re-Testing:
Testing a functionality in a modified build to confirm report a defect is properly resolve or not. It’s called Re-Testing.
Regression Testing:
It is a process of identifying various functionalities in the modified build where there is chance of side effects getting due to some code change’s then re-testing. these connected is called Regression Testing.
What is the Difference between Re-Testing, Regression Testing?
Re-Testing is carried out on the modification is to confirm report a defect’s or properly resolve or not where as regression testing carried out on the modification built to identify the side effect’s which made acquired due to These bug’s fixes or any other code changer
1)Regression testing also a part of Re-testing.
2)Instead of during these Re-Testing and Regression testing manually and every modified build it’s recommended to go for automation of Re-Testing or Regression Testing.
System Integration Testing:
Checking the Communication and the data integration between two or more application involved in the business is called System Integration Testing.
1) Check the new employ registered in payroll software is getting recognize by the bio-metric system or not
2)Check the attendance recorded in the bio-metric system is automatically updated into payroll software database or not.
End to End Testing:
Testing the overall features of the product in a précised manner to make a decision whether to stop testing or not it’s called end to end testing
These end-to-end testing is carried out and the final build by the team lead.
Exploratory Testing:
Exploratory the application understanding the application then testing the application is called Exploratory testing.
These exploratory testing comes in the following two scenarios.
1) If requirement documents not available.
2) If requirement documents not providing sufficient inputs.
Monkey Testing:
Wantedly performing a random operation or jig-jag operation like a monkey with intention of finding a bug called a Monkey Testing.
Non-Functional Testing
UI Testing:(User Interface)
Checking the developed User Interfaces are looking good or not it’s called UI testing.
Check list for UI testing:
1) Check company logo /company title are properly visible or not.
2) Check company brand colors are used in website pages or not.
3) Check consistency in font size, font type, font Style.
4) Check all required elements present in or not.
5) Check all mandatory fields are highlighted or not.
6) Check Images/Banners/Content is relevant to the appropriate.
Usability Testing:
Checking whether the developed application Easily usable by End user or not called Usability testing.
Compatibility Testing:
Checking whether the application is properly visible and properly working in different devices, browsers, and operating systems present in the market or not. It’s called compatibility Testing.
Security Testing:
Verifying all the required Security conditions are properly implemented or not. It’s called Security Testing.
Load Testing:
Checking whether the application can handling multiple users at a given point or not. It’s called Load Testing. Is the load is limited we do load test manually is the load is huge we automate load testing use in the tools. Like load runner, JMeter etc.,
Performance Testing:
Checking page load time and transaction response time under various load condition. It’s called performance testing.
Recovery Testing:
Checking data backup and data recovery features are available and whether they are working to recover the lost data or not. It’s called recovery testing.
Globalization Testing:
Checking whether the application is available in different International languages and Currency or not. It’s called Globalization Testing. Its required only for the application design for multiple localities of users like amazon, Flipkart etc.
Localization Testing:
Checking whether the application is available in Local languages and using Local Currency or not. It’s called Localization Testing.
User Acceptance Testing (UAT):
Testing conducted on the delivered application by the domain experts are end users to gain the confidence whether this application ready to use or not. It’s called UAT. These UAT carried out at two stages.
1. Alpha Testing
2. Beta Testing
Alpha(α) Testing:
It’s a first level of acceptance testing carried out a development company environment by the domain experts preferable by the Alpha Testing
Beta(β) Testing:
It’s a last level of acceptance testing carried out by End users before giving live
STLC (Software Testing Life Cycle):
STLC will explain various activities involved testing a project. They are
Test Planning:
It is the first phase of software testing where Scrum Master (Project manager) will plan what need to be tested in the current schedule and test approach then assign the work to the team members.
Test Analysis:
In this phase Tester analyze project requirement to understand customer expectation domain the team members (KT’s)-Knowledge Transfer.
Test Design:
In these phase QA team prepare
1. Test Scenarios
2. TestCases and TestData
3. Requirement Traceability Matrix (RTM)
Test Scenarios:
A feature to be tested or what needs to be tested in our Application Under Test (AUT) is called Test Scenarios.
Note: To ensure 100% requirement coverage and for the feature reference test scenarios are useful.
Few Test Reference Test Scenarios for Calculated.
TS1: Check Addition
TS2: Check Subtraction
TS3: Check Multiplication
TS4: Check Division
Test Scenario for IRCTC:
1. New Customer registration
2. Check customer able login or not
3. Check booking a train ticket
4. Check cancellation train ticket
Test Scenario Template:
TestCase:A Testcase is a plan and approach that explain how to validate a functionality in the system. In other word a testcase is deep description of what to test and how to test. A test case must explain test procedure, test data, expected behavior to validate to check functionality in the system.
Testcases are recommended to ensure 100% requirement coverage and also feature reference.
Test Case Template:
Software TestCase Design:
To avoid exhausted testing and to ensure 100% requirement coverage the following techniques introduce the software testing
1) ECP (Equivalence Class Partition)
2) BVA (Boundary value Analysis)
ECP (Equivalence Class Partition):
As per ECP techniques is multiple testcases or multiple inputs producing in same output we consider only one input some each group to validate in the feature.
BVA (Boundary Value Analysis):
If you want a check a feature it a range of input then BVA techniques is applicable. As per the BVA technique consider Lower Boundary Value and Upper Boundary Value for positive Testing and Lower Boundary Value -1, Upper Boundary Value +1 for Negative Testing.
LBV: 21
Positive Testing UBV: 60
LBV:20
Negative Testing UBV:61
If there is a range in the partition apply BVA technique. If no range in a partition then go for ECP technique.
Requirement Traceability Matrix:
Mapping Business Requirements to Corresponding Scenarios and Corresponding TestCases in called Requirement Traceability Matrix.
Requirement Name
Test Scenario
TestCases
R1 – Login Management
R2 – Employe Management
R10 *******
TS001
TS002
*****
TC001
TC002
***
Advantages of RTM:
1) To determine percentage of test coverage
2) As we are able to identify a group of TestCases belongs to a specific requirement test execution process becomes easy.
3) As we are able to identify a group of scenario a group of testcases belongs to a specific requirement change request process can be easily implemented.
Test Execution:
In these phase we execute planned Testcases on the given build (Stagging Environment) defects identify during test execution will be documented in a defect report then submitted to developer. Developer fix defects compile modified build released to given it QA Team.
At first QA Team perform retesting on the modified build to confirm report defects properly resolve or not. After retesting QA Team perform regression testing on the modified build to identify the side effects. This process will be continued until all defects are close.
Defect/Bug Report:
In order to record the defect, submit the defects to the developer we use a format called a Defect/bug report.Defect/Bug Report Template:
Reproduceble defect:
If a defect is an Occurring every Time, then it’s called defect severity.
Defect Severity:
Impact of the defect or how serious the defect is called Defect Severity.
Different Defect Severities:
Tester decides to defect severities.
Very High
High
Medium
Low
Different Defect Priorities:
The ordering which Defects to be resolve is called Defect Priorities.
Very High / P0
High / P1
Medium / P2
Low / P3
Developer assigned by the defect priorities.
Defect Severities, Defect Priorities:
Ø Mostly defect Severities and defect Priorities are directly proportion to each other. But in some situation change. An example for a defect which low severities but high priorities.
Ø In correct company logo, spelling mistake in company title.
Ø An example for a defect which status high severities but low priorities. A major issue belongs to feature release model.
Defect Status:
A defect status indicates current position of the defect in development process
Different Defect Status:
1. New
2. Open {In progress}
3. Fixed {Resolved}
4. Closed
5. Re-open
6. Rejected
7. Postponed
8. Hold
9. Duplicate
Defect Life Cycle or Bug Life Cycle:
Defect life cycle will explain various stages of defect some is identification till is closer.
When a defect identified by the tester, this defect details recorded in a defect report with the status New.
All new defects are reported to developer. Developer verify the received defect is valid or not? If it is valid developer Open the defect. If it is invalid developer Reject the defect. If the defect is not clear to developer, the developer Hold the defect. For any reason if defect is postponed to next phase, defect status updated as postponed. If the defect already reported developer update status as duplicate.
Once this analysis completed by developer they start resolving the open defects. Soon after the defect is resolved developer update status as Fixed. After resolving all defects developer creates a modified build release to QA team for Re-Testing.
QA team perform Re-testing on the modified build to confirm reported defects are properly resolved or not? After Re-Testing QA Team performs Regression Testing on the modified Build. If any New defects or side effects identified in the modified build, they will be recorded with the status New. Then reported to developer. The same cycle will be continued until all defects are closed.
Test Closure:
Test Closure are when to Stop Testing.
We stop testing when the following conditions are:
ü If all prepare testcases are executed Successfully and pause.
ü If all identify defect are resolve and close.
Agile Model:
In An Agile model is a Big project divided into modules, then each module further divided into Smaller components then this Small component will be Implemented In short schedules called Sprints.
A big project divided into modules first.
Advantages of Agile Model:v Agile model guarantee more customer satisfaction by rapid on continues delivery of usable product to the Client.
v Agile model saves time and money because of less documentation.
v Daily meeting with the team members and clients results in better product.
Agile Model Terminology:
Scrum:
A Scrum is the most popular Agile development model where developers and testers work together as a team under the guidelines of Scrum Master.
Scrum Master:
A Senior person the Lead or Manager who manages entire team is called Scrum Master.
Product Owner:
Business Analyst finalizes product requirements it’s called Product Owner.
Product Backlog:
A Product backlog is a list of requirements on features plan to implement in the Product.
A Product Backlog contains an Epics and User Stories.
Epic: A major Business requirement is called an Epic.
User Stories: A feature to be implemented is called User Stories.
Task: A Planned work Item is called Task.
Example for Epic, User stories and Task.
0 Comments