QA Interview: Top 80: Manual Testing Interview Questions (41:80)

 Other Useful Links:

Previous: Manual Testing Interview Questions (01-40)

41. What is Verification in software testing?

  • Verification is the process, to ensure that whether we are building the product right i.e., to verify the requirements which we have and to verify whether we are developing the product accordingly or not.
  • Activities involved here are Inspections, Reviews, Walk-throughs.

42. What is walk through?
  • A walkthrough is an informal meeting conducts to learn, gain understanding, and find defects.
  • The author leads the meeting and clarifies the queries raised by the peers in the meeting.

43. What is Inspection?
  • Inspection is a formal meeting lead by a trained moderator, certainly not by the author. The document under inspection is prepared and checked thoroughly by the reviewers before the meeting.
  • In the inspection meeting, the defects found are logged and shared with the author for appropriate actions. Post inspection, a formal follow-up process is used to ensure a timely and corrective action.

44. What is Validation in software testing?
  • Validation is the process, whether we are building the right product i.e., to validate the product which we have developed is right or not.
  • Activities involved in this is Testing the software application.

45. What is configuration management?
  • Configuration management (CM) is a process of systems engineering to maintain system resources, computer systems, servers, software, and product’s performance in a consistent state.
  • It helps to record all the changes made in the system and ensures that the system performs as expected even though changes are made over time.

46. What is Test Suite?
  • Test Suite is a collection of test cases. The test cases which are intended to test an application.

47. What is Test Scenario?
  • Test Scenario gives the idea of what we have to test. Test Scenario is like a high-level test case.

48. What is Test Case?
  • Test cases are the set of positive and negative executable steps of a test scenario which has a set of pre-conditions, test data, expected result, post-conditions and actual results.

49. What is Use Case?
  • A use case tells how a system will behave or perform certain task provided the given condition.

50. What is Use Case Testing?
  • In order to identify and execute functional requirement of an application from start to stop "use case" is used and technique used to do this is known as use case testing.

51. What are the best practices for writing test cases?
  • Write test cases with end-users perspective
  • Write test steps in a simple way that anyone can follow them easily
  • Make the test cases reusable
  • Set the priority
  • Provide a test case description, test data, expected result, precondition, postcondition.
  • Write invalid test cases along with valid test cases
  • Follow proper naming conventions
  • Review the test cases regularly and update them if necessary.

52. What is Test Bed?
  • An environment configured for testing. Test bed consists of hardware, software, network configuration, an application under test, other related software.

53. What is Test Environment?
  • Test Environment is the combination of hardware and software on which Test Team performs testing.
    • Application Type: Web Application
    • OS: Windows
    • Web Server: IIS
    • Web Page Design: Dot Net
    • Client Side Validation: JavaScript
    • Server Side Scripting: ASP Dot Net
    • Database: MS SQL Server
    • Browser: IE/FireFox/Chrome

54. What is Test Data?
  • Test data is the data that is used by the testers to run the test cases. 
  • While running the test cases, testers need to enter some input data. To do so, testers prepare test data. It can be prepared manually and also by using tools.

55. What is Test Harness?
  • A test harness is the collection of software and test data configured to test a program unit by running it under varying conditions which involves monitoring the output with the expected output.

56. What is Test Closure?
  • Test Closure is the note prepared before test team formally completes the testing process.
  • This note contains the total no. of test cases, total no. of test cases executed, total no. of defects found, total no. of defects fixed, total no. of bugs not fixed, total no of bugs rejected etc.,

57. What is test coverage?
  • Test coverage helps in measuring the amount of testing performed by a set of tests.
  • Test coverage can be done on both functional and non-functional activities. It assists testers to create tests that cover areas which are missing.

58. What is Code coverage?
  • Code coverage is different from Test coverage. Code coverage is about unit testing practices that must target all areas of the code at least once. It is usually done by developers or unit testers.

59. What are the most common components of a defect report?
  • The most common components of a defect report format include the following:
    • Project Name
    • Module Name
    • Defect ID
    • Defect detected on
    • Defect detected by
    • Priority
    • Severity
    • Defect resolved on
    • Defect resolved by

