development

Delivering a Hippo

/ jankka / Leave a comment
When delivering software through the delivery chain, I’d like to refer to the software as a Hippopotamus. Previously I have heard Michael Bolton (Not the singer, or the guy from Office Space) refer to software (and the delivery process) and especially requirement handling by telling a story about blind men and elephant. I do have my reasons to switch the elephant to a hippo, which I then explain later on.
If you like elephants more than hippos, too bad.

The Story

There is a group of blind men. They get a task to describe what a hippopotamus looks like. They need to give the description to a man that will build a crate to transport the hippo to the wild.
The group is first gathered around the head. They describe the beast as a big headed creature that has a huge mouth and sharp, long teeth, relatively small eyes and small, but alert ears. The creature seems to also have a slightly bad temper. They measure the size of the head and give the description to the transport team.
After the description, the transport team builds a crate and the delivery starts.
They get the whole head to the crate, it fits perfectly. But then there comes something else.
It seems they’ve forgotten something.
At this point it’s about the time for me to reveal a bit on how do I see this. First of all the group of men, the blind ones, I saw them first as bunch of software developers delivering the latest features on maintenance project. But to be fair, the group should also contain some test engineers, requirement responsible (product owner or whatever the title is), project manager and so forth. For as far as I know, regardless on the role on the project, in this kind of scenario we people tend to get blind. And it is not related on this scenario. When we as humans concentrate on the problem at hand we have great capabilities on concentrating on just that and to forget everything else. Which is somewhat crucial. It is crucial for the delivery to be delivered as it should’ve been. It should also be crucial to focus on other things than just the delivery itself.
What the group of blind men has forgotten is that the hippo has it’s body. The body is bigger and wider than the head and therefore it has no place in the crate. However, if they want to deliver the head, they should also deliver the body. So they turn back to the hippo and feel the sheer size of it’s body.
They describe the quite huge creature to the  transport team. The transport team, for they are clever, will now build a crate to contain both the head and the body. Not just the body.
So everything should now be fine, or what do you think?
The team has now delivered the complete hippo to the transport team and managed to get it inside the crate. Sure, and everybody is happy. The main functionality is delivered with the maintenance package without huge amount of flaws in it. As it usually is.
But did they forget something? No, everything is neatly packaged and ready to be delivered.
Well, the hippo has the rear end. And as you know, hippos tend to mark their territory with their rear end. They are clever in that way that they spread their manure (aka hippo -shit) around by wagging their tail vigorously. It’s an effective way to spread the message. And there we have the slip through. To be honest It wouldn’t matter if the group of men were blind or not; slip through will eventually happen every now and then to the teams that are or are not visually impaired. Really, we’ve all been there.
What we can learn from here is few things. First of all, the roles of the team should be spread a bit. There should be at least one person taking care of the maintenance and regression. Whether that is a test engineer or a developer does not actually make any greater difference. It usually is enough that you verify that he regression should not happen and that the old stuff is delivered also. The other thing to consider would be to take one of the transport team to check the delivery.
And for the love of God (or whatever deity your world goes around – money, consuming, stock exchange, sex, rock n’ roll etc), don’t get me wrong here. I do not mean that we need more people to the team. I do think that more blind men see just as much as less of them. What I mean with the role is that we, humans, are capable of switching to different roles. Even during the workday. Regardless what I think about multi-tasking (I am strongly against, really, it does not work for me), I do think that same person that handles the delivery of the main functionality can also handle te delivery and verification of the maintenance delivery. And the verification of regression tests. Does not even have to be a developer to do that. Or QA, depending on from which side you look at it. There’s plenty of things we QA -engineers can learn from the developers and developers can also learn a thing or two from testers. Some of the test engineers are even capable of writing code themselves and most of the developers are capable of testing their (or someone else’s code) during the day. And after this is done, they can continue concentrating to deliver the main functionality. It really is as simple as that. Nothing fancy here.
So, now we’ve covered the main functionality and the regression. The head and the body are happily delivered. What to do with the tail?
First of all. We will always have slip throughs. Really, there is no way we can get rid of them. There is no way we can test and code in a way that will lead to a delivery and simultaneously not have anything weird hidden in the delivery. But of course we should do anything we can to prevent them happen.
What could be helping here was that there is a role in the team for experimental testing. Do something unconventional. Someone from the team should get to bash the hell out from the application, tease the boundaries, break it, create chaos. Do things users won’t do (that list is actually shorter than you think ;)). That will, eventually reveal some of the bugs that the more conventional testing won’t do. If possible, automate that and do it all the time. Just keep the chaos running.
Advertisement

Learning curves

/ jankka / Leave a comment

It seems I have a road ahead. Not sure what is going to happen, but at least I know that I’ll enjoy the ride. The ride will be long and it will be hard at times, but all I have to do is to remember that I have all the time in the world for this and the target is not to create a perfect application, but to learn how to automate tests and develop with Python and Robot Framework. Both skills I see as needed in the future.

First of all, after everything was installed yesterday, I sat down and went through some tutorials. Both git & Robot Framework are getting more familiar now. Far from being perfect, but at least I’ve been using both. Git is, by the way, a lot more intuitive with the commands than CVS. And it really neat to use a service like GitHub to store my stuff in. At the moment the solution I started to lab with is stored as private in GitHub. In the future I plan to create a public variant on that in order to get it shared properly.

I also managed to start the Algorithms -project and created the first excercise. It is a simple insertion sort I managed to get together by help from stackoverflow (a really good site to search for information;)) and a slight use of my brain. I actually needed the stackoverflow -solution more or less as interpreter to the algorithm -books pseudo -code.

