Ethan Williams

August 11, 2016

Building Windows Application for Software Testing and a Sample Java Application with Accompanying Guidelines for Integration

Integration Testing- Problem

At the beginning of my internship I learned about testing that Nexteer conducts on the various software packages that are bought from different companies. The software is received and test cases, which contain specific directions and expected results, are applied to the software. Depending on which software it is there are different sets of tests out of the thousands that have been created for this purpose. The issue that I solved was with how these tests were being kept track of. Everyone on the PLM team had access to a set of spreadsheets which had all of the roughly 200 test cases in them. This solution kept track of testing but presented several problems. The first and most important was that these relied on local storage. Each member of the team had the information in one document and could not view or work on the same information at the same time. This problem extended to difficulty in communication because the tests were kept track of verbally. This resulted in extra time testing things that had already been tested and completely missing some tests that were required. For this reason the PLM team was looking for a solution which would minimize the loss of information and the amount of time spent testing the software.

Example Spreadsheet

Solution from the CPI Team

My first week I sat in on a demo of a system that attempted to solve this problem using Microsoft Access, a simple database program which is in the Microsoft Office suite of products. This was far better than using Excel spreadsheets for several reasons. First, it could have a recorded history; for each new test that was done the record of who did it, if it worked or not, and comments were kept and could be viewed at any time. There was also a feature where the user could view all of the failed tests that had been conducted. The user could read what was supposed to happen and read the other user’s comments. If they figured out a way to fix the problem, they could correct it in the database and it would no longer be required to test. In addition, several reports could be generated to give users a better idea of progress in the testing process as well as accountability on previously recorded test cases. The final feature was the ability to add new users, test cases, and software versions to the database. The solution using Access was much better than the Excel spreadsheets because there was a record for accountability and an easier way to store the data by the creation of a simple front end for the user. The issue still remained that this used localized storage though. The Access file had to be transferred to another computer in order to have the database and front end available.

Main screen for CPI testing

Adding a new test record

Adding new users, versions, or test cases to the database

Correcting failed test cases

My Solution

Organization

When given all of the integration test cases, for which I was responsible for creating a system for, I went through each of the spreadsheets and determined what information I would need to store in a database. Working with Chad Foster we decided that all test cases could be broken down into an overarching category, a subcategory, and a specific test case ID that denoted individual test cases. Databases work with tables, so I had one table which held all the information which was needed on a test case, including category, subcategory, and test case ID, a description of the test case, a condition on which it would be run, and the expected results that a user should get when they performed the test. My other main table stored the records of test cases that were performed. This included information on who had conducted the test, whether it had passed or failed, if there were any comments on the test, and what day the test was conducted on. My third main table was used to store which test cases were needed for a specific software release. Because not all 2200 test cases are tested every time, the team and I decided there needed to be a function within the application to find which test cases needed to be tested given a release. This table includes the release and the test case that is needed for that release. Other tables are linked tables to help with ease of data management storing categories, subcategories, users, releases, logs, and rules/ administrative notes which are referenced by the other tables.

SQL Server

The first idea I had on how to improve the system that was being used by the CPI team was to use a SQL server for the database. This solved the problem of localized storage because several people could edit and view information stored in the database at the same time. I was initially going to host the database on my laptop with an account tied to my Nexteer email. This wouldn’t work though because after I left for school my email would be recycled nobody would have access to the server. I learned that Nexteer has servers dedicated to SQL so I connected with Luke Stehle and got a portion of database 39 to host my information. I set up all of my tables in that database and started to build a front end to make user interaction with the database easier and safer.

Version 1

After talking with the PLM team we decided that the first version using the SQL back end should be similar to the Access file that was built for use by the CPI testing team. I decided to build a Windows application for several reasons. The first was that it was easier and more secure than hosting an online application. I would have had to find web hosting space which Nexteer doesn’t have very readily available, whereas an application could be installed directly on users’ computers. Also, anyone who had the link could access the database if I didn’t set up security on it, with a Windows application any user would have to have access to the installer in order to have access to changing the database which is much easier to control.

Main window of version 1

