Tag: BA

Unraveling, without becoming unraveled…

I seem to be unraveling all my previous dilemmas. That mysterious Gosu code turns out to be block code. That still means nothing to me, but now at least I know where to look in the documentation to learn more. I’m also happy to report that frantically posting my query about the damned nested if statements to the Guidewire Community site paid off. I got two suggestions, and the “.add” to an array solution worked! Why I didn’t remember this from my Java class, I don’t know, as it’s similar logic. Sometimes it’s tough to connect what you’ve learned with the current mess in front of you.

In positively JOYOUS news, that ghastly defect user story that spawned ANOTHER defect user story, has finally passed QA and it in the release queue! I suspected this might happen, as I ran a few furtive SQL queries yesterday to check was I thought might be our QA tester’s payloads to the integrated system, and they all looked good. I swear, I’m so happy I could cry…sometimes I really feel like the life of a developer is a series of roller coaster rides—devastating lows followed by meteoric highs. It’s exhausting, but I’ll still take this over being a BA any day.

The new guy got his Java quandary sorted out. He needed version 121 for our Guidewire Studio, but tech support had installed a higher version. He’s now wading through my instructions on how to copy over a database to his local machine, while also trying to figure out his on-boarding HR tasks (signing up for benefits, taking various online courses in our ethics and sensitivity training, etc.). He’s also starting his moving process this weekend, to eventually end up at our southern hub. I can’t imagine attempting to pack and move while learning the ins and outs of a new job, but he appears to be managing it. Seeing as no one is actually physically working at any of our offices at this point, it’s going to remain to be seen when he can actually darken the door of the place. I hear it’s very nice…when you can actually go inside…

TWILIGHT ZONE – Part Deux

Well, the recovery from my ghastly QA Epic Fail has been just as WEIRD as the original problem. First of all, when our BA mentioned “Criteria 1” he was talking about the main gist of the change — driver age was still getting populated with the age at the time of exposure creation and not the age at loss. I scoured the code in GitHub and the code my coworker added was just a bunch of loggers to troubleshoot HIS issue with his code, so that wouldn’t affect anything with my code.

