RBCS and UC Berkeley Extension in Berkeley, California have partnered to create a new educational program, called "Advanced Workshop in Software Testing for Developers"

By Rex Black

Participants get a detailed picture of the complex and highly interrelated activities involved in software testing, and gain the knowledge and skills that software engineers need to be successful in implementing testing activities during the software development lifecycle. 

The multi-week workshop is designed for developers, test automation engineers, and technically-oriented test engineers who wish to broaden and advance their careers. The hands-on, intensive, project-based workshop provides a comprehensive overview of methods and techniques for deriving, specifying, implementing, and automating software tests, including unit tests, integration tests, and system tests.  

This class is ideal for professionals working in embedded, web-based, mobile, and client-server technologies, in both traditional and agile lifecycles.

The focus is on applying a risk-based approach to the complete spectrum of test design: black-box (behavioral) testing, white-box (structural) testing, static code analysis, reviews, and exploratory testing. The program covers both functional testing of attributes such as accuracy and suitability and non-functional testing of attributes reliability, portability, maintainability, and performance. 

Recently, RBCS staff worked with UC Berkeley Extension to create and deliver this course to a large manufacturing company from Korea.

As RBCS President and the lead courseware author and instructor, I found this to have been a great experience, from the initiation of the project to the delivery course. During development of the courseware, we found that UC Berkeley's carefully selected and custom-configured platform provided an excellent, highly reliable software and hardware environment in which to develop over three dozen practical, hands-on exercises which demonstrated the many, many techniques that we covered.  The course is evenly split between lecture, discussion, and hands-on work on a running embedded system, which we knew participants would really enjoy.

Once we started delivering the course, we could see that the attendees immediately sank their teeth into the content. Right from day one, they were learning and applying sophisticated test design and test automation techniques right on the embedded system, testing realistic code examples and the Debian Linux operating system itself. They had an opportunity to learn and use a dozen open-source testing tools available for the Linux operating system--they even managed to find some bugs in some of those tools! The strong technical and programming skills of the students, combined with the breadth, depth, and practicality of coverage of the course materials, made this a really enjoyable class to teach.  My other two instructors and I all really enjoyed the opportunity, and welcome future opportunities to lead another group through the class.

For more information on cohorts from 20 to 30 employees to do an intensive 1-week or 2-week program on the UC Berkeley campus that includes the option for grades and a UC Berkeley Extension transcript, please contact Robert David (robertdavid@berkeley.edu). By doing the course at Berkeley, some firms are able to utilize tuition reimbursement program funds. 

 Structural Testing Techniques
 

By Rex Black and Jamie Mitchell

The following is an excerpt from Chapter 2 of the new edition of Advanced Software Testing: Volume 3, by Jamie Mitchell and Rex Black. Jamie is the primary author of the material in this chapter.

Structure-based testing uses the internal structure of the system as a test basis for deriving dynamic test cases. In other words, we are going to use information about how the system is designed and built to derive our tests.

The question that should come to mind is why. We have all kinds of specification-based (black-box) testing methods to choose from. Why do we need more? We don't have time or resources to spare for extra testing, do we?

Well, consider a world-class, outstanding system test team using all black-box and experience-based techniques. Suppose they go through all of their testing, using decision tables, state-based tests, boundary analysis, and equivalence classes. They do exploratory and attack-based testing and error guessing and use checklist-based methods. After all that, have they done enough testing? Perhaps for some. But research has shown, that even with all of that testing, and all of that effort, they may have missed a few things.

There is a really good possibility that as much as 70 percent of all of the code that makes up the system might never have been executed once! Not once!

How can that be? Well, a good system is going to have a lot of code that is only there to handle the unusual, exceptional conditions that may occur. The happy path is often fairly straightforward to build-and test. And, if every user were an expert, and no one ever made mistakes, and everyone followed the happy path without deviation, we would not need to worry so much about testing the rest. If systems did not sometimes go down, and networks sometimes fail, and databases get busy and stuff didn't happen...But, unfortunately, many people are novices at using software, and even experts forget things. And people do make mistakes and multi-strike the keys and look away at the wrong time. And virtually no one follows only the happy path without stepping off it occasionally. Stuff happens. And, the software must be written so that when weird stuff happens, it does not roll over and die.

To handle these less likely conditions, developers design systems and write code to survive the bad stuff. That makes most systems convoluted and complex. Levels of complexity are placed on top of levels of complexity; the resulting system is usually hard to test well. We have to be able to look inside so we can test all of that complexity.

In addition, black-box testing is predicated on having models that expose the behaviors and list all requirements. Unfortunately, no matter how complete, not all behaviors and requirements are going to be visible to the testers. Requirements are often changed on the fly, features added, changed, or removed. Functionality often requires the developers to build "helper" functionality to be able to deliver features. Internal data flows that have asynchronous timing triggers often occur between hidden devices, invisible to black-box testers. Finally, malicious code-since it was probably not planned for in the specifications-will not be detected using black-box techniques. We must look under the covers to find it.

Much of white-box testing is involved with coverage, making sure we have tested everything we need to based on the context of project needs. Using white-box testing on top of black-box testing allows us to measure the coverage we got and add more testing when needed to make sure we have tested all of the important complexity we should. In this chapter, we are going to discuss how to do design, create, and execute white-box testing.

ASTQB Conference 2015

Washington, D.C.

September 14, 2015: Tutorials
September 15-16, 2015: Conference

 New release price: $499 (regularly $599)

 Complimentary Webinars

Green Tip    

In the United States, food typically travels between 1,500 and 2,500 miles from farm to plate. Transporting our food that far means higher energy consumption and less local agricultural investment. See what's available at your local farmer's market this week - we think you'll like how it tastes!