Reference no: EM133680795

Build dynamic websites

Assessment Project

Introduction/summary the website:

discussion on the objective or purpose of the system
a high level of a system overview of key functionality and constraints (business, technically or both; even external)
Objective or Purpose of the System:

The system, named "We Are Stars," aims to create a talent management platform. Its primary objective is to connect talented individuals with casting professionals globally.

The platform operates as a member-based subscription service, providing a curated directory of diverse talents, from acting to influencing.
System Overview:

The system overview includes key features such as member subscriptions, talent portfolios, and global connections with casting professionals.
Constraints could involve technical limitations, business rules, or external factors affecting the platform's operation.

The functionality of the website including:
The key functional requirements

The key non-functional requirements
i. Key Functional Requirements:

Talent Submission Forms: Users can submit their profiles, including details like name, age, skills, etc.
Member Subscriptions: Options for subscription plans (six months, one year, lifetime) with associated costs.
Talent Tagging to Projects: CEO tags potential talents to different projects and titles.
Blog Publication: Communication Manager publishes regular blogs and news on the website.
Message Handling: The "Contact Us" form allows users to send messages.
ii. Key Non-functional Requirements:

Performance: Ensuring efficient Response Time, Throughput, Utilization, and Static Volumetric measures.
Scalability: The website should handle a growing number of users and data.
Availability: Ensuring the platform is accessible 24/7.
Security: Adherence to cybersecurity procedures and protocols.
Usability: User-friendly interface and accessibility.
Interoperability: Compatibility with various browsers and devices.
Technical architecture requirements

specific detail about the technical environment in which the software will operate. Including but not necessarily limited to compatible operating systems
identify all elements of the development environment including versions of software
identify the database to be used including version
outline at least one (1) technical standard that will be adhered to and why it is relevant to this website.
I. Technical Environment:
The software will operate in a Linux environment for web servers.
II. Development Environment:
HTML5, CSS3, JavaScript, PHP (v7.4), Apache (v2.4), MySQL (v8.0).
These versions ensure compatibility and support for modern web development.
III. Database:
MySQL (v8.0) will be used as the database to store user profiles and related data.
IV. Technical Standard:
Adherence to the OWASP standards ensures the security of the web application against common vulnerabilities.

User interface design which must include:

a site map or hierarchy of navigation (with breadcrumbs); explanation of how this addresses at least two (2) relevant accessibility issues
detail about a suitable folder structure (both logical and physical)
prototype/mock-up screens for the proposed system accompanied by text description that details how the design addresses business requirements and design principles.

I. Site Map:
Home > Talent Submissions > Subscriptions > Blog > Contact Us.
Breadcrumbs help in easy navigation and address accessibility concerns.
II. Folder Structure:
Logical: assets, css, js.
Physical: /var/www/html/assets, /var/www/html/css, /var/www/html/js.
Ensures an organized structure for web assets.

III. Prototype Screens:
Mock-ups for talent submission forms, subscription pages, and blog sections, designed to meet business requirements and design principles.

Data storage requirements.

I. an estimate of the data storage requirements for the system and reasoning for this estimate.
I. Estimate:

500 MB for initial data storage.
Reasoning:

Based on the expected number of talent profiles and associated data, an estimate is made to ensure sufficient storage capacity.

A conceptual database design (ERD) including key relationships, if any
i. Any assumptions made to complete this task must be clearly stated in a separate document, titled ‘Project Assumptions'.
I. Assumptions:

Relationships between tables (e.g., Talent, Subscriptions) are assumed based on common database design principles.

Data required to support the process (data attributes) identified and objects or repositories with which these are associated.
Tables details:

Talent Table: talent_id, name, age, etc.
Subscriptions Table: subscription_id, duration, cost, etc.
Identifying key data attributes for each table to support various processes.

Assessment Project 2

1. Website development:
Submit the website developed to meet all the requirements outlined in the scenario as detailed in the document produced in Assessment Task. The website must meet the following criteria:

