Forget About Bugs

Forget About Bugs

Ask my wife how forgetful I am. You’ll probably get a big sigh. Case in point; the other day we were on our way home and we were about 30 seconds away from turning onto the side street we live on. My wife said to me “don’t forget that we need to go to the grocery store.”

“Yes dear”

30 seconds later.

“Why are your turning onto our road! We need to go to the grocery store!”

Yes, I can be that forgetful. I know that I’m forgetful and so I have systems in place to help myself with this. I try to write things down and use software to remind of things when I can. I might be an extreme case, but I think we all forget stuff sometimes.  It happens in software development as well. This is why we have stories, and documentation and defects.

However, sometimes I want to forget things. Take bugs for example. Having a big bug backlog just slows us down and I don’t want to go through it every week or two and see at the things we haven’t fixed. So what can I do to make bugs more forgettable?

Well let’s consider a few ideas:

I could fix it myself. Who says only developers can fix bugs? Sometime I know how to fix it myself or can figure it out with a bit of work, so why don’t I just do that?

I could immediately work with a developer to fix it. Instead of filing a bug and sticking it in some backlog, I could chat with a developer who know that area of the code and see if we can sit down and figure out the issue and fix it on the spot.

I could work with PM to make into a story for the back log. Sometime a bug doesn’t have to be a bug and can just be prioritized with other work we are doing

I could walk away. Maybe this bug is ok to ignore.  Maybe I can just embrace my forgetfulness, look the other way, and go find something more important to fix or work on.

Of course sometimes a bug does need to be remembered, but wouldn’t it be nice to be able to forgot about them more often?

 

Photo by AbsolutVision on Unsplash

API Testing – Getting Started

API Testing – Getting Started

In many ways APIs are the glue of the internet. The modern internet is increasingly built on distributed architectures and companies want to make their platforms extensible. APIs are a crucial part of these kind of business strategies. (If you aren’t sure about API terminology, check out my API testing glossary here).  APIs are also challenging to design and test. By their very nature they are meant to be accessed programmatically and to expose underlying constructs in ways that are simple to use and understand. You might be comfortable with how to test manually or even with various types of test automation, but not really know and understand how to effectively test an API.

I have been working on testing APIs for a while now and have also put together a course that I hope will help people looking to get started with API testing.  I also want to share some material for this on my blog in the hope that I can help others along this path towards API testing skills.

Let’s start with trying to understand a bit about web services. Many web services provide APIs that can be used to drive them and so understanding a bit about what is meant by the term web services is as a good a place as any to start with in API testing. As with any term in technology, it can take on different nuances for different companies and contexts but I find that a helpful way to think about it is actually in terms of mathematical functions. Don’t worry though, no complex math is needed to understand this.

When I was first introduced to functions in grade school I learned to think of them as a black box that took in some inputs and did some kind of transformation on those inputs to then produce an output. I use this same model to think of a web service.

Let’s make it concrete and look at a real life example. Let’s say we are testing an application and we want to get a first and last name to use for a login test.  We don’t want to use the same name every time, but we still want to have somewhat realistic names.  We could find a database of names and write some code that randomly selects names from it, or we could go to a service like uinames.com and get it to generate the name. By giving the service certain inputs (like an API path and perhaps some other request parameters), we can get back a user name that we can use.

We don’t know anything about how that service does what it does. It might use python, or php or javascript to do this work. It might get the names from a database, or it might request them from other services. We don’t know. We can just think of it as a black box that will give us back certain inputs based on the inputs we give. And that’s really all we need to know at this point. This is how I think of a web service. A black box that does some action(s) for you based on the inputs you give it and then gives you an input. In this way of thinking, APIs are the way we get inputs into the service and how the service gives us back the responses it has for us.

I want to start a bit of a series on API testing where we think of it this way.  We could call this black box API testing if we really want to give a name to it. I think it is an important part of interacting with and testing the modern web and I hope you find this that this series helps you along your API testing journey.