Page 2 of 3

QA techniques, advanced level – Equivalence Partitioning, Edge Case

July 2, 2015 / / 0 Comments
Now you see me and now you should still see me 

If you Google equivalence partitioning and edge case (and you know you did), you will probably see the same example over and over again. It’s a form field that takes a well defined numeric value.

Don’t get me wrong. This is a very good example. In fact, it is exactly what you’ll need if you know nothing about these techniques, and you need to understand the theory. Many people stop there. If they ever encounter this exact scenario they will properly write down the input values, according to the equivalence partitioning and edge case example. However, if the real world scenario wears a large pair of sunglasses, or maybe a wig, many people will fail to apply these helpful techniques. In real life, you have the simple cases and the complicated cases. The obvious GUI cases and the abstract cases.

Guess which ones I love…
Continue reading

API mocking for software testing

June 14, 2015 / / 0 Comments
Cloudy weather has its problems

Back in the day (or in my case, way back in the day) , you developed a service, and (after hammering at it for a while) it worked. If you had to use an external API, it was one of the major ones (payment processors, major platform login tokens etc.). If one of them was down, then you and the users are probably too busy fighting away the rabid zombies to notice your application failing.

Today it seems that everything I handle is connected to a spiderweb of external APIs. Each service is an old timer cartoon evil boss – just sits in the high tech chair, and based on an array of CRT screens, and threatening phone calls, decides when to perform his only action – pressing a big red button. I have no issue with that. It’s cool that the service name can describe it’s entire function, and still fit on a single line with no scrolls. More so, it is way easier to test a service from A to Z, if there are no letter in the middle. It makes regression testing easy, so you can focus on the new and changed features. But…. it also means that in order to to test your little (yet chatty) service, you need to  make sure all of its little friends are online. Those little friends are also social beings, and cannot tell the time without several API calls of their own.

Continue reading

The rules for killer KPI for your production environment

May 31, 2015 / / 0 Comments
First things first

This is not a business related blog. When I write about KPI (plural), I mean the real stuff. KPI that tells you if your environment is functioning or not. You can, and should, mentally file it as an extension of your monitoring solution, and carrying the same importance, only requiring deeper understanding of your services, and make use of other metrics and resources (e.g. data base, logs, online counters).

Most of what you may read elsewhere regarding Key Performance Indicators is probably true. Everybody says they should be specific, and they are right. A KPI should be descriptive, right again. Targeting the bottom line, not a step in the process, correct. Read as much as you can about it and you will be a better person for it (and less likely to do something stupid). Business KPI are important, but they should not wake you up at night.

Green, red, and maybe yellow

Business KPI will probably be numerical, maybe even a beautiful gauge. Usually they represent trends. Production environment KPI should be Good / Bad. In some cases, you can allow for middle ground (which means not enough information yet, so if you planned to go home, go to sleep or pretend that you have a life, hold on to that and currently keep refreshing) . So we have green for good, red for bad, and yellow where applicable.

Now that we are all aligned, here comes the rules.

1. A red KPI cannot be ignored

This has two meanings. First – You should never ignore a red KPI. If the KPI describes something that can be left alone in its redness for a while – you don’t need it in the killer KPI list. Second – you should not be able to ignore a red KPI. It should hunt you using all forms of communications, send you push notification, phone calls, email, the works.

Continue reading

The advantage of having magic powers

April 29, 2015 / / 0 Comments
The truth

People, by definition, have faults. Most of the time, people are unaware, to some extent, of them. Those dear people, alog with their said resident faults, go about their daily business. Manifesting code, conjuring methods, summaning instances and remotely communicating with web services. All these creations, once made flesh by their faulty masters, hold the fault pattern in them, emitting, sometimes weakly, sometimes beacon, fault energy. Quality assurance practitioners feed on fault energy. Unseen by others, it calls them. The QA practitioner unorthodox ear allow no beeswax to plug it, to avoid the siren call. His sneaky hands cannot be tethered to the mast. And so, by feasting and consuming the faulty manifestation, the QA practitioner transforms it, elevates it, into production ready code.

Just a bit

OK, that was not exactly true, and maybe, just a bit over the top. Yet, if you have the experience and the talent that motivated you to gain it, you should be able to pull some very impressive tricks. We all makes mistakes, and we all make repeatable mistakes. I’m not talking about the “turning a blind eye to your own best interest” kind (dating a person you know is not good for you, eating that extra fry, delaying a task until there is no way you can complete it in time). Repeatable mistakes are spelling a word wrong for the Nth time, trying to turn on the light when you know the power is out, and more important to this discussion – introducing the same bug – again. We, as the quality assurance people, should expose these bugs like hyperactive magicians during caffeine overdose. These low hanging fruits should not receive any mercy. They count, like all other bugs. And they also give you the opportunity to impress, without actually showing off.

Continue reading

Thinking outside the (Black) box

April 21, 2015 / / 0 Comments
Wisdom of others ltd.

I’m all about learning new technologies, and bathe in the wisdom of others.

I’m also all about nodding my head politely and do my own thing, when I feel like it.

 The polite nodding stops when I hear something along the lines of “black box only”. It gets worse when it is followed by an explanation.

