Functional Testing and Self-Actualization—Embrace a framework for success

Now is the time for aggressive adoption of test automation,   yes, now!  Not next month.  Not next year. Not never.   Now.  I know what you are thinking, we’ve tried this before—It’s hard and we didn’t see ROI.  We lost funding.  We didn’t have a way to manage the tests. The excuses are endless. Today is the day that these excuses end.

 

My premise stems from the fundamental hypothesis that manual testing processes don’t scale as you speed up release cycles, grow the number of people involved and increase complexity. A good example is to think of the early days of telephony vs. today’s global wireless networks.   We all remember the role of the telephone switchboard operator… well maybe some of us do…

 

 Lily-Tomlin-9508630-1-402.jpg

 

Fast-forward to our modern wireless ecosystem. We have fully automated the call connection process, but at the same time, wireless networks have grown increasingly interconnected and complex. Can you even imagine the life of a telephone operator in this day and age?

 

1111111.jpg

 

 

Let’s apply this thinking to testing

 

A few short years ago, the majority of application development and testing was performed using a Waterfall-style with six to nine month release cycles or longer.  Teams may have been distributed and dispersed, but not nearly to the extent they are now.  Much of the application functionality came from centralized teams and the concept of the virtual organization was not widely accepted.   At that time application architectures were mainly monolithic with well understood point-to-point integrations.

 

Now we have the broad adoption of Agile methodology with teams operating in sprints that take a matter of only a few weeks (or even less). Developers, testers, architects and analysts can now sit anywhere and collaborate over tasks, status and dependencies. Monolithic applications have evolved into loosely coupled networks of shared applications and business services that are sourced from either in-house or from the cloud. 

 

While these trends enable agility, they also greatly increase complexity for developers and testers, and they make efficient fulfillment of tasks impossible without automation.  Manual processes to track, share, integrate, provision and test will not stand up to the velocity expected from distributed Agile teams developing and orchestrating networks of shared services.

 

“Video killed the radio star”

 

In turning specifically to the challenge of testing, I believe the mantra for Agile teams should be, “If it can be automated, it should”.  Manual exploratory testing of systems will always provide value, but build verification, regression and integration testing can and should be automated.   I know what you are thinking, “Automation is hard!  What about the issues:

 

 

·         Manual testers are not automation engineers. How then do we get more automation?

·         Technologies are evolving. How do I tool- and skill-up to automate both GUI and API?

·         How do I automate end-to-end?

·         Automated tests grow like weeds. How can I manage and maintain my automation assets?

·         Is there a way to reduce the maintenance overhead of scripting?

·         How do I share automation best practices and assets across teams?

·         I can’t ask for any more resources.

 

 I feel a Dilbert coming on…

 

2222222.png
Courtesy of www.dilbert.com

 

Take a look at our apporoach

 

We’ve been dealing with these issues for more than a decade and we believe cracking the code on automation starts with embracing a holistic approach. We believe in adopting a testing maturity model that leverages existing assets and skilled resources. This is important as an organization grows in its ability to employ, manage and accelerate automation across the variety of technologies in their architecture. (Use what you currently have to build the future)

 

This theory is much like creating a standard of living that not only sustains and entertains, but actually enables full self-actualization.  Moving up the test maturity model will bring an Agile organization from basic test coverage, to test efficiency to automated optimization of velocity and quality.    (Sounds a bit obtuse?  It’s really quite simple to think about…)

 


A “Maslow” view on the Test Maturity Model:

 

 

333333.png

 

Testing starts with manual… All organizations can and should perform manual testing to explore the boundaries of an application, the user experience and the corner cases.  However, as cycles speed up and volume and complexity increase, the only answer to sustain quality is to automate.  There are plenty of tools to support test automation for GUI, mobile, API, automating aspects of manual testing or keyword-based automation.  These tools have existed for years. 

 

Unfortunately, these tools are only as valuable as the ability to weld it effectively and manage its output.  This is where automation has struggled to be widely adopted and attain a successful ROI.

 

 It’s hard to find:

 

·         The resources that know how to build automations across the myriad of technologies

·         Point tools that address all aspects of automation

 

