Explore topic-wise InterviewSolutions in .

• Black Box Testing: The customer's statement of requirements is the most COMMON source of black-box testing. It's a different kind of manual testing. It's a software testing technique that LOOKS at the software's functionality without knowing anything about its internal structure or coding. It does not necessitate any software programming knowledge. All test cases are created with the input and output of a certain function in mind. The test engineer examines the programme against the specifications, detects any faults or errors, and returns it to the development team.
• White Box Testing: The term "clear box," "white box," or "transparent box" refers to the capacity to see into the inner workings of software through its outside shell. It is carried out by developers, after which the software is handed to the testing team for black-box testing. The fundamental goal of white-box testing is to examine the infrastructure of an application. It is carried out at a lower level, as unit testing and integration testing are included. It necessitates programming skills because it primarily focuses on a program's or software's code structure, routes, conditions, and branches. The main purpose of white-box testing is to concentrate on the flow of INPUTS and outputs via the software while also ensuring its security.

The following table lists the differences between black box and white box testing: 

Walkthrough - A walkthrough is a technique for doing a quick group or individual review. In a walkthrough, the author describes and explains his work product to his peers or supervisor in an informal gathering to receive comments. The legitimacy of the suggested work product solution is checked here. It is less expensive to make adjustments while the design is still on paper rather than during conversion. A walkthrough is a form of quality assurance that is done in a static manner. Walkthroughs are casual gatherings with a purpose.

The following table lists the differences between walkthrough and inspection -

TEST scripts are a line-by-line DESCRIPTION of the system transactions that must be done in order to validate the application or system under test. Each step should be listed in the test script, along with the intended outcomes. This AUTOMATION script enables software testers to thoroughly test each stage on a variety of devices. The actual items to be EXECUTED, as well as the expected results, must be included in the test script.

The following table lists the differences between test case and test script :

Fuzz Testing is a software testing technique that utilizes erroneous, unexpected, or random data as input and then looks for exceptions like crashes and memory leaks. It's a type of automated testing that's used to define system testing techniques that use a randomized or dispersed approach. During fuzz testing, a system or software program may have a variety of data input problems or glitches.

Following are the different phases of Fuzz Testing:

• Identify the Target System: The system or software application that will be tested is identified. The target system is the name given to that system. The testing team determines the target system.
• Identify Inputs: Once the target system is determined, random inputs are generated for testing purposes. The system or software application is tested using these random test scenarios as inputs.
• Generate Fuzzed Data: After receiving unexpected and INVALID inputs, these invalid and unexpected inputs are turned to fuzzed data. Fuzzed data is essentially random data that has been transformed into fuzzy logic.
• Use fuzzed data to RUN the test: The fuzzed data testing process is now being used. Basically, the CODE of the programme or software is EXECUTED in this portion by providing random input, i.e. fuzzed data.
• Monitor System Behavior: After the system or software application has completed its execution, check for any crashes or other anomalies, such as potential memory leaks. The random input is used to test the system's behaviour.
• Log Flaws: In the final phase, defects are detected and rectified in order to produce a higher-quality system or software program.

Following are the different types of bugs detected by fuzz testing:

• FAILURES in assertions and memory leaks - This practice is often employed in large applications where defects compromise memory safety, which is a serious flaw.
• Invalid data - Fuzzers are used in fuzz testing to generate faulty input that is used to test error-handling methods, which is critical for software that does not have control over its input. Simple fuzzing is a technique for automating negative testing.
• Correctness bugs - Some forms of "correctness" flaws can also be detected using fuzzing. For example, a corrupted database, inadequate search results, and so on.

In this case, the interviewer is most interested in learning more about you.

• What types of test STRATEGIES can you conceive of and how do you PLAN to IMPLEMENT them?
• What kind of coverage would you provide in the event of a hotfix?
• How would you test the hotfix after it's been deployed? etc.

If you can relate to the problem, you can use real-life circumstances to answer such questions. You should also explain that you would not be willing to deliver any code to production without proper testing.
When it comes to essential fixes, you should always collaborate with the developer to figure out what AREAS they might affect and set up a non-production environment to test the change. It's also worth noting that you'll continue to MONITOR the fix (using monitoring tools, dashboards, logs, and so on) after it's been deployed to look for any anomalous behaviour in the production environment and ensure that the fix hasn't had any negative consequences.

These questions usually ASK the interviewer to grasp your thinking as a LEADER, as well as what you would COMPROMISE on and whether you would be prepared to produce a flawed product in exchange for less time.
Answers to these questions should be supported by the candidate's actual experiences.

For EXAMPLE, you may say that in the past, you had to make a decision to release a hotfix, but it couldn't be tested since the integration ENVIRONMENT was unavailable. So you rolled it out in stages, starting with a small proportion and then monitoring logs/events before launching the complete rollout, and so on.

These TYPES of questions are open-ended, so you may take the conversation in any direction you desire. You can ALSO highlight your strong talents, knowledge, and technological areas.

You can, for example, use instances of the Automation Strategy you used while constructing a product in a previous capacity to respond to these types of inquiries.

For example, you could say things like,

