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.



Testing Definitions

I have lately met with few of our customers discussing different testing issues and saw that there is a quite a lot of confusion around testing terms which makes is hard to communicate. I wanted to have a quick post on how I see these testing terms and us them in my blog, articles and communication. This is not a full or formal description but what I mean when I talk about these. 

Unit Testing: A white-box developer testing that is built within a framework such as NUnit or JUnit to cover all code paths and interfaces to a class or function. 

Component Testing: Testing of a compiled piece of software (not a white-box approach).Testing is done separately from the full system it is part of. This can be either a component such as a service or an application that is part of a business process that spans across several applications. 

Integration Testing: Testing interfaces between components (or applications that are part of a single business process). This can be tested as part of an end to end (E2E) test but the focus is on the interface between the components – testing edge cases, negative tests of invalid input from one component to another, etc. 

System Level Testing: Testing of a full application as the end user users it. If this application is not part of a larger business process that has other apps, this can also be called End to End Testing. 

End to End Testing: Usually tests a business process that spans across many applications, testing the full process from beginning to end. With Agile becoming more common and testing organization mature it is important to make sure that whatever terms you are using, that the scope of each test suite is well defined and put in the right place in the quality process. 



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.
  • Functional Architect, FT
  • 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.