The Future of Testing Blog
Business innovation thrives with software innovation and quality matters now more than ever. Application teams are running to keep up with business demand by embracing the technologies and methodologies that will help them build faster with confidence to engage consumers, go mobile and release continuously. How does a modern testing team keep up? This blog will focus on the importance and role of the tester, the innovations in testing processes, test tools, test automation solutions and best practices and discuss how to balance speed with quality through Agile, mobile, web, composite and cloud application testing.

Who really does the testing ?

Today I bring you a post from Yoav Eilat - a coleague and friend that is focused on the business applications quality space. Thanks Yoav for contributing this post:

Lately we’ve been talking to our customers’ IT organizations to figure out who actually does software testing.

Historically, we’ve always seen a broad spectrum of testers, from completely non-technical business users to expert QA. In a “typical” organization, if there is such a thing, it looks like most testing is done by business analysts or users, since the size of the QA staff (even with outsourcing help) is quite small compared to the size of the organization. Business users are better informed about ongoing changes to the application, especially for applications that implement corporate business processes like ERP/CRM. So business users are responsible for testing the processes they know, while the QA team focuses on testing infrastructure, test automation and quality processes. This means we need to make sure the tools that are used fit the skills of of the target audience.

I am interested to hear how close is this description to what you see in your company? How is the division of labor between business analysts/users and QA affected by the type of application under test, the testing methodology (automated vs. manual), and the industry you’re in?

Looking forward to your replies on this one.



Centralizing the test automation team

OK, so before I start babbling on about all the aspects of testing that I think are really interesting, and before you jump in and decide whether this blog is worth spending the time on, I thought I’d give a short intro about why I decided to start this blog and what I hope for it. Later on, starting with this post and probably continuing with later ones, I’ll write about a change that is happening, for a while now, in the quality assurance industry and testing in particular in mid to large IT shops that is changing the way testing is being done, managed, planned and funded – Centralization or a formation of a ‘Center of Excellence’ (CoE).

Why does this blog exist?

Well, during the years of my professional life I experienced endless conversations, debates, arguments, failures, successes, epiphanies and unanswered enigmas. All those shaped my view on what I professionally do and how I choose to do it. Although I read blogs, blogging myself was as far from what I was planning to do as me being able to remember where I put my cell phone. After many conversations with customers of mine as well as our solution-engineers that are working with them, I understood how much such a blog can help not only me, in getting my thoughts and understandings well defined and put through but also allow amazing knowledge to be shared across the huge customer base and beyond it as well as continuously learn from you - the readers, through your replies and not just wait for the next meeting or customer visit. Of course this can happen only if you take the time to read and reply. Any feedback is welcome. In this blog, I will focus on thoughts and problems related to both manual and automated functional testing (FT).

OK, enough wasting electronic web pages…let’s get to it.

Centralization of Automated Functional Testing

With this post, I’d like to start describing a change that has been happening in the industry around centralization of quality assurance activities and automated testing in particular. For few years now, IT shops have been gradually centralizing many of the QA related activities, starting with shared administration of QA tools such as Quality Management, Source Control, Defect Management, Requirement Management and others. This was followed by centralization of infrastructure and whatever made operational and business sense. The centralized group is often referred to as the ‘Center of Excellence’ or CoE. During this whole time many shops continued to have FT, manual or automatic, silos in their business units either due to the domain expertise that was needed for each business unit or due to the relatively small size (if relating to automation teams) and in some cases low exposure to upper management.

During the last 2-4 years, I am seeing more and more organizations making the automation team part of their CoE or centralizing it in one way or another. This means these companies have a single team (sometimes few teams each supporting few business lines) that owns the automated FT tool, responsible to manage licenses and administrate them as well as distribute the tool if needed around the organization. These are the very basic functions that can cut down on cost, license consumption and maintain consistency in deployment. However, where I see the most value is where these teams also own the best practices that are then shared, and implemented in the different testing teams and the actual centralized the development of automation skill sets. Having these capabilities in a specialized team, allows the organization to learn and grow its test automation initiatives faster. It also means that there needs to be a well defined process for allocating the shared resources and sharing the knowledge or output throughout the organization.

Setting these processes and embedding them into the organization is not an easy task and usually requires effective documentation, hours of guidance to the relevant people in the business units and continued support by the automation CoE to the different business units. This also means there needs to be a strong enough owners from the recipient side (the line of business) that can observe these best practices and scale them further. Absorbing and growing the knowledge is best done by what I call a ‘Local Champion’. This key person seems to be one of the most important people for success of an automation initiative within the line of business. Their technical capabilities, partnership with the automation CoE and the level of guidance and support the CoE gives is a make or break in the success of such an effort.

Due to the difficulty of this partnership I have seen models where the automation CoE decided not to hand over the ownership to the business unit but rather automate in full the test suite and hand it over ready to run. This is a valid approach in my opinion as I have seen organizations using it with great success but I have to say that it does has the down side of slow scaling and can position the automation CoE as a bottleneck. The advantage of this approach is of course the maximization of knowledge re-use. It also makes reusability of test assets (reusable libraries, functions, etc.) much easier as there is 1 single team that creates and manages everything. With the other approach of having the CoE hand the ownership at some point to the local champion, there needs to be an on-going contact to keep circulating the knowledge that is gathered in the different projects and a well defined process to document the reusable assets that are made available to everyone. Nevertheless, even if reusability is not perfect in this approach, when the local champions are strong, this has great success and scales up fast.

With all of the above in mind, the CoE needs to carefully choose the tools that allow to effectively creating, managing, sharing and standardizing the processes, best practices and test assets.

To recap shortly, the key points, in my opinion, to a successful automation CoE are:

  1. Centralized ownership of the FT tool

  2. Standardization of test development process and best practices and the ability to share those across the organization

  3. Strong Local Champions in the lines of businesses (if the ownership is passed to the project).

  4. Strong and on-going relationship, having the automation CoE support the local champion and facilitate knowledge sharing between the local champions.

  5. Well defined processes that allow sharing of reusable assets between tests in the same test suite and between projects when possible.

  6. Automated functional testing tools and test management tools that support the needs above.

That’s it for this time…




Showing results for 
Search instead for 
Do you mean 
About the Author(s)
  • GTM Marketing for HP Software's ADM team. I am passionate about design, digital marketing, and emerging tech.
  • This account is for guest bloggers. The blog post will identify the blogger.
  • Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.
  • Michael Deady is a Pr. Consultant & Solution Architect for HP Professional Service and HP's ALM Evangelist for IT Experts Community. He specializes in software development, testing, and security. He also loves science fiction movies and anything to do with Texas.
  • HP IT Distinguished Technologist. Tooling HP's R&D and IT for product development processes and tools.
  • Rick Barron is a Program Manager for various aspects of the PM team and HPSW UX/UI team; and working on UX projects associated with He has worked in high tech for 20+ years working in roles involving web design, usability studies, and mobile marketing. Rick has held roles at Motorola Mobility, Symantec and Sun Microsystems.
  • WW Sr Product Marketing Manager for HP ITPS VP of Apps & HP Load Runner
HP Blog

HP Software Solutions Blog


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.