Lessons learned

Testing has begun on the systems as the developmental processes comes to the end of the project timelines. Though extensive and exhaustive, manual and automatic unit testing will determine any outlying issues all to be completed by an independent and qualified testing team. Unit testing has begun and is working through the units as time allows, through revision and retesting on failure items. There are multiple groups in the EiS organization that oversee the testing phase. The first group “verification” who has the responsibility to verify that the code and the systems are complaint with the source information, documentation, and the requirements agreed upon by EiS and organizational stakeholders. The second group “creation” is responsible for creating an automated and manual set of testing that will be responsible for finding and reporting fault items to the development team that coded the item. They will work together to re-code / re-test and validate any code / functional faults. Team three “final” will run automated and manual testing on the units and work through the complete functionality to return faults or mis-code that could result in noncompliance with documentation and functional requirements. Passing final testing will validate and certify the software to gold status.

All teams will work simultaneously as the project begins to near completion and gold. This is the point where the development team are working to combine modules and the units of the system to a final product and begin the integration. The “Final” team will also be testing the final integration and validate that all the units and modules are functioning as a single unit. Testing will consist of functional, usable, and stability controls.

Regression Testing: A set of defined procedures used to test a software to confirm if the features of a software or code has not affected its features.

Network-readiness testing: The entire look or thorough search of a network to confirm its strength and ability to be able perform the basic functions of a network and that is transmit successfully.

Volume testing: It’s the use of a quantified amount of data used to test a software.

Recovery testing: The pace at which a software is able bounce back successfully after a system failure or crash or possibly a deadlock both for hardware and software.

Penetration testing: The use of black box technique to check and verify the security integration policy of a system of database.

Migration testing: The successful transfer or the move of the inheritance of the framework from one system to the other.

Ready-for-use testing: The set of tools used to test a network to check its availability to be used immediately for a service delivery.

 Hardware-certification testing: The checking of hardware components to confirm if they conform to specific hardware rules as they are supposed to.

EiS is taking into consideration a network for education institutions that receives and transacts with students, lectures, employees and other institutions.

Map

EiS system to 1. Customer

2. Central education location

3. Headquarters of EiS

4. Sms Company

5. Other education institutions

Objective of test case: To prove the competence and strength for a network to perform basic functions. Its availability to be transferred successfully to another platform and then also meet basic standards of software and hardware component rules.

Setup procedure: The way and manner by which the system would be set up to perform those functions. How it would interact with the database and then also communicate successfully with other systems such as client’s details per transaction and also communicate effectively with other systems such as that of other educational institutions.

Expected results: the system should simply be able to do the following; be able to receive any request from one account of a customer in question.

Figure 1

Showing in Figure 1 a representation of how the testing cases are represented.

Procedure for executing test case: Scenario Activity: A client has two accounts and they are namely student A and Account B. Student Account B should be able to receive order from another account into Account B and then be able to successfully track the order to his or her location. Hence the EiS would alert the client for the successful transaction.

Test Case 1

Test case 1's objective is to test the creation of a new user account. We will test this objective by creating an account that will test the system as well as any redundancies of the system. The first step will be to test if by entering a new email to set up an account if the system will accept the email and create the account. The second step will be to enter an existing email to test for a current account. This will test if the system can recognize if an account is already created and signal if the system will alert if there is an existing account. The third step will be to enter the pertinent information when creating an account to ensure that the system will recognize and accept the user’s details. The 4th step will be then to display the user information as entered and lastly to test that the system will store a zip code and then save after it is entered.

In testing or system we had to fix the email redundancy check and ensure that the system will recognize when you are entering an existing email when creating an account. This will cause issues that all emails will be accepted which will cause overlap in our system and not allow users to create accounts.

Test Case 2

The second test case will be to setup a strong password policy. This will determine our security procedures in our system and ensure that each users account is secure with a unique password and not allow a user to create an account with a blank password in the field.

The first step will be to enter a new password for the system and ensure that our system will only allow strong passwords based on a criteria we will set that will give the user a parameter when it comes to password strength. Step 2 and 3 will repeat this the first being that if the password is generic it will return with a weak password warning and not allow the account to be set up. Step 2 and 3 will test if the password is ok or a strong password and return the notification informing the user of the strength of the password. Step 4 and 5 will ensure that the password does not match the user name and when the password is strong and unique that it will return an alert of success. Lastly based on the parameters set the password will have an expiration date and it will test if this system works properly informing the user that the user must update or change their password based on the date of creation.

Ensuring that our users have strong passwords will increase the chance that there will be no breach of data and that our users can feel safe with the security measures we have put in place.

Test Case 3

The third test is to test user account login. Using this test we will be testing the ability for a user to login and if the account is active. We will be testing if the account is active, valid, and if the password is not expired. We will be testing the verification of account access. We will perform this test by testing the account verification system that we have already established in test 1 and test 2. The major points of this test will be to ensure that the user can log on then log off as well as that the system will recognize the users account info.

Test Case 4

Test 4 will determine if the system will have accurate and responsive application navigation. We will be performing this test by using the different navigation buttons on the system itself to ensure that will work properly. The buttons we will mainly be testing will be the menu, home, new documents, my documents, share, and friends’ buttons. The main way in which to perform this test will be to navigate through the site to the numerous different areas and ensure that no matter what page we are currently viewing we are able to use the different buttons an d they will return us to the desired locations.

Test Case 5