You also have to remember that most testers will require time to increase their skills.

 In addition, automation benefits break down as scripts multiply, become hard to manage and are often duplicated.  What is needed is an integrated, systemic approach to functional testing—what I’m referring to as “holistic”—that allows organizations to progress through a maturity curve while they protect and inherit their efforts and investments from the past.  We believe this is the key to automation success and have built out this holistic, systemic approach.

 

A closer look at how the HP testing product suite can help you

 

Making getting started simple: If you start with HP manual testing with HP Sprinter, you can capture your efforts in re-useable test cases and can convert those Sprinter-produced recordings into automations.  Then these artifacts can be auto-populated into HP Unified Functional Testing (UFT) and used to fully create automated tests that cover web- or mobile-GUI and extend to API and back.  This supports the industry’s widest set of protocols and programming frameworks including web and mobile.

 

Efficiently manage as your automations grow: After a while, you may notice that you have too many automated test assets floating around across your test teams. These assets may start to get duplicative and difficult to maintain when applications change.   (You will need to move up the hierarchy of needs) You may already be thinking about a framework to help you build a structure to manage automations as shareable components.  HP delivers this with our new HP Business Process Testing (BPT) version 11.5, expressly designed to architect a framework for re-usability and maintainability of test artifacts with support for both manual and automated components.  

 

And, with the new HP BPT version 11.5, you don’t have to start from scratch. Once a framework is architected, your test automation engineers can rapidly populate the BPT components with automations they create or have created from within their automation tool (HP UFT). They don’t need to learn a new framework user interface or separate test automation IDE to do this.  BPT components can consist of either HP Sprinter manual authored tests or UFT automations and components can switch between them as the application changes.

 

Rise above the script:  Finally, as you fill out your component library in your BPT framework, you are probably thinking, “How can I get out of the business of writing scripts in the first place”?   It’s time to fully achieve automation efficiency.   

 

We offer a suite of pre-built components designed for packaged applications that can be immediately configured to populate your BPT framework.  Our C-Factory script-less testing software can help test teams assemble automations by introspecting and analyzing application structure and data, even for custom application. This ability relieves effort by reducing, or even eliminating, the need to script.  This approach to script-less testing is the fastest path to filling out your library of pre-built, re-useable test components.

 

Become best practice:  Now, the final step up the maturity model addresses the question of “How do we make these libraries available in a published, managed and intuitive way to all testing teams who need them?”  Let’s self-actualize by not only being successful on a project but by sharing the benefits as best practice.  HP Quality Center and HP ALM offer a managed repository for testing artifacts that is supported by a full, highly scalable test management platform

 

By using HP Quality Center, your QA teams gain the ability to plan their testing efforts based on:

 

·         New project demand coming from the Program Management Office or PMO

·         New project requirements or Agile user stories

·         New defects being uncovered in testing or as incidents coming in from production service management

 

With HP Quality Center, QA teams can schedule their testing efforts. This enables test teams to rapidly assemble test execution scenarios populated by re-useable BPT components consisting of packaged accelerators, UFT scripts or Sprinter manual authored test cases. Now they can shave significant time off the testing effort there-in. 

 

In addition, HP Quality Center provides metrics on test productivity, defect burn down, overall project risk and quality, via test success/failure and test coverage.  Managing the overall testing process is the highest level of achieving value and ROI from functional testing efforts.

 

I hope you see the benefits of assembling an automated, holistic system into your testing environment. Don’t lose sight of the importance of manual testing, but understand the importance of automation to maintain quality in your complex environment.  I would love to hear from you about your experience. Feel free to reach out to me in the comments below.

 

Want more detail?  Here are some recent deeper dives into the topics discussed today:

 

·         Download a one-page infographic on HP’s Testing model

·         Video: HP’s Testing Maturity Model with Subject Matter Expert, Andrew Flick

·         Blog:  What’s new in UFT 11.5—features to support automation of  GUI and API scenarios

·         Blog:  The 9 reasons why  BPT is a great framework

·         Video:  The challenges and solutions for testing packaged applications

·         Learn more about the HP Accelerators for packaged applications and C-Factory based script-less testing here

 

Engage with us:

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Kelly has over 20 years experience with enterprise systems and software in individual contributor and manager roles across product manageme...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.