July 23, 2024

Manual Testing Vs Automation Testing

Manual Testing	Automation Testing
Testing the functionality or Behavior of the application manually according to the customer’s requirements is called Manual Testing.	Testing the functionality or Behavior of the application with the help of tools like Selenium, with a scripting language like According to the customer’s requirement, Java, python, JavaScript, Ruby, etc. is called Automation Testing.
Time Taken is more	Time Taken less to complete the task
Human-driven	Tool-Driven
Highly effective	May not be effective for every Testing Type
Maintenance is less in Manual Testing	Maintenance is more in Automation Testing
Easier to adapt changes if requested is changing	Not easy to adapt changes since scripts must be changed
Highly effective testing for UI Testing	Not so highly effective for UI Testing since it cannot check the look and feel of the application, color, etc

Black Box Testing Vs White Box Testing

Black box Testing	White Box Testing
Testing the application without looking at the code	Testing each line of the code is called white box testing
Testers or end user/customer do this	Developers do this
To do this testing testers follow some techniques like Equivalence class partitioning, Boundary value analysis, etc	To do this testing, developers use techniques like Path Testing, Code Coverage, etc.
The name of this testing is black because code will not be visible	The name of this testing is white because the code will be visible

Retesting Vs Regression Testing

Retesting	Regression Testing
Retesting is done to make sure the ﬁxed bug is working ﬁne as per the customer requirement.	We do this to make changes like adding a feature, deleting a feature, ﬁxing a bug or any code modiﬁcation is not impacting the unchanged features of the application
Can be done by both developers as well as Testers	Will be done only by the testers
It takess very less time	Takes more time
Retesting should be done manually	Regression should be done by Automation Testing
The scope of Retesting is less	The scope of regression Testing is more usually full application

Test Scenario Vs Test Cases

Test Scenario	Test Cases
High-level documentation	Detailed Documentation
By looking into this it will be hard to test the application until and unless you have a good project knowledge	By looking into test cases, you can easily test any application , no matter whether you have good project knowledge or not
It tells what to test	It tells how to test
Test Scenario doesn’t have data that you need to enter into an application to test	Test Cases has all the exact data that you need to enter
A Test Scenario is just a short sentence that says what to test	Test cases have steps to reproduce, a precondition
Test Scenarios are derived from Requirement	Test Cases is derived from Test Scenarios
Need less time to prepare	Need more time to prepare
With the help of test scenarios, we validate the functionality of an application	Here we can check or validate if test scenarios are correct or not.
Required fewer resources to write and execute compared with Test Cases	Required more resources to write and execute

B2B	B2C
Stand for Business to Business.	Stands for Business to Customer.
Traﬃc will be less on these apps.	Traﬃc will be more on these apps.
Longer Release cycle	Shorter release cycle

Service Based Company	Product based Company
They give services to others	They develop their product
Examples are Accenture, Deloitte Consulting, IBM Global Services, Salesforce, Tech Mahindra, Wipro, Infosys etc	Examples are Google, Flipkart,Apple, Tesla,Samsung, swiggy, ola,uber, etc

Positive Testing	Negative Testing
It will be performed as per the requirements.	It will not be performed as per the requirements.
It will be done first	It will be done later
It doesn’t cover all possible test cases	It can help us to cover more possible test cases.
It takes less time	It takes more time.
It can be done by anyone in the testing team.	It will be done by professionals or experienced testers.

Static Testing	Dynamic Testing
Performed at the early stage of development.	Performed at the later stage of the development.
In this testing we don’t execute the software.	In this testing, we execute the software.
The cost of fixing the issue is less	The cost of fixing the issue is more
We do this to avoid bugs that may arise later	We do this to find bugs
We do this before the build is ready.	We do this after the build is ready.
Can be done by both Dev and Tester.	The dev and tester can do it, but it is the tester’s responsibility.
Examples:Code review, Walkthrough, Test Plan, Test Cases	Examples: Component Testing, Integration Testing, System Testing etc.

Verification	Validation
Verifying CRS, SRS, HLD & LLD and to check whether it is according to the requirement or not is called Verification	Testing the functionality of an application by executing test cases is called Validation
The following activities are involved in Verification: Reviews, Meetings, and Inspections.	The following activities are involved in Validation: Testing like Black box testing and all functional and non-functional testing.
Execution of code does not come under Verification.	Execution of code comes under Validation.
Verification is carried out before the Validation.	Validation activity is carried out just after the Verification.
The following items are evaluated during Verification: Plans, Requirement Specifications, Design Specifications, Code, Test Cases, etc.,	The following item is evaluated during Validation: Actual product or Software under test.
The cost of errors caught in Verification is less than errors found in Validation.	The cost of errors caught in Validation is more than errors found in Verification.
Done by Developer	Done by Tester

Smoke Testing	Sanity Testing
A Smoke test is designed to touch every part of the application casually or at a high level.	A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity Testing is usually narrow and deep.
This testing is conducted to ensure that the most crucial functions of a program are working.	This Testing is done to check the new functionality/bugs have been fixed
This testing is a normal health check-up to the build of an application before taking it to test in-depth.	This level of testing is a subset of regression testing
Smoke test cases can be automated.	Sanity test cases usually not automated.
It is a positive testing.	it is both positive and negative testing
This testing is performed by the developers and testers	This testing is performed by the testers.
Smoke testing is like General Health Check Up	Sanity Testing is like specialized health check up
Smoke testing is performed until your build is not stable	Sanity testing is done once the build is stable
It is often documented	It is not necessarily documented

Alpha Testing	Beta Testing
It is done by internal testers of the organization.	It is done by real users.
It is an internal test, performed within the organization.	It is an external test, carried out in the user’s environment.
Alpha Testing uses both black box and white box testing techniques	Beta Testing only uses the black box testing technique.
Identifies possible errors.	Checks the quality of the product.
It is performed before Beta Testing.	It is the final test before launching the product on the market.
It answers the question: Does the product work?	It answers the question: Do customers like the product?
Functionality and usability are tested.	Usability, functionality, security, and reliability are tested with the same depth.

SDLC	STLC
SDLC stands for Software Development Life Cycle.	STLC stands for Software Testing Life cycle.
It is primarily connected to software development, which means that it is the procedure of developing a software application.	It is mainly linked to software testing, which means that it is a software testing process that contains various phases of the testing process.
While performing the SDLC process, we needed a greater number of developers to complete the development process.	The STLC process needed a smaller number of testers to complete the testing process.
The objective of the Software development life cycle is to complete the development of software successfully.	The objective of the Software testing life cycle is to complete the testing of software successfully.
The SDLC phases are done before the STLC phases.	The STLC phases are completed after SDLC phases.