I’m not without my own moments of stupidity.  I recently decided the reduce the stress level in my life and only accept contracting jobs that were pure testing.  No more Test Management jobs!  I just wanted to run my tests and go home for the day and leave work behind me.  I know, I know.  What was I thinking?  The stress is still there – it’s just a different kind of stress. Most of that stress comes from having to work for completely inept managers.  The rest comes from other testers who have absolutely no clue what they are doing.  At least as a Test Manager I have some control over that part.  Then I just have to deal with idiot development managers.  Let’s face it – I need to be in charge of something.

Now, I’m not God’s gift to software development – but I’m no slouch either.  I don’t admit to knowing all there is to know about Test Management.  I don’t!  But I’ve been doing this for a long time and I have a pretty good record to back it up.  I do know a thing or two.

So I tried to be “just a tester.”  I tried really hard.  But I couldn’t keep my Test Manager’s mouth shut.  It was definitely a learning experience.  The most valuable lesson I learned – most project managers and test managers have absolutely no clue what software quality means or what it looks like.  Worse – they really didn’t want to hear from me what it was either.

I know what quality is – I have a pretty good track record of insuring quality products are provided to the customer.  It completely blows me away when any manager dismisses any defect as “not important.”  Take for example spelling and grammar errors.  Minor? Sure.  Insignificant?  No way! It’s these stupid little errors that will make you look like a complete moron.  Stupid is as stupid does! 

That said – mistakes happen.  Especially early in the development process.  Errors are made, builds will break.  If they don’t then I seriously question your development process.  If you don’t make mistakes you are just not trying hard enough.  You’re being too safe.  FYI – I’m a Tester.  If you make me a developer, I can do it, but I may break a build or two.  I know me.  I’ve seen me do it!  If you’re the Test or Project Manager that made me do development work – as Bill Engval says – “Here’s your sign!”

There is a serious difference between stupid and inexperienced.  For example, If you hire less expensive, off-shore, or imported, test or development resources that barely speak the language or understand even simple grammar, you’re going to have problems.  The developers and testers are not stupid – they’re inexperienced.  Now the managers that don’t realize this and don’t come up with ways to verify it don’t get off so easy.  They too may be inexperienced.  But when I tell them about it, and they still do nothing – they enter the realm of stupidity.

To make a short story long – If I have to deal with stupidity, I need to get paid for it.  So Test Management community – I humbly return to your ranks, head held low.  I was wrong.  Please let me come back.  The stupidity ends here!  I’m gonna need more signs.

I recently worked on a project that was off-shored. For the most part things ran pretty smoothly but there were a number of issues that were insanely simple (from my perspective) yet became overly complex over time.  The primary cause, I believe, was cultural differences between testers here in the U.S. and the off-shore development group.  Three simple things that took weeks to resolve:  currency formats, sorting of dates, and phone number formats.  I know what you’re thinking.  How complicated can it be.  Trust me, I lost a lot of hair over these three seemingly simple concepts.
The first one had to do with formatting U.S. currency values – specifically negative values.  The application dealt with currency values on a number of pages.  The customer was a U.S. state, so nothing other than U.S. currency values was involved.  There were a couple of different formats depending on the page you were looking at.  Pages displayed one of two different formats for negative currency values: -$1234.56 and $-1234.56.  Which is correct?  Common usage will tell you the first one is correct.  Unfortunately, there was no specific requirement on formatting currency.  So instead we looked to Microsoft Excel for the answer.  The answer was example 1: -$1234.56 (actually the default was (1234.56) but that’s another story).  We asked them to change it – they did with no argument.
Second – date sorting.  Again not specified in the requirements because according to the Business Analyst: “Everyone knows this.”  Apparently not.  So if we wanted to sort table data by date we have two options:  ascending and descending.  That’s where the problems started.  We had different definitions of what those words meant.  With alpha characters or numbers – not an issue.  With dates, not so much.  The requirement stated only that records would be displayed, by default, in descending order, by date.  To me, that meant the most recent record first through the oldest record.  When the application was delivered to test we got the opposite – oldest records first, newest records last.  So I wrote it up.  In the bug triage meeting there was a huge argument over the concept of ascending vs. descending.  To our off-shore partners descending order by date meant oldest records first, newest records last.  They had a pretty good argument.  Again, Bill Gates to the rescue.  ”What would Microsoft do?”  We finally agreed that descending order by date meant most recent records first and oldest records last.  It only took an entire afternoon to resolve it.  Once again we asked for a specific requirement.  We were denied because requirements shouldn’t address “common sense” issues.  Whatever.
The third issue – phone number formatting – was not so easy.  This time we had a requirement.  Vague – but a requirement none the less.  The requirement basically stated that system would display 10 digit phone numbers using a dash and pair of parentheses.  Well that is exactly what we got.  A phone number was displayed as (5)55-5555555.  Does it meet the requirement?  Absolutely!  Was it a valid U.S. phone number?  Not a chance.  So I wrote it up.  The off shore contractor fought this one for almost a week.  They swore that this was correct and in accordance with the requirements.  They refused to change it.  We found out later that they were penalized if the defect count got too high.  So we figured we would reword the requirement to be more specific.  Easy fix right?  Wrong?  The Business Analysts fought changing it again citing the “common sense” doctrine. A week later, after a lot of arguing, the requirement was changed and the format fixed.
In looking back, I feel that this whole mess came down to a difference in culture.  First of all, the off-shore vendor was a third world country and had no clue how this type of application should work, look, etc.  Also, their culture does not condone “mistakes.”  Defects made them “lose face” so they fought each and every defect we found.  (The defect penalty in the contract didn’t help).  Lastly, this was a culture that prides itself on “doing things right.”  What is right?  In this case the requirements defined right and wrong.  It was either black or white.  ”Doing the right thing,” on the other hand is a gray area.  Harder to define.  You know it when you see it.  It’s sometimes hard to define.

