---
# System prepended metadata

title: MyGrowth Testing Notes

---

# MyGrowth Testing Notes
:::spoiler **INDEX**
[TOC]
:::
### What is Quality?
Quality means, whatever system we are talking about like a pen used for writing, or a smartphone, or a car, or software application, it has to meet the specifications

### System Testing
Series of different tests whose purpose is to excercise the full computer based system. It include a set of activities conducted with intent of finding errors in software so that it could be corrected before the product is released to end users

#### What verify in system testing
1. The fully integrated application including external peripherals in order to check how components interact with one another and with the system as a whole. Also known as "End to end scenario testing".
2. Verify every input in the application to check for desired outputs.
3. Testing of the users experience with the application.

#### Types of system testing
More than 50 types of system testing. Types a software development company would typically use are:
- Usability testing
- Stress testing
- Regression testing
- Functional testing

The specific types used by a tester depend on several variables. Those include: 
- Who the tester works for
- Time available for testing
- Resources available to the tester
- Software tester's education
- Testing budget

---

### Levels of Testing
There are four stages of testing that need to be completed before a program or an application can be cleared for use
![](https://i.imgur.com/gJBZqWC.png)

1. Unit Testing: Micro level of testing. It involves testing individual modules or units to make sure they're working properly. It isolates the smallest piece of the testable software and determines if or no behaves exactly as intended. A unit test can be annything, a functionality, a particular procedure, a function, etc.
2. Integration Testing: This level tells how the units work together. Individual modules are combined and tested as a group and see how do they perform together
3. System Testing: All the components of the software are tested as a whole in order to ensure that overall product meets the requirements specified. Verifies technical, functional and business requirements of a software. Combination of automation testing and manual testing techniques
4. Acceptance Testing: UAT. It determines whether or not the software is ready to release to market. It's important that the tester verifies the business needs are met before the software is released into production

>Each level of testing have their purpose and they provide value to SDLC

---

### Integration Testing
In this phase of testing, individual modules are combined and tested as a group to verify they work as expected. That is to test the modules which are working correctly does not have any issues when integrated. Data transfer between the modules is tested throughly. Is carried up by testers. The main aim of this testing is to recognize the interface between the modules, not the modules but the connection or communication between them. 
Some of the advantages of Integration Testing are:
- Ensures modules work together properly
- Helps to uncover error which are related to interfaces
- Very helpful when there are frequent requirement changes
- Typically covers large volume of the system with a single test so it's efficient
- Ensures that newly added components are not affected
- Writing both unit and integration testing increases the test coverage at faster speed and it improves the reliability of the software

Integration testing does not happen at the end of the SDLC, it's conducted simultaneously with the development, so in most of the times all the modules are not available to test. For that scenarios when you don't have all the modules ready for testing, we have **stubs** and **drivers**. Dummy programs that replace a module with the same functionalities of the original one but not all the core functionalities. Stubs are called "Called Program" and Drivers are called "Calling program".

#### Integration Testing Approaches:
- Top Down approach (TDA): Higher level modules are tested first and gradually moving down to the lowest set of modules one by one. Testing takes place from top to bottom, following the control flow or architectural structure. This technique will require creation of "Stubs" by accepting the parameters received by the module and giving acceptable results. Generally stubs have hard-coded input and output that helps in testing the other modules
    **Pros:**
    - Extremely consistent
    - Less time required
    - Fault localization is easier
    - Detects major flaws
    
    **Cons:**
    - Requires several stubs
    - Poor support for early release
    - Basic functionality is tested at the end of the cycle
- Bottom Up approach (BUA): Opposite of TDA. Lower level modules are tested first and gradually moving up one by one. Testing takes place from the bottom of the control flow upwards. This technique will require creation of "Drivers". 
    **Pros:**
    - Efficient application
    - Less time requirements
    - Test conditions are easier to create
    
    **Cons:**
    - Requires several drivers
    - Data flow is tested late
    - Poor support for early release
    - Key interface defects are detected late
- Big-Bang testing: All components or modules are integrated simultaneously, after which everything is tested as a whole. Involves the entire set of integrated modules together being tested at once. This approach is quite challenging and risky because when you combine all the modules and test them at once if there are any error, it's difficult to find out the reason since all the modules are combined.
    **Pros:**
    - All components tested at once
    - Convenient for small systems
    - Saves testing time
    
    **Cons:**
    - Lot of delay before testing. Have to wait for all modules to be developed
    - Difficult to trace root cause of bugs
    - Possibility of few missing interface links
    - Critical modules are not prioritized
    - Increases project execution time

**Sandwich Integration Approach - Hybrid Approach:** To exploit the advantages of each of these approaches, there's a mixture of two approaches, TDA and BUA. Very useful for large enterprises and huge projects that further have several sub projects. Consists in defining layers and use different approaches for each one.
**Pros:**
- Layers can be tested in parallel
    
**Cons:**
- High cost, big skill set, extensive testing is not done
    
> The choice of approach chosen depends on the system architecture and location of high risk modules

#### Integration Testing Process
1. Choose the module or component to be tested
2. Decide the type of integration testing: Before you proceed you have to make sure that each of these modules which are selected is unit tested already.
3. Deploy the selected modules and start testing: Make initial fixes that are required to get started with integration
4. Perform functional and structural testing: Test all use cases for the components chosen
5. Record, analyse and report the results
6. Repeat above steps until system is fully tested: For example, you combined two modules, test them and if everything is proper you combine a third module and do the same thing again and again.

#### Steps to kick of integration testing and make it simpler and less complex:
- Focus on architecture of application
- Identify each module (Prioritize critical modules)
- Check the how data is communicated
- Understand user requirements
- Create multiple test conditions
- Focus on one test condition at a time 

---

### Acceptance testing
QA process that determines to what degree an application meets end users approval. Ensure the software or app matches business requirements and end-user needs. An acceptance test returns either pass or fail result. A fail suggests that tere is a flaw present and the software should not go into production.

Acceptance testing enables an organization to engage end-users in the testing process and gather their feedback to relay to developers. The feedback helps testers identify flaws that might have missed during development stage tests, such as unit and functional testing. 
Additionally, it helps developers understan business needs and ensure the software or application meets compliance guidelines.

#### Process
Acceptance testing occurs after system tests, but before deployment. Testers set them up to examine how the softwore acts in a simulated production environment. Include the following phases: 
- Plan
- Test
- Record
- Compare
- Result

#### Types of acceptance testing 
Acceptance testing encompasses various types, including user acceptance and operational acceptance. 

User Acceptance Testing (UAT), also called end-user testing, assesses if the software operates as expected by the target base of users. Users could mean internal employees or customers of a business, depending on the project

Operational Acceptance Testing reviews how a software product works. Examines backups and disaster recovery, as well as maintainability, failover and security.

<img src="https://cdn.ttgtmedia.com/rms/onlineimages/software_quality-how_qa_differs_from_uat_desktop.png"/>

---

### The Role of the Tester in an Agile Software Development Lyfe Cycle (SDLC)
#### Traditional Waterfall Method vs Agile Method
In Waterfall method, there's different stages where the product is passed all the way through the stages and testing is done **at the end** after a 6 month period or longer time.
What Agile did is basically took the same stages that has to be done in all SDLC and broke them out in small iterations so it becomes more like a collaborative piece which also involve testing and is not done by a single person, everyone is on that.

#### Now that everyone in the company is taking part of testing, what role take the tester, is still valuable?
Yes, testers are still very valuable in every SDLC because:
- Testers are the voice of the customer: They are putting themselves on the customer facing hat and acting as a user.
- Testers add focus: In agile the testers are giving feedback rapidly so the developers can keep on trails of what they are doing.
- Testers facilitate early clarification of software expectations: Based on prior experience in testing, they can bring about any expectations, risks, issues that could occur with a User Story or feature in development
- Testers are always testing: Testers always have their mind on testing, being nitpicky, thinking about things that are not necessarily in the "happy path" flow, things that could break the system.
- Testers help find bugs early and fix them fast: With iterations, testers can find bugs early rathet than at the end of the waterfall where you can have lots of bugs being produced out to the end user
- Testers ensure that regression testing is a continuous process

---

### Agile Estimation
#### Story Points
In agile estimation, we use something called Story Points. Is an abstract unit of time, for a particular team or person, a Story Point might be half an hour, an hour, a day or maybe a week. The idea of Story Points is to take us away from thinking in absolute time estimates and start doing our estimates relatively.

##### Process
Let's imagine that we've got a stack of story cards in the backlog. What we do is to find one of the story cards that we think is going to be the quickest to do and then we'll find a second card that's going to be one of the longest card to complete for us. Finally, we apply story point scores to them. 
Once we've established points for the quickest and the longest story, we position the rest of them proportionately on that scale so all the estimates are made relative to each other.
**Which number we chose to point our stories?**
We use the **Fibonacci Sequence** which each number is the sum of the two preceding ones. We use that sequence for estimate because we tend to be more accurate using it.

Story points give us an estimate of how long work will take to do that story. But there's another type of estimation which is Value Points. They tell us how important it is that we do a particular task, which is very important because in agile we want to deliver value early. So both estimates are important to have some measure of value and some measure of time.
There's a different between them. Story points are estimated for people who is going to do that work or taks, let's say developers. In other hand, value points because they're saying how worthwhile a particular story is, they are estimated by a customer.
The process to estimate with value point is the same.

The reason we do estimation in agile is primarily to work out what we are going to do next because we are trying to deliver value early. So it's really important that when we are going to do our next iteration we have some way of gauging which stories should do next in that iteration.