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.

Advertisements

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.

Be An Eternal Student

No, I’m not talking about spending your entire life jumping from one major to another so you don’t have to graduate. When I say, “Be an eternal student.”, I am advising you to keep learning throughout your life both actively and passively. Don’t let opportunities pass you by. Just because you don’t need to know something right now doesn’t mean that it won’t come in handy later.

One question I get from many people is how I know all of the things I do. I tell them that I just pick it up as I go. Growing up, I was surrounded by mechanics, electricians, carpenters, and other tradesmen. If they needed help, or were helping me, I paid attention and picked up some tricks from them that help me around the house today. With my career, it’s been a bit different. Until recently, I didn’t have a lot of computer people around to talk to so I had spend a lot of time tinkering on my own and doing research. I learned a lot of ways not to do things; I learned some bad habits; and I gained some excellent insight into how our magical toys work from the ground up.

Aside from the hands-on/trial and error approach, I have also invested a significant amount of time reading, watching videos, and taking courses on various topics. Usually I try to focus on things I am either actively working on or expect to in the near future, but sometimes I throw in something brand new or just plain fun to keep me excited about learning. Recently I did this by taking all of the courses in the Docker Path on Pluralsight.com. While I started the courses for fun, I quickly found that what I was learning could be implemented in my current projects, which was an added bonus since I get to practice what I learned and improve my working environment.

It has been experiences like that and some unpleasant bills, replacing things I didn’t know how to fix, that helped me realize the importance of not growing stale or letting my aptitude for learning atrophy because I already know how to do my job. I was also lucky to have grown up around other perpetual students who gave me a solid understanding of how to acquire knowledge. I have found that the keys to learning are very simple:

  1. Find something you are curious about or need to learn.
  2. Gather resources that cover the topic.
    1. Talk to people who already do or know what you need.
    2. Read books and articles about the topic.
    3. Watch videos about it.
    4. Look for someone teaching a course that you can sign up for.
    5. Experiment on your own.
  3. Do something with what you have learned.
    1. Complete a project using what you learned.
    2. Share what you learned with someone else.
  4. Appreciate yourself for learning something.
  5. Repeat.

If that sounds easy, that’s because it is most of the time. I use this approach in my daily life for everything from plumbing to performance testing applications. Granted I will never be a master plumber (it just isn’t my calling) but I also don’t need to call one when I need to unclog a drain or replace a faucet. When it comes to computers and software, there is always something new to learn regardless of your level of mastery. This is part of the reason it is important to be an eternal student. If being armed with new tools and ideas isn’t enough to fuel your desire to learn, remember that once you stop growing you begin to become stale and obsolete. Don’t let your potential sit idle. Take the time and spend the effort to find out exactly what you are capable of. You might even find out that you can do anything you set your mind to.


I have never let my schooling interfere with my education – Mark Twain

The Journey Begins


While technically my journey towards expanding my career began last year when I created a course to teach the basics of Selenium WebDriver, I lost momentum and allowed myself to fall victim to old habits. In the closing months of 2016, I started attending more webinars and conferences and reading more of the books and articles that I have been collecting. I have now reached a point where I am making the decision to move forward with both purpose and passion*

I have always been a person that enjoyed learning. I’m not talking about sitting in a classroom memorizing facts, but actually gaining knowledge and wisdom through research, exploration, and a bit of trial-and-error (mostly the last two). I recently found out that I get even greater satisfaction from helping others learn and collaborating with them on various projects. I suspect the reason for this is two-fold. First, teaching a subject requires a deeper understanding of the topic than simply using the knowledge. This helps me to get past the tedium that can set between the initial thrill of learning something new and true cementing of the knowledge. The second part is the awareness that the knowledge is not being wasted. Once I have passed it on, I can feel the purpose of having done the work even if I no longer use it myself on a regular basis.

With this in mind, I have started a new regimen where I will be actively learning and then imparting that knowledge onto my followers (maybe I’ll even end up with some minions!) and those who stumble across what I produce. The initial steps are to spend 1 hour each day learning new skills or honing existing ones, to publish at least one blog post each week, and to produce at least one tutorial video each month. Once I have succeeded in creating this habit, I will increase the number of posts and tutorials published. I am also working on developing talks to be given at user groups or conferences.

I am not expecting this to be an easy set of tasks to accomplish. Not only will I need to change my current habits and schedule, but I will be fighting to get past my aversion to public speaking and my introverted tendencies. In the end, I believe that I will be healthier and happier for making the changes and I hope that my experiences will help others expand their horizons as well.


* If those words seem familiar, it is intentional. Several years ago I went through a program called CEO2 with coworkers. One of the exercises we did was to find our “Purpose and Passion”. While many of the things we did fell by the wayside, the statement I created has stayed with me. I am now taking steps to actively pursue my passions rather than passively carrying them along with me.

Eternal Growth

Through resourcefulness, curiosity, and determination, I challenge myself and others to learn new skills and information, face all challenges, and share our experiences to help one another become more than we were, so that we can continue to strive and succeed at making the impossible possible.

Shawn P. Conlin – August 28th, 2012

Return to Top

Building a Selenium Grid