And last, but not least, I actually have now done my first time ever ATDD -approach on developing. The test case was created and it failed in the beginning. After some coding I managed to get it also go through and got a PASS as result. And the test case is of course using selenium webdriver -library to verify that the web -page is up and running.

As a bonus I actually got an idea about a solution on how to parse some input strings properly with groovy -script in SoapUI. A thing I will need to do at work next week anyhow.

So to say, it has been a proper weekend.

Sidekick

/ jankka / Leave a comment

Apparently it never is enough. Nothing is. Man born a hoarder is a hoarder, even during the nights or weekends. The last 2-3 weeks have been kind of challenging mayhem at work. I have to admit that my capability in adopting to varying situations has been tested. Several times. Long days, tough days. No time to reset, besides in the evenings at home or at the gym. Mostly both. Luckily training the unknown when following the CrossFit helps me mentally to get used to attacking the unknown. That’s a blessing. But even though it has been rough, it surely seems I haven’t been capable to do enough on the creative side.

I’ve been bouncing this idea of web -service that could help me as a tester. And since nobody is going to do it for me – partly due to my lack of capability to describe it properly and inthusiastically enough, partly due to the fact that every single other one at the work is evenly loaded – I’ll need to do it myself.

What I have planned is to do the whole stuff with Open Source SW, using Python, Django and git. Cucumber has been fetched and installed, as well as RobotFrameWork. Those are the tools for me to use.

Developing is a creative process and I’m pretty sure I’ll learn a lot on the way. I’m going to tackle this from the ATDD (Acceptance Test Driven Development) point of view. Hopefully I learn new stuff for testing as well as the crucial stuff for automating my tests and using development skills as tools for my work as a tester.

Now, since this is going to be part of my work, it is going to be a system test support tool, I cannot release anything (at least as it is) on my GitHub. I do have plans, though, to put something there, but as stripped version.

So far the project has been setting up stuff: Yesterday, a fresh install of Ubuntu 14.04 to my Dell Latitude, today getting the tools installed and reading the first introduction chapter for Git -usage. Tomorrow I should be good to go.

And for the record, I don’t except things being too ready too soon. This is going to be done for my education and amusement only. Status updates might follow every now and then anyhow 😀

Hunt ‘em down

/ jankka / Leave a comment

Mankind has been practicing hunting, let’s say, for a few years now. we’ve been capable to get our daily rations of protein, carbs and fat by hunting, finding, gathering, looting whatever has been available. And I ‘d like to think we’ve been rather successful on that, too.

Just think about it ; we’re still here, few other species have gone extinct and most of the current ecology –system is more or less constantly threatened by our existence. So I’d like to make a conclusion that we’re are pretty well adjusted for hunting down whatever it is to be down hunted.

So how come it is so hard to do with requirements?

I mean come on, people. There will always be the written down requirements, those are the easy part. Regarding that they are available for all software project participants. Which they might be, and then again, they might not. So let’s not concentrate on them at the moment. Let’s make an ass out of u and me and assume that the written down requirements are available, and what is most important, their whereabouts are known in the whole project for all the participants.

So QA starts their work basing their testing on the requirements and information available. No big deal. Bugs will be found, they will be fixed, life goes on.

But what about the stuff everybody just magically know should work? The packaging standards of the applications, the delivery setups, the way the applications should react to other applications in the system? What if those are de-facto standards, written down ages ago, known to most of the people involved, but just in this particular project there’s a bunch of newcomers.

During the initiate phase such things should be brought up and delivered to them, ain’t it so? sure it is. Well, that is a nice picture, but honestly people, it does not always work as that.

The truth (You can’t handle the truth!) is that we do  live in a perfect world. Yes, you read it right. It is perfect and understandable unambiguous and messy and in the end, it is beautiful to see this multitude of failures, flaws and not working things among the everyday life’s working stuff and understand that it all is part of the process.

Now where I’m going with this? Here; all you need to do is to take your stand and adept to the situation.

As a QA –engineer, your responsibility is to plan and execute test cases with certain expected results. You cannot say that you can’t do them, that you don’t have the requirements. Not if you get to know that you should’ve known. And for the record it is more than OK not to know.Like I pointed out yesterday, it does not matter if you did mistakes, or if someone else did them by not providing the requirements to your lap. What matters that you take a leap towards the newly found information and hunt it down.

Now you might tell me that it is project responsibility to deliver all needed information considered and bring it to you. Hopefully on a silver plate. I’d like that, too. And while they’re at it they could also bring the coffee and take care of my laundry.

Now here’s the crucial part, at least for me; The world as we live is perfect. It is perfect for human beings who are capable to hunt down all the targets they aim to do. And that applies to requirements in software projects. You might not succeed all the time, none of the hunters do, either, but who cares. The point is that you can hunt and that you can catch your prey. Let the prey here be information. Actually, if you’re reading this, your brains have been capturing at least some information on this page. Same applies to requirements. Regardless if they are written down or not.

The next question is, of course, what to do with them? Well, depending of the structure, you’ll need to get to the best parts of them. You might need to skin, peel or mush them. And then split them to chewable pieces. Some of them are nutritionally really good, some of them are completely unusable. Pick what you can use and leave the rest. The ones you picked up, you’ll feed up to your Test Case –creating ogre, called Untar the Defector. And you’re done. For now. Tomorrow will come and bring the new challenges, and your ogre is forever hungry.

Soundtrack for the post:Queen – Live At The Rainbow