2010. május 26., szerda

Moving

Moving into a new company is never easy. Except if you hated your old work.

I didn't hate mine. So now i'm working in a new one. It is interesting of course and the work is much challenging and i will post stuff about it after i'm feeling more comfortable and i have the time to do so.

Until then... this is Skarlso, keep your heads up for update... and now. Some music...

2010. május 14., péntek

How does a porn star pay for her speeding ticket?

With money of course...

And if you are a tester and you didn't thought of this idea then you did two things wrong:

  1. You assumed something
  2. You used a stereotype which was present in your head
As a tester your first question should have been:

"Well i'm curious... how?"

As a tester there is a rule of three that you always have to follow no matter how trivial the problem seems.:

  1. Never assume anything
  2. Always question everything
  3. Never trust anybody
This is a good rule of thumb to follow and should be apply to your life as well. If somebody tells you that the apple you are going to buy at a store is really really good would you buy it on his opinion? Of course you would do that. Because you assume that the guy doesn't lie and has tasted the apple before. And then you bring it home and take a bite and immediately spit it out because it's damn sour. And when next time you meet the guy you ask:

- Hey that apple was pretty bad.
- Why?
- It was sour as hell.
- Yeah i like that a lot, i told you it's good.

Yes you see it was good from HIS point of view not yours. So never trust anybody unless all agree and never assume something before you didn't taste the damn thing.

Gergely.

2010. május 11., kedd

Child parenting in the views of a tester

I want to write about something funny this time.

What is the biggest project you can imagine? Empire state building? Two towers? Pyramids?

Yeah there is something much more bigger. Parenting is almost the hardest and most impossible task that you can face in your life. It is easier to jump from a plane with a parachute. There are so many things that can go wrong...

So how about mapping some of the testing heuristics to child parenting.

Let's see...

In the first few months you got to build your framework you got to find out your user stories and do an initial test case identification. You do a basic exploratory testing and find that everything is okey, the child comes around pretty well. You begin to plan for the future, you develop tests and user stories like:
  • As Amy, i would like to go to collage to be able to get a degree
  • As Amy, i would like to get a breast implant so Joey finds me attractive
  • As Mark i would like have my ears pierced so i could sleep with Amy
  • As Amy i would like to have proper parenting so i don't sleep with Mark just because he has a cool ear piercing, and oh my god did you see that biceps?
So you then begin to run some more tests until you can no longer control the child's evolution. And then comes user acceptance testing. You get a lot of feedback from other people about your child's behavior and general working processes. She did sleep with Mark and you are disappointed that there was something wrong during the testing phase. Now you have to re-factor the child.

This is no longer easy since you are over the initial phases so you have to put in a LOT of effort. That costs time, money, nerves, and a new breast implants for Amy. Eventually you get around and can introduce some patch work on Amy and you are over running your User Stories again and again comes user acceptance testing. This time the feedback is good. Amy behaves and it seems everything is working fine.

And then at some point in time without any notice at all a user comes along and says that he saw Amy doing drugs in the ally. You rush to your child you try to reproduce this bug, but you find nothing. You go again to the user and say that could he specify a bit more what he saw and where. The user tries to describe the bug again, says Amy was there at 2010.05.15. And then you realize that it couldn't have been Amy because she was with you on a weekend vacation. So you reject the bug and say that it could not have been her.

After a while the project gets fully out of your hands into the final stage in which whatever you do, you can no longer perform a re-factor because it became to huge to mess with it. You can only provide some workarounds and good documentation to the user. Maybe hide some of the bugs that were found. Or try to introduce new functionality to hide the old faulty one. ( She get's that breast implant after all ).

So folks. Raising a child is like bringing a huge project to success or at least not to a failure. But don't worry, the feedback is pretty good and if you manage your time properly you don't even have to work overtimes...

Gergely.

2010. május 9., vasárnap

No coding required.

hi!

Today i want to write about automation frameworks who try to sell them selfs by saying: "No coding required."

I don't like frameworks like these and i tell you why. Because it's bullshit. And it is dangerous too. Because it gives illusions. It gives false hope to managers it gives you an extra amount of work and extra amount of stress because of illusions.

Basically when there is a framework that tells you that there is no coding required it often means that it can generate code. This is great all in all, but.. It does not mean that it does not require code, because, let's face it. You REQUIRE a robust, working, expendable framework which will work for another one or two or twenty years. And you can have that without coding.

You require coding IF:

  • You want an environment with which it is easy to work
  • You want an environment which can be easily expanded
  • You want an environment which wont fail if you add another test or 200.
  • You want an environment which is portable
  • You want an environment which is configurable
  • You want an environment which can run on every kind of browser and op system
  • etc.
So you don't get to work around coding. You don't get to skip that part. And why is it dangerous? Because your managers will be impressed and passioned about it and you got to suck it up. Because you won't be able to explain them why it is a lie or at least a partial truth.

What i would like to see is adds that say:
- We can generate code
- We can create a partial framework that needs revising
- We can create a framework skeleton

And so on and so fort. So be very careful what you show to your managers and operatives because they tend to believe in adds.

Gergely.