Testing: The Next Generation

The Internet lowered the cost of communications to virtually nothing and gave us a cheap, globally accessible distribution system for software, e-commerce, and e-business. However, that was just the beginning. As more and more services move onto the Net, our expectations are that "everything" should be doable on the net, and we "need" to be connected more and more of the time. And this is where testers are going to be needed the most.

Collaboration

New Internet-based collaboration technologies enable projects to spread around the globe. Typically, e-business initiatives focus on the transaction systems, but the reality is that they are fundamentally based on people working together. Capabilities such as instant messaging, team rooms, and application sharing are being integrated within software such that they naturally become a part of the work environment. When considered in light of the sharp rise in telecommuting to more than 30 million U.S. workers in 2001, this all points to an impending demand for integrated collaboration tools that are accessible from both land-based and mobile devices. This demand will undoubtedly drive business adoption of new expanded wireless application services.

These services will include proactive and interactive features. Proactive features like notification are called push technology because applications and other users on the network can push messages and data to the mobile device. Data pull functions allow the user to access private corporate applications and data, as well as public Web services, and "pull" data from the application or service into their mobile device, where they can manipulate it.

The dedicated interface and the client/server application will probably be around for a while, but they will not be the major players. Embedded systems will still be around, but more and more of them will be network-connected over IP.

Mobile Computing

As I write this, many of you are in the process of moving your first application software to the mobile Internet. By the time this book is published, most of us in the testing community will be working on some form of mobile Internet application. A survey of development managers in Fortune 1000 companies conducted in early 2002 shows that, on average, 76 percent of the development budgets had been allocated to mobile Internet application development projects.

Your first mobile application might be as simple as a Web application that looks up contact phone numbers and sends the pages to a browser in a mobile phone, or it may be a full-blown mobile client for an ERP application running in a Pocket PC using an 802.11 Ethernet card or a cell modem for connectivity. The point is, we are about to enter a new age of computing.

At this time, it is not possible to say whether the Smartphone or the Pocket PC will win the impending mobile computing race. It doesn't matter if it is one or the other, or both-cost factors and mobility will drive the masses to the handheld computing device.

There are many examples that involve mobile personnel in industries where field workers need access to support services on the company intranet. Many of these workers have never used PCs in their jobs, but the Internet-connected mobile device will give them access to the same applications that have traditionally been accessible from a PC on the corporate LAN. These industries are expecting to experience large improvements in speed and efficiency in their service provisioning and customer care.

Back in my Prodigy days, we were limited by slow data transmission rates, small displays, limited memory, and slow processors. We had limited diagnostics tools and strict performance requirements. Applications had to become granular, rather than monolithic. They had to be broken into functional bits so that only the function that was required would be called-not an entire block of logic. The user interface had to be structured into small bits as well, so it could be downloaded quickly and then reassembled to run on computers using the small DOS operating system. This didn't seem to fit with the bigger, faster, smarter, get-DSL-in-your-own-home-and-watch-movies-over-the-Internet way things have been going recently.

MITs Methods and the Next Generation

Grace Hopper, the inventor of the software compiler, is the person who first popularized the notion of a computer bug. [1] She is also credited with saying something to the effect that each new tool we create to improve the way we write code removes whole classes of bugs from existence; simultaneously, it introduces new and different ones to take their place.

As I have said, most of the biggest quality improvements in software over the past 10 years have been due to standardization and improved development methods rather than improved quality assurance or testing. But having said that, when I take stock of where we are today, I have to agree with Grace's quote. There are new bugs coming at us all the time. So even though we don't need to spend too much time verifying and validating data field processors today (unless we are concerned that hackers might attack a weak application that relies on the user interface to prequalify data, rather than validating its own data), we do need to test. However, the things we are testing are changing from simple computing logic to complex multisystem integration issues.

The bugs I am seeking today may have very confusing symptoms; they are usually virtually impossible to reproduce, and they often have far-reaching effects. They can be very hard to diagnose, yet on any given day, this type of bug can affect thousands of users.

My role as a tester has changed a lot over the past 10 years. But I still use the MITs methods. Ten years ago I was shocked and appalled when management suggested that I simply fix the bugs that I was finding and send a report back to development. But today, I routinely fix systems issues and send the report to the responsible party. I draw the line at changing compiled code; I still won't do that. However, I am often expected to redesign the user interface based on test results.

Note 

I still use the same MITs methods even though my testing job has changed a lot.

Today, my role as an integration tester is like the role of a doctor. I am a technician who diagnoses systemic ailments by observing symptoms and performing tests. Once I have made a diagnosis, I prescribe a medication or a cure. I may refer the matter to another technician who may be a specialist in that field. And, the client may choose to ignore my advice.

The Challenges

Now we stand on the threshold of a new era of Internet development: The mobile Internet is upon us even now. By the end of 2002, there will be 1.5 times more Web-enabled cell phones in the hands of the public than PCs. People who have never used PCs will begin using mobile Internet applications on their cell phones, in both their business and personal lives.

In most places, they will be limited by slow data transmission rates over existing cell networks and 320-pixel-wide displays, as well as limited memory and storage. Applications will be broken into small bits so that they can be called as needed-in other words, Web services. And new delivery mechanisms will evolve to ensure that data is delivered to users who will be sometimes connected and sometimes disconnected from the network.

This new (or resurgent old) architecture requires new (or resurgent old) testing techniques. The methods, techniques, and tools in this book were developed in just such an environment, and they are an excellent fit for the needs of testers facing the challenge of testing distributed applications running on handheld Internet-capable mobile devices.

Testing is going to be challenged again, as it was when PCs were introduced. The new connectivity and interoperation of these complex systems, where old technology meets new technology, will be a challenging and stimulating environment for the journeyman tester.

Even if some developers are screaming that no testing is required, there will be those more cautious and mature among the sheep who will be willing to risk a bit on an evaluation, saying, "We really need testers on the Internet; people have been writing code and sticking it out there for years without testing anything." (That quote came from the lead developer in my last eXtreme development project.)

If you can apply MITs methods like the inventory, filled with measurements, you have a good chance of adding value to your client's product, and your testing will be considered worthwhile.

Note 

I use MITs no matter what the maturity of the software development is.

It is important that the maturity level of the test effort meet or exceed the maturity level of the software development. Otherwise, the test effort will be perceived as deficient. There are several such maturity models for software testing. For organizations using the Software Capability Maturity Model (SW-CMM) program, there is also a Software Testing Maturity Model (SW-TMM) program that maps testing activities to development activities.

The methods and metrics that I have discussed in this book fulfill all of the major requirements for a maturity level 5 testing process. I use them successfully to test development projects that are functioning on any CMM level. I simply use the best MITs tools, methods, metrics, and techniques for the job at hand.

I differ with most of the test maturity models in two areas. First, there some organizational issues that I believe need to remain flexible for each organization-for example, how to control and monitor the testing process. Second, I differ with most mainstream thinkers in the area of quality assurance. You can find my views on this topic in Chapter 2, "Maintaining Quality Assurance in Today's Software Testing Environment."

Overall, I believe that existing maturity models don't demand enough from the testers to make the test effort worthwhile. I have tried throughout this book to give you insights into how to show management (and yourself) the value that you add to the product. I do hope that you are able to take advantage of some of these techniques.

Until next time, Happy Testing.

[1]For the full story, see www.jamesshuggins.com/h/tekl/first_computer_bug.htm.



Software Testing Fundamentals
Software Testing Fundamentals: Methods and Metrics
ISBN: 047143020X
EAN: 2147483647
Year: 2005
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net