1. 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
2. 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 screenfor CPI testing
5. 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.
6. 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 windowof version1
7. 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.
Addinga newrecord to the system
8. 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.
Viewingreports
9. 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.
Addingnew users,versions,or test cases to the system
Correctingfailedtests
10. 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
11. 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.
Selectingtestcases for the batch
13. 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.
Correctinga failedtestcase
14. 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.
Choosinga report to view
16. 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.
Updatinga test case’sinformation
19. 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 TestingTeam Solution
Final Version
First Version
20. 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.
21. 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
22. 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.
23. 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
24. 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.