• Because the product necessitated starting automation from the ground up, you had plenty of time to consider and design an appropriate automation framework, opting for a language/technology that the majority of people were familiar with in order to avoid introducing a new tool and INSTEAD leverage existing knowledge.
• You began by automating the most basic functional scenarios, which were referred to as P1 scenarios (WITHOUT which no release could go through).
• You also considered using automated test tools like JMETER, LoadRunner, and others to test the system's performance and scalability.
• You considered automating the application's security features as outlined in the OWASP Security guidelines.
• For early feedback and other reasons, you included automated tests into the build workflow.

Equivalence Class Partitioning (ECP) is another name for the Equivalence Partitioning Method. It is a software testing technique, OFTEN known as black-box testing, that splits the input DOMAIN into data classes from which test cases can be constructed. An ideal test case identifies a type of error that may necessitate the EXECUTION of a large number of arbitrary test cases before a general error is detected. Equivalence classes are evaluated for given input conditions in equivalence partitioning. When any input is given, the type of input condition is examined, and the Equivalence class defines or explains a COLLECTION of valid or invalid states for this input condition.

• Example 1 - Let's TAKE a look at a typical college admissions procedure. There is a college that admits students depending on their grade point average. Consider a percentage field that will only accept percentages between 50 and 90%; anything higher or lower will result in the program redirecting the visitor to an error page. If the user enters a percentage that is less than 50% or greater than 90%, the equivalence partitioning technique will display an invalid percentage. The equivalence partitioning method will show a valid percentage if the percentage entered is between 50 and 90%.

• Example 2 - Consider the following software application as an example. A software application has a function that accepts only a certain number of numbers, not even larger or fewer than that number. Consider an OTP number with only six digits; anything more or less than six numbers will be rejected, and the application will route the customer or user to an error page. If the user's password is fewer than or equal to six characters, the equivalence partitioning method will display an invalid OTP. The equivalence partitioning technique will display a valid OTP if the password given is precisely six characters.

Risk-based TESTING (RBT) is a method of software testing that is based on risk likelihood. It entails analyzing the risk based on software complexity, business criticality, frequency of USE, and probable Defect areas, among other factors. Risk-based testing prioritizes testing of software programme aspects and functions that are more important and likely to have flaws.

Risk is the occurrence of an unknown event that has a POSITIVE or negative impact on a project's measured success criteria. It could be something that HAPPENED in the past, something that is happening now, or something that will happen in the future. These unforeseen events might have an impact on a project's cost, business, technical, and quality goals.

Risks can be positive or negative. Positive risks are referred to as opportunities, and they AID in the long-term viability of a corporation. Investing in a new project, changing corporate processes, and developing new products are just a few examples.

Negative risks are also known as threats, and strategies to reduce or eliminate them are necessary for project success.

Because this is such a crucial decision, it has never been taken by a single individual or by JUNIOR GUYS. This choice is not made solely by the DEVELOPER and tester; senior management is involved on a regular basis. Management tests primarily ENSURE that product delivery is bug-free by validating the following:

• Validating the bug reports that the tester has submitted. How the bug was fixed and whether or not the tester retested it.
• Validating all of the test cases written by the tester for that specific functionality, as well as the documentation and confirmation received from the tester.
• Run automated test cases to ensure that new features do not interfere with existing features.
• Validating test COVERAGE report, which confirms that all of the developing component's test cases have been written.

• Performance Testing: Performance testing is a sort of software testing that guarantees that software programmes function as expected under certain conditions. It is a method of determining SYSTEM performance in terms of sensitivity, reactivity, and stability when subjected to a specific workload. The practice of examining a product's quality and capability is known as performance testing. It's a means of determining how well a system performs in terms of speed, reliability, and stability under various loads. Perf Testing is another name for performance testing.
• Load Testing: Load testing is a type of performance testing that assesses a system's, software product's, or software application's performance under realistic load situations. Load testing determines how a programme behaves when SEVERAL users use it at the same time. It is the system's responsiveness as assessed under various load conditions. Load testing is done under both NORMAL and excessive load circumstances.

The following table lists the DIFFERENCES between Performance Testing and Load Testing :

Following are some of the software testing tools used in the industry :

• TestRail - TestRail is a web-based test case management system that is scalable and flexible. Our cloud-based/SaaS solution may be set up in minutes, or you can INSTALL your own server on TestRail.

• Testpad - Testpad is a more straightforward and accessible manual testing tool that emphasizes pragmatism over method. It employs checklist-inspired test plans that may be modified to a broad range of approaches, including exploratory testing, the manual side of Agile, syntax-highlighted BDD, and even traditional test case management, rather than handling cases ONE at a time.

• Xray - Xray is a full-featured tool that exists inside Jira and works flawlessly with it. Its mission is to assist businesses in improving the quality of their products through efficient and effective testing.

• Practitest - PractiTest is a complete test management solution. It provides comprehensive visibility into the testing process and a better, broader understanding of testing outcomes by serving as a common meeting ground for all QA stakeholders.

• SpiraTest - SpiraTest is a cutting-edge Test Management solution for both large and small teams. Spiratest allows you to handle requirements, plans, tests, issues, tasks, and code in a unified ENVIRONMENT, fully embracing the agile method of working. SpiraTest is READY to use right out of the box and adapts to your needs, methodology, workflows, and toolchain.

• TestMonitor - Every firm can benefit from TestMonitor's end-to-end test management capabilities. It is a straightforward and intuitive way to test. TestMonitor has you covered WHETHER you're adopting corporate software, need QA, produce a quality app, or just need a helping hand with your test project.

The following table LISTS the differences between alpha testing and BETA testing: