BRIEF ABOUT SOFTWARE TESTING

SOFTWARE TESTING 

INTERVIEW QUESTIONS 

1. WHAT IS SOFTWARE TESTING? 

• It is a process of analyzing s/w item to detect the differences between existing and required conditions and to evaluate the features of the s/w item. 
• It is a verification and validation process. 
• Process of demonstrating that errors are not present. 

2. DIFFERENCE BETWEEN VERIFICATION AND VALIDATION? 

Verification→ 

•  It is a process of confirming whether the s/w meets it’s requirement or not. 
•  Process of examining/reviewing of work product. 
•  Are we building the product right? 
•  It is a QA activity. 
•  It’s a static process performed at compile time. 
•  It is performed by a QA team or by developer. 
•  Cost and time effective. o Activities involve in this is testing the application. 

Validation→ 

• It is a process of confirming whether the s/w meets user’s requirement or not. 
• Process of executing a product & examining how it behaves. 
• Are we building the right product? 
• It is a QC activity. 
• It’s a dynamic process performed at run time. 
• It is performed by a QC team or by tester. 
• Cost and time taking. 
• Activities involve in this are inspections, reviews, walk-through.

3. DIFFERENCE BETWEEN QUALITY CONTROL AND QUALITY ASSURANCE? 

QA→ 

• It ensures the prevention of defects in the process used to make s/w application. 
• It involves in process-oriented activities. 
• Aim to prevent defect. 
• Eg:- verification 
• It is the technique of managing the quality. 
• All team members are responsible for QA. 
• QA is responsible for SDLC. 
• It is a process to create the deliverables. 

 QC→ 

• It executes the program or code to identify the defects in the s/w application. 
• It involves in product-oriented activities. 
• Aim to identify and improve. 
• Eg:- validation 
• It is a method to verify the quality. 
• Testing team is responsible for QC. 
• QC is responsible for STLC. 
• It is a process to verify that deliverables. 

4. WHAT IS SDLC?

Ans. Software Development Life Cycle refers to all the activities that are performed during software development, including - requirement analysis, designing, implementation, testing, deployment and maintenance phases. 

5. EXPLAIN STLC - Software Testing life cycle. 

Software testing life cycle refers to all the activities performed during testing of a software product. The phases include- 

• Requirement analyses and validation - In this phase the requirements documents are analysed and validated and scope of testing is defined. 

• Test planning - In this phase test plan strategy is defined, estimation of test effort is defined along with automation strategy and tool selection is done. 

• Test Design and analysis - In this phase test cases are designed, test data is prepared and automation scripts are implemented. 

• Test environment setup - A test environment closely simulating the real world environment is prepared. 

• Test execution - The test cases are prepared, bugs are reported and retested once resolved. 

• Test closure and reporting - A test closure report is prepared having the final test results summary, learning and test metrics.

6. What are the QA/Testing activities?

• Understanding the requirements and functional specifications of the application.
• Identifying required test scenarios.
• Designing Test cases to validate applications.
• Execute test cases to validate application.
• Log test results ( how many test cases pass/fail)
• Defect reporting and tracking.
• Retest fixed defects of previous build.
• Perform various type of testing assigned by test lead.
• Reports to test lead about the status of assigned tasks.
• Participated in regular team meetings.
• Creating automation scripts for Regression testing.
• Provides recommendations on whether or not the application/system is ready for production.

7. What is Test Script ?

Ans. Test Scripts are a line-by-line description of all the actions that are necessary to perform and test on specific user journeys. It lists out each step that should be taken with the expected results. Then testers can easily as systematically test each step on a wide range of devices.

8. What is Bug Leakage ?

Ans. Bug leakage is something, when the bug is discovered by the end users or customer, and missed by the testing team to detect, while testing the software. OR. A defect which exists in the application and not found by the tester which is eventually found by the customer/end-user.

9. WHAT IS BLOCKER? 

Ans. A blocker is a bug of high priority and high severity. It prevents or blocks testing of some other major portion of the application as well.

10. WHAT IS DEFECT LIFE CYCLE? 