The lesson learned:  when dealing with other cultures, common sense may not be so common.

I worked for a Wing Commander, who’s mantra was “push people”.  He felt it was OK that you could make crews work overtime or work weekends etc.  Of course we never pushed the aircraft.  The machines were always given appropriate down time for maintenance, refueling, reloading, etc.  The commander had “stars” in his eyes (in this case general’s stars).  It was an accident waiting to happen.  Unfortunately it did happen – taking 6 lives including a high-ranking government official.  It wasn’t until the accident investigation that his “management style” was revealed and ultimately identified as a major contributing factor – crew fatigue.  It took an accident investigation and the lives of 6 people for the “leadership” to see there was a problem.  They could have asked me 3 months before the crash.

Sometime later I read an article on productivity.  I wish I would have saved it because it has had a huge impact on me ever since.  Essentially, the article stated that people can only be pushed so far before productivity begins to suffer.  When you push them beyond their full capacity, you will see some short-term gains in productivity, but over the long haul productivity will decline – significantly.  So if you have air crews and maintenance crews working 3, 8-hour shifts, you will see some short-term gains when going to 2, 12-hours shifts.  At some point, however, things begin to break down.  Maintenance gets sloppy, minor (but necessary) procedures will get over looked, and accidents happen.  We saw it every time we would go into any long-term or frequent war game, or as we called them – exercise. 

We used to practice going to war all the time.  There would typically be one or two “exercises” a year.  However in the event of a pending major inspection – the exercise schedule would be increased.  Colonels become Generals based on these exercise results.  So twice a year became once a month.  By the time the actual inspection arrived we were exhausted.  We made stupid mistakes – mostly minor – but mistakes none the less.  We passed – barely.  Oh – and we were responsible for handling nuclear weapons.

Back to the article.  The author studied and tracked productivity as workers were stretched from full capacity to beyond full capacity.  The study found that in the short-term, productivity levels did increase – slightly.  Then as time went by productivity dropped dramatically to levels below full capacity.  The bottom line – crews were more productive, over the long-term, if allowed to work normally.  Well not more productive exactly, but productivity did not decrease.  I showed the article to the new commander but he blew me off.  Never confuse a military leader with facts!

In addition to the loss in productivity, there were other negative factors.  The most obvious (now anyway, we didn’t see it at the time) was that personal quality evaluation (Task Evaluation) scores began to decrease.  Periodically, Quality Control inspectors would watch various crew members perform their daily job tasks and complete an evaluation of their performance.  When pushed beyond capacity – they made mistakes – which were ultimately reflected in the evaluation results.  Maintenance crews would take short cuts, not follow instructions, read an indicator incorrectly, etc.  They were tired and exhausted.

