Best Sell Assignment-23

docx

School

Fanshawe College *

*We aren’t endorsed by this school

Course

6104

Subject

Information Systems

Date

Oct 30, 2023

Type

docx

Pages

Uploaded by DrKangaroo3560

Test Strategy Project Name: Best Sell Systems Test Project Prepared By: Onadebi Date: 13/10/2023 Current Test / Project Phase: Testing phase Revision History Version Description of Revision Date Author 1.0 Development of Testing strategy 13/10/2023 Onadebi 1. Introduction to Project The merger of the Best Buy stores with Google Self-driving car company, Waymo, has led to a rebranding and creation of 750 Best Sell stores across Canada. The business has a growth expectation of 25% each year for the upcoming 5 years. Each of these stores would need to manually input their salesperson information to create a daily report file that would be transferred to the head office of Best Sell, located in London, Ontario. This file would undergo processing, which would result in the creation of new Sales reports. The reports will calculate sales amounts per Salesperson, Department, Division and Branch store. The branch store reports would most often be categorized into departments selling:  Smartphones/tablets/Desktops/laptops & their peripherals  Lifestyle technology devices (hoverboards, smart home devices, etc.)  Software  TV's, Video recorders & their peripherals  Appliances  Self-driving cars  Drones  Services like instore helpdesk support in addition to salespeople that work as checkout clerks/salespeople. The project would involve the building of several subsystems, which would all be integrated to function as a unified system, inclusive of the old data entry subsystem. The subsystems include a web-based data entry system, built using Java for the backend technology and HTML with JavaScript for the user facing interface; as well as a Host Mainframe Subsystem housing the Sales Processing and Sales reports creation programs, which are built using Page 1 of 8 Test Strategy Template v1.4 (2021)

COBOL (Common Business Oriented Language) programming language. An additional system would be an SQL server-based Data warehouse, which data would be loaded into. This Data warehouse system would make use of Python and Java to empower business analysts to retrieve reports to make effective and efficient business decisions for the stores and company, by predicting the future using historical data. It is necessary to note that stores that already have existing Sales data entry subsystem will keep using them even after the project completion, because the Head office would have a regular charge for each store to make use of the new data entry system. This charge would be the means to recover development costs as well as fund the maintenance of the system. The choice of programming technologies being used: Java, JavaScript, SQL Server database Warehouse, Python, COBOL is based off experience of Best Sell programmers, having coded a similar web-based system 6 months earlier, using the same technologies. 2. Test Methodologies Various test methodologies would be employed in the testing of the entire system, depending on the degree of access to the system as a whole and the various subsystems. The test levels employed would also vary depending on the degree of subsystems access. Considering the subsystems that make up the entire architecture, the below describes the planned test methodologies and levels that would be used:  Web based Java Data Entry Sub-system and Mainframe Sales Processing & Sales Report COBOL subsystem : This would have comprehensive Whitebox testing due to the developers having full access to the codebase. The code storage and version control would be managed using Git version control, hosted on a private GitLab repository. As part of the management of the subsystem code, the repository would also have a Build pipeline setup to run static automated testing. There would be four (4) levels of testing for these subsystems which include: I. Unit/Component testing : This involves writing unit tests code that would be run in the versioning control automated build pipeline to ensure unit tests are always run when the code is pushed to the repository. II. Integration testing : This test level covers components integration testing that makes up the whole of the individual subsystems. III. Systems testing : This covers system integration tests between the various subsystems, forming a system of systems. IV. Acceptance testing : This covers user acceptance and regulatory acceptance testing.  Old Data Entry Sub-system: The test methodology to be used here is the Blackbox testing, since there is no access by the testers to the code. There would be a test for both functional and non-functional criteria. Page 2 of 8 Test Strategy Template v1.4 (2021)

