Break the Grip of Analysis Paralysis

At some point in their lives, most people will find themselves battling “analysis paralysis” and being completely unable to get something done (or even started). Sometimes this is caused by a lack of confidence or an underlying desire to procrastinate. It can also be the result of trying to tackle something that is simply too large and becoming overwhelmed. No matter what the cause is, the result—getting nothing done—is the same. Fortunately, there are solutions to these impediments and they all start with a decision.

The choice will vary according to the exact situation but ultimately it can be reduced to selecting a task to accomplish and committing to getting it done. This probably seems like an oversimplification and a rather obvious step, but there is a lot more to it than you first see. For example, you have to not care if the decision you just made is right or wrong so long as you have begun to move. Once in motion, you can always change the direction if you need to. This is the most difficult part for those struggling with a lack of confidence.

For those of you who are overwhelmed by a large project, you need to identify something small and obvious that you can get done quickly and then do it. The first task will lead to another small piece that can then be accomplished in the same way. Of course, you might find that how you solved the first piece doesn’t fit with what you need to complete the next and now you have to change your approach. I can already hear some of you saying that if you had just spent a bit more time analyzing the project that wouldn’t have happened. That’s true. It’s also true that if you had continued to analyze the project rather than starting to develop it then you would still be at square one and possible still not been aware of the problem at all.

In both of the situations above, you may have noticed some common elements: doing something rather than thinking about it and not being afraid to make a mistake. The latter of these is probably the most important and hardest to deal with. No one wants to spend their time being wrong. Many of us grow up being told that we can only get somewhere in life is if we “do it right the first time” otherwise we’ll lose our spot to someone that can. This logic runs counter to any form of innovation. How do you do something that has been done before correctly the first time? How do you even know it is correct? You won’t until you’ve tried it.

Just to be clear, I am not suggesting that you should run off half-cocked and start projects without any planning. That is as sure of a way to fail as never getting started at all. The correct time to take the kind of step I’m suggesting is when you have a basic understanding of what you want to accomplish but you are delaying because you aren’t sure of what should be done first or if what is required can be done with your current tool set. Those are times that you need top take a deep breath and jump in. It really is ok to make mistakes so long as you learn from them.

I offer you a few quotes to back up my philosophy:

  • “A journey of a thousand miles begins with a single step” – Lao Tzu
  • “I have not failed. I’ve just found 10000 ways that won’t work.” – Thomas A. Edison
  • “You have brains in your head. You have feet in your shoes. You can steer yourself in any direction you choose. You’re on your own, and you know what you know. And you are the guy who’ll decide where to go.” – Dr. Seuss

For those of you reading this who fall into the group of procrastinators like me, I also have some words of wisdom. Set a goal and hard dates for accomplishing your tasks. This will provide you with some additional motivation. If you are concerned about possible failure, make your tasks a little more flexible. Instead of promising finished deliverables, you can specify that you will complete a proof of concept or perform a simple experiment. Ultimately, my advice is that doing something is better than doing nothing.

 

Advertisements

Selenium Basics for Java is Coming Soon!

In 2016, I published my first course—Automated Testing Using Selenium WebDriver—on Udemy. With that course, my intent was to provide an intermediate level introduction to Selenium WebDriver. I decided to further differentiate it from other courses by working in both C# and Java. While this succeeded in showing that it is easy to apply the concepts taught in multiple languages, I fear that it could be confusing for students that are not experienced in development. This is where my new course will come in.

Students will be required to have a basic understanding of development concepts and Java, but I will be covering the additional technologies and concepts used in greater detail. From installing an IDE and using Git through running tests using a Selenium Grid, my new course will provide you with the foundation you need to become successful in your automation endeavors.

