This user hasn't shared any biographical information
BPMN question
Posted in Tools on April 20, 2011
Recently I learned how to model business processes with BPMN 2.0, the Business Process Modeling Notation. Following, a very, very brief introduction.
Using the BPM standard allows technical and business engineers (and everybody else) to better understand one another by using a process-oriented approach to modeling, while keeping the advantage of having executable (automatable) process models. It is highly recommendend to pre-define certain patterns and guidelines for usage, especially when working cross-departmental and cross-functional or rolling out company wide.
The great thing about BPMN is that it is really simple. This process obviously doesn’t do anything useful, it’s only to show some of the tasks, events etc.:
Now, a problem. Let’s say asynchronous service calls are modeled like like this:
How do you model synchronous service calls? You could do it like this:
But is that really 100% unambiguous? Sure, there would also be notes about the details (and objects used) of the process. But wouldn’t this be better?
There’s been quite some discussion about this; if anybody here has an opinion or best practise advice, let me know.
The Quiz!
[Before I start, a few more words regarding my last post. A colleague of mine recently also took the ISTQB certification exam, and in her group she was the only woman. So as far as my observation about the weak male/female tester ratio goes, there's another confirmation. Sad but true.]
But now, the quiz. About four years ago it all started with a motto/quote-of-the-week on a white board. This quickly turned into a trivia-question-of-the-week and born was the QA Quiz. Week for week, someone on the team would come up with a question for all the rest to answer. As word got around, more and more “players” became regular participants. The category of the question was up for the questioner to decide, and we had it all: trivia, movies, puzzles, history, politics, you name it. He would write down the question and a number of possible answers – of course including the right one - on Monday. The players then had the whole week to leave their mark on the answer they deemed correct until the question was resolved by the questioner on Friday.
With growing numbers, I invented some basic rules. Anyone who read the question had to answer it on the spot – while in the room – to prevent googling. There had to be a minimum of three and a maximum of seven possible answers. As a guideline, the questioners were asked to choose questions they could answer on top of their heads – not to make it easy, but to encourage them to choose a category they knew much about (and not necessarily the rest of the group). Choosing the right answer would score one point, and the questioner himself could not score that round. The person with the most points was asked to go next with the question.
The last rule we changed when it turned out there were always two who fought it out, ping-ponging questions back and forth. The rule had been meant to allow the rest to catch up in the ranks, but choosing a questioner randomly amongst all who had not yet asked any questions turned out to be much more fun. I split the year into two seasons with 20-25 games each, and the winner would be titled QA Quiz Master. As their prize, they’d even get a small trophy, a challenging cup – and they had to bring donuts or cake to please the masses. Every win also comes with a price, like.
So what’s this to do with anything, let alone testing? Not much. I was new at the company when I started the quiz and I am terrible at names. Due to the increasing popularity of the quiz, almost every single person in the department would come by my office at least once or twice a week. I got the chance to do some smalltalk, get to know them, do some team building. First meant for my own benefit and fun mostly, it also brought together odd groups of people talking about silly things sometimes, but talking. It didn’t cost a dime, hardly any time for anyone, and it was a lot of fun.
We stopped playing this summer at the end of a season when organisational changes brought other priorities, but I’ve heard people asking about it again recently. For something like this, you need a group of a manageable size and some minimal moderation, but up to 25 players we had no problems at all. I suppose it wouldn’t work in just any company or department, but (the right culture provided) I’m willing to try it again at my next gig, which is around the corner – I miss the quiz.
A man’s world?
Posted in Testing on October 6, 2010
Today I took the exam for my ISTQB Advanced Level – Testmanager certification. I finished the wearisome online training course weeks ago, and because I felt I needed more preparation than that, I went through the official ISTQB syllabi again to fresh up my memory. But even with those I was absolutely unsure whether I would pass the exam when my mouse cursor hovered over the final Submit button. Well, I did, thankfully. Many of the other participants weren’t as lucky – judging from what the trainer said, quite a large percentage even. That at least made me feel better about my score.
The questions were pretty tough, and some of those who failed the exam might get lucky as the German Testing Board wants to review some of them. Not all use a consistent glossary or have absolutely unambiguous answers. I also wondered how they will deal with newer versions of the advanced syllabus, when the exams also contain questions from the foundation syllabus, which has been updated this year. Keeping it fair for people who took their foundation exams in 2007 or earlier, but who soon will have to take the 2010-version of the advanced exam – how will that work? The certification people didn’t know but asked me to email them, so I guess I will.
If anything I took three things out of the whole ordeal. One, go to a real class next time. Or at least book an online course with a money-back guarantee. Two, when the trainer tells you it would be wise to go to the restroom once more before the exam starts, do it. You are not allowed to leave the room until the three hours are up or you turn in your paper. D’oh. And three, test management is (still?) a domain dominated by men. Of the 10 (12?) participants, all of them were male. Why is that? IT has always been a male-focused business, but it has changed a bit lately and testing in particular is a field of work which could benefit greatly from more diversity – if you asked me.
That voice, I can hear it in my sleep
If you are familiar with software testing you might have heard about the “standard” certifications and training courses a tester can, and should, get today. There is the ISEB side of things, mainly in the UK, and there’s the ISTQB, the International Software Testing Qualifications Board, in Germany and mostly the rest of Europe.
As a software tester, nowadays you usually get the ISTQB Foundation Level certification at some point in your career (earlier better than later), or the ISEB equivalent. Later on, you might go for the advanced levels. That’s what I’m currently pursuing, getting the Test Manager certification.
You have the choice of going to a five-day training course, provided by a professional trainer, and taking the exam afterwards. Or you can book an online course which lets you decide when to learn, though you still have to spend the minimum number of hours on it and take the exam offline as with the traditional course.
I went for the latter. It’s cheaper, and it lets you choose your own pace. Oh boy, what have I got myself into. The content is dry as it is, but this course makes it unbearable. It runs as a slide show in a pretty nice looking Flash-based interface. Unfortunately, the well-established German training provider chose not to hire a professional speaker. Slides, packed with text, and the speaker reads it all to you with almost no variations. Monotonous babbling sends your mind on a long trip to the supermarket and then into space as slide after slide, you drift deeper into the rabbit hole of desparation. You want to listen, you want to learn this, but it’s simply impossible.
The speaker has a dialect, too, which has made me mimic him whenever one of those words comes up. His English (which thankfully is rarely needed, as the course is in German) is quite, hm, questionable as well. The very few exercises are useless as you have no way of checking if what you come up with is even remotely correct. But then again, they are worded very vaguely to begin with. There are logical errors in the practice questions, and there is only one set for each chapter – going through them again a second time does not teach you anything as you already know all the right answers. And then, there are tons of typos – in a training course about quality management.
I wonder if I will pass the exam, well, or if I will remember anything at all when I sit there in front of my multiple choices. However, if I ever have trouble sleeping, I know what to switch on to make me pass out quickly. I’m sure there are better courses out there, if you can recommend any, let me know!
My tester sense is tingling
Posted in Testing on June 1, 2010
A long time ago Voltaire said
Common sense is not so common.
and nothing much has changed. However, one guy’s common sense in the next guy’s idiocy. Common sense, for everyone, is very subjective really unless you put it into perspective by calculating the average of everybody’s idea of common sense, which can be tricky. Common sense is not about democracy.
C.E. Stowe said
Common sense is the knack of seeing things as they are, and doing things as they ought to be done.
Which adds a bit of precision to the definition: common sense is about facts. Facts will allow you to make the right decision – given of course, that your facts are straight and you know what the best decision is. But that’s a different story.
Testing is a lot about common sense; all the techniques are tools of the mind, unlike the practical tools used for programming. It does not matter how a system works, or if you test an application, a document, a process or a sandwich. The approach is the same: get all the facts, define the frame of reference, inspect and compare the expected or desired result with the actual result. Sounds easy. It only works if you get it all right, though. You need all the facts, you need to know the frame of reference exactly. You use logic to get there.
It gets harder if the edges of your frame are blurred. If your facts have multiple variables, possibly all interdependent. You might need to look into the future. This is where common sense comes in.
Don’t mix up common sense with experience. Common sense can be gained and improved by experience, but hardly taught. And remember, common sense is subjective; it means something else for you than it means to Bob. Boundary value analysis may come natural to you. You might believe as the highly experienced programmer Bob is, he would know everything about it as well. Hey, you’re assuming here! Isn’t the tester’s mantra Never To Assume?
As much as you trust your “tester instincts”, as precise as your estimates might be, as trustworthy your risk analysis turns out – common sense will not save you, not more than pure logic will. Because common sense is not so common, because logic and people do not always mix. Measure, step back, use your common sense and measure again. It’s about both, facts and sense. If you neglect any, you will either end up deadlocked or eviscerated.
—
I realize my posts have been somewhat esoteric and elusive lately. I will try to focus on more practical things after the summer break, promised. I will also explain what I meant with my other post about sacrificing quality which came across wrong, apparently.
Show a little love
Posted in Testing on May 19, 2010
As a tester, I have the disposition to embrace perfection. Call it cliché, but of all testers I know, there’s not one indifferent to the quality of the product they are responsible for. Good is never good enough, compromises are loathed and short cuts looked down upon. It’s pride.
Of all the developers I know, there’s a fair number of guys (and gals) who share the sentiment. In general however, a developer’s objective is a different from a tester’s. Does it looks like it works? Ok, I’ll move on, build more cool stuff …
I blame the waterfall and V-model development processes. Who cares if the comments make sense? If the form matches the style guide? If the error message is cryptic? If I won’t wait for the next build to review? The testers will pick it up. And if it explodes, it’s them who get the blame. They get paid less anyway, so they can do the dirty work.
In Scrum, the whole team is responsible for the results. Testers suddenly become the developer’s best friends, someone you don’t want to tick off. Sure, they are in the same boat as you are – but you sure as hell don’t want to get asked to test. Test! Me!
Having direct access to the developers at all times opens a whole new world to testers. They can set or push the limits, get information quickly to improve their skills, and shine in their role as supporters. Because ultimately, “tester” is a support class in the software production role-playing game.
Sure, you cannot prevent things like
// saves teh data private static void dataSave(object datta)
No tester in a team with a 5:1 or higher developer-to-tester ratio can. But you, the developer, can. Show a little love. Please, you won’t regret it.
Couple questions out of context
Posted in EOF on May 6, 2010
Do you love or hate Google’s latest design update?
Speaking of Google, do you believe in their own statistics on how incredibly faster their JavaScript engine is going to be in Chrome 5, and do you still care?
Still speaking of Google, do you value your privacy so much and do you believe Google knows so much about you already, that you should rather mess up their business plans by confusing their search profiling (while of course still continuing to use Google search)?
Will you miss Microsoft’s newsgroups now that they have decided to switch them all off in favor of forums (maybe out of nostalgia)?
Would you, like Sean from F-Secure, ask Microsoft to bundle plain simple PDF/A support with Windows in order to finally get rid of a feature-laden, sluggish, often insecure Adobe Reader?
Do you have any idea what Google (did I mention them already?) could want with a 3D desktop software? Nextgen iPad or Android UI?
Did you know that all the fancy new 3D stuff that’s going on is actually going to damage you permanently (if you believe Mr Pesce, that is)?
Of sacrifice
Posted in Testing on May 1, 2010
I love deadlines. I like the whooshing sound they make as they fly by.
- Douglas Adams
So you estimated three months of testing. You end up being given six weeks. You hear talk about adding non-testers from other teams, yes, even non-techies and people who have never seen your product before, as helpers to compensate (Testing can’t be so hard, right?). You see the Big Triangle in front of you, the three levers one can pull: resources, release date – and quality. The release date was communicated and set in stone months ago. And the resources? You have one tester – for this example let’s say it’s yourself. By adding two others with no testing or product experience, how much more work can you do? You know the answer in your heart: approximately none. You’ll spend a great deal of time handing out instructions and answering questions, and your “helpers” are much less efficient than you in the first place.
In the meeting with the program head or project lead, you hold back your comment about how the company maybe should triple your salary instead of burning the money. No, you voice your concerns and then, you present the third possible solution for the problem: you could reduce the quality of the product. As you will not have enough time to run all the tests, the chance that there will be more bugs in the final product is great, and that usually means a decrease in quality.
As the professional tester you are, and let’s assume you are not the final decision maker, being presented such a “solution” probably makes you cry out load or at least scowl with anger. But if all fails, and you can explain to the “business” what this means, an informed decision to deliver a product which wasn’t fully tested is an option that will save yourself a lot of pain and energy. Energy that you can then invest in fixing bugs and preparing for the next release instead of falling into the deep black abyss after the crunch. Let’s be honest, testers and coders working 14 hours, making last-minute changes on a Sunday – this has never helped any product’s quality. A proper, detailed risk analysis, presented to the decision makers; a realistic, meaningful report showing where you are and what is still in the queue – you need to be informed, know the big picture. You need a contingency plan. Managament backing. And a little bit of luck.
An ultimate set of acceptance criteria, agreed upon with the team and management, can be your “quality safety net”. A maximum number of known bugs of this severity, or a minimum test case coverage, can be defined as a “contract” and prevent a premature product release. Obviously, some kind of critical systems, e.g. defense, medical or aerospace, have zero tolerance built in. But your average B2B, B2C software can possibly live with a margin of error – if you define this margin in advance, it will be easy to come to a go/no go decision.
Every tester wants to deliver the best possible result, but so also wants management – they have more than just one priority, however. As a tester you will have heard this before, but it’s very true and in my experience, forgotten too often.
Plan and prioritize, execute and follow up all your tests in such a way that when you stop testing, no matter how much you have actually tested by then, you have done the best possible test.
Estimate this!
Posted in Testing on April 23, 2010
Randy Rice wrote an insightful post in his blog, “Dirty Little Secrets About Software Test Estimation”. Usually I don’t like just linking to stuff other people write (feels cheap…), but this time I think it’s fair game, because I would have said exactly the same anyway, or most of it, though less elegantly I suppose. Thanks to Randy I can save me that effort now.
While I’m lazily linking stuff, do you already know Rands In Repose? I learn something new every time I go there.
Peer pressure
Posted in Team on April 22, 2010
About yesterday’s post: I continued to discuss making successful sprints objectives for sprint teams, and someone gave me a good point against doing this. Not only would it mean putting the sprint team under a lot of pressure and it would probably make them commit to less user stories – that I thought about myself – but more importantly, it would also put a lot of pressure on the people who accept or reject a sprint: the product owner and other reviewers. This can quickly become very tricky when these people have conflicting interests or close relationships with people in the sprint teams.
Authors
-