Two (2) levels of testing would be used for this subsystem: i. Systems integration testing : This would test that the old data entry subsystem is able to integrate with the other subsystems like the Java web-based subsystem without any problems. ii. Acceptance testing : This would cover user acceptance and regulatory acceptance testing. 3. Resource/Environment Dependencies Several resource and environmental dependencies would be required through the Software Development Life Cycle (SDLC) involving stages of applications development, testing and eventual deployment to production. Based on this, some technical resources that would be needed are: 1) Development Laptops for the software Developers which should have minimum specifications of an Intel Core i7-12700H, 16GB DDR5 RAM, 1TB PCIe NVMe M.2 Solid State Disk (SSD) with 15.6-inch screen. 1 2) Three Hardware Server computers for Development environment, Test environment and Production environment. In addition, there would be an IBM z890 system mainframe server with installed operating system “Linux for System z ” 2 which would is highly performant for running the COBOL subsystem in production. The development Server would be used for all development activities, including hosting applications like the SQL Server database that the software developers would remotely be connecting to from their laptops while building the systems. The project development would take an Agile approach; hence it is mandatory that we have a private code repository tool set up on GitLab for each of the subsystems code base being built and tested. In this regard, Git version control would be used as the means for tracking changes and maintaining previous versions of the codes. This would also ensure that incremental changes can be quickly made and pushed to the GitLab code repository. The importance of this project to the company mandates that there is going to be occasional formal review sprints held every 3 weeks involving key human resource people needed for this test strategy to work. For this reason, it would be expected that 24 hours before any review sprint is to hold, the testing server environments, networks must be up and running and all needed test data loaded into the database. This is to be enforced by the Test manager. The roles that are essential to these formal reviews include: 1. Test Manager : In charge of review executions and determining if review objectives have been met. 2. Moderator : This role is responsible for the running of the meeting and may involve mediating between the various points of views during/after the meeting. 3. Author : Whose chief responsibility is for documents to be reviewed. Page 3 of 8 Test Strategy Template v1.4 (2021)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