Test 5 will be performing the document management tests and will mainly focus on the uploading, downloading, and sharing of documents within the system. We will be performing tests that will check if the user will be able to create new documents as well as to perform all the tasks required regarding the life cycle of documents themselves. Within the tests that we will be performing we will have dependencies that will relate to previous tests. The dependencies for this test will be that the user has an active account, memory space available to produce new documents, as well as that when the user is sharing documents that the user, they are sharing them with will be in the user’s friends list. Within this test we will also be testing the recycle bin which is vital to the deletion of any documents that the users will no longer be needing.

Test Case 6

Test case 5 will be testing the data integrity of the documents and that the system will be able to upload and download data to the system that will be available to your account and the accounts that you share with. With this test we will be performing uploads and downloads and then testing the documents within the system to ensure that will be available to opened and not be corrupted. We will test this by performing the processes of create a document then navigating to the Mydocuments page then uploading that document. We will then download the document and ensure that it opens this will then allow us to test that the document is not corrupted and allow us to open it.

Some of the dependencies for this test will be that the test from test 4 and 5 will have already been confirmed and the system will allow us to perform the tasks to be able to test that the document is not corrupted.

Test Case 7

Test 7 will test the ability of our system to provide data retention backup within or system as it relates to system backup and backup restore capabilities. The dependencies for this test will that the backup and restore policy that we have developed is active and running as well as there is space available for the data to be backed up. We will also be testing that the documents within the MyDocuments section will be the test data for the backup retention policy. We will perform this test by adding documents to the MyDocuments folder and then performing the backup of those documents. Then we will delete all documents from the folder and then initiate a restore. We will then test to ensure that the documents that we have deleted have been restored and that the files are not corrupted.

Test Case 8

Within test case 8 we will be testing the load times throughout our system and how they respond on our different pages. The dependency for this test will be that all of our links are working and are not corrupted as we tested within test case 4 and that we have a stopwatch to test the times for loading within the system. We will perform this test by logging in to the system and then utilizing the navigation buttons we will click our hyperlinks and then run the stopwatch to test the system as it loads the different pages. From these tests we will determine if the system is running correctly based on the speeds in which our pages load.

Test Case 9

Test 9 will be a stress test for our system to ensure that our system can handle a large load of log-ins and that the full system can handle heavy traffic. The dependencies for this test will be 500 concurrent log ins that we have previously performed through previous test cases. We will perform this test by running load tests across the entire platform and utilizing heavy load traffic to ensure that the system will be able to still perform the speeds we intend while also navigating properly between pages and links. We will provide 500 dummy accounts and then with each account have them navigate to different pages and using all the previous test case procedures concurrently have each dummy account perform those same operations. This will then stress the system to the point where we will be able to determine the amount of load that our system can handle at any one time. In performing numerous tests like this we will be able to oversee the system and see how the processes respond to heavy load.

Test Case 10

In test 10 we will be testing whether the system will be able to properly email to our support staff and ensure that the link works properly as well as the email system is operational. The dependencies for this test will be to ensure that the system's email server is working properly and that our hyperlinks are working and active as in test case 4. The tests performed to ensure this test case will be to navigate to the contact support link and that the link to contact support is active. We will test that the fields will populate correctly and that each field within the support contact page is operational and allows the user to enter text into these fields. Then we will test after the fields are populated that the system will deliver the email with all the same information that was originally entered into the fields. This will test if the fields are accurately relaying the information to our support team and that the system is operating as we intend.

The testing of the software is a vital part of the testing process for the improvement and greater quality of the project. With this testing, it is essential to know that lifecycle testing must be strictly followed in all cases.

Planning is a very important part of the testing facilitation process, but the lack thereof can also be just as bad because it can cause delays and over budgeting. The design of the testing is vital because this part is to decide which test to perform and when. Testing flow is important because it starts with simple testing then moves forward with more complex testing. In the unit testing process, each individual unit is tested from start to finish before implementation. The module testing is the combining of individual units into modules for the interactions of each part of the individual phases to check for functionalities. Subsystem testing is a form of testing to test those larger combined parts of the system for a greater functionality of which the user interfacing can be validated as well, (M.U.S.E. © 2019). The system testing is when all other components of the system have been combined and completed of which a performance test can be performed at this time, (M.U.S.E. © 2019). The last and final test is the acceptance testing which is all tests are completed and live data is utilized by the client/customer to see if all requirements and functionalities have been met. If all requirements and functionalities have been met, then there is a sign-off and the payment is made.

Efficacy

The designing for change has several designs for change that if not utilized at the beginning of the software lifecycle, the software will be not that effective, (Rapid Development, S. McConnell © 1996). A reduction from the norm would be fair, no progress visibility, a decrease in the risks of a scheduled risks, first-time successes are good, and long-term successes are excellent. The designing for change is a single design methodology referring to the flexible software designs, (Rapid Development S. McConnell © 1996). The following are a list of the items list of the designing changes; Areas to change, use informational hiding for change, make a development change plan, have families of programs, and have the use of object-oriented designs, (Rapid Development © 1996).

Figure2

Prototyping on an evolutionary scale is a lifecycle type model of which is done in smaller sections for greater development through the inputs of the end-user and the customer feedbacks, (Rapid Development © 1996). With prototyping the efficacy of a normal schedule is excellent, visibility is excellent, long-term is excellent, first-time is successful, and the schedule risk is increased, (Rapid Development © 1996). The risks involved are unrealistic schedules and budgetary expectations, the inefficiency of prototyping uses, performance expectations are unrealistic, a poor design, and the poor maintainability, (Rapid Development © 1996).

(Cited: QMR Template provided by Professor H. Okoro for Rapid Development IT488-1902B-01)