There were other indirect signs as well.  Domestic violence incidents increased.  Alcohol related incidents increased.  There were more driving violations.  Family members were getting in trouble – the list goes on.

Sadly, we’re seeing this today.  Military troops are being pushed way beyond capacity and we’re seeing the results.  Minimum tours have been increased from 12 to 15 months.  Enlistments have been involuntarily extended.  Troops may get to spend a year with their families before being deployed for another 15 months.  The result:  Drinking and drug use are on the rise.  Domestic violence has increased.  Divorce rates among troops is up.  Worst of all – suicide rates for military members is at an all time high.  Is it worth it?

So when you are estimating project length – keep all of this in mind.  You can only push people so far.  Will it be as drastic as I described…probably not.  But there is a downside.  You can’t push people.  They will break!

Shut up and Test!

Shut up and Test!

Shut up and Test!

Shut up and Test!

My new mantra

It’s my job to be different than the rest
And that’s enough reason to go for me
It’s my job to be better than the rest
And that’s a rough break for me

It’s my job to be cleaning up this mess
And that’s enough reason to go for me
It’s my job to be better than the rest
And that makes the day for me

While I’m not a huge fan of American Idol, I’m a big fan of Simon Cowell!  Do you think if one of the Idol winners ever gets an award, like a Grammy, they will thank Simon?  I doubt it.  He’s lucky.  He can be open and say what he feels.  Sure people are angry at him.  But you know what?  He’s usually right.  It’s just the message delivery that upsets most people.  Deep down, they know.  Unfortunately, for software testers, that’s not a luxury we have.

I think Simon would be a great software tester.  A desirable attribute for any good software tester is to tell people what we think – tactfully (OK this is SO not Simon). Software developers, Project Managers, Product Managers, and anyone else on a software project, spend countless hours designing and developing software applications for customers.  They’re proud parents.  It’s their baby.  Then they show it to us, and essentially ask:  ”What do you think?”  More often than not we have to tell them they have an ugly baby!

I imagine, if you have an ugly baby, Simon would tell you so!

Nobody wants to tell someone they have an ugly baby, but unfortunately, it’s our job.  The key is how you tell them.  Sadly, you will always run into a proud parent that will be hurt no matter how you tell them.  Different parents will respond differently depending on the way the message is delivered or received.

So how do we handle these delicate situations?  Having been a test consultant now for a few years, I’ve had to deal with a number of delicate parents.  Here are a few tips on the proper care and feeding of delicate parents:

- Build a Rapport with the Team:  Get to know them.  Take them to lunch.  Buy them bagels or donuts.  Let them know that you are there to make them look good.  When a virtually flawless application is delivered to a customer, no one says how well tested it was.  Development teams will always get the credit.  However, if it is delivered with bugs, everyone will wonder who tested it!

- Be Honest and Responsive:  One of the best compliments I ever received was:    ”If Dave and I grew up together, I’d never let him touch my toys.  He breaks everything!” Tell them up front, you’re going to do everything in your power to break their application.  It’s what you do!  Although a good magician never reveals their secrets, a good tester should.  If I have time, I will usually tell them what my attack plan will be.

- Be Open and Available.  Want me to take a look at your requirements? – Absolutely!  I always let teams know, that if I’m available before formal testing begins, I will give them a free look at their requirements, specifications, code, whatever they have.  I won’t create a defect in the bug tracker.  I’ll just shoot them a quick email, and make a note to look at it later.  It ends up saving everyone time in the long run and, once again, makes them look good when formal testing begins.  It also helps me develop and refine my tests.

- Let Them Review Your Tests.  If you’re going to look at and critique their stuff, it’s only fair to let them do the same to your stuff.

- Don’t Rely on the Bug Tracker.  Never send a public ugly baby notice!  The last thing you want to do is rely on the bug tracker to deliver bad news.  There is nothing worse, or less productive, than flame wars in the bug tracker.

- Talk to someone!  Let them know what you did and why you did it.  Show them.  Lead them towards a solution.  Tell them what your expectations are.  It may be a simple misunderstanding of a vague requirement.  Count to 10, then write it up.

- Check Your Attitude.  This is my personal weakness.  You don’t want to come off badly.  What’s funny to you, or well meaning, can be completely misconstrued.  Be critical, but constructive.  You need an air of friendliness and support.  If you come off as arrogant or condescending, the ultimate message will be lost.