4. Reviewer : This role has specific technical or business background and acts as the checker to identify and describe findings during the reviews. 5. Scribe : Responsible for documenting all issues, open points and problems identified during the review meetings. 4. Testing Objectives/Approach The objective in testing is to ensure that the subsystems and the entire architecture function as expected and efficiently. Efficiency is important because the entire system is expected to be receiving, processing, storing, and generating reports from data input from the 750 Re- branded Bell stores. The scope of testing would cover every subsystem that makes up the whole system architecture. However, the level of access to the individual subsystems would determine whether a Whitebox test or a Blackbox test methodology would be involved. The testing approach would primarily have the testing team carry out the below following steps:  Requirement gathering and Analysis : The functional requirements are gathered and analyzed to establish a clear understanding of what the systems are supposed to do.  Test Design and Planning : The creation of detailed test cases that specify the objectives, test data (i.e., the Sample sales data) and the expected result for each scenario. these test case, a comprehensive test plan is developed, which would also contain the test entry criteria and exit criteria to determine when testing can begin and end.  Test Implementation : This covers several processes including Test Environment Setup (Servers, Database, Networks, etc.), Valid Test Data Preparation, Tests Execution, Performance, Security and User Acceptance testing. White box testing is used to assess the new Java web-based subsystem and the COBOL subsystem. Black box testing is done for the old data entry system. Also, a systems integration test is carried out to ensure seamless connectivity between the newly developed subsystems and the old subsystem. Some Non-functional testing that would be carried out are:  Efficiency : This would be measured using Apache JMeter for all the subsystem servers. This would measure load stress level.  Reliability : This would be tested using JUnit for the Java subsystem and GitLab build test-pipeline for both the Java and COBOL systems. It would however be difficult to test Reliability of the old data entry system, since the testing team and developers do not have access to the application code. Page 4 of 8 Test Strategy Template v1.4 (2021)

 Maintainability : This would test for compliance, stability, changeability, and stability. For this test, the tester would make use of SonarQube. This test would be carried out for the web-based Java Data Entry and COBOL subsystems.  Usability : The Java data entry and COBOL subsystems would be tested for usability and compliance Test cases developed and implemented are documented using the using the IEEE 829-2008 Standard for Software System Test Documentation. 3 5. Deliverables / Procedures Planned test deliverables are essential for making sure that structured and effective testing processes are followed. The deliverables would help ensure quality, communicate progress, and facilitate defect management. Some key planned deliverables and procedures along with their purposes include:  Test Plan : The purpose of this is to present a comprehensive document that shows the detailed step-by-step guide to perform tests. This ensures that all testing is done in a structured way.  The Test Strategy : This is a high-level document of the testing process that describes the techniques and approaches used in testing, also with the scope and methodology.  The Test Data : Without test data, the tester is unable to perform any reasonable test. This document shows the test data input values, datasets and configurations used in the test cases. The purpose is to ensure that texts executed are in specific scenarios with varying conditions.  Test Scripts : This specifies detailed instructions for what needs to be executed, including the test input data, the expected results and the conditions that should produce the results. This ensures that testing is both systematic and repeatable.  Test Defect report : Defects that are detected during testing activities are documented here to report, track, manage and prioritize defects for resolution.  Test Reviews : This involves formal technical reviews/inspections of test plans and test scripts to ensure that expected quality, alignment with requirements and completeness are achieved.  Test Summary Report : This report summarizes the details of testing process, including defects, achievements, and overall quality assessment. The purpose is to inform of the readiness and status of the systems testing.  Change Request : The Change Request Document details how changes to initial requirements, code or test cases would be managed. It is necessary to manage and minimize any changes that would disrupt testing processes.  User Acceptance Testing (UAT) : This documents the result of the software systems meeting technical requirements and is ready for production. Page 5 of 8 Test Strategy Template v1.4 (2021)

 Test Closure : This documents the result of test summary, analysis and formal sign-off after testing activities are concluded. 6. Suspension / Resumption & Exit Criteria/Conditions Test suspension is an interruption of testing activities. This can be caused by several factors. Some of them include:  Test Environment issues: If there is absence of test environment, or the test environment of any of the subsystems has problems, then this would lead to the test being suspended. This can also include Server, Network or Database issues.  Test Data: Unavailability of valid test data can lead to test suspension.  Resource Constraints: When there are key dependencies missing, like unavailability of key technical personnel, this can cause test suspension. Resumption criteria refers to conditions that were previously show-stoppers which led to testing being suspended but have now been fulfilled. Hence systems testing can then be resumed. Some resumption criteria include:  Environment availability and stabilization: This means that the test environment, including Server, Networks, Database etc. is available and stable enough to resume testing activities.  Valid Test Data availability  Resource constraints resolved. Restart Criteria can be because of unrecoverable interruptions during testing that would lead to restarting the tests. This can be due to several factors like, server crash in the middle of testing, database disconnection, sudden change request approval that needs to be implemented before testing can continue or even Test data being corrupted during the testing process. Exit Criteria: These are the predefined requirements or conditions that the test cases must meet for a testing phase to be concluded successfully and the software systems considered ready for production deployment. Some key stakeholders involved at this stage include the Project Manager, Sponsor, Technical Test Manager, Test Analyst, Database Admin, Infrastructure engineer (i.e., responsible for environment setup, networks, and server), and member of the software development team. For the Severity Criteria, according to Rex Black 4 , severity criteria during exit evaluation were graded on a three-point scale. Green: Totally fulfilled, with little remaining risk. Yellow : Not totally fulfilled, but perhaps an acceptable risk. Red: Not in any sense fulfilled, and even poses a substantial risk. Page 6 of 8 Test Strategy Template v1.4 (2021)

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

7. Approvals Roles and Responsibilities Role Name Organization/ Position Contact Information Sign off Comments (Y/N) Manager Rex Black Project Manager 6471234567 Black Sponsor Shelley Lapkowski CEO 6471234568 Lapkow ski DBA Larry Ellison Database Admin 6471234569 Ellison Tester Onadebi Testing Manager 6471234510 Onadebi Software Developer Steve Wozniak Programmer 6471234511 Wozniak Engineer Micheal Dell Infrastructure Administration 6471234512 Dell Sign-off: Rex Shelley Larry Onaefe Steve Micheal Comments: An important thing to note is that because 2 other large projects are being built/tested simultaneously as this project is ongoing, there is likely to be some constraint of time and divided attention of the Testers and Developers between this project and the other 2 projects. Page 7 of 8 Test Strategy Template v1.4 (2021)

References: 1. https://www.techradar.com/news/best-laptop-for-programming 2 IBM (2008). Mainframe Concepts Pg. 44 3 Wikipedia. (2023) Software test documentation. Retrieved October 13, 2023, from https://en.wikipedia.org/wiki/Software_test_documentation 4 Black R. (2016). Advanced Software Testing (2nd ed.). Vol. 1. Rocky Nook Inc. Page 8 of 8 Test Strategy Template v1.4 (2021)