I built my first version with vb.NET using WinForms. I chose this because of my experience with Visual Basic while I was looking at the Access file that was being used by the CPI team; Visual Basic is the underlying language that controlled most of that program. Vb.NET with WinForms improved this because it created standalone applications with a GUI which could connect to a SQL server. My first version was very simple. The main functionality of this version was to record a new test case result. First the user chose the test using comboboxes which determined a query for the database. Upon choosing a test case the history of all records for that test case would be populated in a list below showing who had done the test, what the result was, the version, date, and any comments the tester had.

Adding a new record to the system

The second feature of the first version was generated reports. I decided to use Microsoft Word for my reports. I was able to programmatically generate tables and fill the tables with information from a SQL query which was also done programmatically. This was a better solution than the Access Reports because they were easier to deal with, although their problem was that it took a long time to generate. One test I conducted which had 800 pages of tables took almost 20 minutes to finish. For this reason I began looking at different ways to generate reports for future versions.

Viewing reports

I also had a very basic front end function so that users could add information about new users, versions, or test cases to the SQL database. Finally, the window to correct failed test cases contained a listview populated with a query of all failed records which could then be selected and marked as corrected in the database upon a solution found by the user.

Adding new users, versions, or test cases to the system

Correcting failed tests

I built and performed a demo of this application in only three days as it was strongly based on the Access application and didn’t require much more customization than that. During the demo the team gave me very valuable feedback on additions and revisions to the application at which point I set out to create a revamped version which I would work on for the majority of June and part of July.

Final Version

The final version was distributed to the team on July 17th and included major overhauls which were built in conjunction with weekly input from the PLM team. The most major change that was made was a switch in language that the application was built in. I switched to C# using WPF because with the addition of a XAML component I could customize the look and feel of the application much better and its runtime was slightly faster and more efficient.

Main window

Recording a new test case is now much more efficient than it was on the first version. First, the user will decide on a category and subcategory of a test case they are looking for. This will populate all of the test cases with their information in the database that match the criteria which are found with a SQL query. Additionally, users can filter that list by what software release they are looking for. So if none of those test cases are needing to be tested the list will clear making it much easier to not repeat tests, The user selects all of the test cases they want to add results for and clicks the add to batch button. A batch is the group of test cases the user is recording results for. Once all of the test cases have been added to the batch the user clicks the record button. This will take them to the part of the application that adds the record to the database. The user selects if it passed or failed, who is testing it, what the date is, and optionally can add comments. They then click the add button which adds the results of the batch to the database. This was meant to be as simple for the user as possible while also recording a lot of information on each test case.

Selecting test cases for the batch

Recording test results for the batch

The second feature of the application is correction of failed test cases. First, the user must choose a release. This specifies which version of the software that the user wants to check failed tests for. Upon selection the listview will populate with the test cases. If a user clicks on one of the test cases the condition, description, and expected results for the test will populate along with any comments that the testing user added to the record. If the user figures out a solution to make the test case pass they simply click the correct button which updates the database to reflect the fact that it is no longer a failed test.

Correcting a failed test case

The next feature is the reports. There are 8 options on reports that can be generated. This includes viewing the log which records any changes made for administrative and informational purposes on the PLM team, to a list of all 2200 test cases which can be filtered based on release or category. These reports are very useful because it’s taking a massive amount of information which is being stored on the servers and making it much easier to view and understand. This was improved over the reports in version 1 mainly because these are generated almost instantly even when there are hundreds of database records that are retrieved and shown. They are also much more customizable than the reports I built in version 1.

Choosing a report to view

Sample of a report in the application

The last few features are all very similar to each other in that it allows users to directly modify or add to the database. I did this in the front end because it’s much easier to maintain organization in the server when run through my algorithms for placement and it allowed me to control exactly what a user could put in the database so there were no errors. To update a test case is an example where I really wanted to control how the database was edited. The user is only allowed to change the condition, description, or expected result of the test case. They can’t rename it or delete it which makes the information in the database completely secure except for those fields. The user enters in everything they want to change for their selected test case and clicks the update button. This runs it through an algorithm I created to make sure it can be put into the database correctly and won’t cause any crashes of the database. In addition to this, the user can add a new release to the database, a new test case, a new log entry, or add test cases to the required list of tests for a release.

Updating a test case’s information

Adding a new log entry

Adding a new release

Adding a new test case

Adding test cases to the required list for a release

Effectiveness and Discussion