- Don’t Take it Personally.  Tough to do?  Absolutely!  But you’re just the messenger.  Its’ usually not about you.  You’re just the closest and easiest target.  Grow a thick skin.

- Be Prepared.  It’s going to happen.  Maybe it hasn’t happened yet, but if you do this long enough, it will.  Be ready for it.

- Write an Article.  While it may not solve anything, you will feel better afterwards.  I know I do!

Unfortunately, while these tips tend to work well with in-house teams, it can be difficult with geographically distributed teams.  Since they don’t work with you face-to-face every day, and you can’t take them to lunch or buy them donuts or bagels, there is a tendency for the message to get distorted.  As I recently learned (the hard way).  Even though you may have good intentions, someone’s feelings may get hurt.  Unfortunately, attitudes don’t translate well over the phone or by email.  Don’t be afraid to apologize.  It’s typically a misunderstanding.  It’s more important to heal the relationship and move on than to stand on principle.  If you’re right – gloat to yourself.

Bottom line – no matter what you do, you’re going to hurt someone’s feelings.  Be prepared for it and don’t be afraid to make adjustments if you need to.  It may still be an ugly baby, but it’s never too late to do something about it!  Someone has to do it.  You don’t want the customer to do it.

If you’re in this business for personal rewards or recognition, you probably need to rethink your career choice.  Not that they’re not there.  They’re just few and far between.  No, a good tester gains satisfaction by knowing, albeit silently, that they were the reason the application was virtually flawless.  Sure, no one else may notice, but I know, and that’s good enough for me!

There are 2 groups of people that know absolutely nothing about software testing.  First – test tool vendors.  Second – Software Project Managers (but not you Kathy).  Sadly, the first group is keenly aware of the existence of the second group’s lack of testing knowledge/experience and are like the old traveling salesman when peddling their wares.  Tool vendors remind me of Starbuck in “The Rainmaker”!  Well then call me Lizzie!  I’m not buying it!  (if I’ve lost you – go see the play)

If you are an automated tool vendor – keep reading (by the way – you’re gonna hate me by the end of this – stand in line – behind the Agilistas).  If you’re currently involved in any automated testing project – keep reading.  If you think automation is always the answer – ignore the vendors and keep reading.  Bottom line – automated crap=diarrhea!  If your underlying tests are crap, automation just gives you high speed crap.  Its still crap.

Any test automation is expensive – even if you use a free tool.  In fact, I’m willing to bet a super-deluxe, cream-filled, chocolate donut that free tools, in the long run, cost more than the big high-dollar tools to implement and use effectively.  Not that those big tool vendors are off the hook.

Please don’t think that I’m against test automation – nothing is further from the truth.  Many of the tools are great tools – when used properly and in the right circumstances.  If it is the right tool for the job.  Will automated tools reduce test times? – mostly.  Will they improve your testing? – maybe.  Will they result in a higher quality end product? – rarely.

Much depends on what you choose to automate, or how you define automation.  Engrave the following somewhere in your brain where you can refer to it often…”You cannot, and in most cases, SHOULD NOT, automate everything.  It is rarely economically feasible!  Still with me tool vendors?  Everyone else pay attention!

Let’s take a quick look at functional test tools.  If you only use the test automation tool to run positive, “happy path” tests can you really consider yourself “automated”?  Not really.  Not in my opinion anyway.  The problem with most “free” tools is that all they do is record user responses and play them back at high speed.  Errors page or messages can fly by – just like the good pages or confirmation messages.  If you are not paying attention, you may miss them unless the system crashes.  These tools do not evaluate or validate anything.  That part is still up to the tester.  Just because a test script runs end to end, it may not mean the test passed or the application works.

Higher functioning tools allow you to modify the input data, which is a step in the right direction.  You can now enter bad data and see what happens.  Most tools typically still require some type of manual validation of the results.  Unless it is a critical error and the system crashes, most scripts will sail past error messages. If you are inducing errors, you probably want to see the results.  I would.

The really good tools will not only let you input good and bad test data, but will also evaluate the results.  These are usually not the free tools.  Really good tools will validate page loads or data fields, detect error messages, read parts of the screen, validate databases, etc.  All of the things you would typically do during a manual test. 

