Testing in the 21st Century

Introducing a new breed of testing professional

Software Testing is going through some revolutionary changes on philosophy, practices and tools; largely driven by current business and the IT environment. This article is an attempt to look at factors influencing changes in testing space, emerging trends in testing and the impact they have on testing professionals in the 21st century.

The business environment in which IT operates is changing; this has a direct impact on how both the business and IT look at testing professionals. Testing is no longer a mere gatekeeper but a change agent and someone who highlights risk early enough to provide efficiencies in the way that we develop and deploy our software.

This is being driven by several factors:

• Widespread use of IT -- IT systems are being increasingly used by the common man
• Time-to-market pressures in a competitive market
• Rapid changes in business environment
• Impact of regulations on software applications
• Decreasing appetite for long ROI cycles
• Spending money on IT wisely -- failure rate of large projects still high
• Growing types of IT systems and platforms and languages used to build them.

Planning testing is integral to Project Planning. Testing is becoming a lot more complex. A typical enterprise application has critical integration with external and internal applications. Most of the application has various functional, non-functional testing (right from usability, performance, scalability to deployment and installation) tasks which require planning for environments, test data acquisition, specialized skills. Some of these are high lead time items. Given all of this, planning on testing is becoming much more proactive and upfront. There is a greater realization that testing becomes a bottleneck without upfront planning.

An evolutionary approach to planning is becoming a requirement. 'What' and 'when' questions are increasingly being answered upfront, and 'hows' are being planned nearer to the time of execution.

Early involvement of testing team is mandatory. Many IT organizations are realizing significant benefits in doing this, from finding and fixing issues early to improving predictability over the life of a project - and this provides significant cost savings and efficiencies in how we develop and deploy our software.

For a testing professional this provides both opportunities and challenges. There is a demand of collaborative, multi skilled testers who bridge the gap between business and technology and who understand the practices and tools that make upfront testing viable.

Some of the skills which are common are:

• Good analytical skills to bring out acceptance criteria from customers’ and Business analysts’ heads.
• Ability to create emergent automated test frameworks which can survive several code changes.
• Not just an automated tool expert but a test automation expert, capable of working with fit-for-purpose tool as and when needed.
• Test designing skills based on business value and technological risks involved.

Testability as a design criteria. Early testing involvement has its incumbent demand as well. For example, testability is becoming more and more of a design criteria to allow early, efficient, rapid and maintainable test creation. Testers’ collaboration with development is of paramount importance. Some examples of how and where testability as a design criteria helps in testing and test automation, in general are:

• Making sure there is clear separation of UI and business logic to allow test to be hooked up at the appropriate level to test (UI or business layer).This allows testing tools such as FIT and FitNesse to test through APIs when UI design is not frozen or there is no UI.
• For efficient UI automation use of IDs for UI objects.
• Building configurable mock systems to test applications when external systems are not available or still in development.

Testing from the 'Lean' perspective. How testing can eliminate waste in the delivery process. This thinking is really driving changes in tool space and building a more collaborative testing philosophy which leverages skills of individuals on IT projects and not just the testers. Business requirements and Testers defining tests, Testers and Developers implementing/maintaining tests etc.

Tests as a continuous feedback mechanism. Increasingly, testing is becoming more of a continuous feedback mechanism than a scheduled activity at the end of the development cycle. Integration of Functional Tests into a continuous event driven mechanism (such as CruiseControl) in a build pipeline means that tests are driven by changes in application and not just schedules.

Higher level languages for defining tests. Languages that can be understood by non-IT customer people. This allows having a shared understanding of tests and allows different stakeholders to see the value of the test.

Starting automation early in the project lifecycle. There are tools and frameworks being written which make test maintenance a relatively easy task. There is realization that as test code is like any developer code, it will also benefit from development practices applicable in a rapid development environment such as refactoring (A technique used to make small design changes in the code without impacting behavior, supported by many current IDEs) and test frameworks based on good Object Oriented programming.

Not just GUI driven testing, but at levels under the GUI too i.e. at whatever level we could hook up our tests. Tests are important as long as the feedback is important; it doesn’t matter where you hook up your test as long as it provides feedback on whether or not the right application is being built. Frameworks like FIT/FitNesse help build a repeatable, extensible, readable non-gui test automation suite.

Open Source Software as a viable alternative to commercial testing tools. Commercial tool vendors don’t have a stronghold in test automation tool space. A large community of developers and testers are fueling widespread usage and development of open source tools. The success of tools and frameworks such as Selenium and FitNesse is evidence of impact of open source tool in testing space.

Testers are no longer seen as a 'monkey tester' or 'party pooper' but a stakeholder in successful delivery of application in production environment

• Testers act as customer and stakeholder representatives.
• Testers need to demonstrate business understanding, understand customer priorities and market realities
• Testers are going beyond just protecting the interests of the customer/stakeholders but supporting the development team to build better software.
• Testers are helping development team stay on track (risk mitigation, building the right things in the right manner, detecting fragility/brittle areas of the application early in the development cycle etc).
• Testers are increasingly turning antagonistic relationship to a collaborative relationship between testing and development teams.

The 21st century organization needs to bring testing upfront in delivery life-cycle to provide rapid feedback, build safety net of automated tests to allow rapid changes in application and involve users early to build the right value tests. To do these they need to invest in multi-skilled testing professionals trained in cutting edge test methodologies. Testers alone can’t bring efficiency in testing. For that there needs to be an increase in collaboration between testers and business experts, testers and developers and testers and end users. Organizations which encourage use of agile methods, and tools and techniques which allow collaboration to happen are more likely to deal with changes efficiently.