Description
***REMINDER! You must submit the peer review on YOUR OWN GROUP by the last day of class. This could affect your final grades. I trust everyone has been working hard and contributing!***
Unformatted Attachment Preview
https://github.com/jacobtlin/My-Repository.git0
hindsITe
Phase III
CMSC 495 – 6381
Development Team
Vincent Testagrossa,
Dakota Owen,
Roba Shifare,
Kasey Scott
Instructor
Prof. Shanna Nevarez
1
Table of Contents
PHASE III – HONING…………………………………………………..2
DELIVERABLES ………………………………………………………..2
MILESTONES …………………………………………………………2
HIGH-LEVEL REVIEW……………………………………………………2
INPUT VALIDATION …………………………………………………….2
COHERENT DESIGN ……………………………………………………..3
COMMUNICATION ……………………………………………………….3
TESTING DATA………………………………………………………..3
PAGE NAVIGATION ……………………………………………………..3
REGISTRATION ………………………………………………………..4
LOGIN …………………………………………………………….5
LOGOUT …………………………………………………………….6
GROUP CREATION ………………………………………………………6
PROOFS……………………………………………………………..8
FACILITATOR VIEW …………………………………………………….8
USER VIEW ………………………………………………………….8
SETTINGS PAGE ……………………………………………………….8
REGISTRATION INPUT VALIDATION ……………………………………………8
FINAL THOUGHTS………………………………………………………8
2
Phase III – Honing
The hindsITe project continues to grow within specifications. Last week we were informed of a few bugs
that required fixing as they got in the way of the appropriate workflow we intended for the applicaiton.
For Phase III the overall goal was minimum functionality for the boards, fields and cards. By this point we
wanted to have the app be in a somewhat usable state for establishing the use of cards, as it is a core
operation.
Deliverables
The website for the application is accessible here: https://hindsite-dev.up.railway.app/
The GitHub, and source code, can be accessed here: https://github.com/Bilgecrank/hindsite
Milestones
The outline for this week was focused on bug-fixes and establishing the functionality for users to be able
to create boards, fields and cards attached to their groups. The following are some of the goals we
achieved:
1. Corrected validation errors in regards to user and group creation.
2. Fully mapped relationship objects in the back-end database.
3. Enabled the user to change their information in the beta Settings page.
The functionality for user created boards, fields, and cards wasn’t completed, but a mockup was created
using test data and they should be fairly quick to turn into a fully functional feature.
High-Level Review
The level of complexity in this application continues to be a satisfying challenge for our skills, but is less
condusive to week-by-week deadlines. A multi-module application is a completely different beast to the
single module applications we were trained to write python in. After development slowed in Phase II, we
found that in Phase III it was easier to improve on design once fully understood the underlying
framework and overarching inheritanace. However, we still run into issues of communication, which is
proving to be the primary difficulty in managing a large-scale project like this.
Input Validation
One ofthe primary issues with the Phase II release was that input validation wasn’t properly baked into
the design of hindsITe. For the first time, we understood why these issues plague software development.
When a programmer is pushing for a deadline with a feature, security become secondary in achieving
3
the deadline. To reflect this, besides bug-fixing, we have been working at including input validation and
greater security into our design.
Coherent Design
With the implementation issues of Phase II out of the way, it became easier to revisit older versions of
design, and improve them in order to bring them to proper standards. Relationship models in the
database became fully modeled, HTMx design was being implemented more thoroughly and each aspect
included was being integrated with a more professional degree of quality.
Communication
Coordination tools are valuable in establishing a combined understanding of what the goals in a project.
This GitHub provided the best flexibility in keeping members abreast of any new issues that arose,
allowing the group to handle problems as they arose. However, consistent communication on other
platforms has been difficult, as they may be less purpose-driven. We have found that as we approach the
end of the semester, communications has become more important as deadlines come close for other
obligations.
Testing Data
Enclosed is our testing model for the application.
Page Navigation
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
Pass/
Fail
1.1
Verify all links are
clickable
Click on various
links across the
website.
Links should
navigate to
intended pages.
All links are
clickable and
navigate to the
intended pages.
Pass
1.2
Test direct URL
access
Attempt to access
pages directly using
URLs not obtained
through normal
navigation.
Access should be
denied if not
permitted.
Direct URL access is
denied for
unauthorized
pages.
Pass
1.3
Cross-browser
compatibility
Test website
functionality on
Website should
function
Website functions
consistently across
Pass
4
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
different browsers
(Chrome, Firefox,
Edge).
consistently across
browsers.
Chrome, Firefox,
and Edge.
Pass/
Fail
Registration
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
Pass/
Fail
2.1
Verify required
fields
Check registration
form for required
fields (email,
password).
All required fields
should be present.
All required fields
(email, password)
are present in the
registration form.
Pass
2.2
Test data entry
Attempt to enter
valid and invalid
data in each field.
Valid data should
be accepted, invalid
data should be
rejected with
appropriate error
messages.
Valid data is
accepted, and
invalid data is
rejected with
appropriate error
messages.
Pass
2.3
Successful
registration
Complete
registration form
with valid data and
submit.
User should be
registered
successfully and
receive
confirmation.
User is successfully
registered and
receives
confirmation email.
Pass
2.4
Password strength
Test password
requirements
(minimum length,
character types).
System should
enforce password
strength
requirements.
System enforces
password strength
requirements (e.g.,
minimum length,
character types).
Pass
2.5
Unique email
Attempt to register System should
System prevents
with an already
prevent registration registration with
used email address.
duplicate email and
Pass
5
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
with duplicate
email.
provides
appropriate error
message.
Pass/
Fail
2.6
Required field
check
Submit form
without filling all
required fields.
System should
prevent submission
and highlight
missing fields.
System prevents
submission and
highlights missing
required fields.
Pass
2.7
Account creation
Verify account
creation after
successful
registration.
User should be able User can access
to access their
their account after
account.
successful
registration.
Pass
Login
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
3.1
Verify login form
Check login form
for required fields
(email/username,
password).
All required fields
should be present.
All required fields
(email/username,
password) are
present in the login
form.
Pass
3.2
Valid credentials
Login with valid
email/username
and password.
User should be
logged in
successfully.
User is logged in
successfully with
valid credentials.
Pass
3.3
Invalid credentials
Login with invalid
email/username or
password.
System should deny
access with
appropriate error
message.
System denies
access with
appropriate error
message for invalid
credentials.
Pass
Pass/
Fail
6
Logout
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
Pass/
Fail
4.1
Logout button
availability
Verify presence of a Logout button
Logout button is
logout button.
should be available. available.
Pass
4.2
Successful logout
Click the logout
button.
User should be
logged out
successfully.
User is logged out
successfully upon
clicking the logout
button.
Pass
4.3
Access after logout
Attempt to access
private pages after
logging out.
Access should be
denied.
Access to private
pages is denied
after logging out.
Pass
Group Creation
Test
Case
ID
Objective
Steps
Expected Result
Actual Result
Pass/
Fail
5.1
Access group
creation page
Verify access to the
group creation
page.
Page should be
accessible to
authorized users.
Group creation
Pass
page is accessible
to authorized users.
5.2
Data entry
Attempt to enter
valid and invalid
data in required
fields.
Valid data should
be accepted, invalid
data should be
rejected with
appropriate error
messages.
Valid data is
accepted, and
invalid data is
rejected with
appropriate error
messages.
Pass
5.3
Confirmation
message
Check for
confirmation
message before
creating a group.
System should
display a
confirmation
message.
System displays a
confirmation
message before
creating a group.
Pass
7
Test
Case
ID
5.4
Objective
Successful group
creation
Steps
Expected Result
Actual Result
Create a group with Group should be
Group is created
valid data and
created successfully successfully with
submit.
with confirmation
confirmation
feedback.
feedback.
Pass/
Fail
Pass
8
Proofs
We have included some screenshots to show some at-the-time functionality
Facilitator View
9
User View
10
Settings Page
11
Registration Input Validation
Final Thoughts
With only a week to go in development, there’s a lot of work to be done to get the application to the
way we originally envisioned it. However, with the layout of Facilitator and the User mode, there are only
a few more steps to take in solidifying the presentation of the front-end and ensuring the availability of
the back-end. The backbone of our application is there, and from here the functionality can only
improve.
It’s smooth sailing from here.
Purchase answer to see full
attachment
