Below is a diagram that captures a typical test estimation process:

Two of the most commonly used test estimation techniques are:

• Metric-based approach – this involves estimating the testing effort based on metrics of former or similar projects or based on typical values
• Expert-based approach – this involves estimating the tasks based on estimates made by the owner of the tasks or by experts.

Entry Criteria

Entry criteria is a set of conditions or requirements, which are required to be fulfilled or achieved to start a testing actviity.

Some of possible criteria are:

1. Complete or partially testable code is available
2. Requirements are defined and approved
3. Availability of sufficient and desired test data
4. Test cases are developed and ready
5. Test environment has been set up and all other necessary resources such as tools and devices are available

Exit Criteria

Exit criteria defines the conditions and requirements that are required to be achieved or fulfilled before a testing activity would be considered to be complete.

The commonly considered exit criteria are:

1. Deadlines meet or budget used up.
2. Execution of all test cases.
3. Desired and sufficient coverage of the requirements and functionalities under the test.
4. All the identified defects are corrected and closed.
5. No high priority or severity or critical bug has been left out.

Suspension criteria

Suspension criteria specifies when to suspend/stop all or portion of the testing activity as it provides no further value when testing is continued.

Some examples of this criteria include:

1. Lacking the availability of external dependent components/systems during execution
2. Defect is found and logged which blocks or prevents further testing execution. So suspension of testing process could happen until this defect is resolved.
3. When there is a predefined number of open defects (of certain severity). So testing could be paused until some sort of action/decision has been made.

There are number of test metrics that could be used to assess the quality of test execution for a project i.e. effectiveness of the testing team.

The two most important ones could be:

1. Defect leakage ratio – this refers to the number of defects that have been undetected during the project (SDLC) and ended up in production. These could be due to number of issues such as poor environment, functional testing coverage, missing or incorrect requirements.

The ratio can be determined with the following formula:
PD / (TD – RD) * 100
PD = Total number of defects found in production
TD = Total number of defects found during testing
RD = Total number of rejected/invalid/cancelled defects

• Defect rejection ratio

Defect rejection ratio refers to the number of defects that were raised that have been rejected divided by the total number of defects raised.
There are 3 main categories/types of rejected bugs: irreproducible, incorrect and duplicate bugs.

Ratio is formulated as follows:
(Defects Rejected as invalid by Development team / Total number of defects logged) * 100

Ideally, the test manager or test lead will be responsible however one of the members of the QA team may also be asked to write up the test plan document.

Below are 8 activities that are involved in the process of creating a test plan document:

1. Product and requirements analysis – this is where you try to read and understand the business requirements document, ask any questions if there are any uncertainties, and also try to be more familiar with the functionalities of the system/product.
2. Develop test strategy – this activity involves:
   • Determining what is in-scope and out-of-scope of testing
   • Determining the types of testing/test techniques to apply i.e. which functional and non-functional tests should be performed
   • Identifying any project or product risks and potential ways to mitigate them
   • Figuring out who should be carrying out tests or the type of tester that needs to be involved and when should they be starting to run tests
3. Determine test objectives – Test objective is the overall goal of the test execution. This activity involves identifying all the testable features of the system (functional, performance and so on) and target or end result of those listed features
4. Determining test criteria– Simply put, this involves agreeing/determining on entry (when to start test cycle), suspension (when to pause/hold off on test cycle) and exit criteria (when to complete test cycle)
5. Resource planning – This involves listing/identifying all the resources that are required for successful completion of the project. These resources include human resources, as well as software and hardware resources.
6. Define/plan test environment – This involves planning the number of environments that need to be created/set up, their configurations as well as what software/packages need to be installed on those environments.
7. Estimation and scheduling – This is where the test manager determines the project schedule. Testing process will be broken into smaller tasks and their efforts will be estimated. The estimations will be based on number of factors including the project deadline, availability of team members (in days/hours), estimation of the project and also any contingencies that needs to be accounted for.
8. Determining test deliverables – This is where the test manager determines what the outcomes of the testing are i.e. test deliverables. Usually, this is divided into 3 phases:
   • Before testing – Test plan document, test specification document, and test cases
   • During testing – Test scripts, Test traceability matrix and test data
   • After testing – Test report, bug report and release notes

API documentation is essentially a user instructions/help guidebook for an API. It tells consumers how to use the API, what the API does, expected input, expected output, relevant status codes and how to resolve errors should they occur.

Good API documentation is crucial because:

• People will find it easier to use the API, leading to better growth and adoption
• Better product maintenance
• Less time and spent on supporting new users of the API

Application Programming Interfaces (APIs) are interfaces that allow communications between different systems or layers of an application.

Applications often have 3 layers: a data layer (database), service layer (API/business logic), and presentation (UI) layer.

This means that testing APIs indirectly help with testing both data and presentation layers.

API testing is divided into 2 categories:

1. Component test (Endpoint test) – this involves testing a single endpoint directly
2. Integration test (Workflow test) – this involves testing multiple endpoints in order to test end-to-end scenarios.

There are 2 ways to verify that API is working as expected:

1. Verifying status code – By checking the status code returned from invoking API, tester will be able to determine whether the test was successful or not. There are 5 categories/groups of status codes. Successful status code is in the 2XX status code group. 4XX status group indicates that there was an error in the request and 5XX status group indicates that there was a server issue and was unable to process the request.
   
2. Verifying the value – This means inspecting and verifying the response returned from the API invocation for a particular value or the entire response itself.

There can be situations where testers are forced to perofrm testing with no or less requirements.
Here are some of the possible solutions to such cases where it is lacking or missing documentations:

• By talking to relevant groups of people that may have more understanding of how the system/application works or should behave
• Error guessing testing technique could be used by the tester who is experienced with the system under test
• Exploratory testing could be carried out to learn more about the system. This would be usually time-boxed.

Risk is used to focus the effort required during testing. It is used to decide where and when to start testing and to idetnfiy areas that need more attention. This approach to testing provides proactive opportunities to reduce the levels of product risk. It involves product risk analysis to:

• Determine which types of testing to be performed
• Determine how much testing to carry out
• Prioritize testing to find the critical defects asearly as possible

Test execution schedule takes into account factors such as prioritization, dependencies, confirmation tests, regression tests, and the most efficient sequence for executing the tests.
Confirmation and regression tests take priority and those tests with dependencies would need to have their dependencies tested first. Then followed by test cases with higher priorities.

1. Managing good and healthy relationship with developers could be challenging. Some developers may become quickly defensive when testers are explaining defects/bugs.
2. Testing under time constraint as often developers quickly become the bottleneck of the project.
3. No or lack of/missing documentation could potentially make testing very difficult and time consuming as testers would need to scavenge through whatever documents available and talk to various groups of people to understand applications/requirements better to continue testing.