General features:
the database must be implemented as per the design, any variation from the design must be detailed including reasons for the change.
configuration file or equivalent file must be used and must contain all database, connection and possibly session information that will need to be used for the new site
Functional requirements implementation:
CRUD functionality must be supported
user inputs must be sanitised in both GETs and POSTS
bind values to parameters with prepared statements
fetched data using query or execute. With query, escape user data seen
all empty form fields and errors communicating with the database must be handled by the web application
provide all key features detailed in the Business Requirements Document.
a. General Features:
I. The Database Implementation:
Explanation: The database structure and operations should align with the initially designed plan. If any deviations occur, they need to be documented with clear reasons for the changes.
Example: If the initial plan was to use a relational database, and during development, a NoSQL database was chosen instead, provide the reasons for this change.
II. Configuration File:
Explanation: A configuration file (or an equivalent mechanism) must store essential information like database details, connection parameters, and possibly session-related information for the website.
Example: In a PHP project, this could be a config.php file containing database connection details and other global settings.
b. Functional Requirements Implementation:
I. CRUD Functionality:
Explanation: The website must support CRUD operations (Create, Read, Update, Delete) as outlined in the business requirements.
Example: If the website involves managing user profiles, ensure there are functionalities to add new users, view user details, update user information, and delete user accounts.
II. User Inputs Sanitization:
Explanation: Any data received from users, whether through GET or POST requests, should be sanitized to prevent security vulnerabilities such as SQL injection or cross-site scripting.
Example: If a user submits a form with potentially harmful data, the system should filter or escape special characters.
III. Bind Values with Prepared Statements:
Explanation: Prepared statements should be used to bind values to parameters, enhancing security by preventing SQL injection attacks.
Example: When executing an SQL query, use parameterized queries to bind user inputs securely.
IV. Fetched Data using Query or Execute:
Explanation: Data retrieval should follow secure methods, such as using query or execute functions depending on the database technology used.
Example: In PHP PDO, fetching data using $stmt->fetch() after preparing and executing a statement.
V. Handling Empty Form Fields and Database Errors:
Explanation: The web application should gracefully handle situations where form fields are empty or errors occur during communication with the database.
Example: If a user submits a form with missing required fields, the system should provide clear error messages.
VI. Provide All Key Features from Business Requirements Document:
Explanation: Ensure that all features specified in the Business Requirements Document are implemented and functional.
Example: If the business requirement includes a user authentication system, ensure that users can register, log in, and access secured sections.

2. Testing documentation
Submit a document as evidence that appropriate tests have been run for the website. The document must contain the following detail:

an overview of the testing process to be undertaken
specific tests that address all features detailed in the Business Requirements Report including:
at least three (3) of the security requirements being addressed at the application level
test results for all planned tests including a minimum of ten relevant screen captures, the screen captures must include:

at least one (1) image of an error message being captured and handled by the site
evidence the website was tested in a minimum of three (3) major browsers
if errors/issues were identified; the following must be provided for each:

a description of troubleshooting performed
an explanation of cause of the error/issue
a resolution

1. Overview of Testing Process:
Explanation:
The testing process involved a systematic approach to ensure the website's functionalities were thoroughly examined. It encompassed various stages, including unit testing for individual components, integration testing to evaluate interactions between modules, and system testing to assess the overall system behavior. Both manual and automated testing methodologies were employed to achieve a balanced and comprehensive test coverage.

Example:
For unit testing, individual functions like user registration and database connectivity were isolated and tested independently. Integration testing ensured that these components worked seamlessly together. System testing involved end-to-end testing of the entire website to validate user flows and business processes.

2. Specific Tests Addressing Business Requirements:
Explanation:
Tests were designed to validate that each business requirement, as outlined in the Business Requirements Report, was implemented accurately. This included CRUD functionality, user input validation, parameter binding with prepared statements, and adherence to the key features specified in the report.

Example:
For CRUD functionality, tests covered creating, reading, updating, and deleting records in the database. User input validation tests ensured that the system properly sanitized inputs to prevent security vulnerabilities. Parameter binding and prepared statements were tested to confirm protection against SQL injection attacks.

3. Test Results with Screen Captures:
i. Image of an Error Message Being Captured and Handled:
Explanation:
A screenshot was captured illustrating an error scenario, such as submitting a form with incomplete data. The image demonstrated how the website effectively identified and communicated the error to the user.

Example:
A user attempting to submit a registration form without entering mandatory fields resulted in a clear error message displayed on the screen, guiding the user on the required actions.

ii. Evidence of Testing in Three Major Browsers:
Explanation:
Screenshots were provided to showcase the website's consistent behavior across different browsers, ensuring a positive user experience regardless of the chosen browser.

