Business-Facing Tester Helps Developer; Film at 11

These days find me sitting squarely on the customer side of the development cycle. I haven't let that limit my approach, though.

I still use automation, APIs, logging, checklists - basically all the tools I used when I was on the other side. Perhaps this delineation of 'sides' is unnecessary when both are striving to work together. This is just a unique configuration, one where a technical "expert" is collocated with the customers instead of SMEs being collocated with the development team.

One day, our software vendor set up a WebEx to walkthrough the installation of their software. I shared my desktop and began to follow the developer's instructions. The first one hour session ended when we encountered an anti-virus policy that was not accounted for in the install package. Simply put, our company disallows "autorun.inf" files to be created on the file system, but the software has a dependency whose installer unpacks just such a file. This looked like it would be a job for our internal IT department, who would ultimately be responsible for deploying this software anyway. One session down, one to go.

In our second session, we were able to continue the installation by temporarily bypassing the blocking process. Since this is what the IT department would have to do, I felt it was not masking any potential issues. The dependency installation was taking more time than the developer expected. We tracked it down to another internal IT process that was pushed out recently. Search indexing was working hard to account for the deluge of new files being created on the file system. Once we disabled that process for the sake of brevity, we continued on to the last issue.

The package was finally installed on my system and all that remained was to update it. It was at this time that my co-worker Shane asked what would happen if we attempted to update while a session was active. We explored this scenario with the developer and were able to confirm that the update did not occur - as we had expected. However, the developer was perplexed as to why the active session window did not close during the update attempt.

The developer mentioned that the recent buyout of their company required them to update all their company branding, including their window titles. It was possible that the routine responsible for closing the session window was looking for something with Company X in the title, but was actually Company Y. The developer began to search through their code to determine if this was the case.

I thought I could prove his point rather easily during our WebEx. I fired up AutoIt and compiled the following code:

WinSetTitle( "Company Y", "Company X" )

I ran this on the remote box where we had an open session, observed that the window title changed, then re-ran the update utility. Sure enough, the window closed and we were able to move on. The developer gave us a great compliment, exclaiming that what we had just done was, "a pretty cool hack". We were able to confirm his suspicions in real time, and thus confirmed where his fixes needed to occur.

I later looked back on that moment with much fondness. It reminded me that there are still some technical activities we can engage in that provide value for both sides of the effort. After all, we all just want to deliver good stuff. Who cares if some customers understand those lower-level details, provided the testing represents the customer's interest?