Defect Life Cycle or Bug Life Cycle is the specific set of states that a Bug goes through from discovery to defect fixation. 

Bug Life Cycle phases/status:- The number of states that a defect goes through varies from project to project. Below lifecycle diagram, covers all possible states 

• New: When a new defect is logged and posted for the first time. It is assigned a status as NEW. 
• Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to the developer team. 
• Open: The developer starts analyzing and works on the defect fix.
• Fixed: When a developer makes a necessary code change and verifies the change, he or she can make bug status as "Fixed." 
• Pending retest: after fixing the defect the developer gives a particular code for retesting the code to the tester. Here the testing is pending on the testers end, the status assigned is "pending request." 
• Retest: Tester does the retesting of the code at, to check whether the defect is fixed by the developer or not and changes the status to "Re-test." 
• Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is "verified." 
• Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to "reopened". Once again the bug goes through the life cycle. 
• Closed: If the bug is no longer exists then tester assigns the status "Closed." 
• Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to "duplicate." 
• Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to "rejected." 
• Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status "Deferred" is assigned to such bugs 
• Not a bug: If it does not affect the functionality of the application then the status assign to a bug is "Not a bug". 

• New - A bug or defect when detected is in New state 
• Assigned - The newly detected bug when assigned to the corresponding developer is in Assigned state 
• Open - When the developer works on the bug, the bug lies in Open state 
• Rejected/Not a bug - A bug lies in rejected state in case the developer feels the bug is not genuine 
• Deferred - A deferred bug is one, fix of which is deferred for some time(for the next releases) based on urgency and criticality of the bug 
• Fixed - When a bug is resolved by the developer it is marked as fixed 
• Test - When fixed the bug is assigned to the tester and during this time the bug is marked as in Test 
• Reopened - If the tester is not satisfied with issue resolution the bug is moved to Reopened state 
• Verified - After the Test phase if the tester feels bug is resolved, it is marked as verified 
• Closed - After the bug is verified, it is moved to Closed status.

11. WHAT IS SMOKE AND SANITY TESTING? 

SMOKE→ 

• It is a kind of Software Testing performed after software build to ascertain that the critical functionalities of the program are working fine. 
• The purpose is to reject a badly broken application so that the QA team does not waste time installing and testing the software application. 
• In Smoke Testing, the test cases chose to cover the most important functionality or component of the system. The objective is not to perform exhaustive testing, but to verify that the critical functionalities of the system are working fine. 

SANITY→ 

• Sanity testing is a kind of Software Testing performed after receiving a software build, with minor changes in code, or functionality, to ascertain that the bugs have been fixed and no further issues are introduced due to these changes.

12. WHAT IS EXIT AND ENTRY CRITERIA? 

ENTRY→ It describes when to start testing i.e. what we have to test it should be stable enough to test. Ex:- if we want to test home page, the SRS/BRS/FRS document & the test cases must be ready and it should be stable enough to test. 

EXIT→ It describes when to stop testing i.e. once everything mentioned below is fulfilled then s/w release is known as exit criteria:- 

a. Followed before actually releasing the s/w to client. Checking computer testing is done or not.

b. Documents checking:- test matrix (RTM)/summary reports. 

SUSPENSION CRITERIA→ when to stop testing temporarily. 

13. WHAT IS REGRESSION TESTING? 

To test whether the changed component has introduced any error to unchanged component or not is called as regression testing. It is perform on QA/production site depends. 

14. WHAT IS RETESTING? 

To test whether the reported bug has been resolved by the developer team or not, is known as retesting.

15. MONKEY/AD-HOC TESTING? 

It is an informal testing performed without a planning or documentation and without having knowledge of the applications/software functionalities. Monkey testing is a type of testing that is performed randomly without any predefined test cases or test inputs.

16. SEVERITY AND PRIORITY? 

Priority→ 

• “How prior we need to fix the bug is priority.” 
• It means the occurrences of defect. 
• Decide by developer team. Types(low, medium, high, critical) 

SEVERITY→ 

• “How severe the bug is severity”. 
• It means how bad the defect is and what impact it can cause in our application. 
• Decide by the testing team. Types(minor, medium, major) 

17. What is defect priority? 

Ans. A defect priority is the urgency of the fixing the defect. Normally the defect priority is set on a scale of P0 to P3 with P0 defect having the most urgency to fix. 

18. What is defect severity? 

Ans. Defect severity is the severity of the defect impacting the functionality. Based on the organisation, we can have different levels of defect severity ranging from minor to critical or show stopper. 

19. Give an example of Low priority-Low severity, Low priority-High severity, High priority-Low severity, High priority-High severity defects. 

1. Low priority-Low severity - A spelling mistake in a page not frequently navigated by users. 
2. Low priority-High severity - Application crashing in some very corner case. 
3. High priority-Low severity - Slight change in logo color or spelling mistake in company name. 
4. High priority-High severity - Issue with login functionality.

20. What is Latest version of Android and iOS ?

The latest version of Android OS is 12.

The latest version of iOS 15.6

21. Which is dynamic in nature, Verification or validation?

Validation is dynamic in nature. It's a dynamic process performed at run time.

22. Different types of Payment Gateway?

1. PayPal
2. Amazon Pay
3. Skrill
4. Stripe
5. 2Checkout
6. Payza

23. What are the test cases for Stripe Payment Gateway?

Let us look at the different testing ways that we must take into consideration before launching a payment gateway.

Functional Testing – This form of testing ensures that the gateway is fully functional with all its features working as specified. This helps in verifying that the application page and the gateway, both are behaving in the correct manner.

Performance Testing – This is for ensuring that no matter what number of customers are using the gateway, it should not affect its functioning.

Security – The gateway must go through a secure page and all the data should be encrypted as it contains sensitive information. There should be a deep security check before enabling any gateway.

UI Test Cases for Payment Gateway

1. Check if all the labels and boxes are visible.
2. Verify the payment gateway company logo or name.
3. Check if the credit card number is masked or not.
4. Verify that all the payment options are visible.
5. Check if the color scheme matches the specifications.

Functional Test Cases for Payment Gateway

1. Check if each of the payment options is selectable.
2. Check if the default credit/debit card gets automatically added.
3. Verify that the page does not proceed to the payment page before all the mandatory information is filled.
4. Check if multiple cards can be saved as default or not.
5. Verify that the correct currency is reflected on the page.
6. Check if the payment is not getting processed for null values in the cart.
7. Verify if multiple payment options are not getting selected. Only one at a time.
8. Check if the payment is not getting proceeded with an expired/blocked card.
9. And some other similar combinations
10. Check if the user gets a confirmation message or mail if the payment is successful.
11. Check if a pop-up appears if the session has expired.
12. Verify that the user gets information about unsuccessful payment.
13. Check if double payment is not occurring in any case.
14. Check what happens after the session gets expired. Does the payment still occur?
15. Verify if the respective payment option triggers the right payment gateway.
16. Check if the user is directed back to the application after a successful transaction.
17. Check what happens if the payment gets stopped midway. Does the amount still gets deducted?
18. Check if the pop-up blocker during the payment is functional.
19. Check if the application page is not getting redirected to some other page or link.
20. Verify cases like-

• Credit/debit card number+wrong date+ right cvv
• Credit/debit card number+ right date+ wrong cvv
• Wrong credit/debit card number+ right date+ right cvv

Security Test Cases for Payment Gateway

1. Verify if the credit card information is in a masked form.
2. Check that the payment is happening through a secured channel. i.e the link starts with HTTPS instead of the regular HTTP pages.
3. Verify if the OTP reaches only the verified number linked with the card.
4. Verify if the transaction gets canceled if the wrong OTP is entered.
5. Check if it cannot be entered multiple times. A hacker can do a brute force attack by entering various combinations.
6. Check if the session gets expired within the specified time.
7. Verify that the person gets notified if the wrong OTP is entered.
8. Check that it does not reflect on multiples numbers.
9. Verify the bank name reflecting on the payment page is the same as the user.
10. Check if the amount deducted is the same as the amount mentioned.

