Quality Assurance and Results of Test-Case Execution

Quality Assurance and Results of Test-Case Execution

Test Case 01

Test Case ID: / TC-01 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Markup Validation / Test Design date: / 02/29/16 / Test Executed date: / 03/14/16
Test Priority: / 5/5
Description: / Validate markup for all web pages (validate HTML and CSS for syntax errors) to make sure it is compliant with the standards
Pre-Condition: / Markup files complete.
Dependencies: / Angularjs, jQuery
Post-Condition: / All markup file will be functionally complete as well as compliant with all web design standards.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Determine all pages which will be tested. / n/a / n/a / n/a / n/a / n/a
2 / Test that all elements have been closed in the proper place. / n/a / All opened elements have been closed in expected locations. / All elements were properly closed. / Test Passed / n/a
3 / Test that all elements have the required class definition. / n/a / All elements should have the proper class definitions allowing for proper styling and functionality. / Some class definitions were missing / Classes corrected. Test Passed. / Testers completed corrections
4 / Review all HTML to ensure the optimal elements and attributes have been used. / n/a / All HTML should be written using optimal code following all web design standards. / All attributes were properly used. / Test Passed / n/a
5 / Complete markup validation. / n/a / All markup code has been validated. / All markup was validated / Test Passed / n/a

Test Case 02

Test Case ID: / TC-02 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Mandatory Fields / Test Design date: / 02/24/16 / Test Executed date: / 03/14/16
Test Priority: / 0.8
Description: / All mandatory fields should be validated and indicated.
Pre-Condition: / All mandatory fields have been created and are functional.
Dependencies: / jQuery
Post-Condition: / All mandatory fields have been verified to be functionally correct and marked appropriately
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Determine required fields. / n/a / n/a / n/a / n/a / n/a
2 / Determine proper test data for required fields. / n/a / n/a / n/a / n/a / n/a
3 / Test required user fields / Test user data, multiple test users per role. / Entered data should be properly stored in scope and entered to or query the database. / All test users were created and performed as expected. / Test Passed / n/a
4 / Test the required products, orders, and services fields. / Test product data / Entered data should be properly stored in scope and entered to or query the database. / All test products were added and functionally correct. / Test passed / n/a
5 / Test remaining required fields. This should include any field deemed required in Step 1 but not previously tested. / Test data determined in Step 2 / Entered data should be properly stored in scope and entered to or query the database. / Some fields were lacking in text entry restrictions. / Test passed / Test team made corrections
6 / Examine all required fields HTML to ensure all are marked with appropriate markings. / n/a / All fields should be marked with a symbol or marking to show it is required. / All fields were labeled correctly. / Test Passed / n/a
7 / Ensure all fields follow standards. / n/a / All fields should follow web design standards. / All standards were followed / Test passed / n/a

Test Case 03

Test Case ID: / TC-03 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Error Page Routing / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.6
Description: / Application crash or unavailable pages should be redirected to proper error page.
Pre-Condition: / Error pages have been created and receiving an error directs the user to one.
Dependencies: / UI-router
Post-Condition: / Error pages have been validated and errors direct to appropriate pages.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Determine Error pages and what routes should lead to them. / n/a / n/a / n/a / n/a / n/a
2 / Test each route that should lead to an error page. / n/a / Each error route should lead to the appropriate error page. / All routes lead to corresponding error pages. / Test passed / n/a
3 / Validate the error pages individually. / n/a / All pages should contain required error information, appropriate links and no extra access. / Each error page is functional and has appropriate restrictions. / Test passed / n/a
4 / Validate navigational functionality. / n/a / Error pages should maintain navigational stability, after being directed to the page the back button should return you to prior to the error. / The back button leads users to the page prior to error. / Test passed / n/a

Test Case 04

Test Case ID: / TC-04 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Confirmations / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.6
Description: / Confirmation messages should be displayed before performing any update or delete operation.
Pre-Condition: / Update and delete functionality has associated confirmation messages.
Dependencies: / Angularjs
Post-Condition: / All update and delete functions are preceded by appropriate and working confirmation messages.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Determine all elements that modify the database using update or delete. / n/a / n/a / n/a / n/a / n/a
2 / Examine each element updating or deleting from the database to determine if the conformation message is complete and working. / n/a / Each element will require confirmation from the user to modify the database. / All database calls require confirmation. / Test passed / n/a

Test Case 05

Test Case ID: / TC-05 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Database Verification / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.8
Description: / Check the database and all database interfaces for correctness and completeness.
Pre-Condition: / Page database interaction is functional.
Dependencies: / Mongoose
Post-Condition: / All data stored in database is complete, correct, and stored in a consistent fashion.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Check if correct data is getting saved in database upon successful page submit. / Test page data for Users and Products. / Data is consistent from entry to database storage. / Submitted data appears properly in the database. / Test passed / n/a
2 / Check if data is committed to database only when the operation is successfully completed. / Test data for page both correct and incorrect according to data acceptance policies. / Incorrect data in not entered in the database. / No data was stored without confirmation / Test passed / n/a
3 / Input field leading and trailing spaces should be truncated before committing data to database. / Test data for page both correct and with excess spacing. / Data is stored in the most consistent and correct manner. / All database input was managed correctly. / Test passed / n/a

Test Case 06

