-
Notifications
You must be signed in to change notification settings - Fork 0
System Test Plan
| Version | Date | Author | Comment |
|---|---|---|---|
| 0.1 | 24.04.2023 | Mohaddeseh Tibashi, Selvana Ayunda | Created and add executing plann |
| 0.2 | 25.04.2023 | Selvana Ayunda | Added Testschedule |
| 0.3 | 17.05.2023 | Selvana Ayunda | Change feature and executing plan |
The AAS Management test plan outlines the strategies, approaches, and methodologies that the QA team will use to verify that the application meets the established requirements of the SRS. It includes testing activities such as unit testing, integration testing, system testing, user acceptance testing, and regression testing, as well as defining the testing environment, tools, resources, and timelines. The test criteria and test cases are based on the SRS requirements to ensure that the application meets the functional and non-functional requirements. The test plan is critical in guiding the testing efforts of the QA team to identify any defects or errors in the application and ensure that it is ready for release.
Application • meets the System Requirement Specification and System Architecture Specification, • satisfies the business purpose • satisfies the testing thresholds laid out in this document
T: Test TC: Test Case QA: Quality Assurance SRS:System Test Report
The testing scope for AAS Management is determined by the functions specified in the System Requirement Specification. This document serves as a guideline for the QA team to ensure that all the required functions are tested thoroughly. The results of the testing activities are documented in the System Test Report, which provides a comprehensive summary of the testing efforts and results. The report serves as a valuable resource for stakeholders to evaluate the quality of the application and determine its readiness for release.
| Req-ID | Functionality | Priority | T ID |
|---|---|---|---|
| AASM-REQ1: Default landing page - GUI Components | browse the package explorer with AAS content, log in to an account, access to a customized package explorer with an extension of more functions and dynamically customized content depending on the user's user group, and logout | A | T001,T002,T003, T004, T005,T006 |
| AASM-REQ2: Identity & Access Management | centralized management of identities and access permissions, with role-based access rights | A | T008,T012,T013, T014 |
| AASM-REQ3: AAS content data management | admin has the possibility to upload and delete AAS content | B | T009,T010 |
| AASM-REQ4: Search functionalities | find desired AAS content using search functions | A | T011 |
| AASM-REQ6: Error Display | Handle and report errors like no entries found, unexpected errors, etc. | A | T003 |
| Allow user to change Server-URL | A | T012 |
The testing strategy for the AAS Management application involves a comprehensive approach that includes manual and automated testing techniques. The testing will begin with unit testing, followed by integration testing, system testing, user acceptance testing, and regression testing. The testing team will work closely with the development team to ensure that any defects or errors are identified and fixed promptly. The testing will be conducted in a controlled environment that mimics the production environment, and the goal is to ensure that the application meets all the established requirements, is free from defects and errors, and is ready for release to end-users.
The System Testing Entrance Criteria for AAS Management consists of a set of prerequisites that need to be fulfilled before the start of the system testing phase. These criteria include the completion of unit and integration testing activities, the availability of a stable build of the application that includes all the required features and functionality, and the approval of the test plan and test cases by relevant stakeholders. Additionally, any necessary test environment setup and configuration must be completed, all required testing resources must be available, and all defect fixes from previous testing phases must be verified. Meeting these criteria is essential to ensure that the system testing phase can proceed effectively and efficiently and helps to avoid delays and additional costs in the testing process.
Test preparation for the AAS Management application involves several steps to ensure that the testing process is effective, efficient, and comprehensive. These steps include:
- Reviewing the System Requirement Specification to identify the scope of testing and requirements that need to be tested.
- Developing a test plan that includes testing objectives, approach, scope, schedule, and resource requirements.
- Identifying and prioritizing test cases based on their relevance, complexity, and impact on the system.
- Preparing test data and test environment to simulate real-world scenarios and ensure accurate and thorough testing.
- Identifying and acquiring necessary testing tools and resources to support the testing process, including automation tools, defect tracking tools, and testing environments.
- Ensuring that the testing team has the necessary skills, expertise, and training to carry out the testing activities effectively.
- Defining and establishing testing metrics to measure the effectiveness and efficiency of the testing process.
- Ensuring that all stakeholders are aware of the testing process, its objectives, and expected outcomes.
By following these steps, the testing team can prepare thoroughly for the testing activities and ensure that the application is thoroughly tested, meets all the requirements, and is ready for release.
Usability testing is an important aspect of testing for the AAS Management application that focuses on the ease of use and user-friendliness of the application. It involves defining the objectives and goals of the usability testing, identifying representative end-users, developing usability testing scenarios, determining the methodology to be used, conducting usability testing sessions, analyzing the results, implementing necessary changes, and repeating the process to validate the effectiveness of the changes made. By conducting usability testing, the testing team can ensure that the application provides an excellent user experience, meets the needs of its end-users, and is user-friendly.
Functional testing is a crucial aspect of testing for the AAS Management application as it ensures that the application's functions are working as intended and meet the specified functional requirements. The testing process involves identifying the functional requirements that need to be tested, developing test cases that cover these requirements, executing the test cases, documenting any issues or defects found, validating defect fixes, and repeating the process until all functional requirements have been tested and validated. By conducting thorough functional testing, the testing team can ensure that the AAS Management application is functioning correctly, meets all the specified requirements, and is ready for release.
Defining Suspension Criteria and Resumption Requirements can improve the efficiency, effectiveness, and organization of the testing process, resulting in higher-quality testing and more reliable testing results.
• Unresolved critical defects that may cause further defects. • Unavailability of necessary testing resources such as hardware, software, or personnel. • Any environmental issues that may affect the accuracy of testing results, such as network or server downtime.
• The resolution of all critical defects identified during the testing process. • Availability of necessary testing resources. • Confirmation that the environmental issues that caused the suspension have been resolved. • Retesting previously failed test cases to ensure that they pass after the suspension.
• User profiles • Transactions • System configuration • Security permissions
• User profiles will be created using realistic demographic information and academic history. • Transactions will be created manually by the testing team to ensure all scenarios are covered. • System configurations will be set up according to the specified requirements in the System Requirement Specification. • Security permissions will be set up for different user roles such as guest, advance, and administrators.
• All test data will be stored in a secure location with limited access to authorized personnel. • The test data will be updated as needed to ensure that it remains relevant to the testing activities being performed. • A tracking system will be used to keep track of all test data and ensure that it is being used correctly during testing.
| Testcase ID | T001 |
|---|---|
| TC Name | User login for advanced |
| Req-ID | AASM-REQ1 |
| Description | This test cases verifies that user can log in with correct Email and Password |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Open Website | https://jotec2002.github.io/TINF21C_AAS_Management/ | Website is open |
| 2 | Click on log in button | the pop-up window appears | |
| 3 | Enter valid e-mail address and password. | email: [email protected] password: advanced | type login data in text fields |
| 4 | Click on the "Login" button. | login successfully, email adress as dropdown with log out appears |
| Testcase ID | T002 |
|---|---|
| TC Name | User login for admin |
| Req-ID | AASM-REQ1 |
| Description | This test cases verifies that user can log in with correct Email and Password |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Open Website | https://jotec2002.github.io/TINF21C_AAS_Management/ | Website is open |
| 2 | Click on log in button | the pop-up window appears | |
| 3 | Enter valid e-mail address and password. | email: [email protected] password: admin | type login data in text fields |
| 4 | Click on the "Login" button. | login successfully,User Management , Add Asset , and email adress as dropdown with logout appear on navbar |
| Testcase ID | T003 |
|---|---|
| TC Name | User login for invalid access |
| Req-ID | AASM-REQ6 |
| Description | This test cases verifies that user with invalid acess can't log in |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Open Website | https://jotec2002.github.io/TINF21C_AAS_Management/ | Website is open |
| 2 | Click on log in button | the pop-up window appears | |
| 3 | Enter valid e-mail address and password. | email: [email protected] password: ss | type login data in text fields |
| 4 | Click on the "Login" button. | error massage with login failed show |
| Testcase | ID | T004 |
|---|---|---|
| TC Name | User logout | |
| Req-ID | AASM-REQ1 | |
| Precondition | User is already logged in | |
| Description | This test cases verifies that user can log out successfully |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on dropdown email | logout button shows | |
| 2 | Click on log out button | email on navbar will be deseppear |
| Testcase | ID | T005 |
|---|---|---|
| TC Name | Asset and their Submodels | |
| Req-ID | AASM-REQ1 | |
| Precondition | user is on homepage | |
| Description | This test cases verifies that basic-user has only limited submodels |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on Asset | AAS_WEISS_HN400607 | Show Nametamplate and TechnicalData on rightside |
| Testcase | ID | T006 |
|---|---|---|
| TC Name | Asset and their Submodels | |
| Req-ID | AASM-REQ1 | |
| Precondition | user is on homepage and login as advanced | |
| Description | This test cases verifies advanced has more submodels as basic |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on AAS_WEISS_HN400607 (Asset) | Show more than Nametamplate and TechnicalData on rightside |
| Testcase | ID | T007 |
|---|---|---|
| TC Name | Asset and their Submodels | |
| Req-ID | AASM-REQ1 | |
| Precondition | user is on homepage and login as admin | |
| Description | This test cases verifies admin has more submodels as basic |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on AAS_WEISS_HN400607 (Asset) | Show more than Nametamplate and TechnicalData on rightside |
| Testcase ID | T008 |
|---|---|
| TC Name | Change Role |
| Req-ID | AASM-REQ2 |
| Precondition | The user is already logged in as admin |
| Description | The admin wants to use admin dashboard to change role of the other user |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on User Management | Admin Dashboard appears | |
| 2 | Click on edit icon on advanced | Popup Edit appears | |
| 3 | Enter new admin password and choose new role | password: admin, role:admin | |
| 4 | Click on submit edited account | advaced has role as admin |
| Testcase ID | T009 |
|---|---|
| TC Name | Delete Delete Asset |
| Req-ID | AASM-REQ3 |
| Precondition | User is already as admin logged in on Admin Dashboard |
| Description | This test cases verifies that admin can delete the AAS Content successfully |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on AAS_WEISS_HN400607 (Asset) | Submodels appears on rightside | |
| 2 | Click delete button | delete dialog appear | |
| 3 | Click delete button | Asset will be deleted, redirect to homepage |
| Testcase ID | T010 |
|---|---|
| TC Name | Add AAS content |
| Req-ID | AASM-REQ3 |
| Precondition | User is already as admin logged in on Admin Dashboard |
| Description | This test cases verifies that admin can add the AAS Content successfully |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on Add Asset in Navigationbar | Addasset page appear | |
| 2 | Choose file .assx | file:https://demo-digital-twin.r-stahl.com/ids/asset/123456789 choose:RStahl_220381_123456789_Instance.aasx | file information appear |
| 3 | Enter AAS-ID | AAS-ID: https://demo-digital-twin.r-stahl.com/ids/asset/123456789 | Alert to say that the asset is added |
| Testcase ID | T011 |
|---|---|
| TC Name | Search function |
| Req-ID | AASM-REQ4 |
| Precondition | User is on homepage |
| Description | This test cases verifies that user can find specific asset |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Enter name of specific asset | serach: AAS_WEISS_HN400607 | just AAS_WEISS_HN400607 on Assetbar appears |
| Testcase ID | T012 |
|---|---|
| TC Name | Change Server |
| Req-ID | |
| Precondition | User is on homepage |
| Description | This test cases verifies that user can change URL-Server |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Enter new URL-Server | URL-Server:https://ccae4836-001e-48c2-a4f9-235554f9400b.ma.bw-cloud-instance.org/ | URL-Server in placeholder |
| 2 | Click enter button on your keyboard or click on change button on Navigationbar | Assets will be change |
| Testcase ID | T013 |
|---|---|
| TC Name | Create new user |
| Req-ID | AASM-REQ2 |
| Precondition | User is login as admin and is already on Admin dashboard |
| Description | This test cases verifies that admin can add new user |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on Create account button | Pop-Up Create Account appears | |
| 2 | Enter new user access | Username:[email protected] Password: advanced Role: advanced | Enter user access |
| 3 | Click on Submit new account | new user will be appear |
| Testcase ID | T014 |
|---|---|
| TC Name | Delete user |
| Req-ID | AASM-REQ2 |
| Precondition | User is login as admin and is already on Admin dashboard |
| Description | This test cases verifies that admin can delete user |
| Step | Action | Data | Expected result |
|---|---|---|---|
| 1 | Click on delete icon | user:[email protected] | Pop-Up Delete appears |
| 2 | Click on delete | User doesn't exist anymore |
GitHub Issues will be to keep trackinng of any of failed tests.
Defects will be reported by the System Test Manager to the Front End Development Team and Back End Development Team directly via arbitrary communication channel.
Defects discovered by testing will be fixed by the respective development team, status reports are delivered in the regularly scheduled meetings.
used to categorize the severity of defects discovered during testing. In the context of the AAS Management application, defects are classified into three categories: critical, medium, and low.
Critical defects are those that cause catastrophic or severe errors, resulting in major problems and rendering the functionality unavailable to the user. Examples of critical defects include system abends, data corruption, and the inability to post data to the database. Remedying a critical defect may require a high level of effort or the implementation of a complex manual procedure.
Medium defects, on the other hand, do not significantly impair system functionality and can be categorized as medium severity. Examples of medium defects include incorrect form navigation and inconsistent field labels with global terminology. Remedying a medium defect may require a medium level of effort or the implementation of a less complex manual procedure.
Low defects are those that have little to no impact on system functionality and are considered cosmetic. Examples of low defects include repositioning fields on screens and incorrect text font on reports. Remedying a low defect may require a low level of effort or the implementation of a straightforward manual procedure.
By using these severity definitions, the testing team can prioritize defect remediation and ensure that critical defects are addressed first to prevent major problems and ensure the application's functionality is available to the user.
The testing approach for the AAS Management application involves cloning the most recent version of the code from the git repository and running it in a suitable program environment. Front-end testing will be conducted by loading the application in various browsers and testing its functionality with various inputs. The results of the testing will be documented in the System Test Report.
The AAS Management system testing is scheduled for one week, from May 8, 2023 to May 12, 2023. The System Test Manager will conduct all tests during the first week, while retesting of defects will occur on the last day of system testing. The dates for defect retesting may be modified as necessary to ensure that all defects are retested and closed. While it is ideal to close all defects, it is not necessary as long as the defects are not critical. The primary objective is to minimize the number of open defects.