Topics to be covered include:

  • Installing an IDE
  • Installing browser drivers
  • Creating your first Selenium WebDriver test
  • Locating web elements on a page
  • Waiting for web elements
  • An overview of the Page Object Model
  • Running tests against a Selenium Grid
    • Local Dockerized
    • BrowserStack
    • Sauce Labs
    • Testing Bot
  • Other tips, tricks, and concepts for writing great automation

The following is a sample video showing how to setup a Selenium Grid using Docker and Docker-Compose on an Ubuntu virtual machine. This lesson will be part of the Selenium Grid section of the course.

Establishing a Selenium Grid Using Docker and Docker-Compose from Shawn Conlin on Vimeo.

Adventures in LoadRunner

As we came into the new year, I was in process of learning how to use LoadRunner for a new project. I’ve been meaning to do this for quite a while so I’ve been rather excited. I started by going through some legacy tests and then I signed up for a course on Udemy, Load Testing Using HP LoadRunner 12. While the audio and video quality of the course was lacking, the content of the course was very informative. I still have a couple of other courses I picked up, but I was able to get my confidence up enough that I jumped in with both feet and started working on tests.

As is normal, the first test was a bit sketchy. I hadn’t gotten a real feel for the application nor I had I realized that the scripts are “C like” and not “written in C”. This means that you may not have all of the functionality you expect from C readily available to you unless you manually install additional libraries. I also found that the normal method of creating header files and class files doesn’t seem to apply either. Rather than creating separate header and class files, the developer simply includes the classes and methods in the same file. I’m not sure if this considered a “best practice” for LoadRunner, but it does seem to be widely practiced.

As I continued working through the tests, one utilizing system level commands and others operating a terminal, I continued to improve them as I got more familiar with the application. After the initial runs were working, I had to start refactoring for use with the controller so that the tests and data were accessed such that multiple users could be generated and run concurrently. Those changes went surprisingly well and I am now working on the environment the tests will be run on.

I know that there is much more to LoadRunner than I have seen thus far and I am looking forward to mastering this new tool.

 

Redefining “QA”

I am not a fan of fussing about what to call something so long as everyone knows what is being discussed. With this in mind, I was surprised to find this note scrawled in my ideas notebook: “Replace ‘Quality Assurance’ with ‘Quality Advocates’.” Unfortunately, I don’t recall the source (I think I was listening to a Test Talks podcast) that made me jot it down.

Anyone who has been to a conference or followed the general flow of the testing community has heard that we need to change the expectations and image of testers such that we can become part of the team and establish a clearer understanding of what it is we do. There are a number of key items that are seen as needing to be changed for this to happen with a major one being the elimination of the “Quality Assurance” title, because that is not what a tester does. In time, we might be able foster some other reference for our career path, but currently QA is simply too ingrained to get rid of.

For those who aren’t sure what I’m talking about, I will try to summarize the thoughts on this topic. There is a stigma and attitude surrounding QA that threatens our usefulness. It tends to revolve around the idea that a tester is either a gatekeeper/enforcer or something akin to a goalie. This leads to friction between developers and testers because either the tester keeps refusing to let features be released as a result of “minor issues” or developers don’t bother checking their work and throw everything over to QA. For organizations with a healthier dynamic, testers and developers work closely together and take equal responsibility for the quality of the product. This is often accomplished by QA helping to define test scenarios early in development so the devs can check their work as they go. As the product/feature moves closer to completion, the tester can focus on integration and regression rather than basic functionality. In this respect, the tester’s role becomes one of keeping a focus on quality through the SDLC rather than trying to look for it at the end.

What I would propose is that rather than drop a perfectly good initialism, we should redefine it. By changing a single word, we can bring our common title/department inline with what our actual role is in the organization—Quality Advocate. Granted, this would make some titles a bit awkward (Sr. Quality Advocate Engineer) but that is ultimately a minor thing since the initialism is likely to remain in common use.

I would love to hear what others think of this option so please take some time to comment, email me, catch me on Twitter (personal or Academy) or G+ (personal or Academy, or in the #Testers Slack.