60. On what basis is the acceptance plan prepared?
  • Requirement Document: The requirement document specifies what exactly is needed and not needed in the existing project from the customer’s perspective.
  • Input from customer: Input from the customer will be in the format of formal emails, informal talks, discussions, etc.,
  • Project plan: Project plan document prepared by the project manager.

61. What is a Defect?
  • The variation between the actual results and expected results is known as a defect. If a developer finds an issue and corrects it by himself in the development phase then it’s called a defect.

62. What is a Bug?
  • If testers find any mismatch in the application/system in testing phase then they call it as Bug.

63. What is an Error?
  • We can’t compile or run a program due to a coding mistake in a program. If a developer unable to successfully compile or run a program then they call it as an error.

64. What is a Failure?
  • Once the product is deployed and customers find any issues then they call the product as a failure product. After release, if an end user finds an issue then that particular issue is called as a failure. 

65. What is Bug Severity?
  • Bug/Defect severity can be defined as the impact of the bug on customer’s business.
  • It can be Critical, Major or Minor.

66. What is Bug Priority?
  • Defect priority can be defined as how soon the defect should be fixed. It gives the order in which a defect should be resolved.
  • Developers decide which defect they should take up next based on the priority. It can be High, Medium or Low. Most of the times the priority status is set based on the customer requirement.

67. Tell some examples of Bug Severity and Bug Priority?
  • High Priority & High Severity: Submit button is not working on a login page and customers are unable to login to the application
  • Low Priority & High Severity: Crash in some functionality which is going to deliver after couple of releases
  • High Priority & Low Severity: Spelling mistake of a company name on the homepage
  • Low Priority & Low Severity: FAQ page takes a long time to load

68. What is a Critical Bug?
  • A critical bug is a show stopper which means a large piece of functionality or major system component is completely broken and there is no workaround to move further.
  • Example: “Sign In” button is not working on Gmail App and Gmail users are blocked to login to their accounts.

69. What is HotFix?
  • A hotfix is a build aimed at resolving a severe issue found in production.
  • At times, a build executed in the production environment would have some critical errors and it would be rolled back.
  • Now development team kept all their work aside and focus on fixing these errors immediately and release a new build to fix that in the production. This build is referred as a hotfix

70. What are the different available models of SDLC?
  • Waterfall
  • Spiral
  • V Model
  • Prototype
  • Agile

71. What are different agile/sprint ceremonies?

  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Interim Review
  • Backlog Grooming
  • Sprint Review
  • Sprint Retrospective

72. Authentication and Authorization

  • Authentication: Authentication verifies who the user is.
  • Authorization: Authorization determines what resources a user can access.

73. If a regression suite contains 100 test cases but only 25 must be executed. How will you select test cases?

  • Select the test cases with frequent defects.
  • Choose test cases with critical functionalities.
  • Select test cases with frequent code changes.
  • Cover end to end flows
  • Cover some field validation and negative test cases.
  • Select collaborative approach (you can discuss with developer regarding all the area’s which can get affected)

74. Explain the STLC: Software Testing life cycle.
The software testing life cycle refers to all the activities performed during testing of a software product. The phases include-
  1. Requirement analysis and validation – In this phase, the requirements documents are analyzed and validated and the scope of testing is defined.
  2. 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.
  3. Test Design and Analysis – Here, test cases are designed, test data is prepared and automation scripts are implemented.
  4. Test environment setup – A test environment closely simulating the real-world environment is prepared.
  5. Test execution – The test cases are prepared, bugs are reported and retested once resolved.
  6. Test closure and reporting – A test closure report is prepared to have the final test results summary, learning, and test metrics.
75. What is SDLC?
SDLC is a systematic process for building software that ensures the quality and correctness of the software built. SDLC process aims to produce high-quality software that meets customer expectations.

