Letter From The Editor – March 2020

Methods and strategy have been my favorite topics since I started working in testing. It’s essentially engineering problem-solving. It’s both looking for efficiency and attempting to measure effectiveness. So, how do we develop a set of practices to solve our Software Testing engineering problems?

One aspect of Lean Software Development and Lean Manufacturing that I love so much is the idea of “amplify learning,” or continuous learning. An example of amplified learning is finding bugs: The more bugs you find, the more you learn, and the better you understand your system. However, Lean practices do not include the idea of “best practices.” Some people live by best practices, and I am regularly asked, “What are the best testing practices?” My response is always the same: there are no best practices. There are better practices, but they depend on the context of your Software Development practices, tools, customers, platform, skills, release cycles, and other factors; thus, this dependency gives way to my conclusion that there are no standard best practices. What this means is that as your product matures and you gain more knowledge on your product, platform, and customers, then your testing strategy must change. The idea that a team is doing what they do because it’s how they have always done it tells me they are not learning nor are they growing. Strategies are not static: they evolve and get fine-tuned.

Strategy questions are some of the most frequently asked questions in my consulting work.

From Developers, I get planning questions:

  • How much testing is enough?
  • What’s the best and easiest method to show that everything’s working?
  • Do I have to unit test at all if I test everything at the API level?

From Test Engineers, I get a wide variety of questions:

  • If they’re running all of these tests at the unit level, what do I have to test at the API or UI level?
  • If I have automated tests in a headless browser, do I still need to test specific browsers?
  • Do we have enough Automated Testing? Do we have too much Automated Testing?
  • How can I get the “biggest bang for my buck” with Test Automation?

From Product Owners, I get the same questions I was asked 20 years ago:

  • Why can’t my test team test faster?
  • Why do they miss bugs?
  • Why can’t we automate all of our testing?

The questions I love the most are:

  • What’s the best method to use for the most coverage with a minimum number of test cases?
  • How can I cut maintenance costs on my automated tests?
  • I don’t know our users—how can I test?

With the exception of developers both doing more testing, these questions are testing questions across development methods. They don’t have to do with Agile, DevOps, or Continuous Integration/Continuous Delivery (CI/CD), and they are not unique to deploying faster, as we are today. The answers to all of these questions revolve around developing a strategy and being able to articulate:

  • The strategy and communicate it to the team
  • That the team of Developers, Product Owners, and Test Engineers all understand what is being tested at what level and how
  • What will be automated, what will be done manually, & what the biggest risks are

The overarching issue here is that you can go through an entire Software Engineering Program at a University and learn little to nothing about test methods and strategy. Most Test Engineers don’t come with built-in skills; they don’t always come with a working knowledge of 5 or 6 different test methods to tackle common or complex testing problems. This means you must solve them with 1 or 2 basic test methods. What I find is that most teams will validate acceptance criteria and then ‘mess around’ (i.e. perform Ad Hoc Testing) with the function for a while, and call it done. However, there are a great number of courses, programs, and certifications surrounding Software Testing today that can give you a great head start—there is no excuse for not knowing multiple ways to build a strategy these days.

So, this brings us to our March issue of the LogiGear Magazine: Smarter Testing Strategies for the Modern SDLC. This issue features some great articles that can start the conversation of, “Do my testing strategies need some tweaks?” Our cover story, Smoke Testing: An Exhaustive Guide for a Non-Exhaustive Suite delves deep into Smoke Testing, highlighting some better practices, and offering some tips and tricks. Blogger of the Month explores all of the necessary components of an effective Mobile Testing strategy. Considerations for Automating Testing for Data Warehouse and ETL Projects explains just what ETL Testing is, as well as how and why you should automate it.  TestArchitect Corner features an in-depth, step-by-step guide regarding automating Cross-Browser Testing, and our infographic, How to Develop a Test Automation Strategy provides a roadmap for ensuring your Automation strategy is effective from the start. Finally, Leader’s Pulse offers some advice for managers and leaders who may be struggling with promoting productivity within their team.

But, as I stated earlier: there are no overarching best practices. While this magazine issue is full of useful information, it is not the tell-all of the perfect testing practice. Rather, use this issue as a means to “amplify learning.” With that being said, please enjoy our newest issue of the LogiGear Magazine!

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

I have been excited about this issue since I included it in the 2011 editorial calendar. This issue of LogiGear Magazine dives into an exploration of agile automation—from the most efficient methods for test automation, to skill sets and better preparation for test teams, and even to understanding the variety of tools in question. We ...
I was just recently at a company that had a beautiful test architecture, framework, and Cucumber with tons of well-automated tests. But there was no good test management on top of the Cucumber tests, and they did not do a good job tagging the tests. Although almost everybody on the team could write and maintain ...
Every organization goes through times when the internal, or home team, cannot execute the testing project easily or quickly enough. The reasons are many, from the lack of an effective test strategy to low automation engineering skill, to staff positions going unfilled due to a great job market. With everyone working and very few people ...
Testers need to learn their craft and hone in on their skill set. That means building skills, sharpening their tools, and becoming creative detectives. There is no cookie-cutter tester and no best practice. The best circumstance is a fully-skilled, aggressive tester mixed with curiosity, nimbleness, and agility.
The Greek philosopher Heraclitus of Ephesus (c. 500 BCE) is credited with saying, “The only constant is change.”   This is a statement that, more than 2,000 years later, still holds true. Today, we are in a time of great change. Everything is in flux. The fact is, we are always in a state of change even if ...
I remember the times when test teams sat in their own area and we were not allowed to “bother” developers.
Testing the Software Car. As usual with the LogiGear Magazine, we are tackling a big subject. With our goal of having single-topic issues, we have the ability to grab and disseminate as much information as we can related to a current topic that is interesting and also on the frontier of Software Testing.   Some ...
On the whole, everyone wants to do a great job, have a better work environment, happy clients and customers, and to be employed by a company earning lots of money. All great goals! But this is not always the case. When it is not, you can suggest process improvements, better tool use, different estimating techniques, ...
Test automation is a big topic. There are so many different areas to talk about: tool choice, jumpstart, cross platform, services, cloud… Each of these areas have changed so much in the recent past that they could each be worth their own magazine issue.
I led the Editor’s Note in our very first mobile issue with “Everything is mobile”, but it is now way beyond what we thought. Mobile has come to mean only the smart phone, mobility is the word that describes everything a smart phone enables you to do. Mobility is more than a device! Mobility is ...
Software development projects are multifaceted. There is staffing and budget work. There are communication and team dynamics. There are project and process issues from what the customer wants, when they want it, revenue projections, and production dates. As part of my work in helping people deliver software, I get involved in all aspects mentioned above. ...
Continuous Testing… what is it? When we first decided to do a magazine issue dedicated to the DevOps practice of Continuous Testing, I joked with someone: “It’s about testing continuously.” And their reply was: “Yeah. What else would it be?” I was joking, but clearly the joke didn’t land. Continuous Testing is about testing continuously, ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe