<\/div>\n

<\/div>\n<\/div>\n

<\/div>\n

Table of Contents<\/div>\n<\/p><\/div>\n<\/div>\n<\/div>\n

<\/div>\n

1. What are the different types of manual testing? <\/a><\/div>\n

2. How do you explain STLC?<\/a><\/div>\n

3. Can you explain SDLC?<\/a><\/div>\n

4. Explain the Waterfall model.<\/a><\/div>\n

5. Explain V- Model.<\/a><\/div>\n

6. What are test cases?<\/a><\/div>\n

7. How do you explain the test case format?<\/a><\/div>\n

8. What is a test plan?<\/a><\/div>\n

9. Is it possible to do exhaustive testing? How much testing is sufficient.<\/a><\/div>\n

10. When should we start doing testing?<\/a><\/div>\n

11. What is the difference between Quality Assurance (QA) and Quality Control (QC)?<\/a><\/div>\n

12. Can you explain Bug Life Cycle?<\/a><\/div>\n

13. What is the difference between Manual testing and Automation testing?<\/a><\/div>\n

14. What do you understand by Unit Testing?<\/a><\/div>\n

15. What is the difference between severity and priority?<\/a><\/div>\n

16. Give an example of high priority and low severity bug?<\/a><\/div>\n

17. Give an example of high severity and low priority bug.<\/a><\/div>\n

18. Give an example of high severity and high priority bug?<\/a><\/div>\n

19. What is a traceability matrix?<\/a><\/div>\n

20. What is the difference between functional and non-functional testing?<\/a><\/div>\n

21. What is the difference between static and dynamic testing?<\/a><\/div>\n

22. Working with different permissions and other Adb commands. <\/a><\/div>\n

22. What is Verification and Validation? <\/a><\/div>\n

23. How can you explain the difference between Black Box Testing and White Box Testing?<\/a><\/div>\n

24. What is your understanding of Regression Testing?<\/a><\/div>\n

25. What has been your greatest challenges while doing regression testing?<\/a><\/div>\n

26. What is the difference between smoke testing and sanity testing?<\/a><\/div>\n

27. What is the difference between System Testing and User Acceptance Testing (UAT)?<\/a><\/div>\n

28. What do you mean by integration testing.<\/a><\/div>\n

29. What is the difference between alpha and beta testing?<\/a><\/div>\n

30. Differentiate between ad-hoc testing and exploratory testing.<\/a><\/div>\n

31. What are static testing techniques?<\/a><\/div>\n

32. What is the difference between formal and informal reviews.<\/a><\/div>\n

33. What is a latent bug.<\/a><\/div>\n

34. What do you understand by equivalence partitioning.<\/a><\/div>\n

35. What is boundary value testing.<\/a><\/div>\n

36. How do you select regression test cases or form the regression test suite?<\/a><\/div>\n

37. Why is impact analysis important?<\/a><\/div>\n

38. What do you understand by performance testing?<\/a><\/div>\n

39. What is the difference between stress testing and load testing?<\/a><\/div>\n

40. Have you ever managed to write the test cases without having any documents?<\/a><\/div>\n

41. Suppose you find a bug in production. How would you make sure that the same bug is not introduced again?<\/a><\/div>\n

42. If a small section of code in the application is updated, what is your approach to validate it?<\/a><\/div>\n

43. How would you begin testing the build that you have recently received? Is there any approach to follow?<\/a><\/div>\n

44. What will be your approach if in case you have any doubts regarding the project?<\/a><\/div>\n

45. How do you solve if there is any conflict with your peer QA on any technical aspect?<\/a><\/div>\n

46. What do you do when your developer denies that what you have filed is not a BUG?<\/a><\/div>\n

47. What are the drawbacks of agile implementation\/methodology that you faced?<\/a><\/div>\n

48. What if the software is so buggy it can\u2019t really be tested at all?<\/a><\/div>\n

49. Explain what will be your reaction if a project you had been working on gets a sudden change in the deadline.<\/a><\/div>\n

50. Write test cases on any device\/ object present around (Example: Chair).<\/a><\/div>\n<\/div>\n

<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

\u00a01. What are the different types of manual testing<\/b>?\u00a0<\/b><\/b><\/h3>\n
Manual testing has three types of testing: white-box, black-box and grey-box testing.<\/p>\n
\n

