If you're a developer, especially a developer who has worked for years without a QA department or a professional tester at all on your team, you don't *have to* have a sense of humor, but it sure makes everyone's lives easier and makes for a room full of awesomeness if you do.
Let me tell you a funny story.
I had this bug fix to test. The bug was that when submitting a commerce-type action, if the name of the group was greater than 50 characters, the commerce transaction failed. The solution was to truncate the name (in sending the transaction) if it was greater than 50 characters.
Still in learning mode and lots of manual testing aiding that, I went into the UI of the QA server so that I could create a group name that was > 50 characters. The field in the UI prevented me from doing that. So I pulled the developer over and asked him what was going on. I figured if the UI prevented it, that was great, then the problem wouldn't happen, but what about records in the database that already had group names greater than 50 chars? Had we run a db script to modify them? Had the UI change just been done to prevent this bug from happening again?
He explained to me that the UI change had been done some time ago, but that we had not modified original records in the database. In those cases, the name would be truncated when the commerce transaction went through. So I went into the database to create myself a record with this quality and then I planned on going back into the UI to attempt the commerce transaction.
SQL Server told me no go on creating a group name like this: "Test One this is a really long group name because I want to test greater than 50 characters and I had to make a long name". It turns out, the database constraint on this field was a varchar(50). WTF? The database would not let me have a value that exceeded 50 characters, so how the heck could this issue even EXIST??
So this time I slid my chair over to the dev desk and asked how that could *ever* happen, and why were we fixing this bug that could not possibly exist. He said to me "Wait, here's how we are going to make it happen." I sat and watched him right-click on the table in SQL Server Mgmt Studio, choose Design..., and then go in and change the field to varchar(100).
I STARTED CRACKING UP AND THEN I YELLED "YOU CAN'T DO THAT!!"
He laughed too and then tried to explain to me that the production database really had that column set to varchar(100) so it was okay. I started laughing harder and said "WAIT! WHAT? The QA database doesn't even MATCH the production database?!?!?"
(as completely crazy as this story sounds, and please take your jaw off the floor, the following is an example of why I really love this team)
At about this point, the dev team lead came over and asked what all the hubbub was about. After we laughed through the explanation, during which I was described as being "a bit dramatic", which I was (I can kinda get a bit OMFGWTFLOL when I encounter these types of things), we agreed that we needed to have a QA web site up that had a QA-only database that was an exact copy of what was on production. We also agreed that from this point on, all changes to the database would be done on development, and then dev/test would check it out there, and they would be scripted such that when dev code was promoted to the QA site (let's call this the "exploratory" site), database changes would also be promoted with the code.
It was as easy as that. The three of us laughed about this craziness, figured out a way to set things up so that we weren't doing that one small thing in a crazy way any more, and just like that, we solved the issue and moved forward. As funny as the example is, I think it's a really great example of how little by little, a cooperative, respectful team can get things done.
And it's so much more fun when we can all laugh about it. Good thing I have a sense of humor!
2 comments:
Sounds like a good team. Little changes that can make things better really add up.
What I would look out for in the long run is that the rule you now set up with the QA environment matches the production as likely as possible, might become constraining.
Let me elaborate what I ran into over the holidays while at work. Our product runs on Java5, since August FitNesse runs on Java6. I exchanged in every code branch java5 through java6 to make it compile again. When I had started up a system I noticed, that I could no longer create customers in the database. When I realized that the only chaneg was Java5 to Java6, I knew there was problem with the implementation. So, I opened up a bug. In the new year I got contacted by two developers from the same team about it. (Note: Bureaucracy is the percentage of what you're doing that you don't understand why you're doing it.) The first developer was highly motivated to investigate the bug and asked to do several things with my system and try to reproduce it. Basically he was pin-pointing the problem. The second developer the next day told me that our product is just "certified" for Java 1.5.0_15 according to document XYZ. Two days later the first developer had fixed the problem in the next release, which is run on Java6 and where the problem still existed. The release of this product is planned for February or March. And I don't directly test that product.
By trying a bit more than the constrainted way, I was able to find a bug in a component, which I was not testing, which might have popped up and caused really big trouble in production for the next release. So, always working after the rules might be a bad thing to do. Hopefully your team is able to transform your new rule over time into a guide and see its limitations.
Post a Comment