Some Things are Worth Doing Badly

Some Things are Worth Doing Badly

The British philosopher/theologian G.K. Chesterton once said that if something is worth doing, it is worth doing badly.  Chesterton meant this as a defense of the amateur or generalist over the specialist, but I want to take this thought down a bit of different path.

If something is worth doing it is worth doing badly, because only in doing it badly will you ever do it well. Do you want to learn how to test APIs? You will have to do it badly at first.  You won’t be very good at it. But if it is worth doing, it is worth doing badly so that eventually you can get good at it.  Do you want to learn programming or scripting? You aren’t going to be very good at it when you start, but if it really is something worth doing then isn’t that ok?

We don’t like doing things badly, but the world needs more people who are willing to not be very good at something. When we stop worrying about how we look and start embracing failure as the path to learning we can get somewhere with the things we want to learn and do.

So step out and doing something worth doing. Do it badly. Get better. Do it again and again.  And don’t forget the point that Chesterton was originally making – sometimes it is in the mistakes and imperfections of the amateur ‘doing it badly’ that we get the most profoundly human insights and results.  Don’t be afraid of the mistakes you will make. You might just change the world.

Photo by Sarah Kilian on Unsplash

Deep Dive into TestProject: A Free Test Automation Platform for Web & Mobile!

Deep Dive into TestProject: A Free Test Automation Platform for Web & Mobile!

Note that this is a sponsored post. Posts like this will only ever be about things that I believe and that I think you would potentially find useful. You can read about my full philosophy on sponsored posts here

I’ve talked about TestProject and some of the great features that it has before. Since then, I have recorded a few more videos (you can watch the whole playlist here) and I wanted to talk about a few more features that TestProject has that make it a tool worth having in your testing tool box.

As the first of its kind free end-to-end test automation platform, I would certainly encourage you to check it out and see if it can help you with the testing challenges you might be facing.  I’ve already talked about how easy it is to get started with using the tool, but now I want to talk about some of the features that can help you take it to the next level. 

For example: Addons. TestProject has an addons library that can help you solve those tricky UI automation problems you might run into. Trying to find an element in a scroll-able container?  Yup, there’s an addon for that. Want to generate some random data for test inputs? Yup, there’s an addon for that. Trying to parse some strings to verify that some text is in it?  You guessed it, there’s an addon for that too. There are many publicly available addons, and if the addon you want is not there, TestProject provides you with the tools that you need to make your own. Since the platform is built around the idea of full team collaboration, you could tap into the developers on your team to help you out with building some addons that extend TestProject to have the capabilities you need. You can then choose to share those addons publicly for others to use or you can just keep them within your team if you prefer. 

Let’s also talk about the TestProject API.  I like APIs. I love how with a simple command definition you can have access to all kinds of power without needing to do any complex coding. Maybe I’m just a bit of an API nerd, but I think it is fun to play around with APIs and to see how I can enhance my testing superpowers with them. The TestProject API can help you take the tests that you have created and make them into something you can easily run in your build system and can really help you take the tool to the next level. 

One thing that every tester knows about testing is that it isn’t just about what you test, but it is also about how you communicate that testing to others. Testing is about much more than just providing information, but effective communication of what you have done is certainly an important part of any testing initiative. This is where reports in TestProject can be very helpful. There are a number of built in reports (that you can download into a pdf if you want) that can help you quickly and easily summarize what is going on with the tests over time and across different devices and browsers. 

There are also really helpful tools for debugging failing tests that are built into the reporting tools as well. I mean let’s just talk about screenshots for a minute. How would you like to have your tool automatically take a screenshot of what it was doing whenever a test steps fails?  Now all you have to do is click on the failing test, go to the step that is causing the issue and click on the screen shot to get some context as to why the test step failed. And yes, this is all automatically taken care of by TestProject right out of the box. 

As you can see, TestProject is a good tool for helping you get started with test automation but it also packs that power that is needed for advanced usage as well. With their  free forever plan there is nothing stopping you from checking it out today!

Photo by Julian Dufort on Unsplash

When DevOps makes life harder

When DevOps makes life harder

I know DevOps is the latest and greatest way to do software development and there is a lot that I like about it, but there is a one big problem with being a DevOps team.

Interruptions.

We’ve started to learn to plan for interruptions. There are going to production issues that need to be dealt with. We are going to get client escalations. Things are going to come across our plate without any warning and we need to be able to respond to them.

The problem is interruptions keep you from getting done what you were planning to get done. Features don’t get delivered and the team can start to get frustrated. Interruptions can really make the life of a devops team get harder.

Do you know what another word for interruptions is?  Bugs.

These interruptions are coming from clients that are having issues. Sometime they are just because we have changed a workflow and they don’t understand it, but to me anything that is impacting the ability of our clients to solve their problems is a bug.  These interruptions are bugs.

