Test Traceability Matrix - bounswe/bounswe2023group2 GitHub Wiki
https://hackmd.io/EETRdpTDRfO_L9ksT907jw
| Req ID | Requirement | Unit Tests |
|---|---|---|
| 1.1.1.1.1 | Users shall be able to create an account using a valid and unique email address or phone number, a unique username, their name, their surname and a password. | test_signup1() test_signup2() test_signup3() test_signup4() test_signup5() test_signup6() test_signup7() test_signup8() |
| 1.1.1.2.1 | Users shall be able to log into their account using their email, username or phone number; and password combination. | test_login1() test_login2() test_login3() test_login4() test_get_me() test_get_username() test_get_username2() test_get_username3() |
| 1.1.1.2.2 | Users shall be able to reset their password via email verification or sms verification. | |
| 1.1.1.3.1 | Users shall be able to log out of their accounts. | |
| 1.1.2.1.1 | Guest users shall be able to create only one emergency. | |
| 1.1.2.1.2 | Guest users shall be able to view emergencies and activities about disasters, including event types, resources available, and actions taken. | test_get_resource() test_get_all_resources() test_get_nonexistent_resource() |
| 1.1.2.1.3 | Guest users shall be able to filter and sort activities about emergencies, events, resources, actions, and needs based on location, date, type etc. | |
| 1.1.2.2.1 | Authenticated users shall have all functionalities that guest users have. | |
| 1.1.2.2.2 | Authenticated users shall create activities. | test_create_resource_missing_fields() |
| 1.1.2.2.3 | Authenticated users shall be able to update and delete their current active activities. | test_update_resource() test_update_nonexistent_resource() test_delete_nonexistent_resource() |
| 1.1.2.2.4 | Authenticated users shall verify their accounts by verifying their phone numbers or emails unless already verified by system admins. | |
| 1.1.2.2.5 | Authenticated users shall be able to delete their accounts. | |
| 1.1.2.2.6 | Authenticated users shall be able to edit their profiles. | test_update_user() |
| 1.1.2.2.7 | Authenticated users shall be able to confirm or reject other users' activities. | |
| 1.1.2.2.8 | Authenticated users shall be able to report malicious users or activities to the admins. | |
| 1.1.2.2.9 | Authenticated users should be able to receive notifications about certain topics based on location, date, type etc. | |
| 1.1.2.2.10 | Authenticated users shall be able to search activities and emergencies. | |
| 1.1.2.2.11 | Authenticated users shall be able to search profiles. | |
| 1.1.2.2.12 | Users should be able to subscribe to topics using filter and search on topics. | |
| 1.1.2.2.13 | Authenticated users should be able to add and delete topics for notifications. | |
| 1.1.2.2.16 | If users have not added their phone number or email address to their profile, they shall be able to do so. | |
| 1.1.2.2.17 | Authenticated users shall be able to choose a role after adding a valid phone number. | |
| 1.1.2.2.18 | Authenticated users shall be able to select who can see their contact information. | |
| 1.1.2.2.19 | Authenticated users shall be able to upvote/downvote an action or event to upgrade its reliability scale. | |
| 1.1.2.3.1 | Role-Based users shall have all functionalities that authenticated users have. | |
| 1.1.2.3.2 | Role-Based users shall be able to search for activities that are related to their proficiency. | |
| 1.1.2.3.3 | Role-Based users shall be able to contact people who state their needs are related to Role-Based user proficiency. | |
| 1.1.2.3.4 | Role-Based Users shall be able to add information about their proficiency and how they can help. | test_proficiency_request1() test_proficiency_request2() |
| 1.1.2.4.1 | Credible users shall have all functionalities that role-based users have. | |
| 1.1.2.4.2 | Credible user shall be able to create a special activity which is prioritized on lists and maps. | |
| 1.1.3.1 | Admin users shall be able to create actions, such as relieving needs, sending rescue teams, etc... | |
| 1.1.3.2 | Admin users shall be able to search users and see the contact information of other users. | |
| 1.1.3.3 | Admin users shall be able to view the misinformation reports. | |
| 1.1.3.4 | Admin users shall be able to accept or reject a misinformation report. When the misinformation report is accepted, the event will be removed. | |
| 1.1.3.5 | Admin users shall be able to remove activities from the platform. | |
| 1.1.3.6 | Admin users shall be able to see authenticated and verified users' activities. | |
| 1.1.3.7 | Admin users shall be able to cancel verified users' verification or authenticated user's authentication. Once admin users cancel verification/authentication, they shall not be able to be verified or authenticated again. | |
| 1.1.3.8 | Admin users shall be able to see and recover canceled verification or authentication. | |
| 1.1.3.9 | Admin users shall be able to select or approve users as credible users. | |
| 1.1.3.10 | Admin users shall be able to cancel credible users' credibility. | |
| 1.1.3.11 | Admin users shall be able to pin some activities at the top to increase their visibility. | |
| 1.2.1.1 | A user profile shall have these attributes: Name and surname (required), Email, Phone (at least one is required), Date of birth (optional), Nationality (optional), ID number (optional), Education (optional), Condition of health (optional), etc. | |
| 1.2.1.2 | The system should show related actions, needs, resources and events to the authenticated user that has related proficiency. | |
| 1.2.2.1 | The system shall allow users to report malicious users and activities. | |
| 1.2.2.2 | The system shall allow users to check for a number of other users' upvotes or downvotes about activities. | |
| 1.2.2.3 | The system shall carry on reports to the administration system. | |
| 1.2.2.4 | The system shall not accept the restricted accounts to register again. | |
| 1.2.3.1.1.1 | A resource shall have these attributes: Type, Subtype, Location, Quantity, username, creation time, last update time, status, number of approvals and rejections, reliability scale. | |
| 1.2.3.1.1.2 | A resource should have attributes: different resources should have additional attributes if needed, available at certain times, extra information, related needs (optional). | |
| 1.2.3.1.2.1 | Resources should be organized in a structured manner to allow for easy access and management. | |
| 1.2.3.1.2.2 | The following predefined resources shall be included: food, clothing, accommodation, and human resources. | |
| 1.2.3.2.1.1 | Events shall have these attributes: Type, Creation time, Creator username, Location, Interaction rate, Related needs, Confirmer username, Last confirmation time, Approval and Rejection number, Reliability scale. | |
| 1.2.3.2.2 | The following predefined event types shall be included: Road Blocked Event, With Live Human Collapsed Event, Power Cut, On-Fire Event, Building Tent City Event. | |
| 1.2.3.3.1.1 | Actions shall have these attributes: Type, Creation time, Creator username, Interaction rate, Related resources, needs and events, Confirmer username, Last confirmation time, Approval and Rejection number, Reliability scale, Current status. | |
| 1.2.3.3.2.1 | Actions should be created with the following attributes: Start location, End location. | |
| 1.2.3.4.1.1 | Needs shall have these attributes: Type, Subtype, Creation time, Creator/Demander username, Location, Quantity, Urgency, Approval and Rejection number, Reliability scale, Current status. | |
| 1.2.3.6.1.1 | Emergencies shall have these attributes: Type, Location, Contact Name, Contact Number, Notes, Is Active, Is verified, Number of Upvotes, Number of Downvotes, Creation time, Creator username, Dealt by username, Dealt at time, etc. | |
| 1.2.4.1 | The system shall sort activities based on location, reliability scale, date, emergency level etc. | |
| 1.2.4.2 | The system shall sort emergencies based on location, reliability scale, date, emergency level etc. | |
| 1.2.4.3 | The system shall sort users based on their roles and locations. | |
| 1.2.5.1 | Maps shall contain some annotation on them. Annotations shall have different colours based on the emergency level. | |
| 1.2.5.2 | The map shall be zoomed in and out and interactable. The annotations in the map should scale up and down accordingly. | |
| 1.2.5.3 | The user’s location shall appear on the map so that users are able to understand what’s happening around them | |
| 1.2.5.4 | The map shall show the locations that are filtered. | |
| 1.2.6.1 | The system shall use the W3C Geolocation API standard for implementing location-related information. | |
| 1.2.6.2 | The system shall provide all kinds of search functionality for models. | |
| 1.2.6.3 | Users should retrieve results that are semantically similar to their queries. | |
| 1.2.6.4 | Users should be able to annotate different models, and annotations should comply with W3C Web Annotation Data Model. | |
| 1.2.7.1 | The system shall create in-app and push notifications. | |
| 1.2.7.2 | The system should create notifications, if users click the “want to be notified” button on the activity. | |
| 1.2.7.3 | The system should create notifications if users' profession might be implying that they can be a resource to a certain need. | |
| 1.2.7.4 | The system should create notifications if an event takes place near users' addresses when they provide their addresses. | |
| 1.2.8.1 | The system shall collect users' reports about other users in the admin dashboard. | |
| 1.2.8.2 | The system shall collect users' reports about activities and events in the admin dashboard. | |
| 1.2.8.3 | The system shall sort the reports according to the number of reports. | |
| 1.2.8.4 | The system shall hold a list of restricted users and their phone numbers. | |
| 1.2.8.5 | The system shall track the restricted users by their phone number in order to prevent new signs up. | |
| 1.2.8.6 | The system shall hold the admins' logs. | |
| 1.2.9.1 | The system shall support remember me feature. | |
| 1.2.9.2 | The system shall support keep me logged in feature. |