Example:
Screenshots depicted the website's appearance and functionality in Google Chrome, Mozilla Firefox, and Microsoft Edge. This confirmed that users accessing the website from various browsers would have a uniform experience.

4. Error/Issue Identification and Resolution:
iii. Description of Troubleshooting Performed:
Explanation:
When issues were identified, a detailed troubleshooting process was initiated. This involved replicating the problem, reviewing relevant code sections, and debugging to pinpoint the root cause.

Example:
If a form submission error occurred, steps involved replicating the scenario, examining server logs, and isolating the section of the code responsible for handling form submissions.

iv. Explanation of the Cause:
Explanation:
Once the issue's root cause was identified, an explanation was provided detailing whether it was related to code logic, database connectivity, or other factors.

Example:
If a registration error occurred, the explanation clarified whether it was due to a validation rule not being met or a failure in connecting to the database.

v. Resolution:
Explanation:
After understanding the cause, a resolution plan was executed. This could involve modifying code, adjusting configurations, or implementing other corrective measures.

Example:
If the issue was related to a code bug, the resolution section detailed the specific code changes made to rectify the problem. It also outlined any adjustments made to the database or configurations.

3. Sign-off document
Provide a Project Signoff Sheet with appropriate detail to identify the version of the software and enable
acceptance of the completed website, as tested
Purpose:
The Sign-off Document serves as an official acknowledgment and acceptance of the completed website, confirming that it has undergone thorough testing and meets the specified requirements outlined in the project.
Components of the Sign-off Document:
i. Project Information:
Explanation: Identifies key project details, including the project name, client, and project manager. This provides context for the sign-off.

Example: "Project Name: Dynamic Website Development for Memos Tonight"
ii. Version Information:
Explanation: Clearly specifies the version of the software being signed off. This is crucial for version control and tracking changes over the project's lifecycle.

Example: "Version: 1.0"

iii. Completion Criteria:
Explanation: Clearly outlines the criteria that must be met for the project to be considered complete. This often includes meeting all functional requirements, successful testing outcomes, and resolution of identified issues.

Example: "Completion Criteria: All functional requirements from the Business Requirements Report have been implemented, tested, and met. Testing documentation demonstrates the successful execution of tests, including security measures."

iv. Acceptance of Completed Website:
Explanation: Provides a section for stakeholders to officially accept the completed website. Signatories acknowledge that the delivered product aligns with their expectations.

Example:

"We, the undersigned, hereby accept the completed website as outlined in the project specifications."
"Client Representative: ________________________ Date: ____________"
"Project Manager: _____________________________ Date: ____________"
v. Testing Summary:
Explanation: Summarizes the testing process, highlighting key achievements, successful tests, and any outstanding issues. This provides a snapshot of the project's testing phase.

Example:

"Testing Summary: The website underwent rigorous testing, addressing all features outlined in the Business Requirements Report. A total of 30 tests were conducted, with 28 passing successfully. Two minor issues have been identified and documented for future resolution."
vi. Outstanding Issues:
Explanation: Lists any issues or concerns that were identified during testing but remain unresolved. This ensures transparency about the current state of the project.

Example:

"Outstanding Issues: Two minor issues related to form validation have been identified. While these do not hinder the overall functionality of the website, they will be addressed in future updates."
vii. Next Steps:
Explanation: Outlines any recommended or planned next steps following the sign-off. This may include future updates, maintenance plans, or additional features.

Example:

"Next Steps: With the completion of this phase, we recommend scheduling regular maintenance checks and considering future enhancements based on user feedback."
viii. Comments/Notes:
Explanation: Provides space for additional comments, notes, or observations from stakeholders or the project team.

Example:

"Comments: We appreciate the hard work and dedication of the development team. The website aligns well with our expectations, and we look forward to its official launch."

Assessment Part 2

Functionality:
Links

Objective is to check for all the links in the website.

All Internal Links

All External Links

All mail to links

Check for orphan Pages

Check for Broken Links

Forms

Test for the integrity of submission of all forms.

All Field Level Checks

All Field Level Validations.

Functionality of Create, Modify, Delete & View.

Handling of Wrong inputs (Both client & Server)

Default Values if any

Optional versus Mandatory fields.

Cookies

Check for the cookies that have to be enabled and how it has to be expired.

Web Indexing

Depending on how the site is designed using Meta tags, frames, HTML syntax, dynamically created pages, passwords or different languages, our site will be searchable in different ways.

