Every tester has a credit score. You use it every day. Each time you ask a programmer or analyst a question, when you talk to a project manager about your status, when you write up a defect, or when you deliver some other artifact, you are potentially impacting your credit rating.

This week in our online Rapid Software Testing class the topic came up, and it reminded me to relate a recent experience where I upped my street cred. It's worth relating because I think it's an often overlooked aspect of testing. As a tester, many times your effectiveness is relative to your current credit rating. Much like buying a house, even if you have the right information at the right time, you may be overlooked or have to go through a difficult process because of past mistakes or oversights.

In a recent meeting, we had an odd mix of people in the room. We were researching a high profile issue. We had executive management, middle management, project management, architects, technologists, performance testers, key programmers, infrastructure, operational monitoring, and me. I was lucky enough to get called in the night before. This was the status meeting.

At the meeting, several topics were bounced around, many of them works in progress. One of them involved pulling transaction times from a production log. Someone in the room had just pulled down the production log before the meeting. As we discussed the work in front of us, the issue of who would parse the log came up. The super smart Java programmer in the room and I, the tester, were sitting across from each other. We gave each other the "I have it" stare. I threw down the gauntlet and said I would do it.

(I might be exaggerating a bit here, but hey, it's my blog and this is how I want to remember it! We did look at each other, and I did say I would do it. The tumbleweed and high-pitched whistle may or may not have been there.)

Once I had the task, I popped open SciTE and got to work. Here is where the cool part comes in. Standing behind me was one of the more respected architects within the company. A smart, likeable guy, who everyone respects and looks up to. He was looking at my screen.

During the meeting, while the conversation continued, I coded. I filtered most of the conversation, listening/responding only when I absolutely needed to. When I wasn't focused on the conversation, I wrote a Ruby script. Because the architect was looking over my shoulder, I refused to spend a lot of time looking up methods online (pride dictated I had to do it without seeking help), so the code was a bit more complicated then it probably needed to be. In about 10 minutes, I had the finished script and ran it.

@sourceFile = 'C:\\file.log'@

@infile = File.open(sourceFile, "r")@
@responseTimes = []@
@thread9Begin = 0@
@thread9End = 0@
@thread10Begin = 0@
@thread10End = 0@

@#Log file entries look like this...@
@#12:28:29.494 COL D 10 (java_extensions.cxx:1442): ****** BEGIN@
@#12:28:32.914 COL D 10 (java_extensions.cxx:1442): ****** END@

@#0 - 12:28:29.494@
@#1 - COL@
@#2 - D@
@#3 - 10@
@#4 - (java_extensions.cxx:1442):@
@#5 - ******@
@#6 - BEGIN@

@infile.each { | line |@
@currentLine = line.split(' ')@
@if currentLine[6] == 'BEGIN' then@
@if currentLine[3] == '9' then thread9Begin = currentLine[0] end@
@if currentLine[3] == '10' then thread10Begin = currentLine[0] end@
@end@

@if currentLine[6] == 'END' then@
@if currentLine[3] == '9' then thread9End = currentLine[0] end@
@if currentLine[3] == '10' then thread10End = currentLine[0] end@
@end@

@if (thread10Begin != 0) and (thread10End != 0) then@
@responseTimes.push(thread10Begin.split(':')[0] + ", " +@
@(((thread10End.split(':')[0].to_i - thread10Begin.split(':')[0].to_i)*60*60*1000) +@
@((thread10End.split(':')[1].to_i - thread10Begin.split(':')[1].to_i)*60*1000) +@
@((thread10End.split(':')[2].to_i - thread10Begin.split(':')[2].to_i)*1000) +@
@(thread10End.split(':')[3].to_i - thread10Begin.split(':')[3].to_i)).to_s)@
@thread10Begin = 0@
@thread10End = 0@
@end@

@if (thread9Begin != 0) and (thread9End != 0) then@
@responseTimes.push(thread9Begin.split(':')[0] + ", " +@
@(((thread9End.split(':')[0].to_i - thread9Begin.split(':')[0].to_i)*60*60*1000) +@
@((thread9End.split(':')[1].to_i - thread9Begin.split(':')[1].to_i)*60*1000) +@
@((thread9End.split(':')[2].to_i - thread9Begin.split(':')[2].to_i)*1000) +@
@(thread9End.split(':')[3].to_i - thread9Begin.split(':')[3].to_i)).to_s)@
@thread9Begin = 0@
@thread9End = 0@
@end@
@} #infile.each@

@infile.close@

@puts responseTimes@

The best part, it worked the first time I ran it. I copied the results over to Excel, turned my laptop, and presented my results. The meeting wasn't even over and we could talk about the actual data. I got a small verbal pat on the back by the person asking for the information, and we moved on.

Fast forward a day or two...

At another meeting, on a completely unrelated topic, with a room full of different people (except for the architect), we were talking about implementing a new process for an automation issue. As part of that issue, we would need to write some Ruby code to populate some data via a web service.

At one point, I volunteered to write the code to populate the data. That drew some looks from the programmers in the room (I'm just a tester you know). It was at this point that the architect stopped the meeting for a minute to relate what he saw me do in the meeting, writing the code in a hostile environment and it working the first time.

That's the best feeling in the world. Someone else, not even a close friend, stopping a meeting to give you a vote of confidence. And because he has high street cred in the programmer community, I now have higher street cred in that community. It's was more influential then if I had found ten super obscure technical bugs. Probably more influential then if the developers had actually seen me write the simple script (I included it so you could see how simple it is - and I'm sure it could be simpler).

So what's your street cred? How do you build it? How do you cash it in?

On a recent project where we were implementing a service oriented architecture (for the first time on a large scale) we wanted to leverage the design of the system to test early. The plan was to have testers run local servers, get the latest complete code (after developers were done and everything was unit tested), and run component level tests based on risks identified by the test team. We would use automation and manual testing to flush out edge conditions, mapping errors, and un-captured exceptions.

On schedule, several of the developers indicated their code was complete at a status meeting. I configured my local server to run the code and began my testing. Surprisingly (or perhaps not) this caused some problems. Developers were quick to come over and say things like:

• "You can't test in a development environment!"


• "We're not done with that functionality (even though we said we were)."


• "I'm still unit testing, the code won't work until I'm done unit testing."


• "We are working over 30 tickets, things can break at any time."

This was taken by some people on the project as a reason to stop our test-often test-early strategy. I would think each of these indicate a reason why you would want someone testing in the development environment. Let's address these one at a time:

"You can't test in a development environment!"

Actually I can. It's really easy. I just update the code, compile, and start a server. We have the technology. Is there some reason I shouldn't test in development? Isn't the whole idea to find issues earlier when they are supposedly easier and cheaper to fix?

Ok, that's my smart ass inner voice. That's not what I really said (but I really wanted to). I think I really said something like:

"I understand this is something we are doing for the first time on this release. Changes like this are painful as the team learns to deal with new ways of working. We need to test in development if we want to have any chance of hitting our release date. If we wait until all the development is done, we will need to do two months worth of testing in three weeks. We just can't do that.

Can you help me make this easier on you? What can I do to lower the visibility this adds to your work and the pressure that added visibility results in? How can I provide feedback to you in a way that doesn't cause problems for you?

Once the developers (or most of them) accepted we were going to do this testing, they started to warm up to it. After the first couple of weeks (very emotional weeks) we actually hit a groove. By the end of the release, we had very close relationships with many of the developers.

"We're not done with that functionality (even though we said we were)."

Our testing exposed a misunderstanding about project progress. What management thought the status was and what the actual status was did not match. We were told it was done, but it was not. This enabled management to correct their misunderstanding of project status so they could plan and react accordingly. This - aside from all the testing related issues identified - is valuable information. People hold meetings and purchase expensive tools to find out what we found out in 5 minutes of testing and asking questions.

Code does not lie. It works or it doesn't.

"I'm still unit testing, the code won't work until I'm done unit testing."

This is closely related to the above point. Up to this point, developers were in the habit of telling management they were done when they were done coding, not done unit testing. This caused a perception problem. I also have a suspicion that this was a sneaky way of asking for more time in a politically correct way. Who's going to say you can't do more unit testing?

Some of them were reporting they were still unit testing when they were still writing code. They looked farther along then they were. On the other hand, the developers who really were unit testing when we started our functional testing welcomed our scrutiny. "Find a bug if you can!", they said. Sometimes we did.

"We are working over 30 tickets, things can break at any time."

This is the, we break the build on a regular basis argument. That's a fine argument, except that like most teams, we're not suppose to break the build. Ever.

This statement means that developers regularly checkout code, make changes, then check it back in, and then test. This was a "deeper" problem. The developers should have been testing the code before they checked it back in. Some were not. There was an automatic expectation of failure on any code that was checked in, not an expectation of it working. Note, this expectation was the expectation of the development team.

This problem solved itself as we started reporting those defects (normally the same day). The added visibility provided by our defects for these types of issues tipped us into a more positive workflow of testing before integration.

All said and done, we worked side by side with the development team for a little over two months. When our testing stopped, the traditional functional and system level testing began. We had automated hundreds of tests at the component level. We had validated many of the mapping documents. We had become active participants in design meetings (not all of them, but enough that we felt like we had a small victory). And by the end of our testing, we had developers (again not all of them) coming over to us and asking us to review their work. After the initial growing pains of the added visibility to the status of the code, most of the emotions died down, and we were able to release some great software.