So let’s rephrase that statement at the top of this article. Bugs are a big problem with being on a devops team. You know I think they are a big problem with being on any team aren’t they? So what do we do about it? Do we need to spend more time finding the bugs up front so they aren’t coming in as interruptions during the next development cycle?  Sometimes yes – but sometimes these are things we probably never would have found no matter how much time we spent on it.  So what other solutions do we have?

Well we could just account for it in our plans and add a 25% interruption buffer. This doesn’t seem to be the greatest option, but there are times when it makes sense (like when we just changed a major workflow for hundreds of clients). In general though I don’t think this is going to allow us to most effectively deliver value. So what else?

Perhaps we need to make it so that the interruptions don’t hurt as much. If we can pinpoint exactly where the problem is coming from and find the solution more quickly, interruptions becomes less painful.  This mean being committed to good telemetry and good coding practices that let you quickly and easily find issues.

This issue of interruptions and bugs is not a simple one. It is one that has been with us from many years and will be with us for many more. There isn’t just one simple, quick fix answer. I’ve shared a few ideas we’ve been using or working towards on our team.  What ideas to do you have? Share in the comments below!

Photo by Jonathan Safa on Unsplash

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.

How to Become a Great Tester

How to Become a Great Tester

I want you to think about butterflies. The beautiful feathery winged creatures that flit from one flower to another. The weather is warming up, and yesterday my son and I were marveling at the beauty of these little creatures.

Now, let’s go back a bit in the development life-cycle of a butterfly. Let’s go back to the moment a butterfly starts to emerge from the chrysalis. The story is that if you feel sorry for the butterfly and cut the chrysalis open, it won’t be able to open it’s wings.  The struggle is necessary for the blood flow. Now, as with most inspirational stories you hear, it is probably not strictly true, but I think there are still a few lessons that can be drawn from it about how to become a great tester.

Struggle is important for becoming good at your craft. You can really only learn some things through the struggle of trying to do them. Sometimes we can try to short circuit the pain of the learning process, but at the end of the day you aren’t going to be able to learn without some struggle.

This isn’t the only lesson to learn though. The other lesson we can glean comes from the fact that this story is probably not strictly true. A couple of quick google searches shows experts who say that as long as you are careful, there are ways to help a butterfly that is having trouble getting out of the cocoon. Struggle is good and helpful and shouldn’t be short circuited, but there is a time to get help.

So how do you become a great tester?

Do lots of testing and struggle through the pain of trying to figure it out. Don’t think you can just read a few blog posts and listen to few talks and then have what it takes to be a great tester. It will take time. Lots of time. It will take trying things and failing and trying again.  It will take getting stuck and getting frustrated. It will take pain and joy. It will take frustration and annoyance and aha! moments and a powerful sense of accomplishment. In the struggle you will slowly grow and become a better and better tester.

Embrace the struggle, but don’t get lost in the struggle. Don’t forget to ask for help. Find those voices that can speak to you on how to get through the struggles you face. Go to the conferences. Ask the questions. Pair up with the experienced tester. Read the books. Take the course. Get help.

Becoming a great tester takes time and persistence. It also takes help and encouragement.

Happy testing!

 

Photo by Suzanne D. Williams on Unsplash

The Bug is Gone?

The Bug is Gone?

“Now that is weird.”

I stared at my screen and puzzled over the problem. How could this happen?

It had all started with a 500 error due to a missing config. When I checked the config panel, sure enough, the config was missing. We were searching through pull requests trying to figure out what had gone wrong, when one of my co-workers said that it seemed to be there for her.

So I refreshed the page. And there it was.

How can that be? We didn’t make any code changes to the site so how can a config that wasn’t there a minute ago just appear?

But oh well right? The initial thing I was trying to do was working now, so maybe it was just some network glitch or something.  I felt the temptation to just shake my head, attribute it to the whims of the software gods, and move on. But I decided to be curious and to see if I could find out anything else.

I posted on our company’s testing slack channel asking for ideas and within minutes I had a response that led to understanding the issue. We were creating the variable too late in the process and so the site didn’t know about it the first time we tried to use it. We got a fix together and took care of the issue, but I think there are a few important lessons to learn.

Be curious – It would have been easy to shrug my shoulders and move on, but that would have led to a bunch of clients hitting weird random errors when they first started using the feature.  Not a good first impression!

It takes a team –  I might have noticed the issue, but without the help of others it would have taken a long time to understand what was going on. We can’t know everything about everything. It really does take a team to solve problems like this

Open communication – A team isn’t a team without good communication and if it wasn’t for open communication channels like Slack, it would have taken much longer to get to the bottom of an issue like this.

Intermittent bugs are still bugs –  Just because you can’t reproduce something, doesn’t mean it doesn’t matter. The only way to reproduce this bug is to create a whole new site. The problem is we create hundreds of sites for clients for each release. So even though I can’t reproduce this bug (at least not without spinning up a whole new site), it would still be a high impact bug.  The more users and usage you have, the more important intermittent bugs become. Don’t just ignore them!

Did that bug really go away? Don’t assume it too quickly!

 

Photo by Sebastian Pichler on Unsplash