Tag Archives: Software development

Preventing Issues or Helping to Mitigate Risk

I recently read an article by Cassandra H. Leung claiming that promoting the idea that testers prevent issues is harming the “tester brand” by establishing unrealistic expectations for testers. My initial reaction was to think that she was crazy because testers do prevent issues if we are allowed to join the project early and influence development. After reading a bit farther, I realized that the latter part of that thought was what she was talking about. Testers can’t prevent issues if they are not allowed to be part of planning or their warnings go unheeded. Unfortunately, both of these scenarios are more common than teams would like to admit.

This revelation leads us to an identity crisis as we are forced to ask, “What should we being doing as testers?”.

Over the years, testers have been charged with many formidable tasks including: assuring quality, catching bugs, policing issues, preventing issues, enforcing acceptance criteria, etc. As a whole, we’ve done a fair job of achieving success despite having the odds stacked against us by these vague definitions. The reason we cannot be completely successful is that we rarely have the level of control needed to perform these tasks.

As thought-leaders continue to move quality considerations “left” and raise awareness of the need to have testers involved early in the process, the need for testers gets questioned. If developers are testing and product owners are writing tests in the form of acceptance criteria, testers need to properly define their role on the team. Since Quality is a team responsibility, we cannot claim it as our goal. My recommendation is to define the tester role as mitigating risk though observation and review of project quality considerations and conversations with the team.

This means that testers are not gatekeepers, defenders of quality, or even responsible for catching all of the bugs. It is our job to bring our unique perspective and abilities to the team and use them to minimize the risk of issues within an implementation.

I admit that this definition is still a bit vague but it is something that we can accomplish. Testers cannot control the quality developed into the product. Testers cannot prevent decisions that could result in issues down the road. Testers can raise concerns to the team and make sure that quality conversations occur so that everyone involved has the best information available to them before making a risky decision.

Advertisements

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

Automate All the Things!

“Automate all the things” has become a common battle cry heard when discussing software testing. Those who follow that banner will often support it with claims of improved ROI, faster deployment times, and lower personnel costs. In an idealized situation, this would all be true, but reality rarely deals in Utopian terms.

As a developer turned tester, I recognize the importance of good testing practices and thorough test coverage for producing a quality product. As applications become more complex, the possibly of introducing bugs into a seemingly unrelated module increases. Granted that this becomes less likely when using well-planned and executed architecture, but I have found few developers that have had the fortune to never deal with legacy systems (usually some of the most intricate and fragile balls of mud known to man). Since it is always better to err on the side of caution, someone needs to makes sure that new features are working as expected and that the rest of the system is also functioning as it should. Enter the manual testers.

Management teams often consider their developers to be too precious of a resource to have them spend time testing applications and instead bring in the “QA Team”.  This team of typically less technical employees is usually charged with reviewing and verifying all of the functionality in the application prior to release. While this sounds reasonable at first glance, QA typically gets the application two days before release because development ran into snags or was given a short deadline  that would look better at the quarterly meeting. This means that if the company intends to actually get the testing done, the number of testers required becomes a payroll issue. The alternative to this is to automate all of the tests and thus reduce many salaries to a smaller team of developers (wait, aren’t they a precious resource?).  The problem with this strategy is that it is usually implemented with the concept of a “one-time cost”, which is rarely the case. In fact, the only successful automation efforts are those that take into account that tests will require regular maintenance to remain current with the applications.

Another issue with the “Automate Everything” concept is that there are things that can be tested manually more efficiently. Computers may work faster than human employees, but they are either slower to adjust to changes or require a significant amount of time and expense to develop. With this in mind, it becomes obvious that the best strategy for ensuring quality is to develop a team with the skills and authority to implement a blended solution.

In my experience, a team that will produce the most successful results is cross-functional and aligned towards a common goal. Bear with me if that sounded like a case of jargon dropping, it wasn’t. In order to keep the focus narrow I will focus on the developers and QA. This team doesn’t deal in hand-offs between members. Instead, they share the the whole cycle. Many testers may not understand the code that resides within the bowels of the program, but they do know what it is expected to do. It is their job to provide this insight to the developers prior to development to reduce the chances of the finished product diverging from the expected one. Armed with the knowledge of what is expected, the developers should implement appropriate unit tests while writing the new features to make sure that each portion of the application performs as expected. On the other end of the development cycle, the testers are charged with confirming the functionality prior to release.

Ok, you are probably wondering what happened to the automation portion or you think that it was dumped solely onto the developers. You would be wrong. Unit and integration testing are important and should be done as part of development, but they may not cover the full spectrum of tests and requirements. Burdening the development team with writing regression suites would bring them to a crawl in regards to producing new features. Likewise, manual testers will rarely be able to complete such tests within deadlines and would probably be bored to tears performing such tedious tasks repeatedly. This is the proper place for automation.

A good automation strategy identifies the tests that provide the most benefit to the organization that can also be reasonably automated. Scripting a test that accesses the UI and clicks on every button on the screen is a waste of resources. The only thing this test catches is a lazy developer that didn’t even check to see if his code worked. While it can be argued that there is value there, I think such an issue would show itself in other ways. Better automation candidates would be the main business process flows through the application because they are usually time consuming to be done manually and will cover the majority of the applications uses. Having these paths automated will not only save time, but will free the manual testers to explore fringe cases and usability considerations, which machines either don’t do well or would offer little ROI from.