What
"Testing aimed at demonstrating the software can be ported to specified hardware or software platforms".
BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST)

Portability can be considered in the same group as compatibility testing, conversion testing, installability testing and recovery testing. This group of test techniques all occur at the top of the V model and are concerned with the system as a whole. On large projects, sub systems may also be tested using these techniques.

Portability is definitely a black box technique as it is conducted without reference to the code level.

The best definition of portability I can find is:-

A software unit is portable (exhibits portability) across a class of environments to the degree that the cost to transport and adapt it to a new environment in the class is less than the cost of redevelopment.
Software Portability Home Page. West Virginia University.

Why?
Our old friends risk and complexity appear again. The sheer range of potential environment, in which we expect software to operate can be bewildering. Even bespoke software that is to run only on Windows, will have to be tested against the various flavours, e.g. 2000 and XP. These can have radically different effects on the behaviour of software. Especially if the software utilises the Windows operating system functionality.

It this portability that we are testing. Does the system behave as we want it to in these different environments?

Who?
Ideally an independent team of system testers, will cover all the scenarios, across all environments that the software is expected to operate.

In a highly regulated with tight controls on testing, this may be mandated. Examples may be the nuclear or aeronautical industries. Here the software will have to be tested to the nth degree in every environment in which it may operate.

However this is not possible in many cases. A product such as Office is expected to operate with many different operating systems. Against this we have to combine in the different hardware. Thus the software is extensively tested in house. However due to the complexity of the software and the range of environments, extensive beta testing may be required, therefore the testers are in effect the users. In many cases, it is at this stage that faults are found.

Where?
At the site of the developing organisation. However as described above, many portability derived faults will only appear under operational conditions in beta testing.

When?
Even though portability testing is high up on the V-model, early consideration should be given to it. Decisions about which environments and hardware configurations will need to be made early on in the process. These decisions may have an effect on the central core architecture.

If the organisation is using the Rational Unified Process, RUP®, they may decide to test portability (if considered an risk that has to be mitigated early), in the Inception or Elaboration phases. Thus they can see if the chosen central architecture is suitable, therefore mitigating a large element of risk.

How?
Portability testing, as with virtually all other techniques requires two things:- requirements and predicted outcomes.

Requirements should state in which environments the software is designed to work in, and the behaviours they need to exhibit, whilst in each environment. Note that the behaviour may differ according to the environment. For example, it may appear different to the User depending on whether a PC or an Apple is displaying the user interface. Environmental details may include the operating system, type of hardware and database platforms.

The predicted outcome should be derived from the behaviour detailed in the specification for the environment in question.