One Zip Coder’s Journey Trailblazing Angular Test Automation

Written by Chris Frahme, Lead QA Engineer, Wilmington Trust

As a QA Lead for Wilmington Trust and a corporate partner with Zip Code Wilmington, my colleagues and I  have established a solid relationship with the organization, its leaders, and its students. I have personally been a speaker at several of the Speaker Series Lectures and enjoy enlightening students on what to expect when they hit the workforce.   Our business at Wilmington Trust is different from most of the other financial institutions in the area and I feel it is important to highlight those differences, so the students can make an informed decision when given employment choices.

One of the things I have enjoyed doing during the speaker series is demonstrating how we can use our software development talents and creativity to develop in house testing tools that can be leveraged by the entire team.  As I walk through the designs of our tools, I can see the interest and fascination in the student’s faces as they connect the dots and get a fresh perspective on how to leverage technology on the job.

I have had the privilege of hiring a few Zip Code alumni on my team and enjoy the enthusiasm and fresh perspective they bring to our organization!

Mexi Liang, who was hired last September, is my trailblazer.  Since completing her initial assignment helping to test and write test automation for Wilmington Trust Connect (www.wilmingtontrustconnect.com) Mexi has been working with me through challenges related to writing test automation against new products written using our updated tech stack. 

For a while, she seemed to be hitting one road block after another and I have been working with her daily through these issues.  She finally got to the point where she could write the more straightforward tests and then moved on to her next challenge, which is writing tests that require data staging.  These are tests designed to run against the product in our QA servers, isolated from the actual product certification environment.  This allows us to perform the data manipulations needed without affecting any testing that may be taking place by our business partners.  The QA server vision has been in place for a while, but we never got to the point of putting it to good use.

One day, as Mexi was eagerly looking forward to her well-earned vacation, I was reflecting on where we were and how long this journey has been.   But wait, it actually hasn’t been a long journey.  It actually has only been about 2 ½ months.  That blew my mind as, based on the issues we have continually been resolving, seemed like a lot longer period of time.

While driving home that afternoon (I have a long commute home, so plenty of time to think), I began to think about the journey Mexi has been on and how far she has come in that 2 ½ months!  Not only that, but the innovations she has been spearheading have been pretty much done independently.  Sure, she gets my guidance and advice on a daily basis, but when she is cut loose, she is taking those long strides on her own to getting us where we need to support other products on the horizon.

I decided when I got into the office the next morning, I was going to make a list of all she has gone through and accomplished in that 2 ½ months and show it to my boss, Glenn Force.

Here is the list I came up with:

1. Initial attempts to automate the product using our standard Selenium toolset. We ran into the automation timing out.  Mexi did some Googling on Angular automation.
2. Mexi found that protractor was used in a lot of Angular automation. She downloaded that and began to take a look.  We decided that the cases and framework were more applicable for business acceptance testing and we needed tooling at a lower level.
3. Mexi investigated toolsets, focusing on automating some of the 3^rdparty libraries used by our development team, which seemed to present themselves as a “black box” to automation scripts due to proprietary reasons.
4. Mexi found a GUI based automation tool sold as product by one of our 3^rdparty library vendors. She downloaded and tried that and, lo and behold, we could create automation and not experience the timeouts we saw with Selenium. Now we are getting somewhere.  But 2 things did not sit well with me with this solution. 1. There was a decent cost per seat for this tool 2. Producing automated tests via clicking GUI elements does not sound like it will be challenging enough for my folks in the long run.  I found a free library by the same vendor as well and asked Mexi to give that a shot.
5. Mexi started working with the library, which ended up being very Selenium-like, but then ran into the problem that her tests would cause the product to “advance states” that could not be “rewound”. That then led us to hosting the product on the QA servers, so we could restage the data as needed before the tests.  But it wasn’t that simple.  Turns out 3 DBs needed to be staged:  The product under development, a 3^rdparty application it interfaces with plus a table from another system within Wilmington Trust.  Mexi set off on staging these pieces, plus the product itself, in the QA environment.  That was her first exposure to Microsoft IIS.
6. While doing all the above, Mexi was also gaining knowledge on the product under test as well as some of the business processes the product was supporting
7. Once past the product and DB staging and update challenge, Mexi was able to write 20 automated tests for the product. Now we’re cookin’.
8. Once the initial set of tests were written, we moved onto spec out other tests where we would simulate conditions by injecting records into the DB.

And that is where we left off…..

That is certainly a lot of progress for 2 ½ months.   Especially for a new hire on the job for a total of about 6 months.  Not to mention the positive attitude and determination Mexi has demonstrated along the way.

Now I’ll work on the list for Mexi for when she returns from vacation….