The purpose of the Iteration Test Plan is to gather all of the information necessary to plan and control the test effort for a given iteration. It describes the approach to testing the software. This Test Plan for Betterzon supports the following objectives:

Identifies the items that should be targeted by the tests.
Identifies the motivation for and ideas behind the test areas to be covered.
Outlines the testing approach that will be used.
Identifies the required resources and provides an estimate of the test efforts.

1.2 Scope

We will mainly focus on functionality and usability tests.

1.3 Intended Audience

This test plan is intended to help everyone that either wants to use our code and / or tests by giving a clearer structure about our testing strategies.

1.4 Document Terminology and Acronyms

Abbr	Abbreviation
API	Application Programmable Interface
CI	Continuous Integration
CD	Continuous Delivery/Deployment
n/a	not applicable
SRS	Software Requirements Specification
SAD	Software Architecture Document
tbd	to be determined
UI	User Interface
VC	Version Control
TDD	Test Driven Development

1.5 References

Title	Date	Publishing organization
Blog	Oct. 2020	Betterzon
GitHub Repository	Oct. 2020	Betterzon
Wiki with Use Cases	Oct. 2020	Betterzon
SRS	Oct. 2020	Betterzon
SAD	Oct. 2020	Betterzon

2. Evaluation Mission and Test Motivation

The tests will mainly be written to ensure that any changes in the future don't break the application. As part of the tests will also be run as a part of our CI/CD system, any changes that cause a test to fail will not get merged until the issue is fixed.

2.1 Background

Testing serves to ensure that the written code does what it is intended to do. It also prevents future code changes to break existing functionality unnoticed. In the context of integration it can also prevent broken software states to be merged into secured VC branches.

2.2 Evaluation Mission

find as many bugs as possible
find important problems
advise about product quality
avoid merging breaking changes

2.3 Test Motivators

The main test motivators are quality and technical risks as we want to make sure that every version that gets deployed to production is working and as bug-free as possible.

3. Target Test Items

The listing below identifies those test items software, hardware, and supporting product elements that have been identified as targets for testing. This list represents what items will be tested.

As we don't have the infrastructure to perform hardware and operating system tests, our tests will focus on the code we write

4. Outline of Planned Tests

4.1 Outline of Test Inclusions

Frontend: Angular:

UI testing of views/fragments
Unit testing

Backend: Node / Express:

API testing

The tests themself will not be tested and will not account into code coverage.

4.2 Outline of Other Candidates for Potential Inclusion

N/A

4.3 Outline of Test Exclusions

The crawler will not be tested as the effort to testing it properly would not be in proportion to the problems arising from a not-properly-working crawler at this point of the project
Hardware and operating systems will not be tested as we don't have the infrastructure to do this

5. Test Approach

5.1 Initial Test-Idea Catalogs and Other Reference Sources

N/A

5.2 Testing Techniques and Types

5.2.1 Data and Database Integrity Testing

	Description
Technique Objective	Every endpoint should be accessible and return the correct data if the correct input parameters are supplied
Technique	The endpoints are accessed via postman and the answers from the server are checked for correctness
Oracles	The HTTP status code and the body type of the response are checked
Required Tools	Postman
Success Criteria	All endpoints return the expected data
Special Considerations	N/A

5.2.2 Functional Testing

	Description
Technique Objective	Every logic function and component in the frontend should be working and creatable
Technique	Jasmine tests are run in a Karma test suite
Oracles	The creation of components and the outcome of functions are tested
Required Tools	Jasmine, Karma
Success Criteria	Components are created successfully, methods return correct values
Special Considerations	N/A

5.2.3 Business Cycle Testing

N/A

5.2.4 User Interface Testing

	Description
Technique Objective	Every tested page should be accessible and all expected elements should be visible
Technique	The endpoints are accessed via postman and the answers from the server are checked for correctness
Oracles	The required fields and values of these fields are tested
Required Tools	Java, Cucumber, Selenium
Success Criteria	All fields and values are correct
Special Considerations	N/A

5.2.5 Performance Profiling

N/A

5.2.6 Load Testing

N/A

5.2.7 Stress Testing

N/A

5.2.8 Volume Testing

N/A

5.2.9 Security and Access Control Testing

N/A

5.2.10 Failover and Recovery Testing

N/A

5.2.11 Configuration Testing

N/A

5.2.12 Installation Testing

N/A

6. Entry and Exit Criteria

6.1 Test Plan

6.1.1 Test Plan Entry Criteria

N/A

6.1.2 Test Plan Exit Criteria

N/A

6.1.3 Suspension and Resumption Criteria

N/A

6.2 Test Cycles

6.2.1 Test Cycle Entry Criteria

N/A

6.2.2 Test Cycle Exit Criteria

N/A

6.2.3 Test Cycle Abnormal Termination

N/A

7. Deliverables

7.1 Test Evaluation Summaries

N/A

7.2 Reporting on Test Coverage

Karma creates a detailed code coverage report every time the frontend is tested. It provides overall coverage which is also reflected in our GitHub README as well as detailed coverage per file.

7.3 Perceived Quality Reports

N/A

7.4 Incident Logs and Change Requests

Incidents and Change Requests are handled via our project management tool YouTrack.

7.5 Smoke Test Suite and Supporting Test Scripts

N/A

7.6 Additional Work Products

N/A

7.6.1 Detailed Test Results

N/A

7.6.2 Additional Automated Functional Test Scripts

API Tests
Unit Tests are part of every frontend component
Functional Tests

7.6.3 Test Guidelines

N/A

7.6.4 Traceability Matrices

N/A

8. Testing Workflow

Tests should be written and (if required) adjusted alongside the development.

9. Environmental Needs

N/A

9.1 Base System Hardware

The following table sets forth the system resources for the test effort presented in this Test Plan.

Resource	Quantity	Name and Type
Database Server	1
- Network or Subnet		N/A
- Server Name		mariaDB
- Database Name		Betterzon
Client Test PCs	1
- Include special configuration requirements		N/A
Test Repository	0
- Network or Subnet		N/A
- Server Name		N/A
Test Development PCs	0

9.2 Base Software Elements in the Test Environment

The following base software elements are required in the test environment for this Test Plan.

Software Element Name	Type and Other Notes
IntelliJ	Test Runner / IDE
Jasime / Karma	Unit testing library
Cucumber	human readable test definitions

9.3 Productivity and Support Tools

The following tools will be employed to support the test process for this Test Plan.

Tool Category or Type	Tool Brand Name	Vendor or In-house	Version
Test Management	Karma.js	Open-Source	6.3.2
ASQ Tool for functional testing	Cucumber	Open-Source	6.10.3
Test Coverage Monitor or Profiler	Karma.js	Open-Source	6.3.2
Project Management	YouTrack	JetBrains	N/A
DBMS tools	mariaDB	mariaDB foundation	10.5.9

9.4 Test Environment Configurations

N/A

10. Responsibilities, Staffing, and Training Needs

10.1 People and Roles

N/A

10.2 Staffing and Training Needs

N/A

11. Iteration Milestones

We want to keep over 75% code coverage.

12. Risks, Dependencies, Assumptions, and Constraints

N/A

13. Management Process and Procedures

N/A

Test Plan

Table of contents

1. Introduction

1.1 Purpose