Abstract:
A wireless mobile device for tracking the progress of testing a set of software modification projects in an install plan uses a centralized project database where the testers can update their progress of testing software modification projects as they perform the tests. The central database advantageously eliminates the need to contact individual testers of each and every project every time a status report needs to be generated. Instead, through the wireless mobile device, a manager at any time can automatically generate status reports which contain the testing progress of particular projects in real-time to more accurately monitor what projects are on track and what projects may be falling behind schedule.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application is a continuation-in-part of pending U.S. patent application Ser. No. 11/964,367 filed on Dec. 26, 2007, which is incorporated herein by reference in its entirety. 
     
    
     FIELD OF THE INVENTION  
       [0002]    The present invention relates to a data processing system, and more particularly a system for tracking testing of software modification projects from a wireless mobile device. 
       BACKGROUND OF THE INVENTION  
       [0003]    Making modifications or enhancements to software running in a live computer system requires careful planning, especially if the system is a large transaction processing system such as VisaNet™, which processes over one hundred million financial transactions (e.g., credit card transactions) per day. Typically, a set of software modification projects are grouped into an install plan which has a projected install date. On the install date, all of the modification projects in the install plan are released into an active or production system at the same time. 
         [0004]    Each software modification project typically adds or modifies a particular feature. An example of a software modification project may be a feature to add a new transaction type such that the computer system can handle prepaid card transactions in addition to credit/debit card transactions. 
         [0005]    In turn, each software modification project typically affects multiple software applications. For each affected software application, a set of test cases are developed and tested by an assigned tester against the software application to ensure that there are no bugs. When all of the applications in each of the projects in the install plan are fully tested, the projects are released into a live system at the designated install date. 
         [0006]    Often, administrators, managers and software testers need to track the progress of testing the software modification projects of a particular install or a particular project within the install to assess where the potential problems lie and whether the projects can be released by the designated install date. Traditionally, the manager would either call or email individual lead testers to report the progress of testing the software modification projects. When all information has been gathered, the manager would then prepare a test progress report summarizing the test status of all projects. As can be appreciated, this process of tracking the progress of testing is very time consuming. Moreover, as some testers may be tardy in responding to the manager&#39;s request for status, the report may not represent the true testing status at a particular time. 
         [0007]    Therefore, it is desirable to provide a system and method for more efficiently and more accurately tracking the progress of testing software modification projects. It would be also desirable to track and update such progress by using a wireless mobile device. 
       SUMMARY OF THE INVENTION  
       [0008]    According to one aspect of the invention, a wireless mobile device for tracking the progress of testing a set of software modification projects is provided. The wireless mobile device includes a wireless transceiver, an input device and a processor. 
         [0009]    Through a wireless network, the wireless transceiver communicates with a tracking computer coupled to a project database. The project database stores a plurality of project data with each project data corresponding to an associated software modification project and containing a test progress indicator updatable by a tester. The input device receives a selection of projects from a user. The a processor is capable of sending a request for status report on the selected project data to the tracking computer, and receiving the status report which the tracking computer has prepared based on the project data retrieved from the project database responsive to the sent request for status report. For each project by the user, the status report contains a project progress value (e.g., percentage completion of testing) representing a progress in testing the project, the project progress value being based on the test progress indicator of the project. 
         [0010]    As can be appreciated, the present invention uses a centralized project database where the testers can update their progress of testing software modification projects as they perform the tests. The central database advantageously eliminates the need to contact individual testers of each and every project every time a status report needs to be generated. Instead, through the wireless mobile device, a manager at any time can automatically generate various types of status reports which contain the testing progress of particular projects in real-time to more accurately monitor what projects are on track and what projects may be falling behind schedule. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0011]      FIG. 1  is a block diagram of an exemplary software modification tracking system. 
           [0012]      FIG. 2  illustrates a block diagram of a server computer that stores and executes a project tracking software module. 
           [0013]      FIG. 3  illustrates a menu map of the project tracking software module. 
           [0014]      FIG. 4  is a screen shot of a main menu page of the project tracking software module. 
           [0015]      FIG. 5  is a screen shot of a status report page through which a specific type of report is selected. 
           [0016]      FIG. 6  is a screen shot of a project maintenance page through which a software project is added, deleted and modified. 
           [0017]      FIG. 7  is a screen shot of a software application maintenance page through which software applications belonging to a particular project is added, deleted or modified. 
           [0018]      FIG. 8  is a screen shot of a forecast date page through which completion dates for various applications are forecast. 
           [0019]      FIG. 9  is a screen shot of an interface test maintenance page through which an interface test is added, deleted or modified. 
           [0020]      FIG. 10  is a screen shot of a regression test maintenance page through which a regression test is added, deleted or modified. 
           [0021]      FIG. 11  is a screen shot of an integration test maintenance page through which an integration test is added, deleted or modified. 
           [0022]      FIG. 12  is a screen shot of an audit trail page through which an audit trail for a particular software install plan is selected. 
           [0023]      FIG. 13  is a screen shot of an audit report page containing an audit trail for a software application of a particular software project. 
           [0024]      FIG. 14  is a screen shot of a status report page that summarizes the progress of a particular software install plan by software projects. 
           [0025]      FIG. 15  is a screen shot of a report card page through which individual software projects for a particular software install plan can be selected. 
           [0026]      FIG. 16  is a screen shot of a status report page that summarizes the progress of a particular software install plan by software projects. 
           [0027]      FIG. 17  is a screen shot of a personal status report page through which software projects across different software install plans for a particular software tester can be selected. 
           [0028]      FIG. 18  is a screen shot of a personal status report page that summarizes the progress of software projects that have been selected through the screen shot of  FIG. 17 . 
           [0029]      FIG. 19  is a screen shot of a status report page that summarizes the progress of interface tests. 
           [0030]      FIG. 20  is a screen shot of a status report page that summarizes the progress of regression tests. 
           [0031]      FIG. 21  is a screen shot of a status report page that summarizes the progress of integration tests. 
           [0032]      FIG. 22  is a block diagram of an exemplary software modification tracking system using a wireless mobile device. 
           [0033]      FIG. 23  illustrates a block diagram of a wireless mobile device as shown in  FIG. 22 . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0034]    For purposes of this application, the terms “code”, “program”, “application”, “software code”, “software module” and “software program” are used interchangeably to mean software instructions that are executable by a processor. 
         [0035]    An exemplary block diagram of a software modification test tracking system  10  is shown in  FIG. 1 . The tracking system  10  contains a server  12  and a software project database  14  in communication with the server. The system  10  can be accessed by software testers and any manager interested in tracking the progress of testing a particular project or a set of projects. In the embodiment shown, the software project database  14  is a relational database using MS SQL Server from Microsoft Corporation of Redmond, Wash. although any type of a database management system can be used. 
         [0036]    The system  10  is connected to a computer network  4  through a communication link  6 . In the embodiment shown, the network  4  may be a private network such as an Intranet, private network such as an Internet, or a combination of private and public networks. 
         [0037]    Referring now to  FIG. 2 , the server  12  of the present invention centrally tracks the status and progress of testing various software modification projects. In one embodiment, the software modification projects relate to software code for a processing system that processes financial transactions involving financial presentation devices (e.g., credit cards and debit cards) that are presentable to providers of goods or services. The server  12  includes a multitasking, real-time software technology that can concurrently handle multiple users. 
         [0038]    The server  12  is connected to the communication link  6  through an I/O interface  22 , which receives information from and sends information over the communication link  6  to the computers  8  of various users. The server  12  of  FIG. 2  includes memory storage  24 , processor (CPU)  26 , program storage  28 , and data storage  30 , all commonly connected to each other through a bus  32 . The program storage  28  stores, among others, a project tracking program or module  34 . Any of the software programs in the program storage  28  and data from the data storage  30  are transferred to the memory  24  as needed and is executed by the CPU  26 . In the embodiment shown, the project tracking module  34  is written in Active Server Pages (ASP) language. 
         [0039]    The server  12  can be any computer such as a personal computer, minicomputer, workstation or mainframe, or a combination thereof. While the server  12  is shown, for illustration purposes, as a single computer unit, the system may comprise a group/farm of computers which can be scaled depending on the processing load and database size. 
         [0040]      FIG. 3  illustrates a menu map  60  of the project tracking software module  34  according to the present invention. The menu map  60  will be explained in conjunction with  FIGS. 4-21 . Referring to  FIG. 4 , after a user logs in through the computer  8  and runs the project tracking software module  34 , the module generates a Main Menu web page  100  and transmits it across the network  4  to the user&#39;s computer  8  which is viewed via the user&#39;s web browser such as Microsoft&#39;s Internet Explorer. In the embodiment shown, the network  4  is an Intranet. The menu page  100  lists seven clickable links among others: Reports, RTN List, Completion %, Interface, Regression, Integration and Audit Trail. Clicking on each link respectively generates web pages  120  ( FIG. 5 ),  140  ( FIG. 6 ),  160  ( FIG. 8 ),  180  ( FIG. 9 ),  200  ( FIG. 10 ),  220  ( FIG. 11) and 240  ( FIG. 12 ). 
         [0041]    As can be seen in a status report page  120  in  FIG. 5 , there are four types of tests that are performed on the software features being modified or added: functional testing, interface testing, regression testing and integration testing. Functional testing is the most basic testing which is performed for each and every project. Functional testing is performed to ensure that the changes required by each project are working as required and expected. There are two types of functional testing: negative testing and positive testing. Positive testing involves ensuring that all valid data related to the enhancement are processed correctly through the card transaction processing system. Negative testing involves ensuring that invalid transactions or data combinations are properly processed through the processing system. 
         [0042]    Interface testing involves tests that are performed to ensure that upstream and downstream applications accurately communicate with the new enhancements and applied changes. Interface testing ensures that the code revisions have not negatively impacted or broken the communication paths or patterns between different applications. 
         [0043]    Regression testing serves as a safety net and is performed to ensure that existing services or functionalities were not changed unless specifically detailed in the requirements as enhancements/changes being introduced in the implementation. 
         [0044]    Integration testing is an extension of functional testing. In this test, all modules are combined and tested as a group to ensure that the changes required by the different projects are working as required as a group. The status report page  120  will be described in more detail later herein. 
         [0045]    Referring to  FIG. 6 , the web page  140  is a project maintenance page (RTN List) through which software projects for a particular install plan are maintained by a test administrator. Each software project is tracked by and is given a number called a request tracking number (RTN). In the page  140  shown, all projects associated with an install date of Jul. 27, 2007 are maintained. The project maintenance page  140  has a top portion  142  through which a project is added and a bottom portion  144  through which selected projects are modified or deleted. 
         [0046]    Each project has various attributes including “Maint”, “RTN No.”, “CC”, “Name”, “Install Date”, “QA Proj Risk”, “For Member Testing”, and “Interface” which are maintained in the project database  14 . “Maint” stands for maintenance item and is used to indicate that the particular project is a bug fix, and not a new feature or a modification of an existing feature. “Name” refers to a project name or identifier. “RTN No.” is a project identifier that identifies each project by a number. For example, the project named “VisaNet Cirrus Gateway” has an associated RTN No. 811030. “CC” stands for change control number and is used to indicate a change that has been requested by a customer or software developer. In the case of a card transaction authorization system, the customer is generally a financial institution that issues cards such as debit, credit or prepaid cards. “Install Date” refers to a particular projected install date at which time all of the projects associated with a particular install plan are released into a live system. “QA Proj Risk” refers to a project completion risk factor and can be low, medium or high. The risk factor is determined based on the complexity and importance of the project. “For Member Testing” is used to indicate whether a member financial institution needs to test the project. For example, a project that adds a new field in an authorization request message to a member bank needs to be tested by that bank to make sure that its computer system can recognize and handle the authorization request message with the added field. “Interface” refers to whether the project requires an interface testing. 
         [0047]    To add a software project, the administrator would input various attributes described above in the appropriate input boxes in the top portion  142  and click the “ADD RTN” button  146 . In response to the click, the computer  8  transmits the data regarding the new project to the server  1   2  through the network  4 . The project tracking module  34  then adds the new project and displays the added project in the bottom portion  144 . 
         [0048]    The bottom portion  144  shows a table of existing software projects for a particular install. Each project is displayed in a single row. To modify attributes of an existing software project, the administrator would make the changes to the displayed attributes using a mouse of the computer  8  and click the “COMMIT CHANGES” button  148 . The project tracking module  34  then makes the changes to the project database  14 . 
         [0049]    Once a project is added, the set of software applications that are affected or modified by the project need to be added. Clicking on a “VIEW” button  145  associated with the project brings the administrator to a software application maintenance page  150  (see  FIG. 7 ) through which the affected software applications are added, deleted or modified. 
         [0050]    In the page  150  shown, all applications associated with a particular project are maintained by the administrator. The application maintenance page  150  has a top portion  152  through which an application is added and a bottom portion  154  through which the applications are modified. 
         [0051]    Each application has various attributes related to functional testing and include “Code T/O MM/DD/YY”, “TD/TC MM/DD/YY”, “% TC Executed”  153 , No. of Trans.”, % of Trans. Validated”  155 , “Opened DRs”, “Deferred DRs”, “Cancelled DRs”, “No. of Active DRs” which has sub-attributes of “Sev 1”, “Sev 2”, “Sev 3” and “Sev 4”. 
         [0052]    “Code T/O MM/DD/YY” refers to the date the software code is turned over to the quality assurance department for testing by testers. “TD/TC MM/DD/YY” refers to the date lead tester expects the testers to complete the testing of the application. “% TC Executed”  153  refers to the percentage of test cases that have been executed. “No. of Trans.” refers to the sum of all test transactions that have been created for each test case. Each test case can have a minimum of one transaction or thousands of transactions depending on the complexity of the test case. As an example, assume that the portion of software application being modified relates to exchange rate conversions for card transactions that occur outside of the U.S. One test case may involve Japanese Yen to U.S. dollar conversion while another test case may involve Canadian dollar to U.S. dollar conversion. For each test case, there may be a number of transactions that need to be tested. For the Japanese Yen to U.S. dollar conversion test case, for example, one transaction may be a credit card transaction from Japan with a U.S. issuer bank. Another transaction may be a credit card transaction from Japan with a Japanese acquiring bank. Still another transaction may be a credit card transaction from Japan with a U.S. acquiring bank and U.S. issuer bank. 
         [0053]    “% of Trans. Validated”  155  refers to the percentage of executed transactions (among those in the executed test cases) that have been determined to be valid, i.e., the actual output matched the expected output. “% of TC Executed”  153  and “% of Trans. Validated”  155  comprise an application test progress indicator which is used to calculate an application test progress value. The application test progress value is calculated by multiplying “% of TC Executed”  153  by “% of Trans. Validated”  155  and indicates the percentage of tests that have been completed for the application. 
         [0054]    As an example, in the page  150  shown in  FIG. 7 , the application test progress value for an application called “GRS” is 44% as a result of multiplying 0.80 by 0.55. 
         [0055]    “Opened DRs” refers to the number of opened discrepancy reports, i.e., bugs, that have been found. “Deferred DRs” refers to bugs that have been determined to be non-critical. “Cancelled DRs” means the number of discrepancy reports that have been created in error. “No. of Active DRs” refers to the number of discrepancy reports that are being worked on and have not been cancelled. This attribute is divided into four different severity levels with “Sev 1” being the most severe and “Sev 4” being the least severe. A discrepancy report having a severity of 1 prevents further testing until the bug is fixed or brought down in severity. 
         [0056]    To add an application, the administrator inputs various attributes described above in the appropriate input boxes in the top portion  152  and clicks the “ADD APPLICATION” button  156 . In response to the click, the computer  8  transmits the data regarding the new application to the server  12  through the network  4 . The project tracking software module  34  then adds the new application and displays the added application in the bottom portion  154 . 
         [0057]    The bottom portion  154  shows a table of existing software applications for a particular project. As shown in  FIG. 7 , a project called “VisaNet Cirrus Gateway” affects three applications called “GRS”, “RSI” and “SMS OFF”. Each application is displayed in a single row. To modify attributes of an existing software application, the administrator would make the changes to the displayed attributes using a mouse of the computer  8  and click the “COMMIT CHANGES” button  158  to transmit the data to the server  12 . The project tracking software module  34  then makes the changes to the project database  14 . 
         [0058]    The application maintenance page  150  is also the page where the software testers update any of the appropriate attributes in the bottom portion  154  as testing progresses. 
         [0059]      FIG. 8  is a screen shot of a forecast date page  160  in which the lead administrator for a particular install forecasts completion dates for various applications. For each application, the lead administrator reviews all of the projects that modify the application and estimates the date by which certain percentage of testing for that application is to be completed. The page  160  has a top portion  162  through which forecast dates for each application are added and a bottom portion  144  through which the forecast dates are modified. 
         [0060]    Referring to the top portion  162 , to add an application forecast date, the administrator would input the install date for the application, application name, completion percentage and the forecast date, and clicks on the “ADD COMPLETION PERCENTAGE” button  146 . Typically, two forecast dates are added for each application. For example, 50% and 100% completion forecast dates are used. In response to the click, the computer  8  transmits the data regarding the new project to the server  12  through the network  4 . The project tracking software module  34  then adds the new forecast date and displays the added forecast date in the bottom portion  164 . 
         [0061]    To modify attributes of an existing application forecast date, the administrator would make the changes to the displayed attributes using a mouse and click the “COMMIT CHANGES” button  168  to transmit the data to the server  12 . The project tracking software module  34  then makes the changes to the project database  14 . 
         [0062]    Similar to  FIG. 7  for function testing, interface testing, regression testing and integration testing are added and modified through web pages  180 ,  200  and  220 , respectively, through  FIGS. 9-11 . 
         [0063]    As testing progresses, any tester can go to web pages  150 ,  160 ,  180 ,  200  and  220 , and make changes to the attributes to reflect the progress of testing. 
         [0064]    To ensure that unauthorized changes are not made, the project tracking software module  34  provides an audit trail by automatically recording any changes to the projects in the project database  14  including any addition, deletion and modification. By selecting a particular install date in a pull down menu  242 , the audit trail report selection page  240  in  FIG. 12  can be used to generate a complete or partial audit trail report for any install date. An exemplary report is shown in  FIG. 13 . The audit trail web page  260  show a report  262  for all of the changes that were made to an application named “RSI”. The report  262  includes the tester&#39;s identity, the date the change was made and the details of the change. For example, the report shows that tester named MMoreno added application RSI for project 810955 on Jul. 11, 2007, changed the attribute of “Code T/O” (see  FIG. 7 ) on Jul. 30, 2007, and deleted the application on Jul. 30, 2007. 
         [0065]    Once the projects and applications for a particular install have been set up and testing is in progress, any user can generate a variety of status reports through a status report page  120  as shown in  FIG. 5 . As explained above, there are four different types of testing for which reports are available: functional testing, interface testing, regression testing and integration testing. 
         [0066]    Within functional testing, there are four different types of status reports that can be generated by the project tracking module  34 : by each project (“Install Summary by RTN”), by install date (“Install Summary by Application Install Date”), by selected projects within an install plan (“Report Card”), and by projects selected from all install plans (“My RTNs”). The “Install Summary by RTN” report is similar to the (“Install Summary by Application Install Date”), the difference being that the latter includes projects that have been installed earlier than the planned install date. 
         [0067]    In the status report page  120 , the user initially chooses an install date from a pull down menu  122 . Selecting “Install Summary by RTN” and clicking “VIEW REPORT” generates a status report page  280  (see  FIG. 14 ) that summarizes the progress of a particular software install by software projects. The report as shown in  FIG. 14  includes, for each project, a project identifier (“RTN”), project name (“Name”), project risk (“QA Proj Risk”), number of active bugs (“DR”) and their severity (“sev1” through “sev4”) and project test progress value  282  (“% Complete”) which represents the test completion percentage of the project. 
         [0068]    For each project, the number of active bugs at a given severity level is derived by adding the number of bugs at the given severity level for each application being affected. 
         [0069]    The project test progress value  282  for each project is derived as follows. First, for each application of a project, the project tracking module  34  calculates an application test progress value based on the application test progress indicator. Specifically, the application test progress value is calculated by multiplying the “% TC Executed” attribute  153  by “% of Trans Validated”  155  attribute which indicates the test completion percentage for the application. Second, for each project, the project tracking module  34  calculates the project test progress value  282  by averaging the application test progress values for all the applications of the project. 
         [0070]    For example, in the software application maintenance page  150 , the project test progress value is calculated by the following: (0.80*0.55+0.95*0.85+1.00*1.00)/3. Accordingly, the project test progress value is 75%. 
         [0071]    Alternatively, instead of using “% of Trans. Validated”, the project database  14  could track two attributes with one attribute representing the number of transactions executed and the other attribute representing the number of executed transactions that have been validated. In that case, “% of Trans. Validated” could be calculated simply by dividing the number of validated transactions by the number of executed transactions. 
         [0072]    The status report page  280  of  FIG. 14  also includes an overall test progress value (“Overall Install Completion Percentage”) that represents the test completion percentage of the entire install plan. In the page  280  shown, the overall progress indicator is calculated by a weighted average of the project progress values  282  for all projects, the weight being dependent on the project risk factor. In the embodiment shown, the weights given for Low, Medium and High project risks are respectively 1, 2 and 3. Thus, the overall test progress value is calculated by multiplying each project progress value  282  by its weight of 1, 2 or 3, and adding them up for use as a numerator and by adding the total number of weights for use as a denominator. In the example shown in  FIG. 280 , the numerator is 5.82 and the denominator is 35. Accordingly, the overall progress value is 17%. 
         [0073]    From the status report page  120  of  FIG. 5 , selecting “Report Card” under Functional Testing and clicking “VIEW REPORT” generates a project selection page  300  (see  FIG. 15 ) that lists all of the projects in an install plan.  FIG. 15  shows all of the projects for an install date of Oct. 12, 2007. To the left of each project is a check box  302 . Checking the check boxes  302  for selected projects and clicking on “View Report” generates a selected projects report page  320  (see  FIG. 16 ). The selected projects report page  320  is similar to the status report page  280  of  FIG. 14 , except that for each project selected, the report lists detailed test progress data for each application for that project. 
         [0074]    For each project selected in the project selection page  300 , the report  320  as shown in  FIG. 16  includes, among others, the project identifier (RTN), project name (Name), project risk (QA Proj Risk), the number of cancelled and deferred bugs (“Cancelled DRs” and “Deferred DRs”), and project progress value  282  (“RTN Percentage Completion”). 
         [0075]    Moreover, the report  320  includes a detailed breakdown of test progress data for each application of each selected project including the percentage of transactions that have been executed (“% TC Executed”), percentage of validated transactions (“% of Trans. Validated”), application test progress value (“% Complete”), number of opened bug reports (“Opened DR”s), number of active bug reports (No. of Active DRs”) and their severity (sev1 through sev4), and the number of cancelled and deferred bug reports. The report page  320  also includes a project progress indicator (“RTN Percentage Completion”) which represents the test completion percentage of the project. 
         [0076]    Referring back to  FIG. 5 , selecting “My RTN” and clicking “VIEW REPORT” generates a personal project selection page  300  (see  FIG. 17 ) which lists all of the projects that have been assigned to a particular tester across different software install dates in the future. The personal project selection page  300  is similar to the project selection page  300 , except that the projects available for selection in page  300  include all projects across different install plans. For example, projects R810713 and R810955 are listed even though they belong to different install plans. 
         [0077]    In  FIG. 17 , selecting check boxes  342  for selected projects and clicking on “View Report” generates a personal status report page  360  as shown in  FIG. 18 . The report page  360  is similar to the projects report page  320 , but that it also displays an install date for each project as the date can be different from project to project. 
         [0078]    Referring back to  FIG. 5 , selecting “Report Card” under Interface Testing and clicking “VIEW REPORT” generates an interface test progress report page  380  (see  FIG. 19 ) which summarizes the progress of interface testing for a particular install plan. As in other reports such as the projects report  320 , the interface test progress report  380  includes the number of transactions to be tested, interface test progress value (“% Complete) which is calculated by multiplying “% Test Data Created” by “% of Trans Validated” (see  FIG. 9 ), and various data regarding the bug reports DR. In addition, the interface test progress report  380  includes a list of projects that are participating in the interface test. The list of participating projects is obtained from the “Interface” attribute (see  FIG. 6 ). 
         [0079]    Referring back to  FIG. 5 , selecting “Report Card” under Regression Testing and clicking “VIEW REPORT” generates a regression test progress report page  400  (see  FIG. 20 ) which summarizes the progress of regression testing for a particular install plan. As in other reports such as the interface test progress report  380 , the regression test progress report  400  includes the number of transactions to be tested, regression test progress value (“% Complete) which is calculated by multiplying “% Test Data Created” by “% of Trans Validated” (see  FIG. 10 ), and various data regarding the bug reports DR. 
         [0080]    Again referring back to  FIG. 5 , selecting “Report Card” under Integration Testing and clicking “VIEW REPORT” generates an integration test progress report page  420  (see  FIG. 21 ) which summarizes the progress of integration testing for each project of a particular install plan. As in other reports, the integration test progress report  420  includes for each project the number of transactions to be tested, integration test progress value (“% Complete) which is calculated by multiplying “% Test Data Created” by “% of Trans Validated” (see  FIG. 11 ), and various data regarding the bug reports DR. 
         [0081]      FIG. 22  is a block diagram of an exemplary software modification tracking system using a wireless mobile device  40  such as a cellular telephone or personal digital assistant. The wireless mobile device  40  communicates with the server  12  through a wireless network  36  which is in communication with the general network  4 . As shown in  FIG. 23 , the wireless mobile device  40  is essentially a portable computer device containing a wireless transceiver that communicates with the wireless network  36 . Specifically, similar to the server computer  12 , the mobile device  40  includes a processor  46 , input device (e.g., keypad)  42 , memory  44  and display  56  all of which are coupled to a common bus  58 . The device  40  further includes a communication device (e.g., transceiver)  52  that communicates with the wireless network  36 . A web browser module/program  50  stored in a storage device  48  in conjunction with the input device  42  and processor  46  allows a user to interact with the server  12  in much the same way the computer  8  communicates with the server to select and retrieve status reports, and to update various fields in the database  14 . Like the computer  8 , the mobile device  40  is capable of displaying on its display  56  all of the screens shown in  FIGS. 4 through 21 . 
         [0082]    A secure communication module/program  54  in the mobile device  40  in conjunction with the processor  46  provides secure communication between the mobile device and the server  12 . In the embodiment shown, the processor executing the secure communication module  54  creates a virtual private network (VPN) between the mobile device  40  and the server  12 . The VPN utilizes an asymmetric encryption to protect the data being received and transmitted. 
         [0083]    In the embodiment shown, the data being transmitted by the server  12  is encrypted with a server&#39;s private key and is decrypted by the mobile device  40  with a server&#39;s public key. In reverse, the data being transmitted by the mobile device  40  is encrypted with a mobile device&#39;s private key and is decrypted by the server  12  with a mobile device&#39;s public key. 
         [0084]    As can be seen by persons of ordinary skill in the art, the present invention provides a centralized database where the testers can add, update or delete applications, integration tests, regression tests, interface tests of a project and their corresponding status indicators through a wireless mobile device. The status indicators include progress of testing, bug status and bug severity. 
         [0085]    With the present invention, instead of contacting individual testers in all projects, the manager can now use a wireless mobile device to go to the centralized database to generate reports that track in real time the current status of a particular project, what applications may be causing delays, and how many bug reports are still open. 
         [0086]    The foregoing specific embodiments represent just some of the ways of practicing the present invention. Many other embodiments are possible within the spirit of the invention. Accordingly, the scope of the invention is not limited to the foregoing specification, but instead is given by the appended claims along with their full range of equivalents.