Many of the automated test projects that I have evaluated as a consultant fall way short of the level of testing that I would expect.  Most of the tools are purchased by someone far outside of the testing arena who have no clue what they have just bought – usually someone in Purchasing.  They listen to all the tool vendor hype – typically from a salesman with absolutely zero testing experience, and purchase the tool without talking to anyone from the test team.  Then like Santa Claus, bring you this nicely wrapped “gift” that ends up being completely useless.  It ends up on a shelf gathering dust.

So you load the new tool, designate one or two people as “automated testers” and record and run your first test.  You feed in all the right data in all the right places and click all the right buttons.  The test passes.  On to feature number 2.  You demonstrate your library of new high-speed tests to a completely ignorant and clueless group of managers who are wicked impressed.  You continue to automate the remaining suite of tests.  You deliver the product ahead of schedule – all as a direct result of your automated testing.  You now declare yourself “automated”.

But are you really?  At this point all you really have is an automated smoke test.  It’s a start but there is a huge amount of testing remaining.  Don’t forget the negative side.  If you use a free tool you may have no other option than to do only positive tests.  That is typically all these tools will support.  They are usually just record and playback tools.  They are of limited value.  But hey, what do you want for free?

Oh – and a quick word on automated development test tools – they are just that.  They are not a replacement for functional or system level UI-driven tests.  They work under the covers.  You will eventually need a tool that will drive your test from the UI – as the users will.  Rely solely on this “under-the-covers” tool and you are at risk for huge problems down the application lifecycle,  Or worse – after delivery.

Lastly, in spite of what the traveling salesmen tell you – automated tools are not a plug-n-play option.  They require specialized knowledge, development time, and maintenance.  All still pretty expensive.  Once the system is up and running and all of the scripts are recorded and errors are fixed, you may begin to see some cost savings.  Maybe!

Do I hear thunder?  Is that rain?  Bang that drum!  Louder!

Ever since I was a wee lad, I wanted to be a Maine fisherman.  I’m actually from a small island off the coast of Maine.  Well technically it’s not an island anymore since they built a road to it. 

My father, born and raised on the island, would always fill me with romantic stories of growing up on the island and working on the boats.  He enlisted in the Air Force after graduating from high school.  He married my Mom and a year later I was born.  During his 20-something year career, we moved around a lot.  Typically far from Maine.  We would go home every now and then for “Old Home Week” – the island’s week-long Fourth of July celebration.  I followed in my Dad’s footsteps and enlisted in the Air Force right after high school.  My dream, after I retired from the Air Force, was to return home to Maine and be a fisherman.  Deep sea fishing. 

For our “honeymoon” I took my new blushing bride home to Maine for the Forth.  I remember it like it was yesterday.  As we approached the “island” from the mainland, the fog was just lifting, the setting sun glowed orange off of the old white houses on the hillside (shacks really).  It was picture perfect.  Like a picture in a calendar.  The following morning we would be on the fishing boat – I was down right giddy!

We got up really early the next morning.  Even though it was July, the air was crisp and cool.  Steam was gently rising off of my freshly brewed cup of coffee.  There was a thick blanket of fog on the water.  You could hear seagulls somewhere in the distance.  It was perfect!  I boarded the boat ready to experience what my future held.

Reality set in about the time the coffee ran out.  The fog lifted after about an hour and it was hot and muggy.  The lifting fog also released the stench of dead fish.  The seagulls were starting to get annoying.  They smelled the dead herring and were circling the boat looking for food.  We were dodging seagull poop.  The tide was out adding a special aroma to the mix.  We were gagging on diesel smoke.  I spent the first hour or so helping my Dad bait the novice fishermen’s hooks with dead, rotting, slimy herring.  My clothes reeked.  And there was still 4 hours to go! 

The only thing we caught after 5 of the longest hours of my life was a squid.  My new wife caught it.  She didn’t really catch it.  It had the misfortune of swimming by just as she was reeling in her line.  She just kinda snagged its head.  The girls all screamed.  No one wanted to touch it.  So my Dad (who I swear was the model for the Gorton’s fisherman) volunteered to unhook it.  It wrapped its tentacles around his arm and used its sticky sucker-thingys to hang on to him for dear life.  He eventually peeled it off and returned it to the bay.  Somewhat traumatized by the ordeal, and with the exception of having once had a huge fishing hook in its head, the squid was pretty much unharmed.

