Technical Interview Flashcards
How do you know if it’s a front-end or back-end issue?
Front end issues are usually related to the UX/UI of an app
* Pertain to UI rendering or client-side scripting
* Browser or device specific
* involve client-side code
Back end issues are related to the data or logic of the app
* consistent problems across different environments
* Involve server-side code
What is use case?
*Refers to a description of how users interact with a software system to perform certain tasks
* A format used by BAs for specifying system requirements
* Each use case normally represents completed business operation performed by user
* From QA perspective, we will execute corresponding E2E test to make sure the requirement is implemented
What are uses for use case?
- Requirement analysis
- design
- testing
- validation
Describe a test pyramid
There are three levels, from bottom to top
* Unit testing
* Integration testing - validates the data flow between components
* e2e testing - verifies the functionality and performance of the complete system by simulating real-word user scenarios
This distribution helps achieve a balance between test coverage, execution speed, and maintenance effort.
By focusing on a greater number of lower-level tests, teams can catch most defects early in the development process
Dynamic vs static testing?
Static testing focuses on analyzing software artifacts without executing code, to identify defects early in the development process
* cost effective
* a way to determine the root cause of bugs
* part of verification
Dynamic testing involves executing code to assess its functionality and behavior, to verify it meets specified requirements
* later in dev process
* QA analysts can get a look at how the software performs while running in a real-world situation
* stages:
- unit testing
- integration testing
- system testing
- acceptance testing
* part of validation
Difference between verification and validation
Verification is about confirming that the software is being developed correctly according to requirements and standards
* “Are we building the product right?”
* Focuses on assessing whether the software meets its specified requirements and adheres to predefined standards and guidelines
* involves reviews, walkthroughs, and inspections
Validation is about confirming that the software meets the users’ needs and expectations
* “Are we building the right product?”
* Focuses on whether the software meets the needs and expectations of its users and stakeholders
* involves testing, user feedback, and acceptance testing
What are the test documentation types?
- Test Plan
- Test Strategy
- Test Matrix
- Test checklist
- Test case
What is a test matrix?
- document used to track the relationship between test cases and different aspects of the system under test
- rows represent test cases
- columns can represent dimensions like requirements, functionalities, user stories, platforms, browsers, OS’s, environments, and test types
- helps visualize test coverage, assess completeness, and ensure traceability between test cases and other artifacts such as requirements, user stories, design documents, and defects
Boundary value analysis
- A methodology for designing test cases that concentrate software testing effort on cases near the limit of valid input ranges
- At those points when input values change from valid to invalid errors are more likely to occur
- You test boundaries between partitions
- ex, for -9 to 9:
- -9, -8, 1, 8, 9
Equivalence Partioning
- Input data units are divided into partitions that can be considered the same, called equivalent partitions
- then we pick only value from each partition
- if one value in a partition passes, all others will also pass. vice versa
What will you do if you raise a bug but the dev does not agree it is a bug?
- First, I will recheck business/technical requirements
- If it’s not described in those documents, I would ask the PO/BA/PM
- If I’ve explained to the dev and they still insist, I would escalate it to my manager
Bug severity/priority?
- Both are used to rank how important it is to fix a bug
- Severity relates to the impact of a bug on the software’s functionality
- Priority relates to the urgency of fixing the bug relative to other issues
Example of low severity and high priority bug
*Buttons are slightly out of place when site is accessed on chrome. They can still be clicked easily and do what they are meant to do
* This means that functionality is not affected, hence bug severity is low
* But this doesn’t make for a pleasurable visual representation. Poorly designed websites actively turn off users, therefore bug priority is high
Example of low severity and low priority bug
- lack of uniformity in text, there are some typos, font and color of a page doesn’t match the font and color of the main website
- doesn’t affect functionality
- doesn’t need to be fixed immediately
How do you decide when to stop testing?
PMs or project leads decide based on:
* If deadlines are met
* entering test case pass rate
* risk is below the permitted level
* if all critical bugs and roadblocks have been resolved
* if all the requirements are met
