Testing software has little in the way of an underpinning theory. Over time this has lead to ad hoc approaches. You have a problem; you think of a solution; you do some experiments to see how well it works. You have another problem, you find another solution.

Shannon's Information Theory is a simple concept that has proven itself to have wide and disparate application over many different fields: in communications, sociology, physics, biology, financial markets, machine learning, big data, statistics etc. etc. Is it possible that it might have some useful applications in software engineering?

A software program can be thought of as a collection of communication channels. At the macroscopic level the entire program can be seen as an input output channel, irrespective of its syntax and semantics. Finer grained communication channels include every function, class, path, assignment, and expression in the program. I argue that this view of a program provides us with a very powerful and flexible conceptual toolbox with which to solve problems and to explain solutions.

As examples, I first examine the work of Alshahwan and Harman on Output Diversity for test suite coverage and show that information theory explains their outstandingly good results. Then I use my own work on testability to show how information theory can offer solutions to coincidental correctness of test inputs.

In my talk I will discuss the use of planning as means for generating test suites. Planning in Artificial Intelligence is considered as method for generating a sequence of actions to be applied in order to move from the given initial state to the wanted goal state. Such a plan, which is the sequence of actions, can be easily interpreted as a test case to be applied to check the system’s behavior. The question immediately arising is regarding the origin of actions in case of software or system testing. Here we discuss two solutions. One solution for object-oriented languages maps methods to actions but requires pre and post conditions to be specified. The other solution to be developed for security testing captures the behavior of an attacker. Actions usually used by an attacker to penetrate the system under test are formalized in a way such that a planner can generate potentially vulnerable sequences of actions. Besides the foundation of planning, the introduction of the two different applications of planning for testing, I also discuss previous research and future challenges.