After the squid ordeal, I looked up as we slowly sailed past the island.  I found myself jealous of the lucky islanders in their cozy cottages up on the hill, eating a nice hot breakfast. I longed to be back in my nice soft bed, snuggled up against my new wife, or sprawled out on the couch watching television with the smell of sizzling bacon wafting through the house.  I have no clue who would have been cooking it, but that’s not important right now.

I couldn’t wait to get off that stupid boat!  Needless to say, that was my last fishing trip. 

A week later we returned to Colorado.  On the flight home I pondered my future career aspirations.  Whatever I decided to do was going to be indoors, temperature controlled, and not reek of fish.  I hate fish  I don’t even want an aquarium!  It’s been almost thirty years and I haven’t been fishing since.

So here I am – a Software Tester.  I couldn’t be happier!

I recently decided to take a break from managerial roles and return to life as a simple tester.  I assumed the stress would be less, I’d attend fewer meetings, I could just concentrate on my test assignments and go home at the end of the day and leave work at work.  Yeah right!  The bottom line – I really missed getting my hands dirty and doing the actual testing.  My role as a test manager was much more “conceptual”.  Providing test estimates, writing test plans and strategies, giving my “expert opinion.”  And seemingly endless meetings!  When I wasn’t in a meeting, I was in an office all by myself.  Rarely interacting with anyone.  It killed me.  I absolutely hated it!  I know – I’ll be a consultant!

As a consultant it’s easy to shift gears a little,  I just had to modify my resume and remove all the managerial stuff and replace it with hands-on testing stuff.  Then cast it into the water and see what bites.  I got a lot of bites.  But in spite of my best efforts, I was typically found to be over-qualified.  A bit more tweaking was necessary.  So I reworked my resume again and took a look at some of my responses to interview questions and revised them.  It worked – I’ve been able to land a couple of pure testing roles.  This is usually where the “and he lived happily ever after” line usually comes in.  Not so much.

I found it really hard to take off my test manager’s hat.  I was pretty successful as a test manager.  I’ve written about test management, spoken about test management and taught test management,  I know everything there is to possibly know about test management.  I thought to myself – these people don’t know how lucky they are to get me.  I could assume my “tester” role and at the same time help them improve their testing skills, test planning, defect management etc.  It didn’t quite work out that way.

I learned a few things about myself though.  First, that I can be a little over-bearing.  OK – a lot.  I’ve had to learn to just “shut up and test.”  After all, that’s what they hired me to do.  Not improve their test management.  But it’s hard.  After 20 years of doing this I’ve seen what works and what doesn’t.  Whenever I saw something about to be implemented that had failed for me in the past I spent more time raising the “this ain’t gonna work” alarm rather than helping the team move forward.  I admit it, I was somewhat of a whiner.  That’s OK though – I’d just save up a big “I told you so” to use at the first opportunity.  I rarely got that far.

Second – my opinions were rarely wanted.  Just test!  But you don’t understand – I am after all…me!  People pay money to listen to me (sorta) and I’m giving it to you for free.  What’s wrong with you people?

So what I’ve learned is this.  Just because they don’t do things my way, it doesn’t make them wrong.  They’re just different.  Give ‘em a chance.  If I don’t like something or disagree – discuss it as a team member rather that crashing down on them with my “vast testing knowledge and experience”.  People appreciate listening to ideas rather than having them shoved down their throats by “the consultant.”  Consult – don’t dictate!  Tell them your experience, offer suggestions, be there to help.  I now tell test managers that I may disagree with something (I probably will).  Take it for what it is – an idea.  It’s me.  It’s what I do.  You don’t have to agree with me, but at least give me the opportunity to stick my two-cents worth in.  Let me share my ideas and opinions – in private!  You don’t have to agree with me – just listen.  At the end of the day, we may disagree behind closed doors, but once they make a decision, I’m their biggest cheerleader.

Is it easy?  No.  I still struggle with it – everyday.  Much of it is just my personality.  Most of my previous consulting gigs were aimed at process improvement.  Analyze, and make recommendations to improve.  That’s not my role anymore.  I’ll be honest, maybe it’s time for me to return to a test management role or a problem solving consultant role.  But until then – with the exception of this blog and my quarterly “Last Word…” articles in The European Software Tester (T.E.S.T) magazine – I’ll just “shut up and test.”