Resolutions of all Apple products

QA's should always have the resolution list by-heart as it would be helpful when asked either in meeting about a resolution of the device or during scrums. It's kinda easy to remember it if your remember the base resolution and apple devices are limited when you compare to Android. I know that some people would be "A google search would let you know the resolution of the device", but I feel this would be useful when you go for an interview too.

iPhone	Resolution
iPhone 1	320*480
iPhone 3G
iPhone 3GS
iPhone 4	640*960
iPhone 4S
iPhone 5	640*1136
iPhone 5s
iPhone 5c
iPhone Se
iPhone 6	750*1334
iPhone 6s
iPhone 7
iPhone 8
iPhone 6s Plus	1080*1920
iPhone 7 Plus
iPhone 8 Plus
iPhone X	1125*2436
iPhone Xr	828*1792
iPhone Xs Max	1242*2688

Important testing questions which can be asked during interviews

I have listed few of the manual interview questions which can be asked for fresher to mid level QA's.

1. Explain Stub?
- Stub is a substitute for actual code when top down integration is conducted.

2. What do you mean by a driver?
- Driver is a substitute for actual code when bottom down integration is conducted.

3. Explain Big Bang Integration?
- When all the modules are integrated together then it is called as Big Bang Integration.

4. Explain Retesting and Regression testing?
- Retesting is a type of testing which is carried out to test the defect which was found in the previous build and to verify if the defect is fixed.
- Regression testing is a type of testing which is carried out to test the whole module in which the defect was fixed i.e. all the test cases of the module are run along with the defect fixed to check if the defect which was fixed has affected any other functionality.

5. Explain Smoke and sanity testing?
- Smoke testing is a type of testing which is carried out to check if the major functionality of the application is working as per the spec. A smoke test plan checklist is run to check if the build can be further tested.
- Sanity testing is type of testing which is carried out to check if all the functionality are working fine after minor fix of defect is conducted or when moving to a new environment.

6. Explain the difference between Latent and Masked defect?
- Latent defect is a defect which is found in the current release but the defect was introduced in the previous releases.
- When a defect is hiding another defect then the hidden defect is called as Masked defect.

Explain STLC

STLC stands for Software Testing Life Cycle. STLC is a process which is executed in a sequence in order to reach quality goals. STLC has different phase as SDLC. Following are the phases of STLC

1. Requirement gathering and analysis
2. Test Planning
3. Test Case Development
4. Test Environment Setup
5. Test Execution
6. Test Closure

Abbreviations for Mobile Applicaiton Tester

Abbreviations which are required to be kept in mind while giving interview for Mobile application testing

iPa - iPhone Application Archive

apk - Android application package

exe - Executable file

adb - Android Debug Bridge

CMMI - Capability Maturity Model Integrated

QA - Quality Assurance

QC - Quality Control

STLC - Software Testing Life Cycle

SDLC - Software Development Life Cycle

Risk Management in Software Testing with example

Software company should always have a risk management done so that there will be smooth release of the product. Risk management is divided into 3 main parts.

1. Risk Identification
2. Risk Impact Analysis
3. Risk Mitigation

Risk Identification
Risk identification will be the first step of risk management where the QA manager or the QA lead would identify all the risk which could be involved in the project which would impact the project plan

Examples of Risk Identification

- Non availability of test environment or logistics
- Critical defects found during the release state
- Non availability of testing resources
- Requirement or design changes
- Natural calamity
- Understand of technologies

Risk Impact Analysis
QA manager has to prioritize the risk based on the probability of occurrence and impact due to the risk. Taking the same example of risk identification we can prioritize the impact as shown below

- Non availability of test environment or logistics  - Probability Low, Impact High
- Critical defects found during the release state - Probability Medium, Impact High
- Non availability of testing resources - Probability Low, Impact Medium
- Requirement or design changes - Probability Low, Impact High
- Natural calamity - Probability Low, Impact Medium
- Understand of technology  - Probability Medium, Impact High

Risk Impact can be shown in percentages or scale from 1-10

Risk Mitigation
QA manager should be having solutions to every risk that may occur. Solution needs to be practical and should be always be in a state of executing the solutions in a way it is mentioned i,e, Risk mitigation should not give false promises

- Non availability of test environment or logistics - Have a quick meeting with the customer and get him/her to provide a list of devices and test environment which would be their highest priority for the release
- Critical defects found during the release state - If a critical defect is found during the release state then have an experienced working developer and a Qa to just work on the defect and have it regressed quickly as possible
- Non availability of testing resources - If a Qa gets sick or if he leaves the company then have a back up Qa from start of the project where he will be briefed with the project requirements and his involvement will be less than 10%
- Requirement or design changes - Customer has to be formally informed that no changes will be entertained without pushing the release dates and if there is any changes then it would be taken as a Change Request with efforts breakdown
- Natural calamity - A backup resource would be provided in another location and will be assigned with the task if any Natural calamity occurs.
- Understand of technology - Training will be provide and a team which has already released a similar project will help before the project reaches the first alpha.

Adhco testing in Software testing

Adhoc testing is a type of black box testing which is carried out without following any formal process i.e without SRS, Test plan or test cases. Adhoc testing is normally done once the formal test cases are run and testing is completed formally. There are 2 types of Adhoc testing

1. Paired Testing
2. Monkey Testing

Paired testing is type of adhoc testing where two qc's are assigned to test the same project and the goal of the qc's is to find maximum number of defect such that the test coverage is complete. Once the testing is completed both the qc are required to share their observation. Sometimes a qc is paired with the developer to perform adhoc testing which is proved to be a best adhoc type of testing as the developer will also be able to understand how a qc thinks out of the box. But normally it is not advisable if the project is working under scrum.

Monkey testing is done by performing unusual scenarios in order to break the code. Example: Continuously tapping on button, performing immediate sequence, adding inappropriate data as a value.