The Development of a New Password Reset Process - Case Study Example

Software Testing Plan Table of Contents 1INTRODUCTION 3 0. Background 3 1 Interaction of the ITS Support Team 4 2 Operationalization of the System 5 2TEST SCOPE 7 2.1 Identification 7 2.2 Overview of the new System 8 2.3 Document Overview 9 2.4 Relationship to other plans 10 3TEST OBJECTIVES 10 4PROCESS OVERVIEW 11 5TESTING PROCESS 12 6TESTING STRATEGY 14 6.1 Black box testing 16 6.1.1Boundary Value Analysis 16 6.1.2Equivalence Partitioning 17 6.2 Integration Testing 18 6.3 System Testing 19 6.3.1Performance Testing 19 6.3.2Validation Testing 19 7ENTRY AND EXIT CRITERIA 20 8BUG TRACKING/BUG PROCESS 21 8.1 Bugs expectations 21 8.2 Roles played by team members in the resolution of bugs 22 8.3 Bug Report Form 22 Reference 24 1 INTRODUCTION 1.0. Background Currently, the institution is in the process of developing a new portal for use by students and other faculty members in getting access to information regarding their academic progress (in the case of students), and for monitoring by the respective lecturers. This new portal, although it is yet to be unveiled will be a replacement of the current (old) system that so far has served its purpose and seemed inefficient in addressing the required needs of the users. Particularly, the development of the new portal or integration with the old system will be centered around the development of a new password reset process (Kaner, 2012). However, with the new system being but an integration of new features and upgrading of the servers, it is expected to rely on the interfaces of the old system in its development to obtain the new interfaces. Being a high-level overview document, this test plan shall seek to define the testing plan for the MU Portal application, particularly the New Password Reset Process. It is usually objective that the project-wide quality standards be communicated in a formal document, as well as the procedures for the application. This is because it portrays the project’s snapshot as of the termination of the preparation phase. In regards to these, this document shall seek to address the various standards that will to the integration and system testing of the identified application. Additionally, as an ITS Support Team, we will engage the testing criteria under different aspects such as the white box, the black box and the testing paradigms of the system. The paradigm shall include, but not be limited to test cases, the criteria for testing, and the methods of the inclusive design. Throughout the process of testing the application, the team shall apply the test documentation specifications that have been described in the IEEE Standard 829 – 1983 concerning Software Test Documentation. 1.1 Interaction of the ITS Support Team The following listed aspects shall describe the level at which the team members and other stakeholders engaged in this process shall interact with each other for the ensured success of the product. The ITS Support Team will be required to work watchfully with the Quality Assurance Team in the attainment of the highest quality for the application design and the specifications for the user interfaces. This should be based on the necessities of the client. As such, the Test Team will be obligated with the responsibility of ensuring that the test cases are visualized and the quality issues and concerns relating to the project that shall be raised in all level meetings are addressed in time, while the product is still in its development cycle (Kaner, 2012). The ITS Support Team will also be obligated to work jointly with the Quality Assurance Team in determining the capacity to which the application adheres to the criteria set for its completion. In relation to this, should an area of the application be detected as not acceptable for testing, its complete date for the code will be pushed out to give the developers extra time to be able to stabilize the specific area in question. Given that the application will interact with the back-end system components, the ITS Support Team will be required to include the integration testing in the plan. This is because before the team conducts the system testing, it is imperative that the integration testing is done. 1.2 Operationalization of the System The decision to have a new portal system was jointly made by the University Information Technology department in the corporation with the respective stakeholders. As part of this review team, I shall be the only person on the formal test team. The final test plan shall be subjected to the scrutiny of the ITS Support team that shall comprise of the Product Manager, ITS Executive Director, and the Quality Assurance Manager. As part of the MU Portal, the new password reset process application shall have be modified in a manner that ensures that the newly generated passwords for each student bear a minimum of eight (8) characters. The password characters shall include uppercase letters, special characters, and numbers in order to make it exceptional. In this report, the core concern shall be the outlining of the plan to be followed in the testing procedure for the new portal of the university. Subsequently, the testing procedure in accordance to this plan shall require that authentication procedures be undertaken to ensure that the current user ID registered for validation is that of a current student in the university. User IDs for former students shall not be included as part of the new portal validation procedure. In ideal scenarios, the functionality requiring a student to log in to the new portal will require that the student provide an answer to a security question that was previously registered with the new system. The level of this plan is at the testing level and this shall not comprise of the unit testing for the particular portal, as the portal will be subjected to various revisions from time to time, based on the recommendations on its usability and interfaces obtained. However, given that this new portal is enormous in its context, not the entire system will be subjected to the tests except for the mentioned sections that shall also be determined based on their functionality and expected conditions by the University/client. This test plan shall thus, seek to address the aspects of the test such as the scope, objectives, process overview, testing strategy, entry and exit criteria, bug tracking, roles and responsibilities, test schedules and resources, deliverables and the communication plan. Each of these sections shall be subjected to detailed and comprehensive analysis and discussions in order to outlay each of the aspects for the test plan. 2 TEST SCOPE 2.1 Identification The scope for this test plan shall only detail the addressing of the items that relate to the New Portal Password reset process to be adopted by the university. The test plan shall basically describe the system and incorporation tests that will be accompanied on the New Password Reset Process following the integration of the sub-systems and other components that were recognized from the user interface assessments conducted on the old system. The assumption in the conduct of this test shall be that the unit testing shall not be carried out, as the same ought to have been provided for through the black box testing, testing of the module interfaces and the extensive coverage of the source codes. The main purpose for this overhauling of the password system was to test the performance and feasibility of the selected portal interfaces. In this plan, the most essential aspect is that all the sections of the system and its sub-system interfaces should be tested, as well at this early stage in conjunction with the performance of the system. However, the system features and their functionality shall not be subjected to the tests, particularly the prototypes. In other aspects, the scope for this testing shall entail the subjection of the following sub-systems to the tests. i. The registration process at the University. ii. The course catalog. iii. The finance system. Therefore, the testing of this new system is done with the hope that the new portal will provide the same level of information to students and in more details than the current (old) system, but without hindering improvements to be made to it. Additionally, the respective individuals, and granularity (availability of the levels of the details) shall be the core themes in the conducting of the integration and system tests with the aim that there will be an increase in the acquisition of data. 2.2 Overview of the new System The University having developed the new password reset process as part of its portal review process; will require that this be subjected to various integration procedures to determine the adaptability of the same to users’ profiles. However, due to the sensitivity of the codes used in the developing of the application, the scope for this test shall not entail the analysis of the codes as the same shall also not be made available to the ITS Support team. The implementation for this whole system as a final document is due for submission and implementation. Given that this test shall be majored upon the new password reset process as part of the new portal interface, the core operational areas for the analysis and test shall include, but not limited to: a. Ensuring that the new pass is more than 8 characters and includes an uppercase letter, a special character and a number. b. Validation of the user ID and making sure that it is for a current student. c. Requiring that the system commands the students to provide answers to specific questions when attempting logging from an unrecognized application. In total, there shall be a pool of 5 questions that had been previously answered by the students. d. Ensuring that the users change their passwords at every semester and that the system does not allow for the recycling of the previously used passwords. e. Inclusion of a CAPTCHA image that would ensure that the reset of the passwords stored in the system is not automated requests from hackers and not the expected users. This will be used as a further security feature to the log in process in the system (Kaner, 2012). Furthermore, the conduct of this test plan shall ensure that there is an integration with the older interfaces as had been in use by the University. Subsequently, all the other functions of the MU Portal shall be integrated to each other during the test process. 2.3 Document Overview The document for the test plan will be used to track and document all the necessary information and data that will be prerequisite to meritoriously define the approach being used by the ITS Support Team to test the product of the project (New Password Reset Process in the MU Portal). This test plan document was created during the project’s planning phase, and the intended audience was the Project Manager – Mark, ITS Executive Director, the Quality Assurance Manager – John and the ITS Support Team. Given that the ITS Support Team shall be the one concerned with the testing of the application, no further testing teams shall be formed to review the document. The development team will be required to share some portions of this document with the client (MU University), and other stakeholders who may have an interest in the redefining of the Portal system at the institution. However, this will be done with extra caution, but with an open mind as the input/approval of such third parties may prove beneficial to the testing process and implementation of the new portal system. This project is estimated to have a timeline of 6-months, which will be deliberated as an aggressive period for the project. During this period, there is no expectations for delays whatsoever in the development process for the portal, nor in the installation and the certification/verification of any third party software that could be affiliated to the project. This is because the ITS Support Team fears that any delays in this project would have substantial effects on the test plans. In this document, the concern is the expression of the various ways by which the installation and implementation of this new portal can be achieved without having to face any further glitches. Moreover, it is expected that the team will be free to provide frequent reviews to the system in all its forms in situations that could be detrimental to the adaptability of its interfaces. However, the ITS Support Team has approximated the acceptance testing to take about one month from the date that the application will be delivered from its system test. This acceptance testing should be done in parallel to the current application settings. 2.4 Relationship to other plans This test plan shall be related to the other plans such as the master test plan that typically addressed all of the multiple tests into the system, and the phase test plan that addressed only particular test phases, individually. Furthermore, the test plan shall outline the relationships that shall exist to other plans such as the integration test plans, the system test plans, and the acceptance test plans. 3 TEST OBJECTIVES The objective to define and report on the possible bugs that might be detected during the usage of the application by students when accessing the portal. This is guided by a desire to ensure that the integrity of the program is improved and become widely accepted across the various departments in the University. Despite the impossibility of conducting exhaustive testing at this stage, a broad range of tests will be exercised in order to achieve the set goals. Moreover, the testing shall comprise of a Binary Search Tree Application through the utilization of the pre-order traversal layout. The key functions that shall define and be used to manage the application include the delete, create, store/save, search, clear and list (ascending and descending) commands. In order for the Portal user interface to utilize these functions, it will be designed in a friendly manner that shall provide ease in the manipulation by the students. However, this shall not imply that it will be easy to compromise the system by activities of hackers. Given that this application will only be applied as a demonstration tool, the team would ensure that it has the capacity to run from a variability of platforms without having a huge influence on the performance of the application. 4 PROCESS OVERVIEW The overall flow of the testing process can be represented by the following stages: Identification of the system requirements to be subjected to the test. The derivation of the test cases, however, shall be achieved by the contemporary program specifications. Identification of the specific test (s) to be applied in the testing of each of the modules. Reviewing of the test data and cases so that there is surety in the verification of the units having been done appropriately. Subsequently, this will be significant in considering whether the test data and cases are adequate for the proper verification of each of the units. Identification of the expected results in each of the tests. Documentation of the test data, cases, and configurations applied in the testing process. This information will be submitted through the System Test Report (STR). Requirement for a successful unit testing before the declaration of the unit as being fit for component system/integration testing. Generation of a bug report in the event that the testing process becomes unsuccessful. This report should be able to describe in detail the test case, the problems that were encountered, the possible cause of the errors/problems and the categorization of proceedings that led to the problem. The Bug report is essential as it shall be used to form the basis for technical analysis that might need to be carried out in the program in the future. Immediate submission of the test documents and reports, detailing the specifications requiring review, revision or updating by the client (Kaner, 2012). 5 TESTING PROCESS Figure 1: Test Process Flow The above diagram outlines the testing process that shall be followed in this project. Detailed explanations of each of the stages are as described below. a. Organizing the project: Shall involve the creation of system test plan, schedule and testing approach, and the allocation of responsibilities to specific members. b. Designing/Building of the System Test: This stage would involve the identification of the test cases, test cycles, the entry and exit criteria, and the anticipated results, among other aspects. Generally, the test conditions will be identified by the ITS Support Team with the assistance from the Development Team. Furthermore, the Test Support Team will recognize the test cases and the prerequisite data for the same. The conditions for the test will be acquired from the Program Specifications Document. c. Designing/Building the test procedures: In this, the necessary procedures such as the Status Reporting and the Error Management Systems will be set up. d. Organizing/Building the Test Environment: Shall include the building hardware, software, and setups of the data. e. Execution of the System Tests: The tests that had been recognized Design/Build Test Procedures will be executed at this stage. All the obtained results will be required to be documented, and the bug report forms filled and taken to the Development Team for their consideration. f. Signing off: After conducting all the procedures, this will take place after all the pre-defined criteria for doing the same have been attained. 6 TESTING STRATEGY The table underneath summarizes the various types of testing that will be performed for the integration and system testing. Even though this includes the aspects to be tested, the specific use of the cases will define the performance of the testing. Figure 2 below shows the template to be used in designing the cases to be used in testing the strategy. Tested By: Test Case Number Test Case Name Test Type Test Case Description  Item(s) to be tested 1   2 Specifications Input Expected Output/Result Procedural Steps 1   2 3 4 5 6 7 This table will need to be filled in depending on the exact use cases and procedures to be conducted. 6.1 Black box testing This form of testing includes the running of the program through the probable inputs to be able to ascertain that it leads to the right outputs when a software is used in a manner that an end-user would. In this test plan, the decision by the team is to conduct the Boundary Value Analysis, and the Equivalence Partitioning tests to the application (Kaner, 2012). 6.1.1 Boundary Value Analysis The ITS Development Team decided on the acceptable range of values that could be used in this application. Given the limitations presented by the GUI, the size of the input values was also limited to only 3-digits integers so as to allow for easy computations. The acceptable and invalid ranges to be used in this design are as shown below. Alongside are the valid and invalid boundary test values for the application. Acceptable Range: -999  x  999 Valid Boundary Tests: Boundary1: x = -999 Boundary2: x = 0 Boundary3: x = 999 Invalid Ranges: - < x < -999 and 999 < x < +  Invalid Tests: Boundary4: x = 1000 Boundary5: x = -1000 6.1.2 Equivalence Partitioning Considerations for the inputs for the testing will entail two main types of values. i. Legal input values: These will be the test values that will be found in the boundaries of the specified equivalence classes. These values shall include input data that the program will expect and to which the application will be programmed to transform into values that can be used by the end-users. ii. Illegal values: These are values representing the equivalence classes that will exist outside of the specification boundaries. Thus, even though the program may present the input data, no meaningful output will be fashioned from them. This technique used as a test case selection requires that the designer examine the input space that shall be definite for the unit being tested. It also seeks to determine the input sets to be processed identically. The equivalence classes valid and invalid as shall be allowed in this test are as presented in the table below. Input/output result Valid Classes Invalid Classes Allowed values input maximum number 20 values > 20 values Input integers Between –999 & 999 Integers > 999 or < -999 Non-integers (characters & decimal values). Load external file Delimited COMMAS with one value in each line. File exists No commas No file content/ File does not exist Multiple entries per line Storage of external files File exists File does not exist 6.2 Integration Testing This shall engage the incremental testing in which two primary modules will be required to be integrated. The first is the Graphic User Interface, and the second is the Tree Repository (Back-end) module. Upon the integration of these interfaces, the complete Binary Search Tree Application will be formed. These modules are further described below: a. Graphic User Interface: A module that provides the simplest GUI that allows the users to perform various functions. It will be tested separately from the other module in order to check if its interfaces are functioning well e.g. the save button. Subsequently, the tests on this module will be to find out if the actions by mouse events are properly working. The testing will be through the writing of a stub for the elements in the interface. b. Tree Repository/Back-end: Offers the storage capacity for the elements of the data to be used in the application, and the algorithms to be associated to each of the binaries and functionalities. Its separate testing will be done through the printing of the results to the Console. However, the incremental method will be followed in testing for the module, until all the functions that are required are obtained. The combination of the back-end and the GUI modules will result in the formation of a complete binary tree application. Furthermore, to achieve completeness in the integration, the elements in the GUI module will be tested by substituting the stubs with the applicable functions from the back-end module, and the results presented within the GUI module. The substitution of the stubs will take place singly until all have been substituted. 6.3 System Testing This is aimed at detecting the faults that can result from the exposure of the all-inclusive integrated system to the testing. It will be concerned with the areas such as security, configuration sensitivity, performance, validation, and the stress/load (Kaner, 2012). However, for the case of this application, the concern shall be on the performance and validation of the system. 6.3.1 Performance Testing We shall conduct this test by evaluating the system’s fulfillment so as to compare it with the requirements that were specified. The testing will be conducted via the black box method by: Deleting all the unnecessary data and then checking whether it follows the right algorithms for sorting the results. Storage of the data to its maximum file level, and then trying to insert more data, and then observing the behavior of the application if it will go beyond the boundary. Trying to load the same data when they had been loaded already to check if there is any conflict of data. Trying to store already stored data and checking if the former will be overwritten. 6.3.2 Validation Testing This test will be based on the system requirements; thus, ensuring that the right applications are built. Faults noted in the system will be detected, and appropriate measures will be taken to ensure that proper implements of the binary algorithms are attained, and in the required location (Kaner, 2012). Consequently, the behavior of each function contained in the software specification will be recorded. Additionally, the test would entail the checking of the interface to determine if it is operational as anticipated. The interaction between the back-end interface and GUI repository shall also be examined by inserting data and checking if it is processed in the anticipated output format. 7 ENTRY AND EXIT CRITERIA This section is about the description of the criteria that will be used in testing the commencement, temporary stoppage, resumption and completion of the process in the new password reset process in the testing phases. There may be a slight variation in the criteria for the components/features, whereby this will be solved through the mentioning of the same in the test plan. This testing phase will also map the definition of the impact level when a deficiency is entered into the bug tracking stage (Kaner, 2012). The assumption as has been carried throughout is that the unit testing had been carried out; hence, will not be necessary for this plan. This is also true given that the codes for this new portal process will not be revealed for security purposes. This stage of the test plan also requires the analysis of the black box testing and the white box testing to determine their entry and exit points. 8 BUG TRACKING/BUG PROCESS In the process of testing for software applications such as this case, there is often the option that the team members are likely to come across system behaviors that are extraordinary and are off the specified or expected or implied requirements by the product design. In such occurrences, it is recommended that the same be documented so that the bugs can be reproduced for the developers to take a critical look at them (Kaner, 2012). 8.1 Bugs expectations Supposing that the team notices that certain unexpected behaviors are noted, the following measures need to be considered. A track of the application version to which the bug was detected needs to be noted and kept under record. Determining whether the bug had earlier on been written or not. Indication of the steps required to reproduce the bug by writing of enough details so that other persons observing the bug can be able to duplicate it. However, it is required that one be more specific in this and avoid irrelevant access points. Recording the actual results. Assessing the expected results with the actual results based on the implied design specifications. Determining the implications of the bug i.e. how the defect will have an effect on the product quality. In the chart below, the impact levels that can be used in entering the bugs is defined. Impact Definitions Minor Live Release: Fix the bug before the official completion and release of the product. This will entail fixing the crashes or UE’s, content, and GUI changes vital for the discharge. Serious Beta Stopper: Users are likely to encounter this bug in the form of corrupted data, errors in calculations, incorrect data, and system crashes, on common user scenarios. Fatal Test Stopper: This applies in the event that a certain function cannot be accessed so that the bug can be fixed instantaneously. In such a case, the defect will prevent the Quality Assurance Manager from testing the functionality of the feature or its area, and sub-area. 8.2 Roles played by team members in the resolution of bugs a. Resolver: This is an Engineer, who is normally assigned a specific area in the program to monitor and gauge its performance and functionality. b. Author: This is the individual responsible for the writing of the bug, an in most instances he/she shall belong to the ITS Support Team. c. Verifier: Usually, this different Engineer is tasked with the responsibility of testing, fixing and closing the bug upon satisfaction of its resolution. 8.3 Bug Report Form Often times, the review process will encounter bugs and in the event of such occurrences, it is appropriate that the same are formally recorded in the form. This form shall be availed to each of the team members. In this software testing process, the team in reporting bugs that arise shall use the following form. Reference Kaner, C. (2012). Testing computer software. Hoboken, N.J: Wiley. Read More