Performance Test Cases for Payment Gateway

1. Check if the payment gateway does not crash if multiple users are using it simultaneously.
2. Check if the processor is responding quickly.
3. Verify the time taken to reach the payment gateway from the application’s page is the same as specified.
4. Verify if the page is secured from brute force or SQL injection attacks.
5. Check if once logged in, the back button does not log out the user from the application.
6. Check if the payment is happening even after the session expires.

24. Tell any testing number for payment gateway.

Configure the account to use the test card number 4242 4242 4242 4242, a random three-digit CVC number, and any expiration date in the future.

25. What is Defect,Bug,Failure,Error

1. Bug - A bug refers to defects which means that the software product or the application is not working as per the adhered requirements set
2. Defect - A Defect is a deviation between the actual and expected output
3. Fault - A Fault is a state that causes the software to fail and therefore it does not achieve its necessary function.
4. Error - An Error is a mistake made in the code due to which compilation or execution fails.
5. Failure - Failure is the accumulation of several defects that ultimately lead to Software failure and results in the loss of information in critical modules thereby making the system unresponsive.

26. WHAT IS UNIT TESTING? 

It is also called as module testing /component testing. It is done to check whether the individual unit or module of the source code is working properly. It is done by the developer. 

27. INTEGRATION TESTING? 

It is a process of testing the interface between the two s/w units. It is done by 3 ways:- big-bang , top-down, bottom-up approach. Process of combining & testing multiple components together. Normally done by developer but a tester can also perform if he has the knowledge of coding. 

28. SYSTEM TESTING? 

It is a black box testing technique performed to evaluate the computer system. It include both functional and non-functional testing. Verifying the completed system to ensure that the application works as intended or not. “The behaviour of the system is tested as defined by the scope of the development project”. Carried out by specialist tester/independent tester. 

28. USER-ACCEPATANCE TESTING? 

User-requirement testing is done. Done by client as well as end user. It is a final stage of testing before used. 

29. ALPHA-BETA TESTING? 

Alpha→ 

• Developer records all the issues. 
• Done by the end user at dev site. (involves client or tester+dev) 

Beta→ 

• Dev go through all the issues after specific period of time. 
• Done by the end user at the client site. (involves client/user) 

30. HOW MONKEY TESTING IS DIFFERENT FROM ADHOC TESTING? 

In case of adhoc testing although there are no predefined or documented test cases still testers have the understanding of the application. While in case of monkey testing testers doesn't have any understanding of the application.

31. WHAT IS DYNAMIC TESTING? 

It involves in the execution of code. It validates the output with the expected outcome. 

32. WHAT IS STATIC TESTING? 

It involves in reviewing the documents to identify the defects in the early stages of SDLC. 

33. WHAT IS WHITE BOX TESTING? 

• This also called as glass-box testing, clear-box and structural testing. 
• It is based on applications internal code structure. 
• In this, an internal perspective of the system, as well as programming skills are used to design test cases. 
• In white box testing, the tester analyses the internal architecture of the system as well as the quality of source code on different parameters like code optimization, code coverage, code reusability etc. 
• This testing usually was done at the unit level. 

34. WHAT IS BLACK BOX TESTING? 

• It is a process of testing a system component considering input, output and general function. 
• The tester interact with the system through the interface providing input and validating the received output. 
• It doesn’t require the knowledge of internal program structure. o In this we test UI & backend (coding/database). 
• External actions are performed. 

35. WHAT IS POSITIVE AND NEGATIVE TESTING? 

Pt→

• It is determine what system supposed to do. 
• It helps to check whether the application is justifying the requirements or not. 

Nt→ 

• It is determine what system not supposed to do. 
• It helps to find the defects from the s/w. 

36. WHAT IS GRAY BOX TESTING? 

It is a combination of both black box and white box testing. The tester who works on this type of testing needs to have access to design documents, this helps to create better test cases. 

37. WHAT IS TEST STRATEGY? 

It is a high-level document and usually developed by project manager. It’s a document which captures the approach on how we go about testing the product and achieve the goals. 

38. WHAT IS TEST PLAN? 

It is a document which contains the plan for all the testing activities. 

39. WHAT IS TEST SCENARIO? 

It gives the idea of what we have to test. Or testable part of an application is called TS. 

40. WHAT IS TEST CASE? 

It is a set of conditions under which tester determines whether an application/ software is working correctly or not. 

41. WHAT IS TEST BED? 

An environment configured for testing is called test bed. It consist of hardware, s/w, network configuration. 

42. WHAT IS TEST SUITE?

Collection of test cases. 

43. WHAT IS TEST DATA? 

It is a document that is basically used to test the s/w program. It is divided into 2 categories:- 

a) +ve test data which is generally gives to system to generate the expected result. 

b) –ve test data which is used to test the unhandled condition, unexpected , exceptional input condition.

44. Explain equivalence class partitioning. 

• Equivalence class partitioning is a specification based black box testing techniques. ECP means Grouping test data into equivalence classes with the assumpation that all the data items lying in the classes will have same effect on the application. In simple it means diving any module into equal parts and test the each part separately. 
• E.g. 1 :- for testing a Square program(program that prints the square of a number- the equivalence classes can be:-Set of Negative numbers, whole numbers, decimal numbers, set of large numbers etc.) 2 :- suppose we have to test 1-100 no’s. So 1st we will divide this no into 5 equal parts. (Like 1-20, 21-40,41-60,61-80,81-100). Now we will select random 3 values and multiply these values with the no of parts. Whatever the no will be, we will checked for that values from all the module in place of checking 100 values. 
• Purpose:- testing a complete module is exhaustive testing and time consuming that’s why we use quivalence partioning as it is time saving. 

45. What is boundary value analysis? 

Boundary value analysis is a software testing technique for designing test cases wherein the boundary values of the classes of the equivalence class partitioning are taken as input to the test cases. It is also called as a part of stress and –ve testing. e.g. if the test data lies in the range of 0-100, the boundary value analysis will include test data - 0,1, 99, 100.

46. Explain Agile methodology? 

Agile methodology of software development is based on interative and incremental approach. In this model, the application is broken down into smaller build on which different cross functional team work together providing rapid delivery along with adapting to changing needs at the same time. 

• Working is done by individual person. 
• There is scrum master, who will be either tester/developer from the team or the person who has the knowledge of both testing and coding. 
• Responsibility of scrum master is to narrating the stories to both the team i.e. testing team and development team. 
• Scrum meetings can be happen in once a week or in 15 days or once a month. Most of the time client is included in scrum meeting.
• Because of this meeting, if the one person is absent the another person from same team can complete his work. So project isn’t paused and dependency on one person is not happened. This is the main advantage of this model. 
• Sprint is dividing the project into modules and distributing these modules among both the team’s so that the team is working parallelly. 
• When to use:- when the project is big/medium and we have to deliver it as soon as possible then we will use this model. Quality is maintained.

47. What is scrum? 

A scrum is a process for implementing Agile methodology. In scrum, time is divided into sprints and on completion of sprints, a deliverable is shipped. 

48. What are the different roles in scrum? 

Ans. The different roles in scrum are - 

1. Product Owner - The product owner owns the whole development of the product, assign tasks to the team and act as an interface between the scrum team(development team) and the stakeholders. 
2. Scrum Master - The scrum master monitors that scrum rules get followed in the team and conducts scrum meeting. 
3. Scrum Team - A scrum team participate in the scrum meetings and perform the tasks assigned. 

49. What is a scrum meeting? 

A scrum meeting is daily meeting in scrum process. This meeting is conducted by scrum master and update of previous day's work along with next day's task and context is defined in this meeting. 

50. Explain TDD (Test Driven Development). 

Test Driven Development is a software development methodology in which the development of the software is driven by test cases created for the functionality to be implemented. In TDD, first the test cases are created and then code to pass the tests is written. Later the code is refactored as per the standards. 

51. What is Sprint ?

In Agile product development, a sprint is a set period of time during which specific work has to be completed and made ready for review. Each sprint begins with a planning meeting.

52. What are Story points?

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.