My long-suffering coworker who’s been helping me out (let’s call him Mentor #2) had me bring the March Branch into my local (I KNEW this was going to happen), take the payload from our BA’s claim, and plop it into my JUnit test to see which age would appear.

To back this up a bit, the payloads created by our process, that are fed into the integration jobs, have changed format. I was able to escape using these last time by using an older claim for my JUnit tests—no such luck this time, as our BA had created this new claim just for his testing. I had several false starts where the damn JUnit test just didn’t work with the new payload format. Mentor #2 had to dial in for a meeting, so left me to my own devices, telling me to keep trying. After cursing and swearing that the damned payload was a bust, and that he had NO IDEA what he was talking about, and why on earth did they have to change the damned format, and…

…and then I saw it. Yours truly forgot to change the JUnit code to use the claim and policy for the BA’s claim—mine was still in there. Once I fixed this, the JUnit test ran like a Swiss watch…and wouldn’t you know, the correct age popped out! So, the issue wasn’t my code. Seeing that our BA originally created his claim February 4, I decided to take a chance that this might have been a system glitch—especially seeing as my coworker had had his code issue around the same time. Following the QA test scenarios, I created two more claims from the UI. This morning, I checked the final payload that goes to the next system, and again…I got the correct age.

SO, what happened? My tech lead believes it may be due to our BA running his tests before the test Spring Batch cycle ran, but my code was there on January 27 and worked just fine. I checked the output for the Spring Batch Build for Monday and the result said “UNSTABLE,” so perhaps something happened that effected our code.

For now, I’m going to lay low…but I think I’m going to need to keep running my tests every time this code hits a new test region and production.

HappyDanceHappyDanceHappyDance!!!!

I DID it!!! I finally figured out what I was doing wrong with the JUnit testing. There is a line of code at the beginning of the test for a field that says “contextData.” Initially, it appeared to be some sort of memo or reference. As I’d exhausted every other option this week, short of Voodoo chants, I checked the field again and…I was wrong! Far from being a “memo field,” the code is actually used to pull in the data elements that have been changed in the payload. So, in my instance, I needed to add Date of Birth, Loss Date, and Driver Age to this string, separated by pipes, so that these are be accounted for in the test.

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

I also participated in a fire drill today—okay, it was more like a full-on 5-alarm blaze. Our BA (you remember him—the poor bastard who inherited all my work when I went off to Code Academy last July) found out that one of the user stories for his other agile group tanked in regression-testing. The developer who worked on it is offshore and was one of the many who was off for Pongal. It was my boss’ idea to put me on this as a learning experience, with the other developers. We all checked different things to see why this wasn’t working. My task was to scour the past release’s code for anything to do with the logic that was broken, and then compare to see what was overlooked and/or changed by the user story code in this release.

THEN, it occurred to me…I asked our BA, “What exactly DID the error message say?” I searched our GitHub repository for the exact wording, and FOUND it! The odd error message came from one of the new Gosu rules (.gr file) the user story added. I did my best to figure out what on earth the code meant that led up to it throwing an error. The other developers had in the meantime found other odd things to do with the test environment, so hopefully between all of us the group can determine how to fix the issue.

I have to say it was very exciting to discover that I can in fact troubleshoot code I had nothing to do with writing, and understand it! This is pretty good, in that I’m hopeless at troubleshooting knitting and crocheting mistakes for people when I didn’t personally create the article.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

HappyDanceHappyDanceHappyDance!!!!

I DID it!!! I finally figured out what I was doing wrong with the JUnit testing. There is a line of code at the beginning of the test for a field that says “contextData.” Initially, it appeared to be some sort of memo or reference. As I’d exhausted every other option this week, short of Voodoo chants, I checked the field again and…I was wrong! Far from being a “memo field,” the code is actually used to pull in the data elements that have been changed in the payload. So, in my instance, I needed to add Date of Birth, Loss Date, and Driver Age to this string, separated by pipes, so that these are be accounted for in the test.

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

I also participated in a fire drill today—okay, it was more like a full-on 5-alarm blaze. Our BA (you remember him—the poor bastard who inherited all my work when I went off to Code Academy last July) found out that one of the user stories for his other agile group tanked in regression-testing. The developer who worked on it is offshore and was one of the many who was off for Pongal. It was my boss’ idea to put me on this as a learning experience, with the other developers. We all checked different things to see why this wasn’t working. My task was to scour the past release’s code for anything to do with the logic that was broken, and then compare to see what was overlooked and/or changed by the user story code in this release.

THEN, it occurred to me…I asked our BA, “What exactly DID the error message say?” I searched our GitHub repository for the exact wording, and FOUND it! The odd error message came from one of the new Gosu rules (.gr file) the user story added. I did my best to figure out what on earth the code meant that led up to it throwing an error. The other developers had in the meantime found other odd things to do with the test environment, so hopefully between all of us the group can determine how to fix the issue.

I have to say it was very exciting to discover that I can in fact troubleshoot code I had nothing to do with writing, and understand it! This is pretty good, in that I’m hopeless at troubleshooting knitting and crocheting mistakes for people when I didn’t personally create the article.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

Day 16: Stringing You Along…

We had two major blasts today in class.

One: we got our Friday projects back. The good news is that, by and large, our instructor felt we did well. The bad news is that I completely spaced on putting all my inputs into a <form> element—apparently, I wasn’t the only one, and there were a few other things I missed that needed attention. We all had issues to correct, on which we spent most of the morning working. One issue, a link not working, turned out to be a non-issue. I suspect our instructor had us immediately work on our defects as, in real life, during an Agile Sprint, it would be expected that you would correct mistakes right away. As a BA, I’ve been on the other side of this equation (“What do you mean, you didn’t make the changes YET???”).

Two: we worked with strings today. We used different functions and methods, such as indexOf(), lastIndexOf(), substr, slice, etc. Before you ask, NO…this is NOT as much fun as working with that other type of string (a.k.a. yarn).

This all culminated in an exercise to parse out a full name by prefix (if present), first name, middle name, last name, and suffix (if present). After much wailing and gnashing of teeth, I DID IT!!! Woohoo!!!

Tomorrow we work on dates…no, not the type you eat…

KT-ing to the new guy, or…do I REALLY know this little?

…and if so, why do I have so much documentation???

In preparation for my great move to Code Academy on July 8 I am in the process of doing KT with the BA who will be taking my place. I always assume people know what I mean by acronyms–KT stands for “knowledge transfer.” I have four days to impart my great wisdom (stop laughing) to my heir-apparent before the 4th of July weekend.

When my boss and I found out that I’d been accepted into Code Academy, after congratulating me on a job well-done, he informed me that he’d already found a replacement business analyst. I can’t decide if I’m relieved or insulted that I was this easy to replace.

In time-honored corporate tradition, the new BA is going to be doing his work and mine. We are in the wonderful world of Agile/Scrum now, so BAs don’t have as much to do as they used to. I know…BLASPHEMY! I’m probably breaking some sacred BA code by even mentioning it, but honestly our product owners now do a lot of the heavy lifting in getting our requirements. From what I’ve heard from BAs in other organizations, their BAs ARE the product owners–it’s not a separate role at all. Couple that with the fact that our product owner is a NINJA businessperson who also is very familiar with many systems…this is one of the reasons I decided that now would be a good time to pursue development work again. It’s only a matter of time before someone upstairs figures out that our BA roles can be just as easily performed by product owners trained to also document (remember: Agile…there isn’t as much anymore) and understand how the systems and the data flow. As it is, our product owner is also adept at designing test scenarios and use cases. Honestly, what’s left? When I first began being a business analyst back in 2008, we were still doing QA testing. This, of course, is now done offshore.

Despite all this, I still have quite a bit to impart to the new guy. He has some understanding of our system, but I’m filling in the blanks for him. I’m not too worried about him being lost because…well, see above. Our product owner, who used to work on the system as an adjustor ages ago, probably knows more than the developers.

And, in answer to the inevitable question…no, I have no desire to segue into product owner work. I really feel that this is all happening for a reason. Ever since my mainframe system work was shipped offshore back in 2008, I’ve missed developing. I’m excited about coding again!