Phase 1: Requirement collection and analysis Phase 2: Feasibility study Phase 3: Design Phase 4: Coding Phase 5: Testing Phase 6: Installation/Deployment Phase 7: Maintenance Requirement collection and analysis
  • The requirement is the first stage in the SDLC process. It is conducted by the senior team members with inputs from all the stakeholders and domain experts in the industry.
  • Planning for the quality assurance requirements and recognition of the risks involved is also done at this stage.
Feasibility study
  • Once the requirement analysis phase is completed the next SDLC step is to define and document software needs.
  • This process conducted with the help of ‘Software Requirement Specification’ document also known as ‘SRS’ document. It includes everything which should be designed and developed during the project life cycle.
There are mainly five types of feasibilities checks:
  • Economic: Can we complete the project within the budget or not?
  • Legal: Can we handle this project as cyber law and other regulatory framework/compliances.
  • Operation feasibility: Can we create operations which is expected by the client?
  • Technical: Need to check whether the current computer system can support the software
  • Schedule: Decide that the project can be completed within the given schedule or not.
Design
  • In this third phase, the system and software design documents are prepared as per the requirement specification document. This helps define overall system architecture.
  • This design phase serves as input for the next phase of the model.
Coding
  • Once the system design phase is over, the next phase is coding. In this phase, developers start build the entire system by writing code using the chosen programming language.
  • In the coding phase, tasks are divided into units or modules and assigned to the various developers.
  • It is the longest phase of the Software Development Life Cycle process.
Testing
  • Once the software is complete, and it is deployed in the testing environment. The testing team starts testing the functionality of the entire system.
  • During this phase, QA and testing team may find some bugs/defects which they communicate to developers. The development team fixes the bug and send back to QA for a re-test.
  • This process continues until the software is bug-free, stable, and working according to the business needs of that system.
Installation/Deployment
  • Once the software testing phase is over and no bugs or errors left in the system then the final deployment process starts.
  • Based on the feedback given by the project manager, the final software is released and checked for deployment issues if any.
Maintenance
  • Once the system is deployed, and customers start using the developed system, following 3 activities occur.
  1. Bug fixing – bugs are reported because of some scenarios which are not tested at all
  2. Upgrade – Upgrading the application to the newer versions of the Software
  3. Enhancement – Adding some new features into the existing software
76. Bug Life Cycle
  • The bug life cycle is also known as the Defect life cycle. 
  • Defect life cycle or Bug life Cycle is a set of state through which bug goes during its entire life.
  • The purpose of defect life cycle is to easily co-ordinate and communicate current state of defect which changes to various assignees to make defect fixing process systematic and less efficient.
New
  • When a tester finds a new defect. He should provide a proper Defect document to the Development team to reproduce and fix the defect. In this state, the status of the defect posted by the tester is “New”
Assigned
  • Defects that are in the status of New will be approved (if valid) and assigned to the development team by Test Lead/Project Lead/Project Manager. Once the defect is assigned then the status of the bug changes to “Assigned”
Open
  • The development team starts analyzing and works on the defect fix
Fixed
  • When a developer makes the necessary code change and verifies the change, then the status of the bug will be changed as “Fixed” and the bug is passed to the testing team.
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.”
Closed
  • After verified the fix, if the bug is no longer exits then the status of the bug will be assigned as “Closed.”
Reopen
  • If the defect remains the same after the retest, then the tester posts the defect using the defect retesting document and changes the status to “Reopen”. Again the bug goes through the life cycle to be fixed.
Duplicate
  • If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate” by the development team.
Deferred
  • In some cases, the Project Manager/Lead may set the bug status as deferred.
77. When Bug is Deferred?
  • If the bug found during the end of the release and the bug is minor or not important to fix immediately.
  • If the bug is not related to the current build.
  • If it is expected to get fixed in the next release.
  • The customer is thinking to change the requirement.
  • In such cases the status will be changed as “deferred” and it will be fixed in the next release.

Greetings, reader! Your input is highly important to us. Please share your thoughts in the comments section below.

Contact:

Email:  piyushagrawal.automation@gmail.com

Follow on LinkedIn: Piyush Agrawal - LinkedIn

Follow on YouTube: Piyush Agrawal - Youtube

Happy to Help You !!

By at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)