Continuing the previous articles in my series, I added few more great questions that relevant for the “Theoretical” side if testing.
Please pay attention that memorizes my answers is NOT the right way to work in the testing industry, my goal is to help you to understand the basic questions that you may be asked during a job interview with a short explanation regarding the appropriate answer.
Q1: Explain code “debugging”?
Operations that made by the software engineer, to locate a defect that found, analyze the cause, and provide a valid solution.
Q2: Explain test environment?
When you are testing or using a software, you need to run it on supported architecture (Mobile phones, Specific Hardware Etc.). The testing environment, is the architecture that supported by the software and used by the testing team to validate the compatibility of the software against it.
Level 1: The Hardware layer.
Level 2: The operating system layer.
Level 3: Any relevant software that needed to run the application (Drivers, web Browsers, Flash Player Etc.)
Level 4: Preparing the communication architecture (open ports, trusted sites, DNS configurations Etc.).
Level 5: The software installation (Client, link Etc).
Q3: What are the basic steps of Risk Management?
Step 1: Identifying the risks
Step 1: Identifying the risks
- Resources related risks
- Customers related risks
- Timelines related risks
- Business related risks
- Testing related risks
Step 2: Risk Analysis
- Understand the ROI for removing this risk (deadlines, Resources, performance etc.)
- Understand the impact on the project/software/business etc.?
- Understand the potential for occurrence (Probability).
- Understand the reasons that creates this risk?
- Understand the impact after fixing this risk?
Step 4: build a plan to handle the risk
Deadlines - the declines boundaries are critical for each project, you must be familiar with those boundaries to manage the project timelines and resources.
Step 5: Removing the risk
Step 6: track the changes
Q4: Explain software “Risk”?
Software risk is the probability/potential for occurrence of uncertain and undesirable outcomes (any result that fails to meet the expected behavior) when using the software, by definition, Risk is more “Potential” based, then true “Fact” (there is a potential for a problem although it can never happen).
Analyze the risks is far from being an easy task, why? Because risk is a “Potential” for something to happen, this issue creates “uncertainty” about the future, as such, the “uncertainty” factor can impact the way we get out decisions and in both desirable and undesirable ways.
Additional Points to take into consideration:
- The most important fact to remember, we cannot test everything, therefore we should understand that the software is not free from bugs and the risks are there.
- When “Risk” has high potential to occur, we must fix it before release.
- Risks are relevant to every aspect of the SDLC process (Business, customer, timelines regulations, technology etc.).
- When releasing a software we want to make sure that all the areas that covered are free from potential risks.
- Sometimes, we can publish the software with known risk (Sometimes the ROI to fix them doesn’t allow it).
- The higher the potential of uncertain behavior is, the more we desire to remove this risk.
Q5: What kind of customer inputs, can help you to design a better testing process?
Testing Data - in most cases, you will not get the customer data, but if you can, you can use it as testing inputs on a dedicated test case. Those inputs will help the testing team build a proper test plan that covers the main use cases of the client.
Requirements - it’s basic, what are the requirements for the software? What expectations must be fulfilled? How the software interface should look like?
The Client Environment - yet again, understanding the client environment challenges, will help the testing team to simulate and reduce the risks.
Acceptance tests - a list with all tests that must be approved for the acceptance test are pure gold for you, if you understand them, you can make sure that stupid failures will be excluded from this type of tests.
Q6: Explain “Static” testing
Static testing is a decisive part of the verification process, this kind of tests performed without executing the software code, in static testing, we want to verify the project requirements, specifications and all other reevaluated documentation that may affect the software design.
Q7: Explain “Dynamic” testing
All tests that involve code execution, this type of tests includes Inputs and Expected outputs that approve or decline the behavior of the tested functionality.
Q8: Explain “Regression” testing?
Regression tests, are usually performed to verify that a tested and working functionality/non-functionality does not affected by different changes that affect the software after the 1st stage of testing is done.
Examples of software changes:
- New supported architectures
- Changed requirements.
- Merge back/forward.
- New features.
- Bug Fixes.
Regression tests, should be designed by humans and executed, but auto tools, you need to remember that all tests under regression are already tested and verified on previous testing cycles, all you need to do, is to see is that the same test cases are not affected by the new changes.
Q9: Explain “Accessibility” testing?
There are many people that have special needs (Blind/mentally disabled Etc.), accessibility testing will verify that the tested software is suitable and accessible to use.
Q10: Explain “Retest” testing?
Retesting is a testing method that used to re-run the same test case after a software bug have been fixed by the engineering team. In such case, the tester should make a bug “Verification” that’s made by rerun the test case to verify that the bug is fixed properly.