\n<\/ins>\n<\/div>\n
\n
White-Box Testing: It is an approach that allows testers to inspect and verify the internal implementation of the software.<\/li>\n
Black-Box Testing: It is an approach that allows testers to test without having any knowledge of the internal implementation. It is just to check whether it is meeting the customer\u2019s requirements without any knowledge of the code.<\/li>\n
Grey-Box Testing: In this approach, we test the software with some knowledge of the code. It is a blend of both white-box and black-box testing.<\/li>\n<\/ul>\n
2. How do you explain STLC<\/b>?<\/b><\/b><\/h3>\n
STLC stands for software testing life cycle. Software testing life cycle is the whole process of how testing is performed, and what are the phases involved. The testing life cycle consists of six phases:<\/p>\n
\n
Requirement analysis<\/li>\n
Test planning<\/li>\n
Test case development<\/li>\n
Test environment setup<\/li>\n
Test Execution<\/li>\n
Test cycle closure.<\/li>\n<\/ul>\n
$\"\"$ <\/p>\n
So, it starts with the requirements gathering, where a requirement document is shared with the team. After going through the requirement documents, the test planning is done. The test plan is a document describing the approach, resources and scheduling of the testing activities.<\/i><\/b> Next, we develop test cases for the functional and non-functional specifications in the test case development phase. After this phase, the environment is set feasible to start testing. After the environment is set, test cases are executed and lastly, the closure of the whole life cycle is done and a report is generated.<\/p>\n
3.\u00a0Can you explain SDLC<\/b>?<\/b><\/b><\/h3>\n
SDLC stands for Software Development Life Cycle. The development process adopted in every project is according to its aims and goals. There are six phases involved in SDLC.<\/p>\n
\n
Requirements Gathering<\/li>\n
Design<\/li>\n
Development\/implementation<\/li>\n
Testing<\/li>\n
Deployment<\/li>\n
\u00a0Maintenance<\/li>\n<\/ul>\n
$\"\"$ <\/p>\n
SDLC starts with the requirements gathering, then the design is implemented as per the requirement analysis. After the design is ready, it\u2019s been given to the development team for implementation. After implementation, the product goes into the testing phase. After the product is successfully tested, it is deployed. After deployment, the product is regularly maintained after the user starts using it.<\/p>\n
<\/b><\/p>\n
4. Explain the Waterfall model.<\/b><\/b><\/b><\/h3>\n
This model is in a linear sequential manner. This development model involves executing each phase and then going into the next phase.<\/p>\n
$\"\"$ <\/p>\n
Merits<\/u><\/b>:<\/u><\/b><\/p>\n
\n
Suitable for small and mid-size products with fixed requirements.<\/li>\n<\/ul>\n
\n
Easy to determine the critical points in each phase.<\/li>\n<\/ul>\n
\n
Best when there are enough resources.<\/li>\n<\/ul>\n
Demerits:<\/u><\/b><\/p>\n
\n
Testing happens at the end of the project, so the defects tracked are close to the implementation.<\/li>\n<\/ul>\n
\n
Not suitable for the projects having frequent changes in requirements.<\/li>\n<\/ul>\n
\n
Resources have to sit idle and wait for the phases to complete. For example, if the project is in the development phase, then testers have to sit idle and wait for the development phase to complete.<\/li>\n<\/ul>\n
\n
Backtracking is not possible as requirements are constant.<\/li>\n<\/ul>\n<\/div>\n
\n
5. Explain V- Model<\/b>.<\/b><\/b><\/h3>\n
As the name suggests, the testing and development life cycle run parallel, the one side of V is verification (development) and the other side is validation (verification). Hence this is also called the Verification and Validation model as well. This model is an extension of the waterfall model, the only difference is that the process steps are bent upwards after the coding phase, to form a typical V shape.<\/p>\n
$\"\"$ <\/p>\n
Merits:<\/u><\/b><\/p>\n
\n
Designed for small and medium-sized projects.<\/li>\n
Better than the waterfall model as it allows to test the software side by side.<\/li>\n
V-model provides guidance that testing needs to begin as early as possible.<\/li>\n
It has four Test levels- component, integration, system, and acceptance testing.<\/li>\n
Defect tracking is easy.<\/li>\n<\/ul>\n
Demerits:<\/u><\/b><\/p>\n
\n
Lack of flexibility.<\/li>\n
Changing requirements at the later phase could cost high.<\/li>\n
High business and development risk.<\/li>\n<\/ul>\n
6. What are test cases<\/b>?<\/b><\/h3>\n
It is a document that has the steps that have to be executed. This document is planned before the test case execution phase.<\/p>\n
7. How do you explain the test case format<\/b>?<\/b><\/b><\/h3>\n
A test case format has the following fields:<\/p>\n
\n
Test case ID<\/li>\n
Test case Description<\/li>\n
Severity<\/li>\n
Priority<\/li>\n
Test Data<\/li>\n
Environment<\/li>\n
Build Version<\/li>\n
Steps to execute<\/li>\n
Expected Results<\/li>\n
Actual Results <\/b><\/li>\n<\/ul>\n
8. What is a test plan<\/b>?<\/b><\/b><\/h3>\n
Test planning is done before the start of testing activities. It is a document specifying the strategy, scope, approach, resources and schedule of the testing activities. It should cover the following details:<\/p>\n
\n
Test strategy<\/li>\n
Test objective<\/li>\n
Exit\/suspension criteria<\/li>\n
Resource planning<\/li>\n
Test deliverables<\/li>\n<\/ul>\n
9. <\/b>Is it possible to do exhaustive testing? How much testing is sufficient<\/b>.<\/b><\/h3>\n
It is impossible to test everything, instead, we can focus on prioritizing test cases. An extensive test that finds more bugs doesn\u2019t mean we have discovered every defect. Since exhaustive testing is not practical, our best approach as a tester is to pick those test cases that are most likely to find bugs. <\/b><\/p>\n
10. When should we start doing testing<\/b>?<\/b><\/b><\/h3>\n
We should start testing as early as possible. The earlier a bug is tracked, the better it will be for the software. A bug tracked early can save money and time as well.<\/p>\n
<\/a><\/p>\n
11. What is the difference between Quality Assurance (QA) and Quality Control (QC)?<\/b><\/b><\/b><\/h3>\n
Quality assurance<\/b> involves process-oriented activities. It ensures the prevention of defects while developing software applications.<\/p>\n
Quality Control<\/b> involves product-oriented activities. It executes code to identify the defects in the software application.<\/p>\n
12. Can you explain Bug Life Cycle<\/b>?<\/b><\/b><\/h3>\n
Bug life cycle mainly refers to the entire phases of detecting a new bug\/defect by a tester to closing that bug by the tester. Below diagram describes the stages for a bug life cycle:<\/p>\n
$\"\"$ <\/p>\n
In the first stage, a new<\/b> bug is detected by the tester. The bug is documented by the tester and the tester shares the document with the development team. The project manager will then assign the bug to the development team and it comes under the \u201cassigned<\/b>\u201d state. When the development team starts working on the defect, it is in an \u201copen<\/b>\u201d state. In the open state, the bug is classified into different states, duplicate, rejected, deferred, not a bug.<\/p>\n
Let\u2019s discuss these states of bugs that developers can assign:<\/p>\n
\n
Rejected<\/b>: If the defect is not considered as a genuine defect by the developer then it is marked as \u2018Rejected\u2019<\/b> by the developer.<\/li>\n
Duplicate<\/b>: If the developer finds the defect as same as any other defect or if the concept of the defect matches any other defect then the status of the defect is changed to \u2018Duplicate\u2019<\/b> by the developer.<\/li>\n
Deferred<\/b>: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as \u2018Deferred\u2019<\/b>.<\/li>\n
Not a Bug<\/b>: If the defect does not have an impact on the functionality of the application then the status of the defect gets changed to \u2018Not a Bug<\/b>\u2019.<\/li>\n<\/ul>\n
Next, when the developer fixes the bug and assigns the state to \u201cfixed<\/b>\u201d. After fixing the defect, when the developer shares the code to the tester for retesting, the tester assigns a stage \u201cPending Retest<\/b>\u201d. When the tester starts retesting, the state is \u201cRetesting<\/b>\u201d. If the bug still persists, the tester assigns it again to the development team and the state is \u201cRe-open<\/b>\u201d. If the tester verifies the bug and finds out it is fixed, then he assigns a state as \u201cVerified<\/b>\u201d. If everything is done and the tester confirms the bug is fixed and he has completed re-testing and the bug no more exists, the bug is assigned to the \u201cClosed<\/b>\u201d state.<\/p>\n
13. What is the difference between Manual testing and Automation testing<\/b><\/b>?<\/b><\/h3>\n
Manual Testing<\/b> is verifying the software manually and finding defects without the intervention of any tools. The tester has to execute each test case one by one. They manually verify the software as an end-user would. They give input and manually verify the output.<\/p>\n
Automation Testing <\/b>is testing the software with the help of some automation tools like Selenium. The code is run for automating tests and the input data is given to the tool. The output data is then compared with the expected results. Automation testing is generally performed for repeated tasks so that the time can be saved.<\/p>\n
14. What do you understand by Unit Testing<\/b>?<\/b><\/b><\/h3>\n
Testing the smallest piece of code is called unit testing.<\/i><\/p>\n
15. What is the difference between severity and priority<\/b><\/b>?<\/b><\/h3>\n
Priority<\/b> is how soon a bug needs to be fixed.<\/p>\n
Severity <\/b>is the impact of a bug on the software.<\/p>\n
16. Give an example of high priority and low severity bug<\/b><\/b>?<\/b><\/h3>\n
If there\u2019s an issue with the logo of the website, then it will be a high priority and low severity bug. <\/b><\/p>\n
17. Give an example of high severity and low priority bug<\/b>.<\/b><\/b><\/h3>\n
Web page not found when the user clicks on the link, if the user doesn\u2019t visit that page in general. This can be an example of high severity and low priority because the user is not regularly visiting the page so priority is low but the severity is high because its impact is high.<\/p>\n
18. Give an example of high severity and high priority bug<\/b>?<\/b><\/b><\/h3>\n
An error which occurs on the basic functionality of the application and will not allow the end-user to use the system. This type of bug will be of high priority and high severity. For example, if the user is unable to log in to the application.<\/p>\n
19. What is a traceability matrix<\/b><\/b>?<\/b><\/h3>\n
Traceability matrix is a document that shows the mapping between test cases and the requirement.<\/p>\n
20. What is the difference between functional and non-functional testing<\/b><\/b>?
<\/b><\/h3>\n
Functional Testing <\/b>focuses mainly on the software\u2019s functional requirements rather than the internal implementation. Functional testing is a type of black-box testing. It mainly focuses on testing the functional requirements which are how the system is behaving? Is it meeting the requirement or not?<\/p>\n
Non-functional Testing <\/b>tests the software\u2019s non-functional requirements. Non-functional requirements refer to the quality of the system such as performance, security, scalability and usability. Non-functional testing happens after functional testing. This testing is done to ensure that the software is secure, scalable, high performing and won\u2019t crash under heavy load.<\/p>\n
21. What is the difference between static and dynamic testing?<\/b><\/b><\/h3>\n
Static testing is performed in the early stages of development to avoid errors as it can be fixed easily in the early stages. The errors that can\u2019t be found in dynamic testing will easily be found in static testing.<\/p>\n
With dynamic testing methods, the software is executed using a set of input values and its output is then examined and compared to what is expected.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n
Static Testing<\/strong><\/p>\n<\/td>\n
\n
Dynamic Testing<\/strong><\/p>\n<\/td>\n<\/tr>\n
\n
Testing is done without executing the program.<\/p>\n<\/td>\n
\n
Testing is done by executing the program.<\/p>\n<\/td>\n<\/tr>\n
\n
This testing does the verification process.<\/p>\n<\/td>\n
\n
Dynamic testing does the validation process.<\/p>\n<\/td>\n<\/tr>\n
\n
Performed before compilation.<\/p>\n<\/td>\n
\n
Performed after compilation.<\/p>\n<\/td>\n<\/tr>\n
\n
It is about the prevention of defects.<\/p>\n<\/td>\n
\n
It is about finding and fixing defects.<\/p>\n<\/td>\n<\/tr>\n
\n
Involves checklist and process to be followed.<\/p>\n<\/td>\n
\n
Involves test cases for execution.<\/p>\n<\/td>\n<\/tr>\n
\n
Requires lots of meetings.<\/p>\n<\/td>\n
\n
Comparatively requires lesser meetings.<\/p>\n<\/td>\n<\/tr>\n
\n
Return on investment will be high as this process is involved at an early stage.<\/p>\n<\/td>\n
\n
Return on investment will be high as this process is involved after the development phase.<\/p>\n<\/td>\n<\/tr>\n
\n
More review comments are highly recommended for good.<\/p>\n<\/td>\n
\n
More defects are highly recommended for good<\/p>\n<\/td>\n<\/tr>\n
\n
The cost of finding defects and fixing is low<\/p>\n<\/td>\n
\n
The cost of finding defects and fixing is high<\/p>\n<\/td>\n<\/tr>\n
\n
Gives assessment of codes and documentation<\/p>\n<\/td>\n
\n
Gives bugs\/bottlenecks in the software system.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/h3>\n
22. What is Verification and Validation?<\/b><\/b>\u00a0 \u00a0 \u00a0 \u00a0 \u00a0<\/h3>\n
Verification <\/b>is a static testing technique. Testing is done without executing the code in verification. Examples are reviews, walkthroughs and inspection.<\/p>\n
Validation <\/b>is a dynamic testing technique where testing is done by executing the code. Examples are functional and non-functional testing techniques.<\/p>\n
In the V model, both these activities go simultaneously.<\/p>\n
23. How can you explain the difference between Black Box Testing and White Box Testing<\/b><\/b>?<\/h3>\n
White-Box Testing<\/b> is an approach that allows testers to inspect and verify the internal implementation of the software.<\/p>\n
Black-Box Testing<\/b> is an approach that allows testers to test without having any knowledge of the internal implementation. It is just to check whether it is meeting the customer\u2019s requirements without any knowledge of the code.<\/p>\n
24. What is your understanding of Regression Testing<\/b><\/b>?<\/h3>\n
Regression Testing<\/b> is performed after re-testing. It is performed on the unchanged part after the bug fixes. In regression testing, software application is tested to make sure that a change is not going to affect the functionality.<\/p>\n
$\"\"$ <\/p>\n
25. What has been your greatest challenges while doing regression testing<\/b><\/b>?<\/h3>\n
While doing regression testing the challenges faced are:<\/p>\n
\n
Data Issue.<\/li>\n
Compromised business value.<\/li>\n
Time-consuming.<\/li>\n
Large suite to execute. \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/li>\n
Reproducing the defect in production hence becomes inconsistent.<\/li>\n
Re-executing tests repeatedly.<\/li>\n
Improper selection of regression test cases might skip a major regression defect to be found.<\/li>\n<\/ul>\n
26. What is the difference between smoke testing and sanity testing<\/b><\/b>?<\/h3>\n
Sanity testing <\/b>is a kind of software testing performed after receiving a software build, with minor changes in the functionality (code). This is done to ensure that the bugs have been fixed and no further issues have been introduced due to these changes.<\/p>\n
Smoke testing <\/b>is a special type of testing performed on software build to check the critical functionalities of the program.<\/p>\n
27. What is the difference between System Testing and User Acceptance Testing (UAT)<\/b><\/b>?<\/h3>\n
User Acceptance Testing (UAT<\/b>) is the last step before the product goes live or before the delivery of the product is accepted. UAT is done after the product itself is thoroughly tested.<\/p>\n
System<\/b>
\nTesting<\/b> is the level of testing where complete and integrated software is tested. The purpose of this test is to evaluate the system\u2019s compliance with the specified requirements.<\/p>\n
28. What do you mean by integration testing.<\/b><\/b><\/h3>\n
Integration testing\u00a0<\/b>is testing where individual modules are combined and tested. It is a level of testing, usually performed after unit testing.<\/p>\n
29. What is the difference between alpha and beta testing<\/b><\/b>?<\/h3>\n
Alpha Testing <\/b>is a part of user acceptance testing and is performed internally before delivering to the client. It is performed to ensure no bugs present at the time of delivery.<\/p>\n
Beta Testing <\/b>is performed by the customers at their end in a real production environment. <\/b>This is done to get real feedback from the users using the software. It is also a part of user acceptance testing.<\/p>\n
30. Differentiate between ad-hoc testing and exploratory testing.<\/b><\/b><\/h3>\n
Ad-hoc testing<\/b> <\/b>includes learning the application first and then proceeding with the testing process.<\/p>\n
Exploratory testing <\/b>is a form of testing that involves learning of the application while testing.<\/p>\n
31. What are static testing techniques<\/b><\/b>?<\/h3>\n
Static<\/b>
\ntesting<\/b> is the testing of the software work products manually, or with a set of tools, but they are not executed. It starts early in the life cycle and so it is done during the verification processes. It does not need a computer as the testing of the program is done without executing the program, e.g., inspection, reviewing, walkthroughs.<\/p>\n
There are two types of static testing: Reviews<\/b> and Static Analysis<\/b> by tools.<\/p>\n
Reviews<\/b> are informal<\/b> and formal. Informal<\/b>
\nreviews<\/b> are applied during the early stages of the life cycle of a document. A two-person team can conduct an informal review, as the author can ask a colleague to review a document or code. In later stages, these reviews often involve more people and a meeting. The goal is to help the author and to improve the quality<\/u> of the document. Informal reviews have types but there is one characteristic that is common in all informal reviews is that they are not documented. <\/u>The formal review<\/b> process is related to the factors like the maturity of the development process, any legal or regulatory requirements or the need for an audit trail. Inspection is the most documented and formal review, yet it is not the only one.<\/p>\n
Static analysis<\/b> is just another form of testing. It is focused on finding defects rather than failure and the goal is to find the defects whether or not they may cause failure.<\/p>\n
32. What is the difference between formal and informal reviews<\/b>.<\/b><\/h3>\n
An informal review<\/b> is a review not based on a formal(documented) procedure. <\/i><\/p>\n
And, Formal review<\/b> is a review characterized by documented procedures and requirements, e.g., inspection.<\/i><\/p>\n
Informal reviews are not documented and performed at early stages. Whereas formal reviews are always documented. Inspection is the most documented and formal review, yet it is not the only one. Below are the differences listed between formal and informal reviews:<\/p>\n\n\n\n\n\n\n\n
\n
INFORMAL REVIEW<\/strong><\/p>\n<\/td>\n
\n
FORMAL REVIEW<\/strong><\/p>\n<\/td>\n<\/tr>\n
\n
Conducted on as needed i.e. informal agenda.<\/p>\n<\/td>\n
\n
Conducted at the end of each life cycle phase i.e. formal agenda.<\/p>\n<\/td>\n<\/tr>\n
\n
The date and time of the agenda for the informal review will not be addressed in the project plan.<\/p>\n<\/td>\n
\n
The agenda for the formal review must be addressed in the project plan.<\/p>\n<\/td>\n<\/tr>\n
\n
The developer chooses a review panel and provides and\/or presents the material to be reviewed.<\/p>\n<\/td>\n
\n
The acquirer of the software appoints the formal review panel or board, who may make or affect a go\/no-go decision to proceed to the next step of the life cycle.<\/p>\n<\/td>\n<\/tr>\n
\n
The material may be as informal as a computer listing or hand-written documentation.<\/p>\n<\/td>\n
\n
The material must be well prepared.<\/p>\n
For ex- Formal reviews include the software requirement reviews, the software preliminary design review, the software critical design review, and the software test readiness review.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
33. What is a latent bug<\/b>.<\/b><\/h3>\n
A Latent defect<\/b> is a bug that remains dormant and does not cause any failure as the exact set of conditions have never been met.<\/p>\n
34. What do you understand by equivalence partitioning<\/b>.<\/b><\/h3>\n
Equivalence Partitioning <\/i><\/b>is a black box technique in which test cases are designed to execute representatives from equivalence partitions. In principle, test cases are designed to cover each partition at least once.<\/i><\/p>\n
The idea behind the technique is to divide a set of test conditions and each partition is then tested separately. We need to test only one condition from each partition because we are assuming all the test conditions in a partition will be treated by the software in the same way. If one condition in a partition works, we assume all the conditions in that partition will work. Similarly, if one condition in a partition fails, then we will assume the entire partition doesn\u2019t work.<\/p>\n
35. What is boundary value testing<\/b>.<\/b><\/h3>\n
Boundary value analysis <\/i><\/b>is a black box design technique in which test cases are designed based on boundary values. <\/i><\/p>\n
In boundary value analysis, we have both valid boundaries (in valid partitions) and invalid boundaries (in invalid partitions). A boundary value includes minimum and maximum values at inside and outside boundaries. BVA is a part of stress and negative testing.<\/p>\n
BVA gives testers ease to create test cases for an input field. Let\u2019s take an example of an address text box that allows a maximum of 500 characters. Writing test cases for each character would be a challenging situation, so we can use boundary value analysis.<\/p>\n
36. How do you select regression test cases or form the regression test suite<\/b><\/b>?<\/h3>\n
We will select the regression test cases and form the regression test suite by including the test cases<\/p>\n
\n
That verify core features of the application<\/li>\n
For functionalities that have undergone recent changes<\/li>\n<\/ul>\n
\u00a0That have frequently yielded bugs.<\/p>\n
<\/p>\n
37. Why is impact analysis important<\/b><\/b>?<\/h3>\n
To practice Risk-based, Impact analysis has to be done. By doing so test cases can be designed in a way that all the severe bugs, critical from the customer\u2019s view can be solved before time. A good study of the business, client\u2019s need and their usage of the software is to be taken care of.<\/p>\n
For Example,<\/strong> the most important risk associated with software in the banking domain is Security. Any new form added to the already existing software can be vulnerable. A good amount of security testing is advisable by adding proper links, redirection, and navigation to the proper page, installing proxy if needed.<\/p>\n
38. What do you understand by performance testing<\/b><\/b>?<\/h3>\n
Performance testing <\/b>is testing the stability<\/b> and response<\/b>
\ntime<\/b> of the application by applying load<\/b>.<\/p>\n
Response<\/b>
\ntime<\/b> is the time taken to send the request to the server, run the program in the server and take back the request from the server.<\/p>\n
And the load<\/b> is the number of users using the application at a particular period of time.<\/p>\n
39. What is the difference between stress testing and load testing<\/b><\/b>?<\/h3>\n
Load Testing <\/b>helps us to study the behavior of the application under various loads. The main parameter to focus on here is the response time. Load testing is done to ensure how many concurrent users that server can handle effectively and quickly.<\/p>\n
Stress testing <\/b>helps us to test the stability of the application. The main objective of stress testing is to identify the breaking point of the server.<\/p>\n
For example,<\/b> if 50 users are active on an application for approximately 3 seconds at the same time, then in load<\/b> testing we will be testing for less than or equal to<\/u> 50 users in 3 seconds. But in stress<\/b> testing, we will be testing for more than<\/u> 50 users in 3 seconds.<\/p>\n
Behavioral interview questions and answers<\/u><\/b><\/span><\/p>\n
40. Have you ever managed to write the test cases without having any documents<\/b><\/b>?<\/h3>\n
You have to answer this question very carefully and first, you need to tell which projects you have worked on. Whether these projects were in-house or not? Your answer should be related to your previous or ongoing projects.<\/p>\n
For example: In one of my previous projects, we had to redevelop our internal tool with new technology, but there were no tests\/documentation for the old\/existing product. As there is no documentation, below are the steps I have followed:<\/p>\n
\n
Understand and explore the existing product to come up with scenarios<\/li>\n
Understanding the tool from the product owner or seniors or developers who had worked earlier on the same tool.<\/li>\n
Going through production bugs that are found previously for products so that edge test cases are not missed in writing the tests for the upgraded products.<\/li>\n<\/ul>\n
41. Suppose you find a bug in production. How would you make sure that the same bug is not introduced again?<\/b><\/b><\/b><\/h3>\n
Finding a bug in production can be very challenging. To make sure the same bug is not introduced again, we need to add that uncaught functionality to regression test cases. If we have an automated regression suite, then we need to write a new script that validates the above functionality.<\/p>\n
42. If a small section of code in the application is updated, what is your approach to validate it?<\/b><\/b><\/b><\/b><\/h3>\n
If any small change is done in the code, a tester needs to discuss with the concerned developer that what areas he has updated. After getting the information, a tester will try to perform testing on the same page. If the page has three links for example and the developer has changed only one link. In this case, the tester needs to test the remaining links in the page and then the page itself. It\u2019s not necessary to test the entire application again. <\/b><\/p>\n
43. How would you begin testing the build that you have recently received? Is there any approach to follow?<\/b><\/b><\/b><\/b><\/h3>\n
Yes, we follow an approach as follows:<\/p>\n
Smoke Testing> Sanity Testing> Exploratory Testing> Functionality Testing> Regression Testing and Final Product Validation<\/p>\n
44. What will be your approach if in case you have any doubts regarding the project?<\/b><\/b><\/b><\/b><\/b><\/h3>\n
In case of any doubts, the first approach should be to go through the documentation available. If this would not help, then you should approach your senior team members.<\/p>\n
We can also approach the business analysts and the development team. The last option would be to approach the manager and the stakeholders.<\/p>\n
45. How do you solve if there is any conflict with your peer QA on any technical aspect?<\/b><\/b><\/b><\/b><\/b><\/h3>\n
There should be an argument but only up to a certain extent with your peer on why you are correct. If the conflict still persists then involve the team and discuss the conflict issues with larger audiences that may be other QAs, development team and scrum masters. In the meeting, you can have open suggestions and get the right direction. You must accept any decision made from the team meeting with a smile.<\/p>\n
46. What do you do when your developer denies that what you have filed is not a BUG?<\/b><\/b><\/b><\/b><\/b><\/h3>\n
When you file a bug and your developer denies it, then we can take the following measures:<\/p>\n
\n
We can provide business documentation reference to support why the bug is not as per design.<\/li>\n
We can have a meeting with the product owner\/business analyst for the discussion regarding the bug and how it is deviating from the requirement document.<\/li>\n<\/ul>\n
If the bug is not reproducible, then,<\/p>\n
\n
Provide screenshots of the bug, give timestamps on when you reproduced this so that developer can check in application logs.<\/li>\n
Provide test data you have used for replicating the issue.<\/li>\n<\/ul>\n
47. What are the drawbacks of agile implementation\/methodology that you faced?<\/b><\/b><\/b><\/b><\/b><\/h3>\n
Agile methodology is very popular because of its flexibility to take testing and development parallel but it has some drawbacks as well.<\/p>\n
\n
Sprints are very deadline-constrained.<\/li>\n
Documentation is not a priority.<\/li>\n
Frequent changes in requirements can be sometimes messy.<\/li>\n<\/ul>\n
48. What if the software is so buggy it can\u2019t really be tested at all<\/b>?<\/b><\/b><\/b><\/b><\/h3>\n
If the software is buggy, first we need to categorize the bugs as per their severity. The critical bugs can impact the software and need to be fixed quickly. For this, you need to let the manager know with proper documentation as proof. \u00a0<\/b><\/p>\n
49. Explain what will be your reaction if a project you had been working on gets a sudden change in the deadline<\/b>.<\/b><\/b><\/b><\/b><\/h3>\n
As a tester, we have to be open to our thoughts if we can deliver the project with QA signoff covering all the test cases. If pre-release is a must, then we need to discuss the opportunities of increasing QA resources or the possibility of partial product delivery. We have the power to hold QA sign off if we are not satisfied with the quality of the product which eventually stops the release date.<\/p>\n
50. Write test cases on any device\/ object present around (Example: Chair)<\/b><\/b><\/b>.<\/b><\/b><\/h3>\n
When asked questions on these scenarios, always start with gathering requirements. Ask questions after selecting your object. This will show your knowledge level in the software development life cycle.<\/p>\n
In this case:<\/p>\n
\n
Ask for the type<\/b> of chair, office chair, study table- chair, sofa chair, dining table chair, comfortable chair.<\/li>\n
What material<\/b> it is made of? Wood, steel or plastic.<\/li>\n
Ask for the dimensions<\/b> of the chair such as height, weight based on the type of chair.<\/li>\n
Ask for availability<\/b>.<\/li>\n<\/ul>\n
Start making test cases based on the specifications gathered. Test cases would differ for each type of chair, which is better left for your thinking capability (For Example,<\/strong> the purpose of chair, dimensions according to the type of chair, portable-non portable, light-weight, purchase options). For each chair, a performance test case can be:<\/strong> to derive the tensile strength or the maximum weight-bearing capacity.<\/p>\n
<\/p>\n<\/div>\n<\/div>\n<\/div>\n
<\/div>\n<\/section>\n
<\/body><\/html><\/p>\n","protected":false},"excerpt":{"rendered":"
Table of Contents 1. What are the different types of manual testing? 2. How do you explain STLC? 3. Can you explain SDLC? 4. Explain the Waterfall model. 5. Explain V- Model. 6. What are test cases? 7. How do you explain the test case format? 8. What is a test plan? 9. Is it […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1672","post","type-post","status-publish","format-standard","hentry","category-interview-questions","post-wrapper","thrv_wrapper"],"_links":{"self":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1672","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1672"}],"version-history":[{"count":0,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1672\/revisions"}],"wp:attachment":[{"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1672"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rahulshettyacademy.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\u00a01. What are the different types of manual testing<\/b>?\u00a0<\/b><\/b><\/h3>\nManual testing has three types of testing: white-box, black-box and grey-box testing.<\/p>\n\n\n<\/ins>\n<\/div>\n

<\/h3>\n