The final application that I created was much improved from the Access file for several reasons. Primarily this was because of the SQL server back end. This means that as long as someone has my application installed, they can access the database at any time and can view and edit it in real time and changes are seen from all other users’ computer. Also, it’s much easier to use due to my front end UX. The application flows very well and is very easy to use for the user, a big improvement over what existed before. Finally, it added many more features which allows for a much more useful and efficient way to conduct tests. The application is now in use by the PLM team and customization is being discussed for use in other groups to facilitate testing of other systems.

Excel Spreadsheets

CPI Testing Team Solution

Final Version

First Version

Teamcenter Services Example Application and Guidelines

My second project of the summer was on Teamcenter Services. The basic idea of this is that it allows creation, revision, and deletion of information from Teamcenter as well as retrieving data from third party applications over the HTTP protocol. This is useful in a variety of ways although the bottom line is that it increases efficiency with easier access to data between different software.

My first task in this was to research how this worked. This included looking into the history of web services and how they worked. I did extensive research on CORBA, SOAP, and REST. This research took about a week and I presented my findings to Brian Chapman primarily and some members of the PLM team who were interested in the abilities of Teamcenter services. After this presentation I was tasked with writing an example application for other developers along with a set of guidelines on how to utilize Teamcenter Services to integrate their software with Teamcenter. The example application that I built has full functionality of several complex features and partial functionality so far of another. The example application is based on an example application built by Siemens but it is almost completely rewritten to be applicable to Nexteer’s system and uses. The application is written in Java because I have the most experience in Java and felt confident I could build an efficient example that would make sense when looked at by other developers.

The first feature in the example application lists the home folder of the user who logged into the application. This is done by checking the user and then finding the directory within Teamcenter where the home folder is located. This can be tweaked to find any folder in Teamcenter very easily making it easily adaptable for other developers.

Sample console output for administrator account

The second feature is a query of the Teamcenter database. The example application first finds and validates a saved query. The application then adds in the values of the different required entries for the query and executes it. In the final part of the application a text file is created in which all the contents of the query are written separated by pipes (The | character) which makes it easily imported into excel which can be used with business information programs such as Microsoft’s Power BI.

The final completed feature involves slightly more in the background so for purposes of making this paper shorter only functionality will be explained. This part allows a user to create, revise, or delete items in Teamcenter. This allows third party applications to directly edit Teamcenter objects drastically increasing the ability of other software making it easier on end users.

Sample code to generate new item IDs, a small part of this feature

public ItemIdsAndInitialRevisionIds[] generateItemIds(int numberOfIds, String type) throws ServiceException{ // Get the service stub DataManagementService dmService = DataManagementService.getService(SOASession.getConnection());

GenerateItemIdsAndInitialRevisionIdsProperties[] properties = new GenerateItemIdsAndInitialRevisionIdsProperties[1]; GenerateItemIdsAndInitialRevisionIdsProperties property = new GenerateItemIdsAndInitialRevisionIdsProperties();

property.count = numberOfIds; property.itemType = type; property.item = null; // Not used properties[0] = property;

// Execute the service operation GenerateItemIdsAndInitialRevisionIdsResponse response = dmService.generateItemIdsAndInitialRevisionIds(properties);

BigInteger bIkey = new BigInteger("0");

@SuppressWarnings("unchecked") Map<BigInteger,ItemIdsAndInitialRevisionIds[]> allNewIds = response.outputItemIdsAndInitialRevisionIds; ItemIdsAndInitialRevisionIds[] myNewIds = allNewIds.get(bIkey);

return myNewIds;}

The last feature which is still being built adds a dataset to a given item. This part currently finds a specified file in the user’s file system to be added to Teamcenter. The part that is not completed is getting the file onto the server. The error is an FCC proxy that is being located within Teamcenter’s resources developer resources. Once these libraries are located that part of the program will be fully functional and will complete the groundwork for guidelines on how to program for Teamcenter services.

Conclusion

During my time spent at Nexteer I became proficient in C#, vb.NET, XAML, and SQL, and increased my knowledge in Java and C++. The application I built is being used by the PLM

team which consists of Brian Chapman, Chad Foster, Gerik Witucki, and Brandon Jackson. My Java application for Teamcenter Services will be used by Nexteer developers in the future looking to start integrating non-Teamcenter applications with Teamcenter data. My supervisor was Karen Proffer who assisted me the entire summer in addition to the PLM team I developed for.