Meta Tags

Frames

HTML syntax.

1.5 Database

Two types of errors that may occur in Web applications:

Data Integrity:

Missing or wrong data in the table.

Output Error:

Errors in writing, editing or reading operations in the tables.

The issue is to test the functionality of the database, not the content and the focus here is therefore on output errors. Verify that queries, writing, retrieving or editing in the database are performed correctly.

Functionality Testing
1.1 Links
1.1.1 All Internal Links
Objective: Ensure that internal links correctly navigate users within the website.
Test Steps:
Click on each internal link on the website.
Confirm that the user is directed to the expected pages.
Address any discrepancies or broken links.
1.1.2 All External Links
Objective: Verify that external links lead to the intended external sources.
Test Steps:
Click on each external link.
Confirm redirection to the specified external websites.
Address any broken or incorrect external links.
1.1.3 All Mail-to Links
Objective: Confirm that mail-to links open the default email client with the correct recipient.
Test Steps:
Click on each mail-to link.
Ensure the default email client opens with the correct recipient's email address.
Address any issues with mail-to links.
1.1.4 Check for Orphan Pages
Objective: Identify pages that are not linked to from other pages on the site.
Test Steps:
Review the site structure and navigation.
Identify any pages not accessible through links.
Address orphan pages by providing appropriate links.
1.1.5 Check for Broken Links
Objective: Identify and fix any broken links within the website.
Test Steps:
Use link-checking tools to scan the website for broken links.
Verify the tool's findings manually.
Address and rectify any broken links.
1.2 Forms
1.2.1 All Field Level Checks
Objective: Ensure all form fields undergo proper validation.
Test Steps:
Submit forms with empty fields.
Submit forms with invalid inputs in each field.
Verify that appropriate error messages are displayed.
Address any missing or incorrect error messages.
1.2.2 All Field Level Validations
Objective: Validate form inputs to ensure accuracy and adherence to specified criteria.
Test Steps:
Submit forms with valid inputs in each field.
Verify that the data is accepted without errors.
Address any validation issues.
1.2.3 Functionality of Create, Modify, Delete & View
Objective: Test the functionality of forms for creating, modifying, deleting, and viewing data.
Test Steps:
Create new records using the form.
Modify existing records.
Delete records.
View details of records.
Verify that each operation is successful.
1.2.4 Handling of Wrong Inputs (Both Client & Server)
Objective: Validate the website's ability to handle and respond to incorrect user inputs on both the client and server sides.
Test Steps:
Enter incorrect data in form fields.
Submit the form.
Verify that appropriate error messages are displayed.
Confirm that incorrect data is not processed.
1.2.5 Default Values if Any
Objective: Confirm that default values, if specified, are correctly displayed and processed.
Test Steps:
Check forms for fields with default values.
Submit forms without entering data and verify default values.
Address any issues with default values.
1.2.6 Optional versus Mandatory Fields
Objective: Verify that mandatory fields are enforced and optional fields can be omitted.
Test Steps:
Submit forms without entering data in mandatory fields.
Verify that appropriate error messages are displayed.
Submit forms with optional fields left blank.
Confirm that optional fields can be omitted.
1.3 Cookies
Objective: Check for the cookies that need to be enabled and verify their expiration.
Test Steps:
Identify cookies used by the website.
Confirm that users are prompted to enable necessary cookies.
Verify cookie expiration and renewal.
1.4 Web Indexing
Objective: Evaluate how the site's design affects web indexing.
1.4.1 Meta Tags
Test Steps:
Inspect the implementation of meta tags.
Verify that meta tags are correctly influencing web indexing.
1.4.2 Frames
Test Steps:
Verify the functionality of frames.
Confirm frames do not hinder web indexing.
1.4.3 HTML Syntax
Test Steps:
Inspect HTML syntax.
Ensure HTML syntax is structured for effective web indexing.
1.5 Database
Objective: Test the functionality of the database, focusing on output errors.
1.5.1 Data Integrity
Test Steps:
Submit data to the database.
Verify data integrity by checking for missing or incorrect data.
Address any issues with data integrity.
1.5.2 Output Error
Test Steps:
Execute queries to retrieve data from the database.
Verify that data retrieval, writing, and editing operations are performed correctly.
Address any output errors identified.

2. Usability:
Navigation