Test Case ID: / TC-06 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Page Performance / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.8
Description: / Check if page load time is within acceptable range.
Pre-Condition: / Server is capable of serving application pages.
Dependencies: / Nodejs
Post-Condition: / Server responds to requests with and immediate response.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Benchmark server to determine baseline response time for designated user volumes. / n/a / Server response baselines. / Server benchmark was created and met expectations. / Test passed / n/a
2 / Calculate the response times for this application under different user volumes. / Test user volumes. / Application response baselines. / Test volumes met calculated benchmark. / Test passed / n/a
3 / Test different volumes of users against the calculated baselines. / Test user volumes. / Application follows expected response times. / Test volumes met calculated benchmark. / Test passed / n/a

Test Case 07

Test Case ID: / TC-07 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Database Performance / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.6
Description: / Check database query execution time.
Pre-Condition: / Database is application accessible.
Dependencies: / Mongoose
Post-Condition: / Database responds to requests with and immediate response.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Determine benchmark response times for the database. / Test data for each model. / Database response baselines. / Database bench created and met expectations. / Test passed / n/a
2 / Test database with various user volumes to determine response time under load. / Test data for each model and test users. / The database response time is acceptable compared to the baseline. / Volume test met calculated benchmark. / Test passed / n/a
3 / Test the database from various other networks to determine response across the internet. / Test data for each model and test users. / The database response time is acceptable compared to the baseline. / Volume test met calculated benchmark. / Test passed / n/a

Test Case 08

Test Case ID: / TC-08 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Stress testing / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.8
Description: / Check the application's performance under pressure.
Pre-Condition: / The application is over all functional, other modules may be under parallel testing.
Dependencies: / Application functionality
Post-Condition: / The application will be remain responsive, even under heavy user stress.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Determine application operational limits for concurrent users, page requests and database queries. / n/a / Operational limits. / The operational limits occur at 20,000 users. / Test passed / n/a
2 / Test the application near, at, and above the operational limits for each: concurrent users, page requests and database queries. / n/a / Application should work until the operational limits are reached then crash gracefully. / Applications response speed becomes unacceptable with over 20,000 concurrent users, but remains stable below the threshold. / Test passed / We find this limit to be acceptable as concurrent users should be primarily workers with few customers as this application is local only.

Test Case 09

Test Case ID: / TC-09 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Security Verification / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 5/5
Description: / Verify security procedures.
Pre-Condition: / Security procedures are in place and functional
Dependencies: / Passportjs
Post-Condition: / Security has been validated for correctness and completeness.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Verify secure protocols are used on all pages. / n/a / All pages use HTTPS and all internal routing is secure. / All pages require HTTPS. / Test passed / n/a
2 / Server info should remain secure. / n/a / No pages including crashes should reveal server data. / The application has no ability to modify the server. / Test passed / n/a
3 / Validate input. / n/a / All inputs only accepts appropriate input. / All field have acceptable input requirements. / Test passed / n/a
4 / Validate password security. / n/a / Password policies are enforced and password storage is secure / All password policies are enforced. / Test passed / n/a

Test Case 10

Test Case ID: / TC-10 / Test Designed by: / Elizabeth Yáñez / Test Executed by: / Test Team
Test Case Name: / Verify storefront / Test Design date: / 02/24/16 / Test Executed date: / 03-14-16
Test Priority: / 0.8
Description: / Check the Point of Sale module of the application for completeness and correctness.
Pre-Condition: / The storefront module is functional.
Dependencies: / Moltin
Post-Condition: / The storefront module is fully functional, complete and correct.
Step / Test Steps / Test Data / Expected Result / Actual Result / Status / Notes
1 / Test the checkout process. / Test user. / Checkout process allows users to add items to a cart and proceed to payment information. / Users are able to make digital purchases of products with the assistance of a sales associate. / Test passed / n/a
2 / Test the payment acceptance methods. / Test user. / The payment methods successfully process payments. / All digital payment options accepted. / Test passed / n/a
3 / Test order creation after successfully payment. / Test user and Test order. / Orders paid for are successfully created. / Orders can be successfully created by customers with associate assistance. / Test passed / n/a

Quality Management Report

The testing plan is currently following the predicted schedule as expected, modules are being tested following completion using automated unit tests and thorough testing and examining of the source code by qualified testers. Unit testing on the project nears 50% completion in terms of completed unit testing. This is considering the tests that passed and failing tests that have been corrected. Three teams are currently working on the development of this project. Team A is working on developing the application according to the requirements and documentation, Team B is writing automated tests for the modules as the development team is creating them, these two teams are working closely in tandem to create the modules and the tests from them. Finally Team C is the testing team, these members are running automated tests and returning errors for corrections. Once all automated tests are completed and passing the test team then analyzes the code completely and runs usability tests.

The three teams currently are on schedule and the project nears the second to final sprint in which developers are assembling and finalizing the modules. The test team is currently testing the final individual module. Integration and systems testing will begin following this sprint when all modules have been assembled. The testing sprint following the assembly sprint will consist of unit testing using automated tests, then code analysis. Code analysis will be parallel to usability testing as the testing team is large enough to complete both asynchronously.

Following will be integration testing done by the entire team to ensure that the modules were all properly assembled. During this time the development team will be building the final production version of the project. After completing the testing team and development team have completed their portions the three teams will come together for volume testing, recovery testing, penetration testing, regression testing, and ready-for-use testing.

It is important to include penetration testing will consist of penetration testing the application server from the application and will not include the network, since as mentioned previously in the documentation the network will not be included in this project and is assumed to be in place and secure prior to beginning. It is my determination that this project will be done and deliverable by the decided upon date.