I have a beef  with the notion that the QA expert should always represent a user.
In other words: “If a bug exists and the user cannot cause / experience it, then it is not a bug, and all other testing methodologies (that do not replicate the user experience) are null”.

 In a fairy wonderland, where every single factor in nature can be calculated and controlled, this might be a valid point. But in real life it makes as much sense as eating a lot of feathers when you feel heavy, or connecting one end of an extension cable to the other end, expecting infinite power. Even worse, in many cases, this idea does not originate out of pure naivety. But let’s start easy….

Source without control

From my experience, such a misguided concept can arise from the following reasons:

 

  • Not understanding testing limitations
  • Not understanding testing capabilities and benefits
  • Underestimating the tester’s technical ability
  • Overestimating code and system quality

 

Continue reading

The rebel QA – a case for doing your own thing

April 12, 2015 / / 0 Comments
On the road, be smart, not right

 

When you work with other QA persons, you have the privilege of having intelligent (= QA)  partners, that understand your language exactly. In all other cases (mostly when working under development or product persons)  you will need to make some adjustments.

 

Most of all, you will have to practice the gentle yet unavoidable art of processing what they asked for, and coming up with what they really want. This sounds a bit presumptuous, but in fact we see it all the times when someone is (only) partially learned in another’s profession – some of the things that comes out of the mouth will be nonsense if you take them literally, and some might be pure stupidity even with some friendly leeway. I’m pretty sure the dishwasher repairman I called knew exactly when to stop listening to my description of the the issue (Probably right after: “Dishwasher does not clean”). Sometimes your task description is just as useful.

 

 

Specing solutions instead of describing the problem

 

This is a very common issue, and it is not limited to QA. Some product people tend to spice up the requirements with technical terms and describe the implementation instead of the feature, reducing the developer’s experience and ingenuity to plain coding (If you have BDD written somewhere on your CV you probably have an allergic reaction to it).

 

In the testing world this becomes even more of an issue. If a product person limits the creativity of the developers (which might prevent a better looking, better performing product) , limiting the tester’s creativity (to the scope of the developer’s) will ultimately limit the test coverage as well, and I don’t have to tell you how it all ends.

  Continue reading

Five things serving in the military can teach you about maintaining a production environment

March 25, 2015 / / 0 Comments

Don’t worry, there will be no “kill or be killed” or “death before dishonor” slogans here.
I do not work in a place where the production environment is responsible for people lives. No one would die if I mess up, or even if I really really mess up. A lot of people, however, will have to look for new jobs. With this in mind, let’s see what lessons from the military would benefit you in maintaining your production environment.

 

Not working is bad. Blows up in your face is worse

No one wants to hear “click” when you expected “bang”.

No one wants to take a look at your online store in the morning and see an error message. Your potential users will wander away, and you now lost 100% of your potential earnings. That’s a bad scenario, and it is tested for. How fast does the site show? Does the home page look good on an obscure browser that only runs on mobile devices from 20 years ago? Very important indeed.

“Kaboom” when you expected “bang” is worse.

Continue reading

Hey, there’s a blogging course blog post on my blog. Wait… what?

March 13, 2015 / / 2 Comments

I’ve been listening, in the past few years, to a lot of entrepreneurship and blogging related podcasts. Add to that a lot of reading. I knew, for a long time, that a blog will help me brand myself, and will give Google something to return when searching my name, due to my social networking non existence. But I didn’t do anything about it.

One reason is pure laziness (I mean, having very little time with my full time high tech job, commute and parenting two children. But also laziness).

But there were two more reasons:

I got many good tips from various podcasters and bloggers, dispersed over multiple locations and time, never all in the same view.

A lot of the tips and guides are very high level. They give valid and important recommendations, which are almost at the philosophical level. I needed someone to hold my hand, while giving that necessary little kick in the back side.

Continue reading

It’s a wild world – so go data driven with real world data

February 28, 2015 / / 0 Comments
I didn’t see that one coming

The world works best when QA professionals do not get surprised a lot.
Actually never would be just fine. After some time you really do see it all, right?

Wrong.

There are some laws of nature that we tend to forget, or just push aside, but always comes back, like a karmic
boomerang of truth. If your system is more than trivial, and you run a database profiler, you will learn something new.
If you run a profiler on your code and stress it, you will learn something new.

If you run your system on real world (“production”) data – you will learn something new.

Mainly, that you have some unexpected bugs.

Keeping it real

Real world data have three things going for it:

  1. There is a lot of it.
  2. It is diverse, and in it’s way, devious.
  3. It mirrors issues with parts of the system that are not currently under test, including 3rd party issues.
  4. If your system has elements open to the world, you get calls that are invalid in just any permutation you can come up with.

Continue reading

The first API you should learn

The first API you should learn

February 25, 2015 / / 0 Comments

Not a case of super heroes

 

After some time in the business, I started to work for an organization that,
for the first time, actually had QA engineers before me. I was still going to
be the only one, but I had a few weeks overlapping with the person leaving the job.

Nice place, nice people. Yet the (soon to leave) QA and one of the developers
were never seen together. Not around the (proverbial) water cooler, not
at lunch, not at all. In fact, the only communication they had was via the bug
tracking system, even though they were sitting less than 10 feet apart and in line of sight.
Continue reading

« Older posts Newer posts »

Categories

© 2024

Theme by Anders Noren — Up ↑