Testing Approach For Next Retail Fashion Store Cloud Based BPM System

Testing Strategy and Execution

Discuss about the Test Plan for the Next Retail Fashion Store Cloud Based BPM System.

This plan defines the approach used for testing the Next Retail Fashion Store Cloud Based BPM System (hereinafter called Next BPM); it also defines the overall testing framework to drive the next BPM testing. This section introduces the test and execution strategies as well as how the test is to be managed.

The Next BPM has been proposed to solve the BPM challenges at Next Retail Store and to link the various disparate systems crucial for running the company. The proposed system is a cloud based BPM system that will streamline the procurement management, employee coordination, data analysis for decision making, and link the information data base.

The tasks specified in this test plan will be performed by the project team members; team members will give input as well as recommendations for the testing. The testing activities and their schedule is planned for by the project manager / team leader: other tasks include reviewing the test plan document, tracking performance, approval of the document, and accountability for the results. Representatives of stakeholders and/ or stakeholders may take part in the testing at the UAT stage to ensure alignment of the next BPM with business objectives (they are not specified in this document). An analyst will provide input if there is need for any functional changes.

Objectives of the Test

To verify the functionality of next BPM and that it works according to the specifications. The test will verify test scripts, identify and fix medium and high severity defects, then perform re rests  as per the entrance criteria. Lower severity defects will be prioritized for future fixing through maintenance. The final test product is a software design ready for production and stable tests scripts reusable for UAT and functional test execution 

Production-like data is required; this data should be available in system before functional testing commences. In every testing phase, the cycle 3 is initiated if cycle 2 shows a high defect rate. This estimation does not consider performance testing and the test team assumes all the required inputs during design for testing will be supported by developers and business analyst. All sign-offs and deliverables to be reviewed by the analysts. The project team has the necessary experience and knowledge in the testing process. No down times are expected during testing, for instance, power outages. The team will perform functional testing while the end users (EU1, 2 and 3) will perform UAT testing.

Test Management and Roles

The focus of testing is to meet business objectives, quality, and cost efficiency

Common consistent procedures will be used by all teams that support the testing process

test procedures are clearly defined, flexible, and can change as needed with testing activities building upon the preceding tests to avoid effort duplication or redundancy (Ellison, 2016).

A production environment is to be emulated as much as possible  by the testing data and tests will be quantifiable, repeatable, and measurable

Testing will be undertaken in distinct phases with each having clearly defined goals and objectives and the testing has criteria for entrance and exit.

The Next BPM will have Pre-loaded testing data during functional testing

Exploratory test

The purpose of the exploratory test is to ensure critical defects are removed before subsequent testing levels can be undertaken

The scope of the test is navigation (first level), followed by administration, and user modules

The testers are members of the project team and will be undertaken without test scripts or documentation and will be done at the start of every testing cycle (Ellison, 2016)

The purpose of the functional test is check application functions with input fed into the next BPM and and output from the system validated.

The scope is to test the cloud based Next BPM and its performance when other systems, based on design, are incorporated

Testing to be carried out by the project team and tests performed according to the functional scripts; the functional test is undertaken at the end of the exploratory tests

An approved functional specification and use cases document must be made available before the test design phase starts; the test cases are then approved and appropriately signed off to commence execution of test

The testing is complete after development and the system passes the functionality tests with the testing having the results shared with them

The test environment is ready with the system installed and configured, ready for use

Are described below;

Serial	Name of Deliverable	Author	Reviewed by;
1	Test plan		Project manager
2	Functional test cases		Project manager
3	Defects logging		Project manager
4	Status reports (daily and weekly)		Project manager
5	Report (test closure)		Project manager

• Issues to do with readiness of the system environment
• Changes in scope (addition or removal)
• Any dependencies impacting time-lines or effort

The purpose is to validate the business processes and logic and will enable end users review the system one final time before deployment. The testers are the end users (selected) and test method will entail validation of scripts (including those not in the scripts) and the test team will note down the UAT test inputs from the end users. The test is done wen all other tests have been expedited.

Serial	Name of Deliverable	Author	Reviewed By:
	UAT Test Cases	Project team	Project manager

The testing will take 7 to 12 days, depending on outcomes

Criteria for Entry and Exit

Testing Phases

Entry criteria are the desirable conditions needed before tests can start and only migration code and the fixes are assessed after every test cycle

Exit criteria are the desirable conditions to be met before proceeding with production and deployment

The entry criteria pertains to having all activities in the test planning phase being 100% completed

Exit criteria pertain ti having all activities in the test execution being 100% complete

Functional testing to have two cycles with all scripts executed in each cycle

The first cycle has the objective of identifying any critical defects, blocking, and majority of the high defects and a work around will be used to get to all the scripts

The second cycle has the objective of identifying any remaining medium and high defects, remove the work around from cycle one, correct gaps in scripts, and get performance results

There is one test cycle for UAT  (Lewis & Dobbs, 2009

The team will execute all scripts in every cycle and if necessary, additional testing to be done if there is a gap in the scripts, especially in the second cycle when the business analyst comes in

The test results for each cycle will be used for defect tracking

The test team will open all defects, link them with their corresponding scripts or actions, assign severity status, perform retests and close it. The project manager to review defects severity and organize, with the technical team, how to fix the defects. The project manager will also communicate when tests should proceed and when they ought to stop. The defects will be categorized as shown below;

Severity	Impact
Critical	Can cause system to crash, lead to corrupt files, or result in data loss Causes abnormal return to the OS such a crash or reboot Causes hanging of application that requires a restart
High	Leads to vital system functionality to fail
Medium	Degrades system quality but a work around gets it to work well It prevents testing of other system components
Low	Unclear error messages returned with minimal impact on functioning of Next BPM system
Cosmetic	Unclear error messages with no effect on system functionality returned

Are defined below;

Report	Description	Frequency
Status of test preparation and execution
Status for daily executions
Status for weekly executions

The tester reports any defects/ malfunction, the defects are validated by test lead, defects fixed by developer, system retested by team, and approvals obtained. The defect is then closed and the process comes to a stop

Tool for Test Management

The tool for testing is the HPE Unified Functional Testing

The testers must understand all requirements and develop corresponding cases for testing each and ensure all are covered

Every test case to be mapped to use cases and to requirements; this is to enable traceability

The business analyst will review all test cases and share their views; the project team will then review those defects before getting a sign off

The preparation phase will entail the use of a prototype used with case and functional specifications

A clarification tracker sheet is maintained by the project team and periodically shared

• There must be access by all the testing team to the test environment
• Tests executed in a stepwise manner and daily and weekly status reports generated
• Defects that are out of the scope of testing are evaluated and captured in the test phase (Lewis & Dobbs, 2009)

References

Ellison, R. (2016, May 23). Reviewing Assumptions for Software QA Process Changes. Retrieved  from https://www.softwaretestingmagazine.com/knowledge/reviewing-assumptions-for-  software-qa-process-changes/

Lewis, W. E., & Dobbs, D. (2009). Software testing and continuous quality improvement (2nd ed.). Boca Raton, FL: Auerbach.