Navigation describes the way users navigate within a page, between different user interface controls (buttons, boxes, lists, windows etc.), or between pages via, e.g. links.

Application navigation is proper through tab

Navigation through Mouse

Main features are accessible from the main/home page.

2.1.4 Any hotkeys, control keys to access menus.

Content

Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is without grammatical or spelling errors. Remove irrelevant information from your site. This may otherwise cause misunderstandings or confusion.

Spellings and Grammars

Updated information

General Appearance

Page appearance

Color, font and size

Frames

Consistent design

Usability Testing
2.1 Navigation
2.1.1 Application Navigation Through Tab
Objective: Evaluate the proper functioning of navigation using the "Tab" key.
Test Steps:
Navigate through the website using the "Tab" key.
Verify that the focus moves logically through interactive elements.
Confirm that the order follows a meaningful sequence.
2.1.2 Navigation Through Mouse
Objective: Assess the website's navigation using a mouse.
Test Steps:
Click through various elements and links on the website.
Confirm that the expected actions occur upon mouse clicks.
Ensure that hover effects, if applicable, provide visual feedback.
2.1.3 Main Features Accessible from the Main/Home Page
Objective: Confirm that essential features are easily accessible from the main or home page.
Test Steps:
Access the main or home page of the website.
Identify and verify access to key features.
Ensure users can navigate to important sections without excessive clicks.
2.1.4 Any Hotkeys, Control Keys to Access Menus
Objective: Identify and test the functionality of any hotkeys or control keys designed for menu access.
Test Steps:
Review documentation or website instructions for hotkeys.
Test each specified hotkey or control key.
Confirm that the corresponding menu or action is triggered.
2.2 Content
2.2.1 Spellings and Grammars
Objective: Ensure that all content is free from spelling and grammatical errors.
Test Steps:
Review all textual content on the website.
Identify and correct any spelling or grammatical errors.
Ensure the language used is consistent and follows established conventions.
2.2.2 Updated Information
Objective: Verify that all information presented on the website is current and accurate.

Test Steps:
Cross-reference information with the latest data.
Confirm that dates, statistics, and any time-sensitive content are up-to-date.
Remove or update any obsolete information.
2.3 General Appearance
2.3.1 Page Appearance
Objective: Assess the overall appearance of web pages.
Test Steps:
Review the visual layout and design of each page.
Confirm that content is well-organized and easy to read.
Check for any visual anomalies or misalignments.
2.3.2 Color, Font, and Size
Objective: Ensure consistency and appropriateness in the use of colors, fonts, and sizes.
Test Steps:
Evaluate the color scheme used throughout the website.
Confirm that fonts and text sizes are consistent.
Ensure readability and accessibility of text.
2.3.3 Frames
Objective: Assess the functionality and aesthetics of frames, if used.
Test Steps:
Verify that frames, if employed, serve a purpose and enhance user experience.
Confirm that frames do not cause navigation or display issues.
Ensure frames do not hinder website responsiveness.
2.3.4 Consistent Design
Objective: Confirm that the website maintains a consistent design across pages.
Test Steps:
Navigate through different pages.
Confirm that headers, footers, and other design elements remain consistent.
Address any discrepancies in design.

Server Side Interfaces:

Server Interface

Verify that communication is done correctly, Web server-application server, application server-database server and vice versa.

Compatibility of server software, hardware, network connections.

Database compatibility (SQL, Oracle etc.)

3.1 Server Interface
3.1.1 Verify Communication
Objective: Ensure seamless communication between the web server, application server, and database server.
Test Steps:
Initiate requests from the web server to the application server.
Confirm that the application server processes requests correctly.
Verify that data is transmitted accurately between the application server and the database server.
Test bidirectional communication to validate responses.
3.1.2 Compatibility of Server Software, Hardware, Network Connections
Objective: Assess the compatibility of server software, hardware, and network connections.
Test Steps:
Check server software versions for compatibility with the web application.
Evaluate the hardware specifications of the servers to ensure they meet requirements.
Test network connections to identify and resolve latency or connectivity issues.
3.1.3 Database Compatibility
Objective: Confirm compatibility between the application server and the database, considering different database systems (e.g., SQL, Oracle).
Test Steps:
Verify that the application server can connect to the database server.
Test basic CRUD operations to ensure compatibility.
Check compatibility with different database management systems specified in the requirements (e.g., SQL, Oracle).
Confirm that data types and structures are handled consistently.