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

Advertisements

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

Let the games begin!

While this isn’t explicitly a learning article, it is about an event that could prove to be an excellent learning experience. Today, I started the Ministry of Testing’s 30 Days Of Testing Challenge.

During the month of July, testers from around the world are being challenged to perform various tasks to expand their knowledge and skills with tools, techniques, and social interaction. Many of the tasks are things that I’ve been meaning to do but never seem to have time for. One of my hopes is that this will help me form habits from vague desires.

We will see how it goes.

Limbering Up QA: Adapting to an Agile Process

In the days of Waterfall, testers were seen as the guardians of quality and the protectors of user experience. They were the last line of defense to prevent a flawed product from being released. This meant that QA needed to have all of the requirements provided to them so they could prepare their tests for when the product was finally complete and they could begin their process. Sure, the deadlines were usually tight because the release couldn’t be moved and development ran long, but that was just part of thrill. QA were sometimes viewed as an obstacle rather than an aid, but they remained strong and provided their sworn services for client and company.

All of this changed with the dawning of Agile.

The once-powerful QA is now faced with shorter deadlines, stories instead of specifications, and seemingly incomplete features being submitted for test. Worse yet, the developers are encouraged to develop unit tests that automate a chunk of what the tester once handled.  How can we possibly work like this? It’s utter madness.

It may seem like madness and chaos, but there is also method and rhythm to be found in the new processes. The first step is to stop fighting the current and dive off the waterfall instead. After taking the plunge, testers can learn to navigate the flow of sprints and iterations. Granted, this is often easier said than done, but any habit can be kicked and new ones formed. It just requires time, effort, and a willingness to change.

Unfortunately, two out of three of those things are often not in the testers’ inventory, time and willingness to change. I’m sure that a number of those reading this might be offended by that statement, but bear with me. I know that no-one will argue with the time part, but everyone trips on the willingness to change. It’s natural for people to find a comfort zone and settle in. It’s also natural to be startled and scared by change. In my experience, testers are often leery of Agile because it seems to value speed over quality, but this couldn’t be farther from the truth. Agile places emphasis on quality but it is done by building it in rather than straining out errors after development.

This change in both thought and method is the key to producing software quickly without compromising quality. The catch is that it requires developers and testers to step out of their silos and work closely together. They should also include product owners and other stakeholders in their discussions to keep everyone aligned.

The idea is to inject the knowledge of QA from the beginning rather than waiting until everything is done. While this may sound like a pitch for TDD or BDD, that is only a piece of the picture. Sometimes, it is already too late for feature to maintain quality once it gets to development. This case is most often found with legacy modifications or a stakeholder pet project that seems “simple enough” but hasn’t been fully evaluated for ripples or pitfalls. This isn’t because someone missed  something. It is a result of their standard thought processes.

  • Developers tend to think in terms of “how can I make this work?”. They are focused on solving the puzzles.
  • Product owners focus on the value of the feature to clients. Most POs leave the technical concepts to the dev team.
  • Stakeholders are usually focused on how the feature will improve their positions or increase the company’s profits

When testers are left out of the planning stages, teams sacrifice an opportunity to reduce bugs and head off troubled projects before they are sent to development. A tester’s mindset generally includes looking at contingencies, interactions, and risks within a system. Even if the person doesn’t know the  system, asking the right question during planning can shine a light on a major issue that may have been glossed over, such as “Have we considered how the new shipping system handles an order including both physical and downloadable content?”.

After planning, QA should be helping to translate business process knowledge from the POs into paths through the software and tests for the new feature. A common method of doing this is by writing Given-When-Then (or similar concept) scenarios. These scenarios will then form a basis for both automated and manual tests used to confirm the functionality during development and prior to release.

In short, testers should make an effort to be involved throughout the project cycle rather than sweeping up at the end. By doing this they can help set the stage for successful projects and avoid the stress of being the roadblock or bearer of bad news just before release. While this is a major change, it is one worth embracing.

Automated Testing Using Selenium WebDriver Course Launched on Udemy!

After just over a month of planning, recording, and editing, my first Udemy course, Automated Testing Using Selenium WebDriver, has been launched. This class covers the essential skills needed to begin developing tests and other automation using Selenium WebDriver.

The topics include:

  • Analyzing a web page to prepare for automation
  • Identifying element locators
  • Implementing the Page Object Model
  • Deploying and connecting to a Selenium Grid
  • Developing a universal framework to expedite any automation project using WebDriver.

To celebrate the launch of the course, we are offering a 50% discount to the first 200 students using this link

https://www.udemy.com/automated-testing-using-selenium-webdriver/?couponCode=CourseDebut

 

Advertisements

A Fount of Knowledge for the Perpetual Student

Advertisements