When testing with Selenium WebDriver, it usually becomes necessary to need access to multiple drivers simultaneously. This may be for running tests in parallel or performing cross-browser testing. One possible solution to this is the use of a Selenium grid. The following video from my course on Udemy explain what a grid is and how to configure one for use with your tests.

There Is No Right/Wrong Way: Writing Tests

Over the years, I have encountered and practiced many different ways of creating, documenting, and executing tests. I have also worked with a number of testers, including myself at times, who harbored strong opinions about how tests should be handled. As a result, I’ve found that the “right way” to handle tests depends upon your environment and your team.

If we look at the methodology and maturity of any team’s development life cycle, we will see that certain approaches to testing are better suited than others. For example, a waterfall team that has a high turn over rate will get more value out of high detail, scripted tests because there will be a smaller product knowledge base among testers. Alternately, an Agile team dedicated to a project/product will likely benefit from more generalized tests and exploratory testing. A company’s culture, regulatory bodies, and procedures also play into how testing is performed and documented.

With this in mind, it is important for testers to keep an open mind and consider their processes carefully. Small changes can result in major savings in time and costs. A good example of this would be changing the test team’s charter from exhaustive to risk-based testing. This change will quickly switch their focus from reviewing every possible combination of data paired with a complete review of the system’s functionality to examining the changes and identifying the sections of the software with the greatest need for testing, which typically results in a significant reduction of test time. As a counter-point to that example, there are situations in which the team may need to perform more in-depth testing, such as when there is a major refactoring and the project is disturbingly light on unit tests.

The point of my ramblings here is that as professionals, we should focus on learning and improving our skills and finding solutions to our pain points rather than arguing over who’s methodology is better. The reason there are so many ways to approach testing is because each situation is different and cannot be handled by a one-size-fits-all solution. Keep learning and remember there is no right or wrong way, it’s just a different style.

 

Automation Strategies vs. Captcha Implementation

I was contacted recently by someone looking for assistance in automating a page that uses ReCaptcha. Since there are only two reasons for doing such a thing, application testing and SPAM, I offered the following information.

First off, the purpose of a captcha is to prevent bots/automation from being used to access an application. This means that if you can successfully automate the captcha then that would be a failed test and the captcha application should be replaced with one that hasn’t been beaten.

With that said, the question of how  sites that implement captcha can be tested with automation remains. This cynical answer is simply, “you can’t”, but this is neither true nor acceptable. The correct answer is to plan ahead and work with developers to implement a test mode that can be toggled securely. This will allow the automation test environment to bypass the captcha and test the meat of the application, while providing confidence in the security of the production site after manually confirming the integrity of the captcha.

After some thought, the manual testing could be skipped (not recommended) if the test mode was built into the captcha module such that when implemented, it would always provide the same challenge. This would allow for verifying the captcha functionality is working and be able to successfully test the remainder of the application as well. The issue with this would be making sure it was not possible to put the captcha into test mode through injections or other trickery in production.

I would be remiss if I didn’t warn my fellow testers that there are methods available for beating captchas such as OCR implementations and some specialized API services. These should be considered when performing your tests and assessing the security of an application. I am not going to promote any of the sites here since I don’t want to make it easier for script kiddies to get their hands on them. They were easy enough to find without my posting links last time I checked.

Software Dance (to the tune of Safety Dance)

We can ship if you want to, We can leave your tests behind.
Cause your tests can’t pass and if they don’t pass, Well they’re no tests of mine

We’ll hide checks where we want to, places where they will never find.
And we can act like we planned it all from the start, leave the real spec far behind

And we can ship

We can ship if you want to, We can leave your tests behind.
Cause your tests can’t pass and if they don’t pass, Well they’re no tests of mine

We’ll hide checks where we want to, places where they will never find.
And we can act like we planned it all from the start, leave the real spec far behind

And we can ship

Francois!

Ah, we can launch when we to, the code is young and so am I
And we can demo real neat with new tools or a suite
And surprise them with a new UI

We can test if you want to, if we don’t nobody will
And you can test really good and be totally removed
And I can test like an imbecile

We can ship. We can ship. Everything is out of control.
We can ship. We can ship. We’ve committed to the date on the wall.
We can ship. We can ship. Everybody looks at the plans.
We can ship. We can ship. Everybody’s taking a chance.

Software Dance
Oh well, the software dance
Ah yes, the software dance
Software Dance

We can ship if you want to, we’ve got all your tests and mine
As long as we abuse it, we’re never gonna lose it
Everything will work fine!

We can ship if you want to, We can leave your tests behind.
Cause your tests can’t pass and if they don’t pass, Well they’re no tests of mine

We can ship. We can ship. Everything is out of control.
We can ship. We can ship. We’ve committed to the date on the wall.
We can ship. We can ship. Everybody follow the plans.
We can ship. We can ship. Everybody’s taking the chance.

Oh Well the software dance
Ah yes the software dance
Oh well the software dance
Oh well the software dance
Oh yes the software dance
Oh the software dance yeah
Oh it’s the software dance
It’s the software dance
Well it’s the software dance
Oh it’s the software dance
Oh it’s the software dance
Oh it’s the software dance
Oh it’s the software dance

A Fount of Knowledge for the Perpetual Student

Advertisements