1. technology and computing
2. software

How To Install Software - A 12 Step Program
--author anonymous
1. Examine the software packaging until you find a little printed box
that explains what kind of computer system you need to run the software.
It should look something like this:
SYSTEM REQUIREMENTS
------------------2386 PROCESSOR OR HIGHER
628.8 MEGAHERTZ MODEM
719.7 MB FREE DISK SPACE
3546 MB RAM
432323 MB ROM
05948737 MB RPM
ANTILOCK BRAKING SYSTEM
2 TURTLE DOVES
NOTE: This software will not work on your computer.
2. Open the software packaging and remove the manual. This will contain
detailed instructions on installing, operating, and troubleshooting the
software. Throw it away.
3. Find the actual software, which should be in the form of either a
3.5-inch floppy diskette or a CD-ROM, located inside a sealed envelope that
says:
LICENSING AGREEMENT
------------------By breaking this seal, the user hereinafter agrees to abide by all
the terms and conditions of the following agreement that nobody ever
reads, as well as the Geneva Convention and the UN Charter and the
Secret Membership Oath of the Benevolent Protective Order of the Elks
and such other terms and conditions, real and imaginary, as the
Software Company shall deem necessary and appropriate, including the
right to come to the user's home and examine the user's hard drive, as
well as the user's underwear drawer if we feel like it, take it or
leave it, until death do us part, one nation indivisible by the dawn's
early light,... finders keepers, losers weepers, ...
4. Hand the software to a child aged 3 through 12 and say, "(Name of child),
please install this on my computer."
5. If you have no child age 3 through 12, insert the software in the
appropriate drive, type SETUP" and press the Enter key.
6. Turn the computer on, you idiot.
7. Once again type "SETUP" and press the Enter key.
8. You will hear grinding and whirring noises for a while, after which the
following message should appear on your screen:
The Installation Program will now examine your system to see what
would be the best way to render it inoperable. Is it OK with you?
Choose one, and be honest:
+-----+
| YES |
+-----+
+------+
| SURE |
+------+
9. After you make your selection, you will hear grinding and whirring for a
very long time while the installation program does who knows what in there.
Some installation programs can actually alter molecular structures, so that
when they're done, your computer has been transformed into an entirely new
device, such as a food processor. At the very least, the installation
program will create many new directories, sub-directories, and
sub-sub-directories on your hard drive and fill them with thousands of
mysterious files with names like "puree.exe," "fester.dat," and "doo.wha.."
10. When the installation program is finished, your screen should display
the following message:
CONGRATULATIONS!
The installation program cannot think of anything else to do to your
computer and has grown bored. You may now attempt to run your
software.
If you experience any problems, electrical shocks, insomnia, shortness
of breath, nasal discharge, or intestinal parasites, you should
immediately *!@!$)$%@&*^^)$*!#$_$*^^&
11. At this point your computer system should become less functional than the
federal government, refusing to respond even when struck with furniture.
12. Call the toll-free Tech Support Hotline number listed on the package and
wait on the line for a representative, who will explain to you, in a clear,
step-by-step manner, how to adopt a child aged 3 through 12.
Installing Software
1.
2.
Prepare for installing:
a.
There's always a risk that something will go horribly wrong when
you install, uninstall or update software. Back up everything you
don't want to risk losing before you install a program. You have to
decide what that is. I make sure that I have recently backed up my
whole system with a disk image before I install programs.
b.
If you downloaded the software, check the file for any pestilence
before you use it. There's not much risk of getting a virus, worm or
Trojan from "boxed" commercial software.
Get your system ready:
a.
3.
Close any programs you have open. The easy way to do this is to
"logoff" your computer. Just log back on to the same account when
Windows asks. (Don't enter a password if you usually don't use one.)
You can also use Task Manager -- Ctrl+Alt+Delete -- to close running
programs or you can do a clean start so that you have no unwanted
programs running.
b.
Disable any antivirus autoprotect processes that you have running.
c.
Optional, but strongly suggested: Run System File Checker to set a
clean starting point. [Click Start > Run > type sfc]
d.
Alternatively, if you're running Windows XP, set a system
checkpoint.
You may need to uninstall the old program first:
a.
If you are upgrading a program to another version, or hope to
solve a problem by reinstalling a program, it's usually best to
uninstall the old program first. Sometimes you get instructions with
the software that tell you whether you should or not. If so, follow
them. Otherwise I'd recommend you install the old program first.
4.
b.
Click Start > Settings > Control panel > Add/Remove Programs >
scroll down the list until you find the old program. Click Add/Remove
and answer OK.
c.
Reboot your computer after you've unstalled the
program. Windows can't delete or replace some files that need to be
changed except during startup.
Install the program/software:
a.
b.
c.
Read everything carefully in each dialog box as the process goes
along. Respond appropriately.
Don't just ignore alert messages during the installation.
Restart your computer if you are notified that it's needed to
complete the installation. Windows can't delete or replace some files
that need to be changed except during startup.
5.
Advanced: Run System File Checker again to see if anything bad
happened during the installation. [Windows 98: Click Start > Run > type
"sfc"] [Windows XP: Open a command prompt and type "sfc"If there are any
potential problems, a dialog box will open. It's usually safe to ignore or
update the system information if the version # of the new file is higher,
even though the date of the old file is later. For example, it's OK if version
3.8.8033 has replaced 3.8.7288, no matter what dates are shown.
6.
Keep a permanent record of the action you've taken (for example -Installed "Avenger" - version 3.0 on 7/4/2002, along with any relevant
notes or observations).
7.
Precaution: Before you install any more software, restart your
computer -- even if you do not get a notice that you "Need to restart your
computer."
Ctrl+Alt+Delete ^top^
Press Ctrl+Alt+Delete (This means press and hold down the first two keys and
then press the Delete key for an instant. Often called the 3-fingered salute in
deference to Bill Gates.
In the Close Program dialog box, click the program that you want to close, and
then click End Task. "AnswersThatWork" has a comprehensive list of
programs to guide you in which programs to start.
Backup ^top^
Before you install, uninstall or update any software, make sure you have a
current backup of at least your critical documents and data. You can't afford to
lose that. It's more likely that something will happen to your system (Windows
mostly) though. It's a good idea to back your system up as well. The Windows XP
System Restore function is an adequate alternative. It can take you back to a
point before the time when the installation went bad.
Alert messages during installation ^top^
A message may pop up during the installation process: "File being copied is older
than the current file". Programs often use files in the Windows folders that are
also used by other applications. When you get that message you should take
precautionary action. Make a copy of the file that is about to be replaced -- and
save it in a convenient folder. [Use Windows Explorer to make the copy. Hold
down the Windows key (between Ctrl & Alt) and press the E key to open WE.)]
Close WE and proceed with the installation. Later, if you find that something does
not work, you can replace the older file with the copyyou made of the newer one..
Installation log ^top^
A log of each program you install or uninstall can be invaluable if you run into a
problem. You can easily create a Log file that automatically enters the date each
time you open it. Open Notepad and create a text file with the single line ".LOG"
(Without the quotes.) Be sure to include the lead off period. Close and save the
file. Now when you open it, you will see the current date. You can then complete
your log entry. Put a shortcut for the file somewhere where you can easily find it
when you need it -- on the desktop for example
The term upgrade refers to the replacement of a product with a newer version of the same
product. It is most often used in computing and consumer electronics, generally meaning a
replacement ofhardware, software or firmware with a newer or better version, in order to bring the
system up to date or to improve its characteristics. Contrast update and replace. See also laptop
upgrade.
Audiophiles use the word upgrade to describe the replacement of a product with a better-quality
product with the aim of bringing enhancements to sound quality.

[edit]Computing
and consumer electronics
Common hardware upgrades include (for example) installing additional memory (RAM), adding
larger hard disks, replacing microprocessor cards or graphics cards, and installing new versions
of software. Many other upgrades are often possible as well.
Common software upgrades include changing the version of an operating system, of an office
suite, of an anti-virus program, or of various other tools.
Common firmware upgrades include the updating of the iPod control menus, the Xbox
360 dashboard, or the non-volatile flash memory that contains the embedded operating
system for a consumer electronics device.
Users can often download software and firmware upgrades from the Internet. Often the download
is a patch—it does not contain the new version of the software in its entirety, just the changes that
need to be made. Software patches usually aim to improve functionality or solve problems
with security. Rushed patches can cause more harm then good and are therefore sometimes
regarded[by whom?]with scepticism for a short time after release (see "Risks").[1] Patches are
generally free.
A software or firmware upgrade can be major or minor and the release version code-number
increases accordingly. A major upgrade will change the version number, whereas a minor update
will often append a ".01", ".02", ".03", etc. For example, "version 10.03" might designate the third
minor upgrade of version 10. In commercial software, the minor upgrades (or updates) are
generally free, but the major versions must be purchased. See also: sidegrade.
When one replaces a product made by one supplier with a product made by a different supplier,
one carries out a competitive upgrade.
[edit]Risks
Although developers produce upgrades in order to improve a product, there are risks involved—
including the possibility that the upgrade will worsen the product.
Upgrades of hardware involve a risk that new hardware will not be compatible with other pieces of
hardware in a system. For example, an upgrade of RAM may not be compatible with existing
RAM in a computer. Other hardware components may not be compatible after either an upgrade
or downgrade, due to the non-availability of compatible drivers for the hardware with a
specific operating system. Conversely, there is the same risk of non-compatibility when software
is upgraded or downgraded for previously functioning hardware to no longer function.
Upgrades of software introduce the risk that the new version (or patch) will contain a bug, causing
the program to malfunction in some way or not to function at all. For example, in October 2005, a
glitch in a software upgrade caused trading on the Tokyo Stock Exchange to shut down for most
of the day.[2] Similar gaffes have occurred: from important government systems [3] to freeware on
the internet.
Upgrades can also worsen a product subjectively. A user may prefer an older version even if a
newer version functions perfectly as designed.
[edit]Audiophile
This section does not cite any references or sources. Please help improve this section by
adding citations to reliable sources. Unsourced material may
be challenged and removed. (September 2010)
The hobby of audiophilia offers a rich playground for potential upgraders and tweakers.
Audiophile circles use the noun "upgrade" to describe the replacement of a system component or
components, for example a low quality or low powered electronic amplifier, with a better quality or
more powerful amplifier from the same or different manufacturer's product range ostensibly to
improve on the quality of reproduced music from a hi-fi system.
However, the description generally excludes the modification to the sound using different types of
interconnect cables, or the replacement of electronic components within the system components
by the owners in order to customise the sound, as this would constitute DIY or tweaking.
The word "upgrade" has spawned the noun upgraditis, used to describe a person's obsession,
compulsion, or addiction (akin to a disease) to perpetually changing his/her hi-fi system
components in order to obtain ever greater enjoyment and fulfillment through enhancements to
sound quality. Although the original aim is to improve the sound quality, persons with extreme
manifestations of this disorder may completely lose sight of the objective and make frequently
and highly expensive component changes for their own sake.
When Should You Upgrade Your Software?
By Dave Paradi
With new versions of the software we use being released regularly, one
of the questions I get often is how should someone decide whether they
should upgrade their software to the current version. In addition to the
cost of the upgrade, which seems to be rising steadily, there is the
hassle factor in using new software - learning the new features or
interface, the bugs that inevitably there and the resulting temporary loss
of productivity. When I am talking about software, I am referring to both
the software drivers that guide the operation of the computer
components as well as the application software, such as a word
processor or spreadsheet.
I generally separate software upgrades into two categories: 1) service
releases or bug fixes and 2) new software versions. For service
releases or bug fixes, I tend to upgrade as soon as they are released
since they usually make the software more stable and reliable. For new
software versions, I use two criteria to determine whether I want to
upgrade:
1. Is my current version no longer supported?
As software manufacturers release new software, they no longer
support the older versions. Most software companies support the most
recent old version and perhaps one more past version, but rarely more
than two old versions. To check if your version is supported, you can go
to the software maker's website and check the support area. When your
software is no longer supported, it may be hard to get answers to
questions you have and this can lead to possible delays and frustration
if you run into a problem with the software.
2. Does the new version have some features that will make my
work more efficient?
Almost every software release includes a slew of new features designed
to make work more efficient or easier. I examine the list of new or
changed features to see if any will really benefit me. Most people never
use more than 10-20% of the features of a software package, so new
features in that unused 80% are of less interest.
The answers to the two questions above lead me towards or away from
a new version of software. But before I upgrade, I consider two more
factors:
3. Has the software been out long enough to detect any significant
problems?
I will usually wait 6-12 months after a major new software version is
released before upgrading. In the first few months, the software
company finds bugs that they didn't find when testing it and they
prepare a service release or minor upgrade to fix those problems. I
usually wait until that first service release is available until I upgrade.
This reduces the risk of upgrading and running into significant problems.
4. Will I run into file format compatibility issues?
If a software application has changed the file format that the information
is saved in, the new files may not be compatible with the old version of
the software. This can cause problems when sharing files with
colleagues or partners. If the file format has changed, I will wait longer
to upgrade in order to ensure that most of the people I will share files
with have upgraded and we will reduce the risk of running into file
compatibility problems.
By considering these four questions, I hope you feel more comfortable
in making software upgrade decisions.
10 things you should do before, during, and after reinstalling
Windows
171Comments
more +









By Alan Norton
October 15, 2008, 11:19 AM PDT
There are some very good reasons why you might want to reinstall Microsoft Windows. Whether it is
2000, XP, or Vista, the registry can become corrupted or it can accumulate settings for programs longsince forgotten, leading to sluggish performance. Or you can find yourself with a stubborn Trojan
Horse. The only way to be 100 percent sure that you have rid yourself of some particularly nasty
viruses is to reload Windows.
I have wanted to document the steps needed to properly reinstall Windows for a long time now. I
always end up missing something after the reload and find myself scrambling to find IDs, passwords,
configuration settings, or favorite Web sites lost in the reinstall.
Be sure to set aside a large block of time to do the reinstall. Don’t do it before a term paper is due or
your business presentation slide show. A weekend is a good time.
An OS reinstall is also a good time to decide to upgrade. If you want to upgrade to Vista, there are a
lot of options available to you. For more information about these options and the pros and cons of
Vista, please read Vista Confusion.
This article focuses on Vista but the concepts apply to all versions of Window. This blog post is also
available in PDF format in a TechRepublic download.
When you run the Windows Vista set-up program, you will see a window with two options: Update
and Custom (Advanced). The Update option is not available when reinstalling Windows Vista. Under
the Custom option, you will be doing what is known as a Clean Install. Follow these 10 steps and you
will, hopefully, not find yourself having to scramble for files or information that you need after the
reinstall.
Please Note: I have gone to great care to test and retest this documentation. It is still possible that
there are errors or missing information or that I have not covered your specific reinstallation
configuration. Please provide feedback in the forum if you find any issues.
Before reinstallation
1. Document your login IDs, passwords, and settings.
If you are using your browser to store the passwords for Web sites, you will be in for a rude
awakening after reinstalling Windows — they will be gone. Your browser is a poor place to keep your
Web site IDs and passwords.
One possible option is to store your information in a spreadsheet. However, if you keep your IDs and
passwords in a password-protected Excel or OpenOffice Calc spreadsheet, be aware that there are
programs that can recover/discover the password for most .xls files. I suggest you use stronger
encryption techniques to better protect Excel 2002, 2003, and 2007 spreadsheets.
If you do have Excel 2002 or later, secure your spreadsheet from hackers and then make sure you
don’t lose your password! Next, add your IDs and passwords. Create a row in your spreadsheet for
your ISP, e-mail, Web hosting company, personal Web sites, and any other password-protected logins.
This file is also a good place to keep your e-mail POP3, SMTP, and newsserver name.
If you don’t have Excel you can keep the IDs and passwords on a piece of paper securely locked away
in a safe place or you can choose one of the software alternatives available. RoboForm is a popular
way to secure your browser login user name and password but is not freeware. GuardID Systems
offers a product called ID Vault that is supposed to be a secure way to store your IDs and passwords
— for a small price. Do not keep your IDs and passwords in a Notepad or Word document unsecured
and “in the clear,” readable by anyone with access to your computer or to a hacker.
2. Export your e-mail and address book, bookmarks/favorites, and cookies.
You can export your e-mail and contacts from Outlook Express, Outlook, MS Mail, and most thirdparty e-mail programs. I have a folder called Mail Exports under my Archive folder where I export my
e-mail. You can export from the various mailboxes. Select the Inbox, Outbox, Sent Items, and Drafts.
Unless you have a special reason otherwise, you can exclude the Deleted and Junk mail boxes.
I don’t bother exporting my contacts. If I need a contact, I pull it up from an archived e-mail. You
might want to export your contacts though, especially if you have a large number.
I used to always forget about bookmarks for my favorite Web sites. I had to spend time searching for a
favorite site after Windows was reinstalled. I made a promise that I would export my IE
Favorites and Firefox Bookmarks the next time I did a Windows reinstall. You can also export feeds
and cookies.
3. Download the latest applications and drivers.
There is a core set of applications that you know you will be using. One good way to identify these
core apps is to take a look at your desktop and Start menu. You can save an image of your desktop to a
non-system folder and use that as a guide to reinstalling your core apps. You can also look at your
installed programs in Programs and Features located in the Control Panel.
I have a logical drive named Documents and on that drive a folder called Downloads. I keep all my
apps and drivers downloaded from the Internet there. These add up in a hurry. To keep it organized, I
have a lot of subfolders including one for Apps and one for Drivers.
Once you have a list of your core apps, download the latest versions from the Internet and save them
to your \Downloads\Apps folder or a non-system folder of your choice.
Some of your core apps may be on DVD, CD, or even floppy. Pull out your media and set it in a stack
ready for reinstallation later.
Download the latest version of your favorite anti-virus software. I like Alwil Software’s Avast! The
free home version includes real-time protection for e-mail, instant message, Web browser, Outlook
Exchange, and four other types of real-time protection. If you can, download a file containing the
latest virus definitions.
How do you know what drivers you will need? There are two basic types of drivers. I separate them
here because updating them is usually handled differently:
Motherboard Specific Drivers - Auto Update

System and Chipset (usually Intel)

Onboard Sound

Onboard Video (some motherboards)

Onboard LAN
Many motherboard manufactures and computer vendors have an application that will check all the
motherboard-related drivers to see if they are current. If your manufacturer or vendor provides this
type of application, go to their Web site and download the latest version now.
If you don’t have access to an update utility, you have to manually identify the motherboard-related
drivers that you will need:
Other drivers - Manual Update

Sound Card (if your computer has a sound card)

Video Card (if your computer has a video card)

Modem

RAID (Intel Matrix RAID, JMicron RAID, or other if you have a RAID-controller card)

Other Unique Devices
If you do not already know the type of video card, sound card, modem, RAID, or other unique devices
in your system, you can identify them by opening the Device Manager (Figure A).
Figure A
The expanded items in the Device Manager show the devices installed on my computer requiring a manual
driver download and install.
If you aren’t running RAID, you should not need to identify any Storage controllers. If you are
running RAID, you will need to have the driver file available on a floppy disk or CD if installing XP
or previous versions of Windows. You also need to know the exact driver/controller name — Intel
82801 GR/GH SATA RAID for my system. Unlike previous versions of Windows, Vista recognizes
your hard drives during setup and you can get your RAID drivers from there.
I don’t have a sound card in my system, but if you do, expand the Sound, video and game controllers
item to determine the sound card installed in your computer.
Mike Smith has put together a handy Windows Reinstall Checklist (PDF) that you might want to print
and use.
After identifying the drivers you need to install, download them and save them to a non-system logical
drive. Do not pull them from old floppies or CDs unless you are sure that new drivers are not
available.
4. Housecleaning and backing up your data.
Now is the time to clean up your hard drive by deleting unneeded or unwanted files. Cleaning up years
of accumulated files that you no longer need or want is no fun. If you want to make it less of a chore,
you can start a week or more in advance of the reinstall. Spend one or two hours each day deleting the
files you are sure that you want to send to the great bit-bucket in the sky.
This is also an excellent time to do a thorough anti-virus scan of all your drives. You don’t want to
back up infected files.
Then do a full backup, which is easy for me to say, right? You can spend hours doing a full backup,
but this is a good investment of your time. Back up anything that you don’t want to lose. It is
especially important if you are one of the unfortunate ones without a Windows OEM disc or a vendor
reinstall disc. Many computer vendors put the Windows setup and installation files on a separate
partition or folder on the hard drive. If you have a vendor built computer, Windows Reinstall - OEM
Computers is a must-read.
If you will be reinstalling Vista on a different partition, you will need almost 15GB of free
spaceminimum on a logical drive/partition to load Vista. I like to create a partition of 30-40GB for the
32-bit version of Vista and 40-50GB for the 64 bit version. Do a full format of the logical
drive/partition that will be your new system partition so that you will have a clean Vista-ready
partition.
Warning! If you will be dual booting using XP and Vista, do not use XP to create the partition that
you will install Vista on. For a very helpful guide to issues dual booting XP and Vista please readDual
Booting Windows Vista & Windows XP by Bert Kinney.
5. Service packs
As of October 2008, the latest service packs are SP3 for XP and SP1 for Vista. There are five ways to
retrieve and install the latest service packs. Some of these methods reduce or eliminate your risk to
security vulnerabilities. Some are alternative methods you can use if you are having problems
installing the service pack from Windows Update. If you are not concerned about either of these two
issues, you can skip this section entirely and move on to item 6.
There are five ways to get the latest Windows service pack:

Download it via Windows Update

Download it from the Microsoft Web site

Order it on CD/DVD disc

Order the latest copy of Windows that includes the latest service pack (should be noted in the
product description)

Install Windows Server Update Services (WSUS) or the System Center Configuration
Manager (SCCM) if available and if the computer is networked on a local Intranet
The update is much smaller when done through the Update utility found in the Control Panel. I
planned to recommend that it is best to download the latest service pack and install it manually. Doing
this would install important security updates in the service pack before connecting to the Internet.
After a request for information from Microsoft I received the following response as to why that is not
recommended:
“Microsoft strongly recommends using Windows Update to download and install Windows Vista SP1
on single PCs.
If a customer prefers to install Windows Vista SP1 from a DVD and has Internet access, they should
first visit Windows Update and install all recommended and optional drivers and updates (the SP1
DVDs will have this advice on their packaging).
Customers should know that the install program on the DVD does not include the same logic that
Windows Update uses to check for device drivers prior to SP1 installation. To make this change, the
installer would need to be substantially modified, which would take a significant amount of time.
Additionally, one of the benefits of Windows Update is that it can dynamically add or remove filtered
devices over time, as is necessary. If the DVD were to ship with the set of filters included, they could
not be added or modified as the driver landscape changed over time.
We also want customers to know that if they have any problems during or after installing SP1, they
can call Microsoft Customer Support Services (CSS) free of charge with questions or for help.”
Note the emphasis added. Both options require connecting to the Internet before installing SP1.
I spoke with a Microsoft technician specializing in Windows Update. He informed me that there are
two primary reasons why you might want to manually install SP1. I added reason three as myreason
for a manual install.
1.
You cannot download SP1 from Windows Update or it will not install properly.
2.
3.
During high demand times SP1 may not be available to some users for up to a week or
possibly longer due to a limitation placed on the number of downloads.
You want the security updates included in SP1 installed before connecting to the Internet.
The technical representative understood why I might want to install SP1 so that my system would be
more secure before connecting to the Internet. He said it was possible to do this. However, SP1 does
not include all the security patches since its release, even if you download it today. You will still have
to start Windows Update to get these security updates.
In case you were wondering, SP1 installs 23 important security updates and 551 hot fixes, and some of
those security updates are cumulative. If you want a closer look at the details, you can review Hotfixes
and Security Updates Included in Windows Vista Service Pack 1.
The service packs for Vista are large — 434.5 MB for the 32-bit version and 726.5 MB for the 64-bit
version. If you are still using dial-up you might be able to download the 32-bit version, but it would be
easier to have a friend with broadband download the 64-bit version for you. Read the knowledge base
article KB936330 carefully before installing the service pack.
I downloaded the Vista 64 bit SP1, and it took approximately 42 hours over four days. Oh the
sacrifices I make for you, my patient reader! Use a download manager if you want to download the
Vista service pack. I don’t recommend you do this over dial-up. At $3.50, just order the SP1 CD or
DVD.
During reinstallation
6. Load Windows.
Tip: When installing Vista in Windows, the installer takes over the entire screen. But you can still
have access to Windows and features like Disk Manager by clicking on the [Windows] key. I have not
had problems doing this when stuck and needed information or wanted to delete files on the target
partition or format the target partition, but it might be dangerous to do while the installer is busy.
Don’t forget to have your product key handy. If you have a RAID setup you will need to load the
RAID drivers (be sure to get the right driver — 32 bit or 64 bit) and know the RAID controller name.
For more information about installing Windows on a RAID system see Want Speed and Data Safety?
Consider RAID. Rarely, you may have to have drivers for a device where Windows will be installed.
As an example, some older motherboards require that you load SATA drivers in order to recognize
SATA drives.
Perhaps the best way to reinstall Windows is the simple and straightforward “insert Windows disc into
optical drive, format target partition and install to target partition” method. You should, if you can,
start with a nice clean partition to install Windows on.
You can reinstall Vista from within your current Vista installation in addition to the traditional
CD/DVD bootup install. If reinstalling from within Windows, connect to the Internet so the installer
can check online for the latest installer updates.
You can replace your existing installation, even from within the existing installation, or you can load
Windows onto a different partition that you prepared in item four. If you do reinstall Windows in a
different partition, the original installation must be removed per the EULA. You cannot format the
target partition if it is the same as the one with the current Windows installation.
Starting with Vista, the system boot files and boot manager are located in a folder called Boot. Gone is
boot.ini, and replacing it is something called a Boot Configuration Data store(BCD). If you are
running a dual-boot system the Boot folder may not be located on logical drive C:\. The boot files are
system files and will be hidden unless you have unchecked Hide protected operating system
files when configuring Explorer. If you want to load Windows onto a different logical drive, be careful
that you do not delete the Boot folder when removing the original Windows installation. You also do
not want to format the logical drive where the Boot folder is located.
Tip: Microsoft includes a comprehensive help file called Installing Windows. It is a good idea to read
this before reinstalling Windows.
After reinstallation
7. Reconfigure personal settings.









I have a routine that I follow — one that I developed over the years. Personal settings are,
wellpersonal. I have a list of my personal settings that I like to make immediately upon Windows
startup. I offer these changes as suggestions and not recommendations.
Read How to Personalize Windows Vista for a step-by-step how-to guide or click on the specific topic
below:
Gadgets
Display resolution
Desktop background
Power settings
Explorer settings
Cookies handling
Defrag schedule
Indexing options
Desktop shortcuts
For those of you who are Vista experts, you might notice that there is something conspicuously
missing from my list. I do not recommend changing the default settings that leave User Account
Control (UAC) turned on, but this is how to turn it off if you must.
If the Windows personalization aren’t enough for you, there is a freeware version of TweakVI for
Vista. You can easily spend the better part of a day going through all the tweaks available, and some
of them are even useful. If you have kids and they have a computer, there are some tweaks that are
useful for hiding administrative tools that you don’t want them to access. Lo and behold, you can even
get your Vista product key plus lots of other detailed information about your system.
You no doubt have a list of your own, many of which have long-since been forgotten that you
suddenly remember after reloading Windows. You might want to keep a list of these personalized
setting so that you will have it the next time you have to reinstall Windows.
8. Enable previous versions and create a “clean install” restore point.
You will need to enable Previous Versions if you are using this feature in Vista Business, Ultimate, or
Enterprise for a specific logical drive or folder. If you aren’t using Previous Versions, you should be,
especially if you are a programmer. For information about how to turn this feature on in Vista,
see Previous Versions in Vista Business, Ultimate, and Enterprise in the #2 Give examples section.
I always like to immediately create a restore point once Windows is installed and personalized. You
can create a restore point in the same Window that Previous Versions is enabled.
Warning! If you are dual booting XP or Server 2003 and Vista or Server 2008, XP / Server 2003 will
delete the Vista / Server 2008 restore points. If Previous Versions is enabled, the shadow copies of
your files will also be gone. There is no simple solution for this. Be sure that Vista is installed
properly before booting into XP in case you need to use a system restore point.
XP users with SP1 or greater and Server 2003 users need not feel left out. They have a similar feature
called Shadow Copies.
9. Configure network, install service packs, patches, and security updates.
There are other security updates and patches that may be required. For example, I had a Micron
Millenium PC that had an atapi.sys patch that had to be installed immediately after installing
Windows.
Install all security updates, patches, and fixes before connecting to the Internet.
How you install SP1, your modem drivers, anti-virus, malware, firewall etc. (items 9.a - 9.e below)
depends on which method you choose. Please use the instructions column of Table A to get the right
order for the method you have chosen. If you skipped item 5, use the instructions for method one.
Table A — The Five Vista SP1 Installation Methods
Method
Method One
Windows Update
Instructions
9.a Install anti-virus, anti-virus definitions,
malware
9.b Install modem drivers and set up network
connection
9.c Run Windows Update
Notes
The Windows Update installer
will have to download files to
update itself, and then it will
have to restart.
9.e Create Restore Point
Method Two
Firewall
Application
Blocking
9.a Install anti-virus, anti-virus definitions,
malware, and firewall9.b Install modem drivers
and set up network connection9.c Run Windows
Update
9.e Create Restore Point
Comodo Firewall ProThe
Windows Update installer will
have to download files to
update itself, and then it will
have to restart.
Windows Update
Method Three
Windows Update
Manual Install
Method Four
Manual Install
9.a Install anti-virus, anti-virus definitions,
malware9.b Install modem drivers and set up
network connection9.c Run Windows Update
9.d Install SP1 manually
9.e Create Restore Point
9.d Install SP1 manually9.e Create Restore
Point9.a Install anti-virus, anti-virus definitions,
malware
The Windows Update installer
will have to download files to
update itself, and then it will
have to restart.
Windows
9.b Install modem drivers and set up network
connection
Update
9.c Run Windows Update
Method Five
(Stand-alone)
9.d Install SP1 manually9.e Create Restore Point
Manual Install
9.a Install anti-virus, malware, and firewall (optional)
Install your anti-virus, spyware, and adware. Restart the computer if prompted before connecting to
the Internet. Don’t forget to configure the anti-virus app to set the scan sensitivity. Set it to High or
maximum for a thorough scan and set the real-time protection to High. If you have a file containing
virus definitions, load these now.
If you have a third-party firewall you want to use instead of Windows Firewall, install it now.
9.b Setup and configure network connection.
Install your modem/network drivers. Create and configure your network connection(s).
9.c Run Window Update to scan for new drivers and updates.
Next, connect to the Internet and use Windows Update to scan for drivers and updates. UseWindows
Server Update Services or the System Center Configuration Manager (SCCM) if available and if the
computer is networked on a local Intranet. The discussion below is centered on those using Windows
Update.
It had been so long since I started Windows Update manually that I had completely forgotten about its
strange behavior. The Windows Update Window will show that it is looking for updates, and then it
will close. It took me awhile to remember that although it appears that Windows Update has died a
look at the notification icons on the taskbar shows that Windows Update is busy downloading updates
(Figure B).
Figure B
Task Manager shows Windows Update process wuaudt.exe running.
When I ran Windows Update after installing SP1, there were 28 important updates (Figure C) and
thirteen of those were security updates (Figure D). I asked if there was a way to get the security
updates created after SP1 in a downloadable cumulative security update file and was told that they are
available only via Windows Update.
Figure C
Windows Update Window shows 28 important updates, totaling 159.4 MB after manually installing Vista
SP1.
Figure D
Clicking View Available Updates reveals the 28 important updates since the release of SP1 — already
marked for update.
9.d Install SP1 manually (optional).
Install the service pack from either a disc or a file. A manual install of Vista SP1 (Figure E) requires
about 7GB of free space for the 32-bit version and 13GB for the 64-bit version.
Figure E
These updates are installed after manually installing Vista SP1.
9.e Create a new Restore Point.
After SP1 is successfully loaded, I immediately create another restore point manually and call it Clean
Install with SP1 or a similar identifiable name. I do this before installing any drivers and apps. I know
I will be installing a lot of drivers and apps and some of those, like video card drivers and apps, may
be problematic. If I begin to have problems after loading numerous apps and drivers, it is nice to be
able to go back to the Clean Install with SP1 point and restart loading the apps and drivers.
Please read Remove All Remnants of the Windows Vista SP1 Installation by Greg Shultz for
instructions about how you can recover disk space gobbled up by the SP1 installer.
10. Reload your drivers and apps.
One thing is almost certain now that Windows has been reinstalled — some of the generic drivers that
Windows has installed are not optimal. If you are lucky enough to have an auto-update utility from
your motherboard manufacturer, install the latest version that you downloaded earlier, connect to the
Internet, and fire up the update app.
Do NOT update the BIOS. This option may be available in your motherboard update app and it may
be called a BIOS update, but it is more commonly known as a BIOS flash. A BIOS flash is nota driver
update. You also want to avoid any option labeled Update All.
Next, pull out your list of drivers requiring manual installation and install them now.
I keep my apps on a separate logical drive labeled Vista x64 Apps. It is a good idea to now go to the
logical drive/folder where you keep your app files and wipe it clean. This is the fastest way to clean
out the deadwood files that you will never use again. If you have all your apps on one logical drive
and nothing else is stored there, it is best to format the logical drive before reloading your apps. Some
programs like your newsreader usually store information like group messages on this logical drive.
Export this information to your \Archive folder if you don’t want to lose it before formatting the
logical drive.
If you are running Intel’s Matrix RAID, install the Intel Matrix Storage Manager.
It is finally time to reload all your applications. Take a peek at the desktop JPEG you created earlier or
use a list of your core apps to determine what apps you want to install. Install to a fully formatted nonsystem logical drive.
There are two basic strategies when reloading your apps. You can reload the apps you use the most
and load additional apps when needed or load a full list of apps up front. I prefer to load the core apps
and load additional apps only when needed.
Take it from experience — it is not a good idea to load a lot of apps requiring a system restart and
postpone the restart. Install a few at a time, restart the computer, and see if all is still well. If you do
find a problem, you can return to the last known good restore point or uninstall the offending app. If
you find no problems, consider manually creating a new restore point.
Don’t forget to reload your e-mail messages, e-mail contacts, browser favorites, and other data that
you exported earlier back into your newly reloaded apps.
The final word
Even a casual glance at this list reveals that loading Windows is the easy part of your reinstall project.
The prep work and configuration will occupy most of your time; plan the actual date and time of the
install accordingly.
There is one more final bit of housekeeping to do. If you reinstalled Windows in a folder with an
existing installation of Windows, you should decide what to do with the Windows.old folder. You will
not find this folder if there was insufficient space on your system partition during the Windows setup.
If you are reinstalling Vista, the Windows.old folder will be too large for a single-layer DVD but may
fit on a dual-layer DVD. You can archive it to a backup drive, or if you have followed the steps
carefully in this article and are satisfied that you have all your Windows-specific data, simply zap it
into oblivion.
Congratulations! By completing the 10 steps outlined here, you have prepared your computer for years
of maintenance-free service. You have also protected yourself from data loss due to a hard drive
failure.
Installing/ Upgrading software...?
-Advantages and disadvantages on installing/upgrading software
-Risks of installing/ upgrading software
-The requirements in preparing for install/upgrade
-How to minimize risks when installing/ upgrading software


2 years ago
Report Abuse
Kim Z.
Best Answer - Chosen by Voters
Before installing, removing, or upgrading software, you may want to learn more about it first. Do
any of the new and/or improved features benefit you? If yes, does the price to purchase the
upgrade match that benefit?
5 Things to Consider:
1. Others Will others be affected by the change? Will employees, vendors, customers, clients or
service providers, have difficulties interfacing with you? Remember, if you make it difficult for
people to work with you, they may choose to go elsewhere!
2. Compatibility Are there programs that you simply must use in the course of your business? Will
the new software be compatible? If file sharing is something you do, will others that share your
files have problems accessing what you have done with their older versions of the same
program?
3. "Buggy" Software
Some software is notoriously "buggy" when first released. Others work like a charm. Do your
homework. If the one you are considering is one that has a tendency to be "buggy" do you have
the patience to work through the problems until a service pack is provided to address those
issues? If not, you may want to wait until those issues have been addressed.
4. Opinions
If you belong to a network of people in your industry, ask their opinion. Get a consensus based on
people with your same skill level and level of patience. Is this something you can quickly pick up
on your own, or are you going to need to take a class or e-course to bring yourself up to speed?
5. New and/or multiple computers
This is the one case where it is more important (from a financial standpoint) to determine if you
should downgrade the new computer or upgrade the old, or perhaps run both versions on
different computers. Think long and hard how you can best serve: Your customer base, your
patience level, and your personal learning curve. If you have one or more computers running on
an older platform it may be financially sound to consider a downgrade for the newer computer. On
the other hand, having the ability to switch back and forth from older to newer might make it a
win-win.
Why It's Important to Upgrade Your Software
Laura G
No comments
When considering staying up-to-date with the latest software and how it can influence your
academic and professional life, you should consider the following:
Compatibility: if all of your classmates and professors are working on a new version of software,
you may run into some problems when trying to submit or share documents.
New software can be faster to operate with increased security features.
New Features: Enhanced technology and new and improved features will allow you to apply the
latest enhancements to your projects.
Receiving support: if you have an outdated version of software you may be not be able to receive
the software support you require, as support is usually designated for newly released software bugs
and technical issues.
Knowing how to use the latest software features can leave you ahead of the game when it comes to
how your school papers or project will be presented. This can also give you an upper hand when it
comes to the work force, as you will already know your way around new software, providing you
with an advanced skill set.
Question: Do I Have to Upgrade Personal Finance Software Every Year?
Some of the most popular financial software offers a new version every year, which can get expensive. Is it worth your
money to buy new financial software annually?
Answer: The primary reason for upgrading to the latest financial software is to get new features and bug fixes for
problems that existed in the previous version. Before you buy the latest personal finance software version, consider
this:
Reasons Not to Upgrade Software



If your current version is supported (you can get tech support and no features have been disabled) and you are
installing updates as they are made available, you should be getting the same bug fixes for your existing software
that are included in the latest version.
The latest version of your financial software may not have eradicated all bugs in the previous version of the
software.
Ironically, with a new financial software release comes the possibility of new bugs. The newest software
version from any reputable developer will have been well-tested and quite functional, but annoying glitches can
surface when the software is being used by the general population.
How Long is Too Long Between Upgrades?
While many financial software users upgrade annually simply to enjoy using the latest technology, some prefer to
upgrade almost never, possibly going a decade before upgrading their software. The problem with waiting too long to
upgrade is that when a new computer is eventually purchased, the old software may not run on the new system.
If several upgrade versions exist between the version currently installed and the latest version, upgrading directly to the
new version may not be possible. This is usually because the latest software can't read the data files which hold all the
transactions entered over the years. To get around this, you need to install a version from between your old version and
the new one to allow the software to convert your data files. After completing one or two of these intermediate
upgrades, you will be able to install and use the latest version of the financial software. To find old software versions,
contact tech support, who should be able to provide one or two free downloads of old versions.
One other hassle caused by waiting for too long between software upgrades is missing out on using time-saving
features included in newer software. These features are often worth the cost of an upgrade.
The Happy Medium for Upgrades
A good rule to follow for getting the most out of money spent on personal finance software upgrades it to upgrade at
least every three years to take advantage of new technology that will generally run faster on your system. Within three
years significant improvements will have been made to the software to make entering data, setting up budgets and
using financial reports easier. Just be sure to know your financial software's obsolescence policy, which may cut off
support and features that require the Internet (like data downloads) sooner.
Software versioning
From Wikipedia, the free encyclopedia
"Versioning" redirects here. For other uses, see Version.
Software versioning is the process of assigning either unique version names or unique version
numbers to unique states of computer software. Within a given version number category (major,
minor), these numbers are generally assigned in increasing order and correspond to new
developments in the software. At a fine-grained level, revision control is often used for keeping track of
incrementally different versions of electronic information, whether or not this information is actually
computer software.
Contents
[hide]

1 Schemes
o
1.1 Sequence-based identifiers

1.1.1 Change significance

1.1.2 Designating development stage

1.1.3 Separating sequences

1.1.4 Number of sequences

1.1.5 Incrementing sequences

1.1.6 Using negative numbers

1.1.7 Degree of compatibility
o
1.2 Date
o
1.3 Year of release
o
1.4 Alphanumeric codes
o
1.5 TeX
o
1.6 Apple
o
1.7 Other schemes

2 Internal version numbers

3 Pre-release versions

4 Modifications to the numeric system
o
4.1 Odd-numbered versions for development releases
o
4.2 Apple

5 Political and cultural significance of version numbers
o
5.1 Version 1.0 as a milestone
o
5.2 To describe program history
o
5.3 Keeping up with competitors
o
5.4 Superstition
o
5.5 Geek culture

6 Overcoming perceived marketing difficulties

7 Significance in software engineering

8 Significance in technical support

9 Version numbers for files and documents

10 Version number ordering systems

11 Use in other media

12 See also

13 References

14 External links
[edit]Schemes
A variety of version numbering schemes have been created to keep track of different versions of a
piece of software. The ubiquity of computers has also led to these schemes being used in contexts
outside computing.
[edit]Sequence-based
identifiers
In sequence-based software versioning schemes, each software release is assigned a unique identifier
that consists of one or more sequences of numbers or letters. This is the extent of the commonality,
however, schemes vary widely in areas such as the quantity of sequences, the attribution of meaning
to individual sequences, and the means of incrementing the sequences.
[edit]Change significance
In some schemes, sequence-based identifiers are used to convey the significance of changes between
releases: changes are classified by significance level, and the decision of which sequence to change
between releases is based on the significance of the changes from the previous release, whereby the
first sequence is changed for the most significant changes, and changes to sequences after the first
represent changes of decreasing significance.
For instance, in a scheme that uses a four-sequence identifier, the first sequence may be incremented
only when the code is completely rewritten, while a change to the user interface or the documentation
may only warrant a change to the fourth sequence.
This practice permits users (or potential adopters) to evaluate how much real-world testing a given
software release has undergone. If changes are made between, say, 1.3rc4 and the production
release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the
real world, in fact contains changes which have not necessarily been tested in the real world at
all.[clarification needed] This approach commonly permits the third level of numbering ("change"), but does not
apply this level of rigor to changes in that number: 1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4.1, etc.[clarification needed]
In principle, in subsequent releases, the major number is increased when there are significant jumps in
functionality, the minor number is incremented when only minor features or significant fixes have been
added, and the revision number is incremented when minor bugs are fixed. A typical product might use
the numbers 0.9 (for beta software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2,
2.1, 2.1.1, 2.1.2, 2.2, etc. Developers have at times jumped (for example) from version 5.0 to 5.5 to
indicate significant features have been added, but they are not enough to warrant incrementing the
major version number. This is improper. It is usually done to create a visual differential between
software versions. A person may be less inclined to go through the trouble of installing, reinstalling,
and/or removing old versions of software if a minor change is made instead. (I.E. Version 5.0 to 5.01,
or 5.0 to 5.1)
A different approach is to use the major and minor numbers, along with an alphanumeric string
denoting the release type, i.e. "alpha", "beta" or "release candidate". A release train using this
approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 == 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more
fixes) == 1.0rc1 (which, if it is stable enough) == 1.0. If 1.0rc1 turns out to have bugs which must be
fixed, it turns into 1.0rc2, and so on. The important characteristic of this approach is that the first
version of a given level (beta, RC, production) must be identical to the last version of the release below
it: you cannot make any changes at all from the last beta to the first RC, or from the last RC to
production. If you do, you must roll out another release at that lower level.
However, since version numbers are human-generated, not computer-generated, there is nothing that
prevents arbitrary changes that violate such guidelines: for example, the first sequence could be
incremented between versions that differ by not even a single line of code, to give the (false)
impression that very significant changes were made.
Other schemes impart meaning on individual sequences:
major.minor[.build[.revision]]
or
major.minor[.maintenance[.build]]
Again, in these examples, the definition of what constitutes a "major" as opposed to a "minor"
change is entirely arbitrary and up to the author, as is what defines a "build", or how a
"revision" differs from a "minor" change.
A similar problem of relative change significance and versioning nomenclature exists in book
publishing, where edition numbers or names can be chosen based on varying criteria.
In most proprietary software, the first released version of a software product has version 1.
[edit]Designating development stage
Some schemes use a zero in the first sequence to designate alpha or beta status for releases
that are not stable enough for general or practical deployment and are intended for testing or
internal use only.
It can be used in the third position:

0 for alpha (status)

1 for beta (status)

2 for release candidate

3 for (final) release
For instance:

1.2.0.1 instead of 1.2-a1

1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)

1.2.2.3 instead of 1.2-rc3 (release candidate)

1.2.3.0 instead of 1.2-r (commercial distribution)

1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)
[edit]Separating sequences
When printed, the sequences may be separated with characters. The choice of characters
and their usage varies by scheme. The following list shows hypothetical examples of
separation schemes for the same release (the thirteenth third-level revision to the fourth
second-level revision to the second first-level revision):

A scheme may use the same character between all sequences: 2.4.13, 2/4/13, 2-4-13

A scheme choice of which sequences to separate may be inconsistent, separating some
sequences but not others: 2.413

A scheme's choice of characters may be inconsistent within the same identifier: 2.4_13
When a period is used to separate sequences, it does not represent a decimal point, and the
sequences do not have positional significance. An identifier of 2.5, for instance, is not "two
and a half" or "half way to version three", it is the fifth second-level revision of the second
first-level revision.
[edit]Number of sequences
There is sometimes a fourth, unpublished number which denotes the software build (as used
by Microsoft). Adobe Flash is a notable case where a 4-part version number is indicated
publicly, as in 10.1.53.64. Some companies also include the build date. Version numbers may
also include letters and other characters, such as Lotus 1-2-3 Release 1a.
[edit]Incrementing sequences
There are two schools of thought regarding how numeric version numbers are incremented:
Most free software packages treat numbers as a continuous stream, therefore a free software
or open source product may have version numbers 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0,
1.11.1, 1.11.2, etc. An example of such a software package is MediaWiki. However, many
programs treat version numbers in another way, generally as decimal numbers, and may
have version numbers such as 1.7, 1.8, 1.81, 1.82, 1.9, etc. In software packages using this
way of numbering 1.81 is the next minor version after 1.8. Maintenance releases (i.e. bug
fixes only) would generally be denoted as 1.81a, 1.81b, etc.
The standard GNU version numbering scheme is major.minor.revision, but emacs is a
notable example using another scheme where the major number ("1") was dropped and a
"user site" revision was added which is always zero in original emacs packages but increased
by distributors.[1] Similarly, Debian package numbers are prefixed with an optional "epoch",
which is used to allow the versioning scheme to be changed.[2]
[edit]Using negative numbers
There exist some projects that use negative version numbers. One example is
the smalleiffel compiler which started from -1.0 and counted upwards to 0.0.[1]
[edit]Degree of compatibility
Some projects use the major version number to indicate incompatible releases. Two
examples are Apache APR[3] and the FarCry CMS.[4]
[edit]Date
The Wine project used a date versioning scheme, which uses the year followed by the month
followed by the day of the release; for example, "Wine 20040505". Wine is now on a
"standard" release track; the most current stable version (as of 2010) is 1.2. Ubuntu
Linux uses a similar versioning scheme—Ubuntu 10.10, for example, was released October
2010.
When using dates in versioning, for instance, file names, it is common to use the ISO
scheme[5]: YYYY-MM-DD, as this is easily string sorted to increasing/decreasing order. The
hyphens are sometimes omitted.
Microsoft Office build numbers are actually an encoded date.[6]
[edit]Year
of release
Other examples that identify versions by year include Adobe Illustrator 88 and WordPerfect
Office 2003. When a date is used to denote version, it is generally for marketing purposes,
and an actual version number also exists. For example, Microsoft Windows 2000 Server is
internally versioned as Windows NT 5.0 ("NT" being a reference to the original product
name).
[edit]Alphanumeric
codes
Examples:

Macromedia Flash MX

Adobe Photoshop CS2
[edit]TeX
TeX has an idiosyncratic version numbering system. Since version 3, updates have been
indicated by adding an extra digit at the end, so that the version
number asymptotically approaches π; this is a form of unary numbering – the version number
is the number of digits. The current version is 3.1415926. This is a reflection of the fact that
TeX is now very stable, and only minor updates are anticipated. TeX developer Donald
Knuth has stated that the "absolutely final change (to be made after my death)" will be to
change the version number to π, at which point all remaining bugs will become permanent
features.[7]
In a similar way, the version number of METAFONT asymptotically approaches e.
[edit]Apple
Apple has a formalised version number structure based around the NumVersion struct, which
specifies a one- or two-digit major version, a one-digit minor version, a one-digit "bug" (i.e.
revision) version, a stage indicator (drawn from the set development/prealpha, alpha, beta
and final/release), and a one-byte (i.e. having values in the range 0–255) pre-release version,
which is only used at stages prior to final. In writing these version numbers as strings, the
convention is to omit any parts after the minor version whose value are zero (with "final"
being considered the zero stage), thus writing 1.0.2b12, 1.0.2 (rather than 1.0.2f0), and 1.1
(rather than 1.1.0f0).
[edit]Other
schemes
Some software producers use different schemes to denote releases of their software. For
example, the Microsoft Windows operating system was first labelled with standard numerical
version numbers (Windows 1.0 through Windows 3.11). Later, Microsoft started using
separate version names for marketing purposes, first using years (Windows
95 (4.0), Windows 98 (4.10), Windows 2000 (5.0)), then using alphanumeric codes (Windows
Me (4.90), Windows XP (5.1)), then using brand names (Windows Vista (6.0)). With the
release of Windows 7 it appears that Microsoft has returned to using numerical version
numbers, although the official version number for Windows 7 is 6.1.[8]
The Debian project uses a major/minor versioning scheme for releases of its operating
system, but uses code names from the movie Toy Story during development to refer to
stable, unstable and testing releases.
BLAG Linux and GNU features very large version numbers: major releases have numbers
such as 50000 and 60000, while minor releases increase the number by 1 (e.g. 50001,
50002). Alpha and beta releases are given decimal version numbers slightly less than the
major release number, such as 19999.00071 for alpha 1 of version 20000, and 29999.50000
for beta 2 of version 30000. Starting at 9001 in 2003, the most recent version as of 2011 is
140000.[9][10][11]
[edit]Internal
version numbers
Software may have an "internal" version number which differs from the version number
shown in the product name (and which typically follows version numbering rules more
consistently). Java SE 5.0, for example, has the internal version number of 1.5.0, and
versions of Windows from NT 4 on have continued the standard numerical versions internally:
Windows 2000 is NT 5.0, XP is Windows NT 5.1,Windows Server 2003 is NT 5.2, Vista is NT
6.0 and 7 is NT 6.1. Note, however, that Windows NT is only on its third major revision, as its
first release was numbered 3.1 (to match the then-current Windows release number).
[edit]Pre-release
versions
In conjunction with the various versioning schemes listed above, a system for denoting prerelease versions is generally used, as the program makes its way through the stages of
the software release life cycle. Programs that are in an early stage are often called "alpha"
software, after the first letter in the Greek alphabet. After they mature but are not yet ready for
release, they may be called "beta" software, after the second letter in the Greek alphabet.
Generally alpha software is tested by developers only, while beta software is distributed for
community testing. Alpha- and beta-version software is often given numerical versions less
than 1 (such as 0.9), to suggest their approach toward a final "1.0" release. However, if the
pre-release version is for an existing software package (e.g. version 2.5), then an "a" or
"alpha" may be appended to the version number. So the alpha version of the 2.5 release
might be identified as 2.5a or 2.5.a. Software packages which are soon to be released as a
particular version may carry that version tag followed by "rc-#", indicating the number of the
release candidate. When the version is actually released, the "rc" tag disappears.
This can apparently cause trouble for some package managers, though. The Rivendell radio
broadcast automation package, for example, is about[when?] to have to release its first full
production release package... v1.0.1, because if they called it v1.0.0, RPM would refuse to
install it, because the algorithm sorts "1.0.0" lower than "1.0.0rc2" (which is because version
comparison algorithms are generally language-agnostic and thus don't know the meaning of
"rc").
[edit]Modifications
to the numeric system
This section does not cite any references or sources. Please help improve this
section by adding citations to reliable sources. Unsourced material may
be challenged and removed. (September 2010)
[edit]Odd-numbered
versions for development releases
Between the 1.0 and the 2.6.x series, the Linux kernel used odd minor version numbers to
denote development releases and even minor version numbers to denote stable releases;
see Linux kernel: Version numbering. For example, Linux 2.3 was a development family of
the second major design of the Linux kernel, and Linux 2.4 was the stable release family that
Linux 2.3 matured into. After the minor version number in the Linux kernel is the release
number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Since the 2004 release
of the 2.6 kernel, Linux no longer uses this system, and has a much shorter release cycle,
instead now simply incrementing the third number, using a fourth number as necessary.
The same odd-even system is used by some other software with long release cycles, such
as GNOME.
[edit]Apple
Apple had their own twist on this habit during the era of the classic MacOS: although there
were minor releases, they rarely went beyond 1, and when they did, they twice jumped
straight to 5, suggesting a change of magnitude intermediate between a major and minor
release (thus, 8.5 really means 'eight and a half', and 8.6 is 'eight and a half point one'). The
complete sequence of versions (neglecting revision releases) is 1.0, 1.1, 2.0, 2.1, 3.0, 3.2
(skipping 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.
Mac OS X has departed from this trend, having gone more conventionally from 10.0 to 10.7,
one minor release at a time. However, note that the 10.4.10 update does not follow the
previously-indicated approach of having a "one- or two-digit major version, a one-digit minor
version, a one-digit 'bug' (i.e. revision) version…". The bug-fix value is not a decimal
indicator, but is an incremental whole value; while it is not expected, there would be nothing
preventing a distant-future "X.4.321" release.
[edit]Political
and cultural significance of version numbers
[edit]Version
1.0 as a milestone
Proprietary software developers often start at version 1 for the first release of a program and
increment the major version number with each rewrite. This can mean that a program can
reach version 3 within a few months of development, before it is considered stable or reliable.
In contrast to this, the free-software community tends to use version 1.0 as a
major milestone, indicating that the software is "complete", that it has all major features, and
is considered reliable enough for general release.
In this scheme, the version number slowly approaches 1.0 as more and more bugs are fixed
in preparation for the 1.0 release. The developers of MAME do not intend to release a version
1.0 of their emulator program.[citation needed] The argument is that it will never be truly "finished"
because there will always be more arcade games. Version 0.99 was simply followed by
version 0.100 (minor version 100 > 99). In a similar fashion Xfire 1.99 was followed by 1.100.
After over 8 years of development, eMule just recently reached version 0.50a.
[edit]To
describe program history
Winamp released an entirely different architecture for version 3 of the program. Due to lack
of backwards compatibility with plugins and other resources from the major version 2, a new
version was issued that was compatible with both version 2 and 3. The new version was set
to 5 (2+3), skipping version 4. The developers also humorously joked that they skipped
version 4 because "nobody wants to see a Winamp 4 skin", referencing the foreskin of a
penis.[12]
A similar thing happened with UnixWare 7, which was the combination of UnixWare 2
and OpenServer 5.
[edit]Keeping
up with competitors
There is a common habit in the proprietary software industry to make major jumps in numeric
major or minor version numbers for reasons which do not seem (to many members of the
program's audience) to merit the "marketing" version numbers.
This can be seen in several Microsoft and America Online products, as well as Sun
Solaris and Java Virtual Machine numbering, SCO Unix version numbers, and Corel
WordPerfect, as well as the filePro DB/RAD programming package, which went from 2.0 to
3.0 to 4.0 to 4.1 to 4.5 to 4.8 to 5.0, and is about to go to 5.6, with no intervening release. A
slightly different version can be seen in AOL's PC client software, which tends to have only
major releases (5.0, 6.0, 7.0, etc.). Likewise, Microsoft Access jumped from version 2.0 to
version 7.0, to match the version number of Microsoft Word.
Microsoft has also been the target of 'catch-up' versioning, with
the Netscape browser skipping version 5 to 6, in line with Microsoft's Internet Explorer, but
also because the Mozilla application suite inherited version 5 in its user agent string during
pre-1.0 development and Netscape 6.x was built upon Mozilla's code base.
Sun's Java has at times had a hybrid system, where the actual version number has always
been 1.x but three times has been marketed by reference only to the x:

JDK 1.0.3

JDK 1.1.2 through 1.1.8

J2SE 1.2.0 ("Java 2") through 1.4.2

Java 1.5.0 ("Java 5")

Java 1.6.0 ("Java 6")
Sun also dropped the first digit for Solaris, where Solaris 2.8 (or 2.9) is referred to as Solaris
8 (or 9) in marketing materials.
Another example of keeping up with competitors is when Slackware Linux jumped from
version 4 to version 7 in 1999.[13]
A similar jump has recently taken place with the Asterisk open-source PBX construction kit,
whose project leads announced that the current version 1.8.x will soon be followed by version
10, which will be followed by version 11, and then 12, and so forth, presumably dropping the
other components (and their useful semantic significance) entirely. This change, though, does
not seem to be motivated by 'keeping up with competition'. [1]
[edit]Superstition

The Office 2007 release of Microsoft Office has an internal version number of 12. The
next version Office 2010 has an internal version of 14, due to superstitions
surrounding the number 13.[14]

Corel's WordPerfect Office, version 13 is marketed as "X3" (Roman number 10 and "3").
The procedure has continued into the next version, X4. The same has happened with
Corel's Graphic Suite (i.e. CorelDRAW, Corel Photo-Paint) as well as its Video editing
software "Video Studio".

Nokia decided to jump directly from S60 3rd Edition to S60 5th Edition, skipping the
fourth edition due to the tetraphobia of their Asian customers.

ABBYY Lingvo Dictionary uses numbering 12, x3 (14), x5 (15).
[edit]Geek

culture
The S.u.S.E Linux distribution started at version 4.2, to reference 42, "the answer to life,
the universe and everything" mentioned in Douglas Adams' The Hitchhiker's Guide To
The Galaxy.

The current Slackware Linux distribution is version 13.37, referencing leet.
[edit]Overcoming
perceived marketing difficulties
In the mid-1990s, the rapidly growing CMMS, Maximo, moved from Maximo Series 3 directly
to Series 5, skipping Series 4 due to that number's perceived marketing difficulties in the
Chinese market, where the number 4 is associated with “death” (see tetraphobia). This did
not, however, stop Maximo Series 5 version 4.0 being released. (It should be noted the
"Series" versioning has since been dropped, effectively resetting version numbers after
Series 5 version 1.0's release.)
[edit]Significance
in software engineering
Version numbers are used in practical terms by the consumer, or client, by being able to
compare their copy of the software product against another copy, such as the newest version
released by the developer. For the programmer team or company, versioning is often used on
a file-by-file basis, where individual parts or sectors of the software code are compared and
contrasted with newer or older revisions, often in a collaborative version control system.
There is no absolute and definite software version schema; it can often vary from software
genre to genre, and is very commonly based on the programmer's personal preference.
[edit]Significance
in technical support
Version numbers allow people providing support to ascertain exactly what code a user is
running, so that they know what bugs might affect a problem, and the like. This occurs when
a program has a substantial user community, especially when that community is large
enough that the people providing technical support are not the people who wrote the code.
[edit]Version
numbers for files and documents
Some computer file systems, such as the OpenVMS Filesystem, also keep versions for files.
Versioning amongst documents is relatively similar to the routine used with computers and
software engineering, where with each small change in the structure, contents, or conditions,
the version number is incremented by 1, or a smaller or larger value, again depending on the
personal preference of the author and the size or importance of changes made.
[edit]Version
number ordering systems
Version numbers very quickly evolve from simple integers (1, 2, ...) to rational numbers (2.08,
2.09, 2.10) and then to non-numeric "numbers" such as 4:3.4.3-2. These complex version
numbers are therefore better treated as character strings. Operating systems that include
package management facilities (such as all non-trivial Linux or BSD distributions) will use a
distribution-specific algorithm for comparing version numbers of different software packages.
For example, the ordering algorithms of Red Hat and derived distributions differ to those of
the Debian-like distributions.
As an example of surprising version number ordering implementation behavior, in Debian,
leading zeroes are ignored in chunks, so that 5.0005 and 5.5 are considered as equal, and
5.5<5.0006. This can confuse users; string-matching tools may fail to find a given version
number; and this can cause subtle bugs in package management if the programmers use
string-indexed data structures such as version-number indexed hash tables.
In order to ease sorting, some software packages will represent each component of
the major.minor.release scheme with a fixed width. Perl represents its version numbers as a
floating-point number, for example, Perl's 5.8.7 release can also be represented as 5.008007.
This allows a theoretical version of 5.8.10 to be represented as 5.008010. Other software
packages will pack each segment into a fixed bit width, for example, 5.8.7 could be
represented in 24 bits: ( 5 << 16 | 8 << 8 | 7; hexadecimal: 050807; for version 12.34.56 in
hexadecimal: 0C2238). The floating-point scheme will break down if any segment of the
version number exceeds 1,000; a packed-binary scheme employing 8 bits apiece after 256.
[edit]Use
in other media
Software-style version numbers can be found in other media. In some cases the use is a
direct analogy (for example, Dungeons & Dragons 3.5, where the rules were revised from the
third edition, but not so much as to be considered the fourth), but more often it's used to play
on an association with high technology and doesn't literally indicate a 'version' (e.g., Tron 2.0,
a video game followup to the film Tron, or the television show The IT Crowd, which refers to
the second season as Version 2.0). A particularly notable usage is Web 2.0, referring to
the World Wide Web as used in collaborative projects such as wikis and social networking
websites.
Version Numbering Conventions
The following article discusses the conventions related to version numbering of the
various artifacts produced by the OpenXData project. Much of this is a rough
summary of the version numbering system used by most maven-based projects and
other Apache Software Foundation projects. However, due to some restrictions with
the JavaME specification's notion of version numbers, there is some deviation from
this convention.
The Basic Version Format
The basic makeup of a version number is the following:
Major.Minor.Incremental
Examples of such numbers are: 1.0, 1.0.0, 1.1, 1.1.2, 1.2, etc.
The major number is commonly changed when there is a major change in the
software. Users can expect behavior that is wildly different or potentially
incompatible with releases sharing other major version numbers. The minor number
is often used when changes are augmentation of prior major.minor version of the
software. Changes that prompt incrementing the minor version number are typically
additional features. Users should not expect changes that intentionally break prior
functionality. Lastly, the incremental number is normally used to indicate a bug-fix or
maintenance release. This is typically used when bugs are found in existing releases
of the software, and a maintenance release is made to fix the behavior. User should
not expect new features or additional incompatibilities when moving from software
differing only in the incremental identifier. It is common to omit the incremental
number until it is needed. For instance, rather than saying 1.0.0 (which is perfectly
legitimate), you commonly see 1.0. Rarely, will you see omission of the minor
number.
Additional Version Component: Qualifiers
This basic format described above accounts for most of the version numbers you'll
see. However, there is an additional component that sometimes comes in handy. It's
called the qualifier and included in the numbering scheme it becomes:
Major.Minor.Incremental-Qualifier
Examples of such numbers are: 1.0.0-beta-1, 1.2-alpha-2, etc.
Unlike the major, minor and incremental numbers, which are compared based on
their numeric values to determine the proper version ordering, the qualifier is
compared textually. This means 1.0-alpha comes before 1.0-beta because the
qualifier 'alpha' sorts before 'beta' alphabetically. Again, this is different than the 1.0
portion of the number, it is compared numerically for each component value (major,
minor, incremental). The qualifier can be used to denote milestones releases, but
generally, one can go without using them.
Snapshot Versions
A snapshot version is a version number that ends with '-SNAPSHOT'. It denotes that
the the project or dependency is under active development. When installing or
deploying artifacts from projects specifying snapshot versions, the installed or
deployed artifacts will end up with special version numbers. These numbers enable
determination of the last built snapshot.
Projects that declare dependencies with snapshot versions will get periodic updates
for that artifact (the frequency is configurable). This enables independent projects to
integrate continuously without requiring them to share source code. Using this
method, the dependent project can track with the dependency as changes are made.
When it is determined that the projects are to be released, the project providing the
dependency is released. The dependent project changes its declaration to the base
version by removing the -SNAPSHOT from the version. So, 1.0-SNAPSHOT would
turn into 1.0. The dependent project is verified to work properly with the release and
then it, in turn, can be released.
It is important to note that release versions can never be a snapshot. Additionally,
release versions should not depend on snapshots. Snapshots change every time the
project is built. Because they change, building projects with snapshot dependencies
can not be guaranteed to produce the same result on subsequent builds (even
without code changes). Since the purpose of a release is capturing and preserving
known configurations, non-repeatable builds are should be avoided. The mavenrelease-plugin provides checks to ensure that your project meets these standards.
J2ME or JavaME Issues
Unfortunately, unlike Maven, the JavaME specification doesn't allow for open version
formats. This means that using unorthodox version numbers is not allowed. The
MIDP specification states the following about version numbering of applications:
Version numbers have the format Major.Minor[.Micro] (X.X[.X]),
where the .Micro portion MAY be omitted.
(If the .Micro portion is not omitted, then it defaults to
zero). In addition, each portion of the
version number is allowed a maximum of two decimal digits (i.e.,
0-99).
...
For example, 1.0.0 can be used to specify the first version of a
MIDlet suite. For each portion of
the version number, leading zeros are not significant. For
example, 08 is equivalent to 8. Also, 1.0 is
equivalent to 1.0.0. However, 1.1 is equivalent to 1.1.0, and
not 1.0.1. A missing MIDlet-Version tag
is assumed to be 0.0.0, which means that any non-zero version
number is considered as a newer version
of the MIDlet suite.
You may notice that convention is very similar to the one described above. However,
without the ability to use a snapshot designation, there is no way of determining
whether an artifact built during active development is final or an intermediate build
made during active development. This may seem like an insignificant detail, but it
means you could confuse two applications as being from the same source code and
they could be completely different! This can be counteracted by introducing some
designation of the revision it comes from, but it introduces a dependency on the SCM
system (like Subversion) to get the revision number.
"Versioning" redirects here. For other uses, see Version (disambiguation).
Software versioning is the process of assigning either unique version names or
uniqueversion numbers to unique states of computer software. Within a given version
number category (major, minor), these numbers are generally assigned in increasing order
and correspond to new developments in the software. At a fine-grained level, revision
control is often used for keeping track of incrementally different versions of electronic
information, whether or not this information is actually computer software.
Contents
 1 Schemes

1.1 Sequence-based identifiers

1.1.1 Change significance

1.1.2 Designating development stage

1.1.3 Separating sequences

1.1.4 Number of sequences

1.1.5 Incrementing sequences

1.1.6 Using negative numbers

1.1.7 Degree of compatibility

1.2 Date

1.3 Year of release

1.4 Alphanumeric codes

1.5 TeX

1.6 Apple

1.7 Other schemes
 2 Internal version numbers
 3 Pre-release versions
 4 Modifications to the numeric system

4.1 Odd-numbered versions for development releases

4.2 Apple
 5 Political and cultural significance of version numbers

5.1 Version 1.0 as a milestone

5.2 To describe program history

5.3 Keeping up with competitors

5.4 Superstition

5.5 Popular culture
 6 Overcoming perceived marketing difficulties
 7 Significance in software engineering
 8 Significance in technical support
 9 Version numbers for files and documents
 10 Version number ordering systems
 11 Use in other media
 12 See also
 13 References
 14 External links
Schemes
A variety of version numbering schemes have been created to keep track of different
versions of a piece of software. The ubiquity of computers has also led to these schemes
being used in contexts outside computing .
Sequence-based identifiers
In sequence-based software versioning schemes, each software release is assigned a
unique identifier that consists of one or more sequences of numbers or letters. This is the
extent of the commonality, however, schemes vary widely in areas such as the quantity of
sequences, the attribution of meaning to individual sequences, and the means of
incrementing the sequences.
Change significance
In some schemes, sequence-based identifiers are used to convey the significance of
changes between releases: changes are classified by significance level, and the decision of
which sequence to change between releases is based on the significance of the changes
from the previous release, whereby the first sequence is changed for the most significant
changes, and changes to sequences after the first represent changes of decreasing
significance.
For instance, in a scheme that uses a four-sequence identifier, the first sequence may be
incremented only when the code is completely rewritten, while a change to the user interface
or the documentation may only warrant a change to the fourth sequence.
This practice permits users (or potential adopters) to evaluate how much real-world testing a
given software release has undergone. If changes are made between, say, 1.3rc4 and the
production release of 1.3, then that release, which asserts that it has had a production-grade
level of testing in the real world, in fact contains changes which have not necessarily been
tested in the real world at all.This approach commonly permits the third level of numbering
("change"), but does not apply this level of rigor to changes in that number: 1.3.1, 1.3.2,
1.3.3, 1.3.4... 1.4b1, etc.
In principle, in subsequent releases, the major number is increased when there are
significant jumps in functionality, the minor number is incremented when only minor features
or significant fixes have been added, and the revision number is incremented when minor
bugs are fixed. A typical product might use the numbers 0.9 (for beta software), 0.9.1, 0.9.2,
0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Developers
have at times jumped (for example) from version 5.0 to 5.5 to indicate that significant
features have been added, but not enough to warrant incrementing the major version
number, though this is improper.
A different approach is to use the major and minor numbers, along with an alphanumeric
string denoting the release type, i.e. "alpha", "beta" or "release candidate". A release train
using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 == 1.0b1, 1.0b2 (with some fixes),
1.0b3 (with more fixes) == 1.0rc1 (which, if it is stable enough) == 1.0. If 1.0rc1 turns out to
have bugs which must be fixed, it turns into 1.0rc2, and so on. The important characteristic of
this approach is that the first version of a given level (beta, RC, production) must be
identical to the last version of the release below it: you cannot make any changes at all from
the last beta to the first RC, or from the last RC to production. If you do, you must roll out
another release at that lower level.
However, since version numbers are human-generated, not computer-generated, there is
nothing that prevents arbitrary changes that violate such guidelines: for example, the first
sequence could be incremented between versions that differ by not even a single line of
code, to give the (false) impression that very significant changes were made.
Other schemes impart meaning on individual sequences:
major.minor[.build[.revision]]
or
major.minor[.maintenance[.build]]
Again, in these examples, the definition of what constitutes a "major" as opposed to a
"minor" change is entirely arbitrary and up to the author, as is what defines a "build", or how
a "revision" differs from a "minor" change.
In most proprietary software, the first released version of a software product has version 1.
Designating development stage
Some schemes use a zero in the first sequence to designate alpha or beta status for
releases that are not stable enough for general or practical deployment and are intended for
testing or internal use only.
It can be used in the third position:
 0 for alpha (status)
 1 for beta (status)
 2 for release candidate
 3 for (public) release
For instance:
 1.2.0.1 instead of 1.2-a
 1.2.1.2 instead of 1.2-b2 (beta with some bug fixes)
 1.2.2.3 instead of 1.2-rc (release candidate)
 1.2.3.0 instead of 1.2-r (commercial distribution)
 1.2.3.5 instead of 1.2-r5 (commercial distribution with many bug fixes)
Separating sequences
When printed, the sequences may be separated with characters. The choice of characters
and their usage varies by scheme. The following list shows hypothetical examples of
separation schemes for the same release (the thirteenth third-level revision to the fourth
second-level revision to the second first-level revision):
 A scheme may use the same character between all sequences: 2.4.13, 2/4/13, 2-4-
13
 A scheme choice of which sequences to separate may be inconsistent, separating
some sequences but not others: 2.413
 A scheme's choice of characters may be inconsistent within the same identifier:
2.4_13
When a period is used to separate sequences, it does not represent a decimal point, and the
sequences do not have positional significance. An identifier of 2.5, for instance, is not "two
and a half" or "half way to version three", it is the fifth second-level revision of the second
first-level revision.
Number of sequences
There is sometimes a fourth, unpublished number which denotes the software build (as used
byMicrosoft). Adobe Flash is a notable case where a 4-part version number is indicated
publicly, as in 10.1.53.64. Some companies also include the build date. Version numbers
may also include letters and other characters, such as Lotus 1-2-3 Release 1a.
Incrementing sequences
There are two schools of thought regarding how numeric version numbers are incremented:
Mostfree software packages treat numbers as a continuous stream, therefore a free software
or open source product may have version numbers 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0,
1.11.1, 1.11.2, etc. An example of such a software package is MediaWiki. However, many
programs treat version numbers in another way, generally as decimal numbers, and may
have version numbers such as 1.7, 1.8, 1.81, 1.82, 1.9, etc. In software packages using this
way of numbering 1.81 is the next minor version after 1.8. Maintenance releases (i.e. bug
fixes only) would generally be denoted as 1.81a, 1.81b, etc.
The standard GNU version numbering scheme is major.minor.revision, but emacs is a
notable example using another scheme where the major number ("1") was dropped and a
"user site" revision was added which is always zero in original emacs packages but
increased by distributors.[1] Similarly, Debian package numbers are prefixed with an optional
"epoch", which is used to allow the versioning scheme to be changed.[2]
Using negative numbers
There exist some projects that use negative version numbers. One example is
the smalleiffelcompiler which started from -1.0 and counted upwards to 0.0.[1]
Degree of compatibility
Some projects use the major version number to indicate incompatible releases. Two
examples are Apache APR[3] and the FarCry CMS.[4]
Date
The Wine project used a date versioning scheme, which uses the year followed by the month
followed by the day of the release; for example, "Wine 20040505". Wine is now on a
"standard" release track; the most current stable version (as of 2010) is 1.2. Ubuntu
Linux uses a similar versioning scheme—Ubuntu 10.04, for example, was released April
2010.
When using dates in versioning, for instance, file names, it is common to use the ISO
scheme[5]: YYYY-MM-DD, as this is easily string sorted to increasing/decreasing order. The
hyphens are sometimes omitted.
Microsoft Office build numbers are actually an encoded date.[6]
Year of release
Other examples that identify versions by year include Adobe Illustrator 88 and WordPerfect
Office2003. When a date is used to denote version, it is generally for marketing purposes,
and an actual version number also exists. For example, Microsoft Windows 2000 Server is
internally versioned as Windows NT 5.0 ("NT" being a reference to the original product
name).
Alphanumeric codes
Examples:
 Macromedia Flash MX
 Adobe Photoshop CS2
TeX
TeX has an idiosyncratic version numbering system. Since version 3, updates have been
indicated by adding an extra digit at the end, so that the version
number asymptotically approaches π; this is a form of unary numbering – the version
number is the number of digits. The current version is 3.1415926. This is a reflection of the
fact that TeX is now very stable, and only minor updates are anticipated. TeX
developer Donald Knuth has stated that the "absolutely final change (to be made after my
death)" will be to change the version number to π, at which point all remaining bugs will
become permanent features.[7]
In a similar way, the version number of METAFONT asymptotically approaches e.
Apple
Apple has a formalised version number structure based around the NumVersion struct,
which specifies a one- or two-digit major version, a one-digit minor version, a one-digit "bug"
(i.e. revision) version, a stage indicator (drawn from the set development/prealpha, alpha,
beta and final/release), and a one-byte (i.e. having values in the range 0–255) pre-release
version, which is only used at stages prior to final. In writing these version numbers as
strings, the convention is to omit any parts after the minor version whose value are zero (with
"final" being considered the zero stage), thus writing 1.0.2b12, 1.0.2 (rather than 1.0.2f0),
and 1.1 (rather than 1.1.0f0).
Other schemes
Some software producers use different schemes to denote releases of their software. For
example, the Microsoft Windows operating system was first labelled with standard numerical
version numbers (Windows 1.0 through Windows 3.11). Later, Microsoft started using
separate version names for marketing purposes, first using years (Windows
95 (4.0), Windows 98 (4.10),Windows 2000 (5.0)), then using alphanumeric codes (Windows
Me (4.90), Windows XP (5.1)), then using brand names (Windows Vista (6.0)). With the
release of Windows 7 it appears that Microsoft has returned to using numerical version
numbers, although the official version number for Windows 7 is 6.1.[8]
The Debian project uses a major/minor versioning scheme for releases of its operating
system, but uses code names from the movie Toy Story during development to refer to
stable, unstable and testing releases.
Internal version numbers
Software may have an "internal" version number which differs from the version number
shown in the product name (and which typically follows version numbering rules more
consistently). Java SE5.0, for example, has the internal version number of 1.5.0, and
versions of Windows from NT 4 on have continued the standard numerical versions
internally: Windows 2000 is NT 5.0, XP is Windows NT 5.1, Windows Server 2003 is NT 5.2,
Vista is NT 6.0 and 7 is NT 6.1. Note, however, that Windows NT is only on its third major
revision, as its first release was numbered 3.1 (to match the then-current Windows release
number).
Pre-release versions
In conjunction with the various versioning schemes listed above, a system for denoting prerelease versions is generally used, as the program makes its way through the stages of
the software release life cycle. Programs that are in an early stage are often called "alpha"
software, after the first letter in the Greek alphabet. After they mature but are not yet ready
for release, they may be called "beta" software, after the second letter in the Greek alphabet.
Generally alpha software is tested by developers only, while beta software is distributed for
community testing. Alpha- and beta-version software is often given numerical versions less
than 1 (such as 0.9), to suggest their approach toward a public "1.0" release. However, if the
pre-release version is for an existing software package (e.g. version 2.5), then an "a" or
"alpha" may be appended to the version number. So the alpha version of the 2.5 release
might be identified as 2.5a or 2.5.a. Software packages which are soon to be released as a
particular version may carry that version tag followed by "rc-#", indicating the number of the
release candidate. When the version is actually released, the "rc" tag disappears.
This can apparently cause trouble for some package managers, though. The Rivendell radio
automation package, for example, is about to have to release its first full production release
package... v1.0.1, because if they called it v1.0.0, RPM would refuse to install it, thinking that
version is *older* than "1.0.0rc2".
Modifications to the numeric system
Odd-numbered versions for development releases
Between the 1.0 and the 2.6.x series, the Linux kernel used odd minor version numbers to
denote development releases and even minor version numbers to denote stable releases;
see Linux kernel: Version numbering. For example, Linux 2.3 was a development family of
the second major design of the Linux kernel, and Linux 2.4 was the stable release family that
Linux 2.3 matured into. After the minor version number in the Linux kernel is the release
number, in ascending order; for example, Linux 2.4.0 → Linux 2.4.22. Since the 2004
release of the 2.6 kernel, Linux no longer uses this system, and has a much shorter release
cycle, instead now simply incrementing the third number, using a fourth number as
necessary.
The same odd-even system is used by some other software with long release cycles, such
asGNOME.
Apple
Apple had their own twist on this habit during the era of the classic MacOS: although there
were minor releases, they rarely went beyond 1, and when they did, they twice jumped
straight to 5, suggesting a change of magnitude intermediate between a major and minor
release (thus, 8.5 really means 'eight and a half', and 8.6 is 'eight and a half point one'). The
complete sequence of versions (neglecting revision releases) is 1.0, 1.1, 2.0, 2.1, 3.0, 3.2
(skipping 3.1), 4.0, 4.1, 5.0, 5.1, 6.0, 7.0, 7.1, 7.5, 7.6, 8.0, 8.1, 8.5, 8.6, 9.0, 9.1, 9.2.
Mac OS X has departed from this trend, having gone more conventionally from 10.0 to 10.6,
one minor release at a time. However, note that the 10.4.10 update does not follow the
previously-indicated approach of having a "one- or two-digit major version, a one-digit minor
version, a one-digit 'bug' (i.e. revision) version…". The bug-fix value is not a decimal
indicator, but is an incremental whole value; while it is not expected, there would be nothing
preventing a distant-future "X.4.321" release.
Political and cultural significance of version numbers
Version 1.0 as a milestone
Proprietary software developers often start at version 1 for the first release of a program and
increment the major version number with each rewrite. This can mean that a program can
reach version 3 within a few months of development, before it is considered stable or
reliable.
In contrast to this, the free-software community tends to use version 1.0 as a
major milestone, indicating that the software is "complete", that it has all major features, and
is considered reliable enough for general release.
In this scheme, the version number slowly approaches 1.0 as more and more bugs are fixed
in preparation for the 1.0 release. The developers of MAME do not intend to release a
version 1.0 of their emulator program. The argument is that it will never be truly "finished"
because there will always be more arcade games. Version 0.99 was simply followed by
version 0.100 (minor version 100 > 99). In a similar fashion Xfire 1.99 was followed by 1.100.
After 6 years of development,eMule has not even reached version 0.50 yet.
To describe program history
Winamp released an entirely different architecture for version 3 of the program. Due to lack
ofbackwards compatibility with plugins and other resources from the major version 2, a new
version was issued that was compatible with both version 2 and 3. The new version was set
to 5 (2+3), skipping version 4. The developers also humorously joked that they skipped
version 4 because "nobody wants to see a Winamp 4 skin", referencing the foreskin of a
penis.[9]
A similar thing happened with UnixWare 7, which was the combination of UnixWare 2
andOpenServer 5.
Keeping up with competitors
There is a common habit in the proprietary software industry (usually, though not always,
spurned by free software programmers) to make major jumps in numeric major or minor
version numbers for reasons which do not seem (to many members of the program's
audience) to merit the "marketing" version numbers.
This can be seen in several Microsoft and America Online products, as well as Sun Solaris
and Java Virtual Machine numbering, SCO Unix version numbers, and Corel Word Perfect,
as well as the filePro DB/RAD programming package, which went from 2.0 to 3.0 to 4.0 to
4.1 to 4.5 to 4.8 to 5.0, and is about to go to 5.6, with no intervening release. A slightly
different version can be seen in AOL's PC client software, which tends to have only major
releases (5.0, 6.0, 7.0, etc.). Likewise,Microsoft Access jumped from version 2.0 to version
7.0, to match the version number of Microsoft Word.
Microsoft has also been the target of 'catch-up' versioning, with
the Netscape browser skipping version 5 to 6, in line with Microsoft's Internet Explorer, but
also because the Mozilla application suite inherited version 5 in its user agent string during
pre-1.0 development and Netscape 6.x was built upon Mozilla's code base.
Sun's Java has at times had a hybrid system, where the actual version number has always
been 1.x but three times has been marketed by reference only to the x:
 JDK 1.0.3
 JDK 1.1.2 through 1.1.8
 J2SE 1.2.0 ("Java 2") through 1.4.2
 Java 1.5.0 ("Java 5")
 Java 1.6.0 ("Java 6")
Sun also dropped the first digit for Solaris, where Solaris 2.8 (or 2.9) is referred to as Solaris
8 (or 9) in marketing materials.
Another example of keeping up with competitors is when Slackware Linux jumped from
version 4 to version 7 in 1999.[10]
Superstition
 The Office 2007 release of Microsoft Office has an internal version number of 12.
The next version Office 2010 has an internal version of 14, due to superstitions
surroundingthe number 13.[11]
 Corel's WordPerfect Office, version 13 is marketed as "X3" (Roman number 10 and
"3"). The procedure has continued into the next version, X4. The same has
happened with Corel's Graphic Suite (i.e. CorelDRAW, Corel Photo-Paint) as well
as its Video editing software "Video Studio".
Popular culture
 The S.u.S.E Linux distribution started at version 4.2, to reference "the answer to life,
the universe and everything" mentioned in The Hitchhiker's Guide To The Galaxy.
Overcoming perceived marketing difficulties
In the mid-1990s, the rapidly growing CMMS, Maximo, moved from Maximo Series 3 directly
to Series 5, skipping Series 4 due to that number's perceived marketing difficulties in the
Chinese market, where pronunciation of the number 4 (四) in Chinese rhymes with “death” or
“failure”. This did not, however, stop Maximo Series 5 version 4.0 being released. (It should
be noted the "Series" versioning has since been dropped, effectively resetting version
numbers after Series 5 version 1.0's release.)
Significance in software engineering
Version numbers are used in practical terms by the consumer, or client, by being able to
compare their copy of the software product against another copy, such as the newest version
released by the developer. For the programmer team or company, versioning is often used
on a file-by-file basis, where individual parts or sectors of the software code are compared
and contrasted with newer or older revisions, often in a collaborative version control system.
There is no absolute and definite software version schema; it can often vary from software
genre to genre, and is very commonly based on the programmer's personal preference.
Significance in technical support
Version numbers allow people providing support to ascertain exactly what code a user is
running, so that they know what bugs might affect a problem, and the like. This occurs when
a program has a substantial user community, especially when that community is large
enough that the people providing technical support are not the people who wrote the code.
Version numbers for files and documents
Some computer file systems, such as the OpenVMS Filesystem, also keep versions for files.
Versioning amongst documents is relatively similar to the routine used with computers and
software engineering, where with each small change in the structure, contents, or conditions,
the version number is incremented by 1, or a smaller or larger value, again depending on the
personal preference of the author and the size or importance of changes made.
Version number ordering systems
Version numbers very quickly evolve from simple integers (1, 2, ...) to rational numbers
(2.08, 2.09, 2.10) and then to non-numeric "numbers" such as 4:3.4.3-2. These complex
version numbers are therefore better treated as character strings. Operating systems that
include package management facilities (such as all non-trivial Linux or BSD distributions) will
use a distribution-specific algorithm for comparing version numbers of different software
packages. For example, the ordering algorithms of Red Hat and derived distributions differ to
those of the Debian-like distributions.
As an example of surprising version number ordering implementation behavior, in Debian,
leading zeroes are ignored in chunks, so that 5.0005 and 5.5 are considered as equal, and
5.5<5.0006. This can confuse users; string-matching tools may fail to find a given version
number; and this can cause subtle bugs in package management if the programmers use
string-indexed data structures such as version-number indexed hash tables.
In order to ease sorting, some software packages will represent each component of
themajor.minor.release scheme with a fixed width. Perl represents its version numbers as a
floating-point number, for example, Perl's 5.8.7 release can also be represented
as 5.008007. This allows a theoretical version of 5.8.10 to be represented as 5.008010.
Other software packages will pack each segment into a fixed bit width, for
example, 5.8.7 could be represented in 24 bits: ( 5 << 16 |8 << 8 | 7; hexadecimal: 050807;
for version 12.34.56 in hexadecimal: 0C2238). The floating-point scheme will break down if
any segment of the version number exceeds 1,000; a packed-binary scheme employing 8
bits apiece after 256.
Use in other media
Software-style version numbers may be used in other media, playing on associations of
version numbers with high technology. Examples include:
 The X-Men Two-Disc Special Edition DVD was released as X-Men 1.5.
 Live Free or Die Hard was released as Die Hard 4.0 outside North America.
 The title of the computer game Tron 2.0 implies that the motion picture (or previous
arcade games) Tron was version 1.0.
 The rock band Garbage's second album is entitled Version 2.0.
 David Gerrold's revised version of his novel When HARLIE Was One was
subtitledRelease 2.0.
 The re-issue of the Mexican pop band Belanova's second album Dulce Beat was
released as Dulce Beat 2.0, which includes a different version of Te Quedas o Te
Vas and a second CD with acoustic versions, re-mixes and two music videos.
 Wizards of the Coast released Dungeons & Dragons 3.5 to demonstrate that
significant rules changes had occurred, but not so significant that a new edition
number was warranted. This has caused many to retroactively refer to the "Black
Books" of 2nd Edition Advanced Dungeons & Dragons as version 2.5.
 Web 2.0 referring to the World Wide Web as used in collaborative projects such
as wikisand social networking websites
 The Net 2.0 is the name of a sequel to the movie The Net
 The first series of The IT Crowd was Version 1.0; the second series was Version 2.0.
 The independent record label Transmission set by the progressive
rock band Porcupine Tree release their records imitating the software versioning to
identify them.
 The original name selected by Kraft for a new food spread
containing Vegemite and cream cheese was iSnack 2.0
 Fan-reedited versions of the fourth and fifth Star Wars films were called Star Wars
I.I: the Phantom Edit, and Star Wars II.I: Attack of the Phantom
How to Find Out What Is on Your Computer
Updated 19. September 2011 - 6:32 by v.laurie
I often help people with computer problems and very frequently it turns out that
they know very little about what is actually on their computer. If you want to know
things such as how much RAM you have, what hardware and software are installed,
and many other interesting details about your PC, you can use a built-in Windows
utility called System Information. Here is how to access it.
Windows XP
On most XP systems System Information can be found in Start-All ProgramsAccessories-System Tools. Another route is:
1.
2.
3.
4.
Open the Start menu
Click “Run”
Enter “msinfo32" (without quotes)
Click “OK”
Windows Vista/7
1. Open the Start menu
2. Enter “msinfo32” (without quotes) in the box labeled "Start search" (Vista) or
"Search programs and files" (Windows 7)
3. Click “msinfo32” or “msinfo32.exe” at the top of the menu
Open System Information from the command line
Another way to access this utility is to open the command line and enter "start
msinfo32" (without quotes). This works in Windows XP, Vista, and 7.
How to use System Information
System Information opens in a two-pane view. The left pane contains the entries
“System Summary”, “Hardware Resources”, “Components”, and “Software
Environment”. To see the details of any category except “System Summary”, click
the + by its name to expand the list and then click a desired sub-category. The right
pane will show the details.
System information freeware
There are also a number of free programs that provide considerably more details
than the built-in applicationSystem Information. Such helpful additional information
as license keys for software are given.
My own favorite is Belarc Advisor, which works on all current Windows versions, both
32-bit and 64-bit. However, when I installed it on Windows 7, I did get the message,
“This software may not have installed correctly”, but there was not actually any
problem.
I have also used System Information for Windows, which comes in a portable
version. It works on Windows XP on up. Added later: the installer for this software is
now being bundled with Open Candy. See Gizmo's articleabout Open Candy.
Go to the link Best Free System Information Utility for more details on this type of
application.
Get your own favorite tip published! Know a neat tech tip or trick? Then why
not have it published here and receive full credit? Click here to tell us your tip.
Software audit can mean:

a software licensing audit, where a user of software is audited for licence compliance

software quality assurance, where a piece of software is audited for quality

a software audit review, where a group of people external to a software development
organisation examines a software product

a physical configuration audit

a functional configuration audit
For a summary of software audits as defined in IEEE Std. 1028-1997, IEEE Standard on
Software Reviews, see software audit review
Software licensing audit
From Wikipedia, the free encyclopedia
This article needs additional citations for verification. Please help improve this article by
adding citations to reliable sources. Unsourced material may be challenged and removed. (July
2007)
Software Asset Management is an organization process, which is outlined in ISO/IEC 19770-1. It is
also now embraced within # ISO 27001:2005 Information Technology - Security Techniques Information Security Management Systems - Requirements[1] and ISO/IEC 17799:2005 Information
Technology - Security Techniques - Code of Practice for Information Security Management.[2]
Software Asset Management is a comprehensive strategy that has to be addressed from top to bottom
in an organization to be effective, to minimize risk. A software compliance audit is an important sub-set
of Software Asset Management and is covered in the above referenced standards. At its simplest it
involves the following:
1. Identification of Software Assets.
2. Verifying the Software Assets including licenses, usage, and rights.
3. Identifying gaps that may exist between what exists on the installations, and the licenses
possessed, and the rights of usage.
4. Taking action to close any gaps.
5. Recording the results in a centralized location with Proof Of Purchase records.
The audit process itself should be a continuing action, and modern SAM software identifies what is
installed, where it is installed, its usage, and provides a reconciliation of this discovery against usage.
This is a very useful means of controlling software installations and lowering the costs of licensing.
Large organisations could not do this without discovery and inventory applications.
From time to time internal or external audits may take a forensic approach to establish what is installed
on the computers in an organisation with the purpose of ensuring that it is all legal and authorised and
to ensure that its process of processing transactions or events is correct.
Software audits should not be confused with code audits, which are carried out on the source code of
a software project.
Software quality assurance
From Wikipedia, the free encyclopedia
This article needs additional citations for verification. Please help improve this article by
adding citations to reliable sources. Unsourced material may be challenged and removed. (January
2010)
Software quality assurance (SQA) consists of a means of monitoring the software
engineering processes and methods used to ensure quality. The methods by which this is
accomplished are many and varied, and may include ensuring conformance to one or more standards,
such as ISO 9000 or a model such as CMMI.
Contents
[hide]

1 Overvie
w

2 See also

3 Referen
ces

4 External
links
[edit]Overview
SQA encompasses the entire software development process, which includes processes such as
requirements definition, software design, coding, source code control, code reviews, change
management, configuration management, testing, release management, and product integration. SQA
is organized into goals, commitments, abilities, activities, measurements, and verifications. [1]
The American Society for Quality offers a Certified Software Quality Engineer (CSQE) certification with
exams held a minimum of twice a year.
Software audit review
From Wikipedia, the free encyclopedia
A software audit review, or software audit, is a type of software review in which one or more auditors
who are not members of the software development organization conduct "An independent examination
of a software product, software process, or set of software processes to assess compliance with
specifications, standards, contractual agreements, or other criteria"
[1]
.
"Software product" mostly, but not exclusively, refers to some kind of technical document. IEEE Std.
1028 offers a list of 32 "examples of software products subject to audit", including documentary
products such as various sorts of plan, contracts, specifications, designs, procedures, standards, and
reports, but also non-documentary products such as data, test data, and deliverable media.
Software audits are distinct from software peer reviews and software management reviews in that they
are conducted by personnel external to, and independent of, the software development organization,
and are concerned with compliance of products or processes, rather than with their technical content,
technical quality, or managerial implications.
The term "software audit review" is adopted here to designate the form of software audit described in
IEEE Std. 1028.
[edit]Objectives
and participants
This section is in a list format that may be better presented using prose. You can help by
converting this section to prose, if appropriate.Editing help is available. (September 2008)
"The purpose of a software audit is to provide an independent evaluation of conformance of software
products and processes to applicable regulations, standards, guidelines, plans, and procedures"
[2]
.
The following roles are recommended:

The Initiator (who might be a manager in the audited organization, a customer or user
representative of the audited organization, or a third party), decides upon the need for an audit,
establishes its purpose and scope, specifies the evaluation criteria, identifies the audit personnel,
decides what follow-up actions will be required, and distributes the audit report.

The Lead Auditor (who must be someone "free from bias and influence that could reduce his
ability to make independent, objective evaluations") is responsible for administrative tasks such as
preparing the audit plan and assembling and managing the audit team, and for ensuring that the
audit meets its objectives.

The Recorder documents anomalies, action items, decisions, and recommendations made by
the audit team.

The Auditors (who must be, like the Lead Auditor, free from bias) examine products defined in
the audit plan, document their observations, and recommend corrective actions. (There may be
only a single auditor.)

The Audited Organization provides a liaison to the auditors, and provides all information
requested by the auditors. When the audit is completed, the audited organization should
implement corrective actions and recommendations.
[edit]Tools
Parts of Software audit could be done using static analysis tools that analyze application code and
score its conformance with standards, guidelines, best practices. From the List of tools for static code
analysis some are covering a very large spectrum from code to architecture review, and could be use
for benchmarking.
Physical configuration audit
From Wikipedia, the free encyclopedia
A Physical Configuration Audit (PCA) is the formal examination of the "as-built" configuration of a
configuration item against its technical documentation to establish or verify the configuration item's
product baseline. The PCA is used to examine the actual configuration of the Configuration Item (CI)
that is representative of the product configuration in order to verify that the related design
documentation matches the design of the deliverable CI. It is also used to validate many of the
supporting processes that the contractor uses in the production of the CI. The PCA is also used to
verify that any elements of the CI that were redesigned after the completion of the Functional
Configuration Audit (FCA) also meet the requirements of the CI's performance specification. Additional
PCAs may be accomplished later during CI production if circumstances such as the following apply:

The original production line is "shut down" for several years and then production is restarted

The production contract for manufacture of a CI with a fairly complex, or difficult-tomanufacture, design is awarded to a new contractor or vendor.
This re-auditing in these circumstances is advisable regardless of whether the contractor or the
government controls the detail production design.[1]
Contents
[hide]

1 Softwar
e

2 See also

3 Referen
ces

4 External
links
[edit]Software
PCA is one of the practices used in Software Configuration Management for Software Configuration
Auditing.
The purpose of the software PCA is to ensure that the design and reference documentation is
consistent with the as-built software product.
Software testing
From Wikipedia, the free encyclopedia
Software development process
Activities and steps

Requirements

Specification

Architecture


Design
Implementation


Testing
Deployment

Maintenance
Methodologies


Agile
Cleanroom

Iterative

RAD

RUP

Spiral

Waterfall




XP
Lean
Scrum
V-Model

TDD
Supporting disciplines

Configuration management


Documentation
Quality assurance (SQA)


Project management
User experience design
Tools

Compiler

Debugger


Profiler
GUI designer

IDE
v·d·e
Software testing is an investigation conducted to provide stakeholders with information about the
quality of the product or service under test.[1] Software testing can also provide an objective,
independent view of the software to allow the business to appreciate and understand the risks of
software implementation. Test techniques include, but are not limited to, the process of executing a
program or application with the intent of finding software bugs(errors or other defects).
Software testing can be stated as the process of validating and verifying that a software
program/application/product:
1. meets the requirements that guided its design and development;
2. works as expected; and
3. can be implemented with the same characteristics.
Software testing, depending on the testing method employed, can be implemented at any time in the
development process. However, most of the test effort occurs after the requirements have been
defined and the coding process has been completed. As such, the methodology of the test is governed
by the software development methodology adopted.
Different software development models will focus the test effort at different points in the development
process. Newer development models, such as Agile, often employ test driven development and place
an increased portion of the testing in the hands of the developer, before it reaches a formal team of
testers. In a more traditional model, most of the test execution occurs after the requirements have
been defined and the coding process has been completed.
Contents
[hide]

1 Overview

2 History

3 Software testing topics
o
3.1 Scope
o
3.2 Functional vs non-functional testing
o
3.3 Defects and failures
o
3.4 Finding faults early
o
3.5 Compatibility
o
3.6 Input combinations and preconditions
o
3.7 Static vs. dynamic testing
o
3.8 Software verification and validation
o
3.9 The software testing team
o
3.10 Software quality assurance (SQA)

4 Testing methods
o
4.1 The box approach

4.1.1 White box testing

4.1.2 Black box testing

4.1.3 Grey box testing

5 Testing levels
o
5.1 Test target

5.1.1 Unit testing

5.1.2 Integration testing

5.1.3 System testing

o

5.1.4 System integration testing
5.2 Objectives of testing

5.2.1 Regression testing

5.2.2 Acceptance testing

5.2.3 Alpha testing

5.2.4 Beta testing
6 Non-functional testing
o
6.1 Software performance testing and load testing
o
6.2 Stability testing
o
6.3 Usability testing
o
6.4 Security testing
o
6.5 Internationalization and localization
o
6.6 Destructive testing

7 The testing process
o
7.1 Traditional CMMI or waterfall development model
o
7.2 Agile or Extreme development model
o
7.3 A sample testing cycle

8 Automated testing
o
8.1 Testing tools
o
8.2 Measurement in software testing

9 Testing artifacts

10 Certifications

11 Controversy

12 See also

13 References

14 External links
[edit]Overview
Testing can never completely identify all the defects within software.[2] Instead, it furnishes
a criticism or comparison that compares the state and behavior of the product against oracles—
principles or mechanisms by which someone might recognize a problem. These oracles may include
(but are not limited to) specifications, contracts,[3] comparable products, past versions of the same
product, inferences about intended or expected purpose, user or customer expectations, relevant
standards, applicable laws, or other criteria.
Every software product has a target audience. For example, the audience for video game software is
completely different from banking software. Therefore, when an organization develops or otherwise
invests in a software product, it can assess whether the software product will be acceptable to its end
users, its target audience, its purchasers, and other stakeholders. Software testing is the process of
attempting to make this assessment.
A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion
annually. More than a third of this cost could be avoided if better software testing was performed. [4]
[edit]History
The separation of debugging from testing was initially introduced by Glenford J. Myers in
1979.[5] Although his attention was on breakage testing ("a successful test is one that finds a bug" [5][6])
it illustrated the desire of the software engineering community to separate fundamental development
activities, such as debugging, from that of verification. Dave Gelperin and William C. Hetzel classified
in 1988 the phases and goals in software testing in the following stages: [7]

Until 1956 - Debugging oriented[8]

1957–1978 - Demonstration oriented[9]

1979–1982 - Destruction oriented[10]

1983–1987 - Evaluation oriented[11]

1988–2000 - Prevention oriented[12]
[edit]Software
testing topics
[edit]Scope
A primary purpose of testing is to detect software failures so that defects may be discovered and
corrected. Testing cannot establish that a product functions properly under all conditions but can only
establish that it does not function properly under specific conditions.[13] The scope of software testing
often includes examination of code as well as execution of that code in various environments and
conditions as well as examining the aspects of code: does it do what it is supposed to do and do what
it needs to do. In the current culture of software development, a testing organization may be separate
from the development team. There are various roles for testing team members. Information derived
from software testing may be used to correct the process by which software is developed. [14]
[edit]Functional
vs non-functional testing
Functional testing refers to activities that verify a specific action or function of the code. These are
usually found in the code requirements documentation, although some development methodologies
work from use cases or user stories. Functional tests tend to answer the question of "can the user do
this" or "does this particular feature work."
Non-functional testing refers to aspects of the software that may not be related to a specific function or
user action, such as scalability or other performance, behavior under certain constraints, orsecurity.
Non-functional requirements tend to be those that reflect the quality of the product, particularly in the
context of the suitability perspective of its users.
[edit]Defects
and failures
Not all software defects are caused by coding errors. One common source of expensive defects is
caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by the
program designer.[15] A common source of requirements gaps is non-functional requirements such
as testability, scalability, maintainability, usability, performance, and security.
Software faults occur through the following processes. A programmer makes an error (mistake), which
results in a defect (fault, bug) in the software source code. If this defect is executed, in certain
situations the system will produce wrong results, causing a failure.[16] Not all defects will necessarily
result in failures. For example, defects in dead code will never result in failures. A defect can turn into a
failure when the environment is changed. Examples of these changes in environment include the
software being run on a new hardware platform, alterations in source data or interacting with different
software.[16] A single defect may result in a wide range of failure symptoms.
[edit]Finding
faults early
It is commonly believed that the earlier a defect is found the cheaper it is to fix it. [17] The following table
shows the cost of fixing the defect depending on the stage it was found.[18] For example, if a problem in
the requirements is found only post-release, then it would cost 10–100 times more to fix than if it had
already been found by the requirements review.
Time detected
Cost to fix a defect
Requirements Architecture Construction System test Post-release
Time introduced Requirements
1×
3×
5–10×
10×
10–100×
Architecture
-
1×
10×
15×
25–100×
Construction
-
-
1×
10×
10–25×
[edit]Compatibility
A common cause of software failure (real or perceived) is a lack of compatibility with other application
software, operating systems (or operating system versions, old or new), or target environments that
differ greatly from the original (such as a terminal or GUI application intended to be run on
the desktop now being required to become a web application, which must render in a web browser).
For example, in the case of a lack of backward compatibility, this can occur because the programmers
develop and test software only on the latest version of the target environment, which not all users may
be running. This results in the unintended consequence that the latest work may not function on earlier
versions of the target environment, or on older hardware that earlier versions of the target environment
was capable of using. Sometimes such issues can be fixed by proactively abstracting operating
system functionality into a separate program module or library.
[edit]Input
combinations and preconditions
A very fundamental problem with software testing is that testing under all combinations of inputs and
preconditions (initial state) is not feasible, even with a simple product.[13][19] This means that the
number of defects in a software product can be very large and defects that occur infrequently are
difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed
tobe versus what it is supposed to do)—usability, scalability, performance, compatibility, reliability—
can be highly subjective; something that constitutes sufficient value to one person may be intolerable
to another.
[edit]Static
vs. dynamic testing
There are many approaches to software testing. Reviews, walkthroughs, or inspections are considered
as static testing, whereas actually executing programmed code with a given set of test cases is
referred to as dynamic testing. Static testing can be (and unfortunately in practice often is) omitted.
Dynamic testing takes place when the program itself is used for the first time (which is generally
considered the beginning of the testing stage). Dynamic testing may begin before the program is 100%
complete in order to test particular sections of code (modules or discrete functions). Typical techniques
for this are either using stubs/drivers or execution from a debugger environment. For
example, spreadsheet programs are, by their very nature, tested to a large extent interactively ("on the
fly"), with results displayed immediately after each calculation or text manipulation.
[edit]Software
verification and validation
Software testing is used in association with verification and validation:[20]

Verification: Have we built the software right? (i.e., does it match the specification).

Validation: Have we built the right software? (i.e., is this what the customer wants).
The terms verification and validation are commonly used interchangeably in the industry; it is also
common to see these two terms incorrectly defined. According to the IEEE Standard Glossary of
Software Engineering Terminology:
Verification is the process of evaluating a system or component to determine whether the
products of a given development phase satisfy the conditions imposed at the start of that
phase.
Validation is the process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements.
According to the IS0 9000 standard:
Verification is confirmation by examination and through provision of objective evidence that
specified requirements have been fulfilled.
Validation is confirmation by examination and through provision of objective evidence that the
requirements for a specific intended use or application have been fulfilled.
[edit]The
software testing team
Software testing can be done by software testers. Until the 1980s the term "software
tester" was used generally, but later it was also seen as a separate profession.
Regarding the periods and the different goals in software testing,[21] different roles
have been established: manager, test lead, test designer, tester, automation
developer, and test administrator.
[edit]Software
quality assurance (SQA)
Though controversial, software testing is a part of the software quality
assurance (SQA) process.[13] In SQA, software process specialists and auditors are
concerned for the software development process rather than just the artifacts such
as documentation, code and systems. They examine and change the software
engineering process itself to reduce the amount of faults that end up in the delivered
software: the so-called defect rate.
What constitutes an "acceptable defect rate" depends on the nature of the software;
A flight simulator video game would have much higher defect tolerance than
software for an actual airplane.
Although there are close links with SQA, testing departments often exist
independently, and there may be no SQA function in some companies.
Software testing is a task intended to detect defects in software by contrasting a
computer program's expected results with its actual results for a given set of inputs.
By contrast, QA (quality assurance) is the implementation of policies and
procedures intended to prevent defects from occurring in the first place.
[edit]Testing
[edit]The
methods
box approach
Software testing methods are traditionally divided into white- and black-box testing.
These two approaches are used to describe the point of view that a test engineer
takes when designing test cases.
[edit]White box testing
Main article: White box testing
White box testing is when the tester has access to the internal data structures and
algorithms including the code that implement these.
Types of white box testing
The following types of white box testing exist:

API testing (application programming interface) - testing of the application using public
and private APIs

Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test
designer can create tests to cause all statements in the program to be executed at least
once)

Fault injection methods - improving the coverage of a test by introducing faults to test
code paths

Mutation testing methods

Static testing - White box testing includes all static testing
Test coverage
White box testing methods can also be used to evaluate the completeness of a test suite that
was created with black box testing methods. This allows the software team to examine parts
of a system that are rarely tested and ensures that the most important function points have
been tested.[22]
Two common forms of code coverage are:

Function coverage, which reports on functions executed

Statement coverage, which reports on the number of lines executed to complete the test
They both return a code coverage metric, measured as a percentage.
[edit]Black box testing
Main article: Black box testing
Black box testing treats the software as a "black box"—without any
knowledge of internal implementation. Black box testing methods
include: equivalence partitioning, boundary value analysis, all-pairs
testing, fuzz testing, model-based testing, exploratory testing and
specification-based testing.
Specification-based testing: Specification-based testing aims to test the functionality of
software according to the applicable requirements.[23] Thus, the tester inputs data into, and
only sees the output from, the test object. This level of testing usually requires thorough test
cases to be provided to the tester, who then can simply verify that for a given input, the output
value (or behavior), either "is" or "is not" the same as the expected value specified in the test
case.
Specification-based testing is necessary, but it is insufficient to guard against certain risks. [24]
Advantages and disadvantages: The black box tester has no "bonds" with the code, and a
tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you
shall receive," black box testers find bugs where programmers do not. On the other hand,
black box testing has been said to be "like a walk in a dark labyrinth without a flashlight,"
because the tester doesn't know how the software being tested was actually constructed. As a
result, there are situations when (1) a tester writes many test cases to check something that
could have been tested by only one test case, and/or (2) some parts of the back-end are not
tested at all.
Therefore, black box testing has the advantage of "an
unaffiliated opinion", on the one hand, and the
disadvantage of "blind exploring", on the other. [25]
[edit]Grey box testing
Grey Box Testing (American spelling: gray box
testing) involves having knowledge of internal data
structures and algorithms for purposes of designing the
test cases, but testing at the user, or black-box level.
The tester is not required to have a full access to the
software's source code.[26][not in citation given] Manipulating
input data and formatting output do not qualify as grey
box, because the input and output are clearly outside of
the "black-box" that we are calling the system under test.
This distinction is particularly important when
conducting integration testing between two modules of
code written by two different developers, where only the
interfaces are exposed for test. However, modifying a
data repository does qualify as grey box, as the user
would not normally be able to change the data outside of
the system under test. Grey box testing may also
include reverse engineering to determine, for instance,
boundary values or error messages.
By knowing the underlying concepts of how the software
works, the tester makes better-informed testing choices
while testing the software from outside. Typically, a grey
box tester will be permitted to set up his testing
environment; for instance, seeding a database; and the
tester can observe the state of the product being tested
after performing certain actions. For instance, he/she
may fire an SQLquery on the database and then observe
the database, to ensure that the expected changes have
been reflected. Grey box testings implements intelligent
test scenarios, based on limited information. This will
particularly apply to data type handling, exception
handling, and so on.[27]
[edit]Testing
levels
Tests are frequently grouped by where they are added in
the software development process, or by the level of
specificity of the test. The main levels during the
development process as defined by theSWEBOK guide
are unit-, integration-, and system testing that are
distinguished by the test target without implying a
specific process model.[28] Other test levels are classified
by the testing objective.[29]
[edit]Test
target
[edit]Unit testing
Main article: Unit testing
Unit testing, also known as component testing, refers to
tests that verify the functionality of a specific section of
code, usually at the function level. In an object-oriented
environment, this is usually at the class level, and the
minimal unit tests include the constructors and
destructors.[30]
These types of tests are usually written by developers as
they work on code (white-box style), to ensure that the
specific function is working as expected. One function
might have multiple tests, to catch corner cases or other
branches in the code. Unit testing alone cannot verify the
functionality of a piece of software, but rather is used to
assure that the building blocks the software uses work
independently of each other.
[edit]Integration testing
Main article: Integration testing
Integration testing is any type of software testing that
seeks to verify the interfaces between components
against a software design. Software components may be
integrated in an iterative way or all together ("big bang").
Normally the former is considered a better practice since
it allows interface issues to be localised more quickly
and fixed.
Integration testing works to expose defects in the
interfaces and interaction between integrated
components (modules). Progressively larger groups of
tested software components corresponding to elements
of the architectural design are integrated and tested until
the software works as a system.[31]
[edit]System testing
Main article: System testing
System testing tests a completely integrated system to
verify that it meets its requirements.[32]
[edit]System integration testing
Main article: System integration testing
System integration testing verifies that a system is
integrated to any external or third-party systems defined
in the system requirements.[citation needed]
[edit]Objectives
of testing
[edit]Regression testing
Main article: Regression testing
Regression testing focuses on finding defects after a
major code change has occurred. Specifically, it seeks to
uncover software regressions, or old bugs that have
come back. Such regressions occur whenever software
functionality that was previously working correctly stops
working as intended. Typically, regressions occur as
an unintended consequence of program changes, when
the newly developed part of the software collides with
the previously existing code. Common methods of
regression testing include re-running previously run tests
and checking whether previously fixed faults have reemerged. The depth of testing depends on the phase in
the release process and the risk of the added features.
They can either be complete, for changes added late in
the release or deemed to be risky, to very shallow,
consisting of positive tests on each feature, if the
changes are early in the release or deemed to be of low
risk.
[edit]Acceptance testing
Main article: Acceptance testing
Acceptance testing can mean one of two things:
1.
A smoke test is used as an acceptance test
prior to introducing a new build to the main
testing process, i.e.
before integration or regression.
2.
Acceptance testing performed by the customer,
often in their lab environment on their own
hardware, is known as user acceptance
testing (UAT). Acceptance testing may be
performed as part of the hand-off process
between any two phases of development.[citation
needed]
[edit]Alpha testing
Alpha testing is simulated or actual operational testing by
potential users/customers or an independent test team at
the developers' site. Alpha testing is often employed for
off-the-shelf software as a form of internal acceptance
testing, before the software goes to beta testing.[33]
[edit]Beta testing
Beta testing comes after alpha testing and can be
considered a form of external user acceptance testing.
Versions of the software, known as beta versions, are
released to a limited audience outside of the
programming team. The software is released to groups
of people so that further testing can ensure the product
has few faults or bugs. Sometimes, beta versions are
made available to the open public to increase
the feedback field to a maximal number of future
users.[citation needed]
[edit]Non-functional
testing
Special methods exist to test non-functional aspects of
software. In contrast to functional testing, which
establishes the correct operation of the software (correct
in that it matches the expected behavior defined in the
design requirements), non-functional testing verifies that
the software functions properly even when it receives
invalid or unexpected inputs. Software fault injection, in
the form offuzzing, is an example of non-functional
testing. Non-functional testing, especially for software, is
designed to establish whether the device under test can
tolerate invalid or unexpected inputs, thereby
establishing the robustness of input validation routines
as well as error-management routines. Various
commercial non-functional testing tools are linked from
the software fault injection page; there are also
numerous open-source and free software tools available
that perform non-functional testing.
[edit]Software
performance testing and
load testing
Performance testing is executed to determine how fast a
system or sub-system performs under a particular
workload. It can also serve to validate and verify other
quality attributes of the system, such as scalability,
reliability and resource usage. Load testing is primarily
concerned with testing that can continue to operate
under a specific load, whether that be large quantities of
data or a large number of users. This is generally
referred to as software scalability. The related load
testing activity of when performed as a non-functional
activity is often referred to as endurance testing.
Volume testing is a way to test functionality. Stress
testing is a way to test reliability. Load testing is a way to
test performance. There is little agreement on what the
specific goals of load testing are. The terms load testing,
performance testing, reliability testing, and volume
testing, are often used interchangeably.
[edit]Stability
testing
Stability testing checks to see if the software can
continuously function well in or above an acceptable
period. This activity of non-functional software testing is
often referred to as load (or endurance) testing.
[edit]Usability
testing
Usability testing is needed to check if the user interface
is easy to use and understand. It is concerned mainly
with the use of the application.
[edit]Security
testing
Security testing is essential for software that processes
confidential data to prevent system intrusion by hackers.
[edit]Internationalization
and
localization
The general ability of software to be internationalized
and localized can be automatically tested without actual
translation, by using pseudolocalization. It will verify that
the application still works, even after it has been
translated into a new language or adapted for a new
culture (such as different currencies or time zones).[34]
Actual translation to human languages must be tested,
too. Possible localization failures include:

Software is often localized by translating a list of
strings out of context, and the translator may choose
the wrong translation for an ambiguous source
string.

Technical terminology may become inconsistent if
the project is translated by several people without
proper coordination or if the translator is imprudent.

Literal word-for-word translations may sound
inappropriate, artificial or too technical in the target
language.

Untranslated messages in the original language may
be left hard coded in the source code.

Some messages may be created automatically
at run time and the resulting string may be
ungrammatical, functionally incorrect, misleading or
confusing.

Software may use a keyboard shortcut which has no
function on the source language's keyboard layout,
but is used for typing characters in the layout of the
target language.

Software may lack support for the character
encoding of the target language.

Fonts and font sizes which are appropriate in the
source language, may be inappropriate in the target
language; for example, CJK characters may become
unreadable if the font is too small.

A string in the target language may be longer than
the software can handle. This may make the string
partly invisible to the user or cause the software to
crash or malfunction.

Software may lack proper support for reading or
writing bi-directional text.

Software may display images with text that wasn't
localized.

Localized operating systems may have differentlynamed system configuration files and environment
variables and different formats for
date and currency.
To avoid these and other localization problems, a tester
who knows the target language must run the program
with all the possible use cases for translation to see if the
messages are readable, translated correctly in context
and don't cause failures.
[edit]Destructive
testing
Main article: Destructive testing
Destructive testing attempts to cause the software or a
sub-system to fail, in order to test its robustness.
[edit]The
testing process
[edit]Traditional
CMMI or waterfall
development model
A common practice of software testing is that testing is
performed by an independent group of testers after the
functionality is developed, before it is shipped to the
customer.[35] This practice often results in the testing
phase being used as a project buffer to compensate for
project delays, thereby compromising the time devoted
to testing.[36]
Another practice is to start software testing at the same
moment the project starts and it is a continuous process
until the project finishes.[37]
Further information: Capability Maturity Model
Integration and Waterfall model
[edit]Agile
or Extreme development
model
In contrast, some emerging software disciplines such
as extreme programming and the agile software
development movement, adhere to a "test-driven
software development" model. In this process,unit
tests are written first, by the software engineers (often
with pair programming in the extreme programming
methodology). Of course these tests fail initially; as they
are expected to. Then as code is written it passes
incrementally larger portions of the test suites. The test
suites are continuously updated as new failure
conditions and corner cases are discovered, and they
are integrated with any regression tests that are
developed. Unit tests are maintained along with the rest
of the software source code and generally integrated into
the build process (with inherently interactive tests being
relegated to a partially manual build acceptance
process). The ultimate goal of this test process is to
achieve continuous deployment where software updates
can be published to the public frequently.[38] [39]
[edit]A
sample testing cycle
Although variations exist between organizations, there is
a typical cycle for testing.[40] The sample below is
common among organizations employing the Waterfall
development model.

Requirements analysis: Testing should begin in
the requirements phase of the software development
life cycle. During the design phase, testers work with
developers in determining what aspects of a design
are testable and with what parameters those tests
work.

Test planning: Test strategy, test
plan, testbed creation. Since many activities will be
carried out during testing, a plan is needed.

Test development: Test procedures, test
scenarios, test cases, test datasets, test scripts to
use in testing software.

Test execution: Testers execute the software
based on the plans and test documents then report
any errors found to the development team.

Test reporting: Once testing is completed, testers
generate metrics and make final reports on their test
effort and whether or not the software tested is
ready for release.

Test result analysis: Or Defect Analysis, is done by
the development team usually along with the client,
in order to decide what defects should be assigned,
fixed, rejected (i.e. found software working properly)
or deferred to be dealt with later.

Defect Retesting: Once a defect has been dealt
with by the development team, it is retested by the
testing team. AKA Resolution testing.

Regression testing: It is common to have a small
test program built of a subset of tests, for each
integration of new, modified, or fixed software, in
order to ensure that the latest delivery has not
ruined anything, and that the software product as a
whole is still working correctly.

Test Closure: Once the test meets the exit criteria,
the activities such as capturing the key outputs,
lessons learned, results, logs, documents related to
the project are archived and used as a reference for
future projects.
[edit]Automated
testing
Main article: Test automation
Many programming groups are relying more and more
on automated testing, especially groups that use testdriven development. There are many frameworks to
write tests in, and continuous integrationsoftware will run
tests automatically every time code is checked into
a version control system.
While automation cannot reproduce everything that a
human can do (and all the ways they think of doing it), it
can be very useful for regression testing. However, it
does require a well-developed test suite of testing scripts
in order to be truly useful.
[edit]Testing
tools
Program testing and fault detection can be aided
significantly by testing tools and debuggers.
Testing/debug tools include features such as:

Program monitors, permitting full or partial
monitoring of program code including:
 Instruction set simulator, permitting complete
instruction level monitoring and trace facilities
 Program animation, permitting step-by-step
execution and conditional breakpoint at source
level or in machine code
 Code coverage reports

Formatted dump or symbolic debugging, tools
allowing inspection of program variables on error or
at chosen points

Automated functional GUI testing tools are used to
repeat system-level tests through the GUI

Benchmarks, allowing run-time performance
comparisons to be made

Performance analysis (or profiling tools) that can
help to highlight hot spots and resource usage
Some of these features may be incorporated into
an Integrated Development Environment (IDE).

A regression testing technique is to have a standard
set of tests, which cover existing functionality that
result in persistent tabular data, and to compare prechange data to post-change data, where there
should not be differences, using a tool like diffkit.
Differences detected indicate unexpected
functionality changes or "regression".
[edit]Measurement
in software testing
Usually, quality is constrained to such topics
as correctness, completeness, security,[citation needed] but
can also include more technical requirements as
described under the ISO standard ISO/IEC 9126, such
as
capability, reliability, efficiency, portability, maintainability
, compatibility, and usability.
There are a number of frequently-used software
measures, often called metrics, which are used to assist
in determining the state of the software or the adequacy
of the testing.
[edit]Testing
artifacts
The software testing process can produce
several artifacts.
Test plan
A test specification is called a test plan. The developers are well aware what test plans will be
executed and this information is made available to management and the developers. The idea
is to make them more cautious when developing their code or making additional changes.
Some companies have a higher-level document called a test strategy.
Traceability matrix
A traceability matrix is a table that correlates requirements or design documents to test
documents. It is used to change tests when the source documents are changed, or to verify
that the test results are correct.
Test case
A test case normally consists of a unique identifier, requirement references from a design
specification, preconditions, events, a series of steps (also known as actions) to follow, input,
output, expected result, and actual result. Clinically defined a test case is an input and an
expected result.[41] This can be as pragmatic as 'for condition x your derived result is y',
whereas other test cases described in more detail the input scenario and what results might
be expected. It can occasionally be a series of steps (but often steps are contained in a
separate test procedure that can be exercised against multiple test cases, as a matter of
economy) but with one expected result or expected outcome. The optional fields are a test
case ID, test step, or order of execution number, related requirement(s), depth, test category,
author, and check boxes for whether the test is automatable and has been automated. Larger
test cases may also contain prerequisite states or steps, and descriptions. A test case should
also contain a place for the actual result. These steps can be stored in a word processor
document, spreadsheet, database, or other common repository. In a database system, you
may also be able to see past test results, who generated the results, and what system
configuration was used to generate those results. These past results would usually be stored
in a separate table.
Test script
A test script is a procedure, or programing code that replicates user actions. Initially the term
was derived from the product of work created by automated regression test tools. Test Case
will be a baseline to create test scripts using a tool or a program.
Test suite
The most common term for a collection of test cases is a test suite. The test suite often also
contains more detailed instructions or goals for each collection of test cases. It definitely
contains a section where the tester identifies the system configuration used during testing. A
group of test cases may also contain prerequisite states or steps, and descriptions of the
following tests.
Test data
In most cases, multiple sets of values or data are used to test the same functionality of a
particular feature. All the test values and changeable environmental components are collected
in separate files and stored as test data. It is also useful to provide this data to the client and
with the product or a project.
Test harness
The software, tools, samples of data input and output, and configurations are all referred to
collectively as a test harness.
[edit]Certifications
Several certification
programs exist to
support the professional
aspirations of software
testers and quality
assurance specialists.
No certification currently
offered actually requires
the applicant to
demonstrate the ability
to test software. No
certification is based on
a widely accepted body
of knowledge. This has
led some to declare that
the testing field is not
ready for
certification.[42] Certificati
on itself cannot measure
an individual's
productivity, their skill, or
practical knowledge, and
cannot guarantee their
competence, or
professionalism as a
tester.[43]
Software testing
certification types

Exam-based: Formalized exams, which need to be passed; can also be learned by selfstudy [e.g., for ISTQB or QAI][44]

Education-based: Instructor-led sessions, where each course has to be passed [e.g.,
International Institute for Software Testing (IIST)].
Testing
certifications

Certified Associate in Software Testing (CAST) offered by the QAI [45]

CATe offered by the International Institute for Software Testing[46]

Certified Manager in Software Testing (CMST) offered by the QAI [45]

Certified Software Tester (CSTE) offered by the Quality Assurance Institute (QAI)[45]

Certified Software Test Professional (CSTP) offered by the International Institute for
Software Testing[46]

CSTP (TM) (Australian Version) offered by K. J. Ross & Associates[47]

ISEB offered by the Information Systems Examinations Board

ISTQB Certified Tester, Foundation Level (CTFL) offered by the International Software
Testing Qualification Board [48][49]

ISTQB Certified Tester, Advanced Level (CTAL) offered by the International Software
Testing Qualification Board [48][49]

TMPF TMap Next Foundation offered by the Examination Institute for Information
Science[50]

TMPA TMap Next Advanced offered by the Examination Institute for Information
Science[50]
Quality
assurance
certifications

CMSQ offered by the Quality Assurance Institute (QAI).[45]

CSQA offered by the Quality Assurance Institute (QAI)[45]

CSQE offered by the American Society for Quality (ASQ)[51]

CQIA offered by the American Society for Quality (ASQ)[51]
[edit]Co
ntrover
sy
Some of
the
major soft
ware
testing
controversi
es include:
What
constitute
s
responsib
le
software
testing?
Members of the "context-driven" school of testing[52] believe that there are no "best practices"
of testing, but rather that testing is a set of skills that allow the tester to select or invent testing
practices to suit each unique situation.[53]
Agile
vs.
traditi
onal
Should testers learn to work under conditions of uncertainty and constant change or should
they aim at process "maturity"? The agile testing movement has received growing popularity
since 2006 mainly in commercial circles,[54][55] whereas government and military[56] software
providers use this methodology but also the traditional test-last models (e.g. in the Waterfall
model).[citation needed]
E
x
pl
or
at
or
y
te
st
v
s.
s
cr
ip
te
d[
57]
Should tests be designed at the same time as they are executed or should they be designed
beforehand?
M
a
n
u
a
l
t
e
s
t
i
n
g
v
s
.
a
u
t
o
m
a
t
e
d
Some writers believe that test automation is so expensive relative to its value that it should be
used sparingly.[58] More in particular, test-driven development states that developers should
write unit-tests of the XUnit type before coding the functionality. The tests then can be
considered as a way to capture and implement the requirements.
S
o
f
t
w
a
r
e
d
e
s
i
g
n
v
s
.
s
o
f
t
w
a
r
e
i
m
p
l
e
m
e
n
t
a
t
i
o
n
[
5
9
]
Should testing be carried out only at the end or throughout the whole process?
W
h
o
w
a
t
c
h
e
s
t
h
e
w
a
t
c
h
m
e
n
?
The idea is that any form of observation is also an interaction—the act of testing can also
affect that which is being tested.[60]
Software Installation
One of the main jobs of the home sysad is to install software - which to
the novice can seem quite tricky.
Fortunately, the task becomes easier once you understand the three main issues
involved. The first issue is to understand how software is installed. Basically, here is
how to do it in three or four steps:

First, you create a folder to house the new software. By convention, this
folder is located in the ‘Program Files’ folder within C: Drive … but it can be
placed anywhere else if you prefer. You may also need to create other
folders, which may or may not go in the original folder;

Next, you place the program files in the right places. Depending on the
software you are installing, this may involve placing just one single file in the
folder you just created, or sprinkling hundreds of different files around the
computer, each in exactly the right folder;

Optionally, you might have to tell the Windows operating system that you are
installing new software, which you do by adjusting various system files and
Registry files;

Finally, you place shortcuts to your new software on the Desktop, in the Start
Menu programs list, and anywhere else you like.
The second issue is whether the software manufacturer provides you with an
automatic installation wizard (known as an ‘installer’), or whether you have
to do all of this manually. Most manufacturers, but not all, give you an
installer. This installer is a program in its own right, but one that only has
one job: it installs you software, and then you can throw it away (or at very
least, save it to a CD, and then delete it from your computer). When you
download software from the Internet, most times you will actually be
downloading installers. The third issue is whether the new software you
install is going to conflict with previously installed software. Some new
software never causes conflicts; others will almost always do so unless you
take special steps by shutting down any other programs during the
installation process. Usually (but not always), the software manufacturer will
warn you when a conflict is likely to happen. They do this by recommending
that you close all Windows programs before installing the new program.
Closing these other programs will usually prevent the chance of conflicts.
Taking all of these issues into account, we will end up with four main types
of installation:
o
Type A: There is no installer: you have to install your software
yourself, manually. The good news is that usually you do not have to
close other programs.
o
Type B: The software arrives as an installer program. Its key feature is
that it ’strongly recommends’ that you shut down other Windows
programs. After you have done that, the installer Wizard walks you
through the installation process.
o
Type C: The software arrives as an installer program. This time, it
does not recommend shutting down other programs, but immediately
walks you through the installation process.
o
Type D: The software uses Windows’ built-in installer, and installs
itself automatically, doing no more than perhaps asking you to agree
to the End User License Agreement (EULA).
So when you first decide to install some software, how do you tell which type
it is? Simple: you run it and see what happens next.
o
If the program you want to use immediately runs, with no sign of
installing, it is not an installer; it is Type A;
o
If the program immediately begins to installs itself, without
suggesting that you close down other programs, it is either Type C or
Type D. The main practical difference between Types C and D is that
Type D software cannot be installed in Safe Mode.
o
Anything else is a Type B installer.
Type A: Manual installation
When you download, what you get is the software program itself, complete
and readyto run. This software will run from anywhere - from the Desktop,
from a floppy, orfrom a USB memory stick. Unless you only want to use it the
once, ‘install’ it thus:1. Create a folder for the software in
C:\\\\\\\\\\\\\\\\Program Files\\\\\\\\\\\\\\\\. To do this, open the
C:\\\\\\\\\\\\\\\\Programs Files\\\\\\\\\\\\\\\\ folder, create a new
folder there, and name it after the program.2. Move the program and any
associated files into that folder.3. Right-click on the program file (the .exe
program) and choose ‘copy’;4. If you would like a shortcut on your Desktop,
right-click on some clear space onthe Desktop, and choose ‘paste shortcut’.
Rename this shortcut if you wish;5. If you would like a link in your Start Menu
Programs list, open the link to the StartMenu’s Programs folder (see Topic
11), and paste a shortcut there.
Type B: First shut down other programs
When you run Type B installers, a message will soon appear to say that it
isrecommended that you shut down all other Windows programs before
proceedingwith the installation. There are two ways to do this:
The Safe Mode Method:
To minimize the risk of software conflicts, the safestmethod is to install in
Safe Mode:
1. Enter Safe Mode (see Topic 10). This will automatically (though only
temporarily)disconnect the Internet, and disable all other programs;
2. Run the Installer either by double-clicking on it, or by right-clicking, and
choosing‘Open’.
3. Install the program (see Installation Tips on next page);
4. Ignore all requests to run the program, or to visit the program’s home
page;
5. Shut down and restart the computer..
The Normal Mode Method:
This method is second-best, but sometimes quicker.
1. Make sure that the Internet is disconnected. If in doubt, pull out the
Internet cable.Under no circumstances use this method while connected to
the Internet;
2. Shut down all other programs. To do this, first look in the Task Bar, and
shut downall programs (other than the installer if it is running). Next, look in
the SystemTray (right bottom of screen), and shut down everything you can
find there. To shutdown System Tray items, right-click on each icon, one by
one, and choose anycommands that hint at shutting down, such as ‘quit’,
‘close’, ‘disable’ or‘shutdown’. (You will probably find one or two System
Tray items that you won’tbe able to shut down; this is normal);
3. Run the Installer, and install the program (see Installation Tips opposite);
4. Ignore all requests to run the program, or to visit the program’s Internet
homepage;
5. Shut down and restart the computer..
Type C: Simple Installer
In this case, the installer does not require you to shut down other programs.
To use aType C installer, just follow the prompts (see Installation Tips
opposite). You caninstall in Normal Mode or Safe Mode.
Type D: Windows Installer
Once again, the installer does not require you to shut down other programs.
Thistime, however, you can only install in Normal Mode.
Installation Tips
Legal Agreement: Unless you know the program to be safe, read the legal
stuff(End User License Agreement, or EULA) carefully. Better still, copy and
paste it intoEULAlyser, a free program you can get from
javacoolsoftware.com. This will highlightany troublesome aspects. If still in
doubt, ask a lawyer, or get a different program;
Finding a home for the program (1):
the usual home for program software is inits own folder within C:Program
Files. Some programs will only work properly ifthey are kept there; others
don’t care where you put them. Feel free to experiment… but don’t be
surprised if you find a program that only works properly in CDrive;
Finding a home for the program (2):
some software manufacturers think theirsoftware works best if it is hidden
buried within strangely-named folders. Forexample, the people who make
the TimeSyncro program think the best place for it isinside a folder called
‘Tools for selling’. Logical? Maybe. But if you don’t think so, feelfree to
rename or reorganize the folders so that you can easily find the software
whenyou want to. It will not make any difference at all to the way the
programs work;h3>After the installation is complete: many installers will ask
you - even try to trickyou - into immediately running the program, and/or
going online to visit theirwebpage, register the software, or update it. For
instance, the program will display adialog box telling you that the installation
is complete, and giving you just one button,labeled ‘Finished’, to press. On
the dialog box, however, will be a ticked box saying,sometimes in small
print, something like ’Run this program now’ or ’Visit ourwebsite now’. In all
cases, you should untick these boxes!
Installing an antivirus program:
before installing an antivirus program, alwayscheck to be sure that there is
no other antivirus program already installed on thecomputer. To do this,
check the System Tray for an antivirus program icon, look in‘Add/Remove
Programs’ (in the Control Panel) to see if there are any antivirusprograms you
recognize, and check the Security Centre (in the Control Panel) to seeif XP
thinks you have an antivirus program. Having two antivirus programs on
theone computer is almost always disastrous;
Installing an firewall program:
Just like antivirus programs, computers do notlike having two different
firewalls. If using XP, disable XP’s own firewall beforeinstalling a new one (do
this at Firewall in Security Center), and then use the samemethods as for
antivirus programs to make sure you never have two firewalls installedat
once.
Uninstalling Software
Another of the main jobs of the home sysad is to uninstall software which to the novice can seem quite tricky, but is usually quite easy.
To remove unwanted software:
1. Go to the Control Panel , and choose ‘Add/Remove Programs’;
2. Select the program you wish to remove;
3. Click on ‘Remove’;
4. Wait for the program to be uninstalled. During this process, you may be
asked to confirm the uninstalling;
5. Restart your computer.
There are two major types of data backup.

System Backup: It can take a long time - many hours, even days - to set up an
operating system, if one counts the time installing all the programs that you
use.If you wish, you can set things up so that if system and programs become
damaged, you can repair them all in a jiffy.

Data Backup: Your emails, music, photos, movies and all your personal
projects can be backed up to floppies, CDs or DVDs. This can have the twin
benefits of keeping them safe, and freeing up hard disk space.
Almost all modern backup systems begin by dividing your hard disk into two
divisions or ‘partitions’, one, called ’CDrive’, for the operating system and
programs, and the other, called ‘DataDrive’, for personal data. This procedure is
both and difficult to learn, and only rarely needed, so we suggest you have it done
by a technician or an experienced person at a computer club.
System Backup
Having partitioned your hard disk, your next task is to decide whether or not to
backup your CDrive, which is where your operating and programs are kept. If you
think installing operating systems and programs is fun, and look forward to hard
disk failures, then skip to the next section. Otherwise, read on.There are many
different ways to backup your operating system and programs, each with its own
advantages and disadvantages. Here we will look briefly at two of the more popular
systems. Both require your hard disk to be partitioned into two.

The Image Method: Using Acronis True Image (www.acronis.com), you copy
CDrive onto some CDs, a DVD, or another part of your hard disk - or all of
them. Thereafter, whenever you need or want to, you use this copy to restore
it to the way it used to be. There are many advantages to using this method.
One is that it is a fairly easy method to use; it allows you to make many
versions of your CDrive (for instance, different versions with different
software installed); and it is very quick to switch between versions.
Furthermore, you can make a whole host of changes experimentally - such
as installing many new programs - but easily return to an earlier version
saved months before if you don’t like the changes.

The Freeze Method: using virtual disk software, you lock CDrive in place.
Thereafter, viruses and computer users can make whatever changes they
like, and it won’t matter; the very next time the computer is restarted, the
changes disappear.
<liBoth: you use both methods.
Data Backup
To some people, the data on their computer is of very minor importance. “If
it were all lost tomorrow”, they say. “Who would care? Not me!” For such
people, the failure of a hard disk, or the attack of a virus would be the most
minor of inconveniences.Such people rarely bother with data backup.For
other people, however, losing data can be a catastrophe. Imagine that you
have spent six years writing a book, and just as you are about to type the
last full stop onthe last page, the computer crashes. Six years of work
disappears … and along with it goes years of music, emails and family
photos. The loss can, for some people, be devastating.So the question of
whether or not to backup is of highest importance.If you decide to backup,
the major part of your task as sysad is to discover what your computer’s
users want backed up, and then to learn how to back it up. For instance, do
your family members want to their emails backed up? If so, then you need
todiscover how to do this. Each computer - or even each user - can require a
different method, depending on what email software is used. The best time sometimes the only time - to do this is before the computer crashes or the
virus hits!
</li
Single user/ site licence
Home | Compositional Analysis | How to Order Compos Analysis | Ecological Consultan
cy | About Us | Useful Links
Compos Analysis software from Smith Ecology Limited
The distinction between the single user and site (multiuser) licence and the student licence:
Single user licence:
You may install and use one copy of the software product, or in its place, any
prior version, on a single computer. You may also store or install a copy of the
software product on a storage device, such as a network server, used only to
install or run the software product on your other computers over an internal
network; however, you must acquire and dedicate a licence for each separate
computer on which the software product is installed or run from the storage
device. A licence for the software product may not be shared or used
concurrently on different computers. The licence is valid for 3 years. At expiry
the licence may be renewed at a discount to the full price.
Multi-user site licence:
A site licence permits use of multiple copies of the software product by the
single entity that holds the licence, at the single entity’s sites. You may make
the number of copies of the software product authorised by the licence
agreement and you may use each copy at the licensed sites in the manner
specified for single users above. The single entity is the licensed organisation,
such as a university department. The software may be copied by (i) the
salaried employees of the organisation, or (ii) students under direct
supervision of such employees at the organisation’s sites (including field
sites) or at home, but not for use by contractors or students elsewhere, and
only provided that the number of copies does not exceed the number
permitted by the licence. The licence is valid for 3 years. At expiry the licence
may be renewed at a discount to the full price.
Student licence:
Available for students, normally defined as someone having a current student
identity card. State if you are a student buying for yourself when ordering. A
student licence covers your own use as a student and does not extend to use
by others. It is only available for the standard version of the software, not the
plus version and is not upgradeable to an alternative licence. The software
supplied is the full standard version. The licence is valid for 6 years but is
non-renewable. To continue use after 6 years you should purchase a regular
single user or site licence.
Software license
From Wikipedia, the free encyclopedia
It has been suggested that Software license agreement be merged into this article or section.
(Discuss) Proposed since November 2010.
This article needs additional citations for verification. Please help improve this article by
adding citations to reliable sources. Unsourced material may
be challenged and removed. (September 2009)
A software license (or software licence in commonwealth usage) is a legal instrument (usually by
way of contract law) governing the usage or redistribution of software.
All software is copyrightprotected, except material in the public domain. Contractual confidentiality is
another way of protecting software. A typical software license grants an end-user permission to use
one or more copies of software in ways where such a use would otherwise potentially constitute
copyright infringement of the software owner's exclusive rights under copyright law.
Some software comes with the license when purchased off the shelf or an OEM license when bundled
with hardware. Software can also be in the form of freeware or shareware. Software licenses can
generally be fit into the following categories: proprietary licenses and free and open source licenses,
which include free software licenses and other open source licenses. The features that distinguishes
them are significant in terms of the effect they have on the end-user's rights.
A free open source license makes software free for inspection of its code, modification, and
distribution. Some free licenses, such as the GNU General Public License (GPL), allow the product
and/or derivative to be commercially sold.
Contents
[hide]

1 Proprietary software

2 Free and open source software

3 Other characteristics

4 Software licenses and
copyright law

5 See also

6 References

7 External links
[edit]Proprietary
software
Main article: Proprietary software
The hallmark of proprietary software licenses is that the software publisher grants the use of one or
more copies of software under the end-user license agreement (EULA), but ownership of those copies
remains with the software publisher (hence use of the term "proprietary"). This feature of proprietary
software licenses means that certain rights regarding the software are reserved by the software
publisher. Therefore, it is typical of EULAs to include terms which define the uses of the software, such
as the number of installations allowed or the terms of distribution.
The most significant effect of this form of licensing is that, if ownership of the software remains with the
software publisher, then the end-user must accept the software license. In other words, without
acceptance of the license, the end-user may not use the software at all. One example of such a
proprietary software license is the license for Microsoft Windows. As is usually the case with
proprietary software licenses, this license contains an extensive list of activities which are restricted,
such as: reverse engineering, simultaneous use of the software by multiple users, and publication of
benchmarks or performance tests.
[edit]Free
and open source software
Main article: Free and open source software
A primary consequence of the free software form of licensing is that acceptance of the license is
essentially optional — the end-user may use the software without accepting the license. However, if
the end-user wishes to exercise any of the additional rights granted by a free software license (such as
the right to redistribute the software), then the end-user must accept, and be bound by, the software
license.
Open source licenses generally fall under two categories: Those that aim to preserve the openness of
the software itself (copyleft licenses), and those that aim to give freedoms to the users of that software
(permissive licenses).
An example of a copyleft free software license is the GNU General Public License (GPL). This license
is aimed at giving the end-user permission to redistribute, reverse engineer, or otherwise modify the
software under the terms of the license. These permissions are not entirely free of obligations for the
end-user, however. The end-user must comply with certain terms if the end-user wishes to exercise
these extra permissions granted by the GPL. For instance, any modifications made and redistributed
by the end-user must include the source code for these, and the end-user is not allowed to re-assert
the removed copyright back over their derivative work. The modified software is therefore also publicly
available for further modification by any user.
Examples of permissive free software licenses are the BSD license and the MIT license, which
essentially grant the end-user permission to do anything they wish with the source code in question,
including the right to take the code and use it as part of closed-source software or software released
under a proprietary software license.
[edit]Other
characteristics
In addition to granting rights and imposing restrictions on the use of software, software licenses
typically contain provisions which allocate liability and responsibility between the parties entering into
the license agreement. In enterprise and commercial software transactions these terms (such as
limitations of liability, warranties and warranty disclaimers, and indemnity if the software infringes
intellectual property rights of others) are often negotiated by attorneys specialized in software
licensing. The legal field has seen the growth of this specialized practice area due to unique legal
issues with software licenses, and the desire of software companies to protect assets which, if licensed
improperly, could diminish their value.
[edit]Software
licenses and copyright law
In the United States, Section 117 of the Copyright Act gives the owner of a particular copy of software
the explicit right to use the software with a computer, even if use of the software with a computer
requires the making of incidental copies or adaptations (acts which could otherwise potentially
constitute copyright infringement). Therefore, the owner of a copy of computer software is legally
entitled to use that copy of software. Hence, if the end-user of software is the owner of the respective
copy, then the end-user may legally use the software without a license from the software publisher.
As many proprietary "licenses" only enumerate the rights that the user already has under 17
U.S.C. § 117, and yet proclaim to take rights away from the user, these contracts may
lackconsideration. Proprietary software licenses often proclaim to give software publishers more
control over the way their software is used by keeping ownership of each copy of software with the
software publisher. By doing so, Section 117 does not apply to the end-user and the software
publisher may then compel the end-user to accept all of the terms of the license agreement, many of
which may be more restrictive than copyright law alone. It should be noticed that the form of the
relationship determines if it is a lease or a purchase, for example UMG v. Augusto,[1] Vernor v.
Autodesk, Inc..[2][3]
How to License Software
When developers sell software they are actually not selling the software, they are selling a license that
allows the user to use the software. Software licensing can take a number of different forms. Software can
be licensed based on the number of computers that the software is loaded on or, as is common with
network software the software can be licensed based on the number of users accessing the application.
EULA = End User License Agreement
Most applications require users to agree to the EULA terms during the installation process. The EULA limits
the developers liability and explains how the software is licensed.
Single License - A single user license is generally defined as a software license that can only be installed
on a single system.
Per Computer - One license for each computer the software is loaded on.
Per User - Allows users to use software on "home" and "work" computers.
Multi-User License - A multi-user license means that the license can be installed on multiple systems or
possibly a network.
Site License - All computers at a single physical location are licensed to run the software. Site licenses are
popular with corporations and schools.
Enterprise Site License - All computers within all offices of a company or school. Enterprise site license
cover multiple locations or satellite offices of a company.
Considerations When Licensing
These issues could come up, so make sure you know how you want to handle them before they do.
1. Some developers expand a single user license to include a secondary system, like a notebook. For your
software users will require a second license, if so is there a discount?
2. Can a single license be used on different computers if they are not used simultaneously? This is a
"backup" installation for redundancy. Do customers need to purchase a second backup license.
3. If you have both a Windows and Mac version, can the purchaser use their license in the opposite
operating system than the one that they purchased?
4. Is the license transferable or assignable? If the company is sold are the software licenses transferable to
the new owners and computers? If a user no longer uses the software can they sell their license on ebay?
Sample EULA
EULA stands for End User Licensing Agreement. This is the agreement through which the software is
licensed to the software user.
Sample EULA
END-USER LICENSE AGREEMENT FOR {INSERT PRODUCT NAME} IMPORTANT PLEASE READ THE TERMS
AND CONDITIONS OF THIS LICENSE AGREEMENT CAREFULLY BEFORE CONTINUING WITH THIS PROGRAM
INSTALL: {INSERT COMPANY NAME's } End-User License Agreement ("EULA") is a legal agreement between
you (either an individual or a single entity) and {INSERT COMPANY NAME}. for the {INSERT COMPANY
NAME} software product(s) identified above which may include associated software components, media,
printed materials, and "online" or electronic documentation ("SOFTWARE PRODUCT"). By installing, copying,
or otherwise using the SOFTWARE PRODUCT, you agree to be bound by the terms of this EULA. This license
agreement represents the entire agreement concerning the program between you and {INSERT COMPANY
NAME}, (referred to as "licenser"), and it supersedes any prior proposal, representation, or understanding
between the parties. If you do not agree to the terms of this EULA, do not install or use the SOFTWARE
PRODUCT.
The SOFTWARE PRODUCT is protected by copyright laws and international copyright treaties, as well as
other intellectual property laws and treaties. The SOFTWARE PRODUCT is licensed, not sold.
1. GRANT OF LICENSE.
The SOFTWARE PRODUCT is licensed as follows:
(a) Installation and Use.
{INSERT COMPANY NAME} grants you the right to install and use copies of the SOFTWARE PRODUCT on
your computer running a validly licensed copy of the operating system for which the SOFTWARE PRODUCT
was designed [e.g., Windows 95, Windows NT, Windows 98, Windows 2000, Windows 2003, Windows XP,
Windows ME, Windows Vista].
(b) Backup Copies.
You may also make copies of the SOFTWARE PRODUCT as may be necessary for backup and archival
purposes.
2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.
(a) Maintenance of Copyright Notices.
You must not remove or alter any copyright notices on any and all copies of the SOFTWARE PRODUCT.
(b) Distribution.
You may not distribute registered copies of the SOFTWARE PRODUCT to third parties. Evaluation versions
available for download from {INSERT COMPANY NAME}'s websites may be freely distributed.
(c) Prohibition on Reverse Engineering, Decompilation, and Disassembly.
You may not reverse engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and only to the
extent that such activity is expressly permitted by applicable law notwithstanding this limitation.
(d) Rental.
You may not rent, lease, or lend the SOFTWARE PRODUCT.
(e) Support Services.
{INSERT COMPANY NAME} may provide you with support services related to the SOFTWARE PRODUCT
("Support Services"). Any supplemental software code provided to you as part of the Support Services shall
be considered part of the SOFTWARE PRODUCT and subject to the terms and conditions of this EULA.
(f) Compliance with Applicable Laws.
You must comply with all applicable laws regarding use of the SOFTWARE PRODUCT.
3. TERMINATION
Without prejudice to any other rights, {INSERT COMPANY NAME} may terminate this EULA if you fail to
comply with the terms and conditions of this EULA. In such event, you must destroy all copies of the
SOFTWARE PRODUCT in your possession.
4. COPYRIGHT
All title, including but not limited to copyrights, in and to the SOFTWARE PRODUCT and any copies thereof
are owned by {INSERT COMPANY NAME} or its suppliers. All title and intellectual property rights in and to
the content which may be accessed through use of the SOFTWARE PRODUCT is the property of the
respective content owner and may be protected by applicable copyright or other intellectual property laws
and treaties. This EULA grants you no rights to use such content. All rights not expressly granted are
reserved by {INSERT COMPANY NAME}.
5. NO WARRANTIES
{INSERT COMPANY NAME} expressly disclaims any warranty for the SOFTWARE PRODUCT. The SOFTWARE
PRODUCT is provided 'As Is' without any express or implied warranty of any kind, including but not limited to
any warranties of merchantability, noninfringement, or fitness of a particular purpose. {INSERT COMPANY
NAME} does not warrant or assume responsibility for the accuracy or completeness of any information, text,
graphics, links or other items contained within the SOFTWARE PRODUCT. {INSERT COMPANY NAME} makes
no warranties respecting any harm that may be caused by the transmission of a computer virus, worm, time
bomb, logic bomb, or other such computer program. {INSERT COMPANY NAME} further expressly disclaims
any warranty or representation to Authorized Users or to any third party.
6. LIMITATION OF LIABILITY
In no event shall {INSERT COMPANY NAME} be liable for any damages (including, without limitation, lost
profits, business interruption, or lost information) rising out of 'Authorized Users' use of or inability to use the
SOFTWARE PRODUCT, even if {INSERT COMPANY NAME} has been advised of the possibility of such
damages. In no event will {INSERT COMPANY NAME} be liable for loss of data or for indirect, special,
incidental, consequential (including lost profit), or other damages based in contract, tort or otherwise.
{INSERT COMPANY NAME} shall have no liability with respect to the content of the SOFTWARE PRODUCT or
any part thereof, including but not limited to errors or omissions contained therein, libel, infringements of
rights of publicity, privacy, trademark rights, business interruption, personal injury, loss of privacy, moral
rights or the disclosure of confidential information.
Developers are responsible for the content of their EULA and this should only be used as a
guide.
What is software piracy?
There are several kinds of software piracy. The bottom line is when software is pirated, the developer does not
receive compensation for their work.
Effects of Software Piracy
When software is pirated, consumers, software developers, and resellers are harmed. Software piracy increases
the risk consumer’s computers will be corrupted by defective software and infected with viruses. Those who
provide defective and illegal software do not tend to provide sales and technical support. Pirated software usually
has inadequate documentation, which prevents consumers from enjoying the full benefits of the software package.
In addition, consumers are unable to take advantage of technical support and product upgrades, which are
typically available to legitimate registered users of the software. Pirated software can cost consumers lost time and
more money.
Developers lose revenue from pirated software, from current products as well as from future programs. When
software is sold most developers invest a portion of the revenue into future development and better software
packages. When software is pirated, software developers lose revenue from the sale of their products, which
hinders development of new software and stifles the growth of the software company.
Kinds of Piracy
End User Piracy Using multiple copies of a single software package on several different systems or distributing registered or
licensed copies of software to others. Another common form of end user piracy is when a cracked version of the
software is used. Hacking into the software and disabling the copy protection, or illegally generating key codes
that unlocks the trial version making the software a registered version creates a cracked version.
Reseller Piracy Reseller piracy occurs when an unscrupulous reseller distributes multiple copies of a single software package to
different customers; this includes preloading systems with software without providing original manuals & diskettes.
Reseller piracy also occurs when resellers knowingly sell counterfeit versions of software to unsuspecting
customers.
Indications of reseller piracy are multiple users with the same serial number, lack of original documentation or an
incomplete set, and non-matching documentation.
Trademark/Trade Name Infringement
Infringement occurs when an individual or dealer claims to be authorized either as a technician, support provider
or reseller, or is improperly using a trademark or trade name.
BBS/Internet Piracy –
BBS/ Internet Piracy occurs when there is an electronic transfer of copyrighted software. If system operators
and/or users upload or download copyrighted software and materials onto or from bulletin boards or the Internet
for others to copy and use without the proper license. Often hackers will distribute or sell the hacked software or
cracked keys. The developer does not receive any money for the software the hacker distributed. This is an
infringement on the developer’s copyright.
Another technique used by software pirates is to illegally obtain a registered copy of software. Pirates purchase
the software once and use it on multiple computers. Purchasing software with a stolen credit card is another form
of software piracy. Unfortunately there are many kinds of software piracy that has hampered the software
industry.
These types of software piracy have hampered the software industry. For the software industry to prosper and
further develop useful software for consumers please support and pay for software. This results in better software
for all.
Software Testing
Carnegie Mellon University
18-849b Dependable Embedded Systems
Spring 1999
Authors: Jiantao Pan
[email protected]
Abstract:
Software testing is any activity aimed at evaluating an attribute or capability of
a program or system and determining that it meets its required
results. [Hetzel88] Although crucial to software quality and widely deployed by
programmers and testers, software testing still remains an art, due to limited
understanding of the principles of software. The difficulty in software testing
stems from the complexity of software: we can not completely test a program
with moderate complexity. Testing is more than just debugging. The purpose of
testing can be quality assurance, verification and validation, or reliability
estimation. Testing can be used as a generic metric as well. Correctness testing
and reliability testing are two major areas of testing. Software testing is a tradeoff between budget, time and quality.
Contents:










Introduction
Key Concepts
Taxonomy
Testing automation
When to stop testing?
Alternatives to testing
Available tools, techniques, and metrics
Relationship to other topics
Conclusions
Annotated Reference List & Further Reading
Introduction
Software Testing is the process of executing a program or system with the
intent of finding errors. [Myers79] Or, it involves any activity aimed at
evaluating an attribute or capability of a program or system and determining
that it meets its required results. [Hetzel88] Software is not unlike other
physical processes where inputs are received and outputs are produced. Where
software differs is in the manner in which it fails. Most physical systems fail in
a fixed (and reasonably small) set of ways. By contrast, software can fail in
many bizarre ways. Detecting all of the different failure modes for software is
generally infeasible. [Rstcorp]
Unlike most physical systems, most of the defects in software are design errors,
not manufacturing defects. Software does not suffer from corrosion, wear-andtear -- generally it will not change until upgrades, or until obsolescence. So
once the software is shipped, the design defects -- or bugs -- will be buried in
and remain latent until activation.
Software bugs will almost always exist in any software module with moderate
size: not because programmers are careless or irresponsible, but because the
complexity of software is generally intractable -- and humans have only limited
ability to manage complexity. It is also true that for any complex systems,
design defects can never be completely ruled out.
Discovering the design defects in software, is equally difficult, for the same
reason of complexity. Because software and any digital systems are not
continuous, testing boundary values are not sufficient to guarantee correctness.
All the possible values need to be tested and verified, but complete testing is
infeasible. Exhaustively testing a simple program to add only two integer inputs
of 32-bits (yielding 2^64 distinct test cases) would take hundreds of years, even
if tests were performed at a rate of thousands per second. Obviously, for a
realistic software module, the complexity can be far beyond the example
mentioned here. If inputs from the real world are involved, the problem will get
worse, because timing and unpredictable environmental effects and human
interactions are all possible input parameters under consideration.
A further complication has to do with the dynamic nature of programs. If a
failure occurs during preliminary testing and the code is changed, the software
may now work for a test case that it didn't work for previously. But its behavior
on pre-error test cases that it passed before can no longer be guaranteed. To
account for this possibility, testing should be restarted. The expense of doing
this is often prohibitive. [Rstcorp]
An interesting analogy parallels the difficulty in software testing with the
pesticide, known as the Pesticide Paradox [Beizer90]: Every method you use to
prevent or find bugs leaves a residue of subtler bugs against which those
methods are ineffectual. But this alone will not guarantee to make the software
better, because the Complexity Barrier [Beizer90] principle states: Software
complexity(and therefore that of bugs) grows to the limits of our ability to
manage that complexity. By eliminating the (previous) easy bugs you allowed
another escalation of features and complexity, but his time you have subtler
bugs to face, just to retain the reliability you had before. Society seems to be
unwilling to limit complexity because we all want that extra bell, whistle, and
feature interaction. Thus, our users always push us to the complexity barrier
and how close we can approach that barrier is largely determined by the
strength of the techniques we can wield against ever more complex and subtle
bugs. [Beizer90]
Regardless of the limitations, testing is an integral part in software
development. It is broadly deployed in every phase in the software
development cycle. Typically, more than 50% percent of the development time
is spent in testing. Testing is usually performed for the following purposes:

To improve quality.
As computers and software are used in critical applications, the outcome of a
bug can be severe. Bugs can cause huge losses. Bugs in critical systems have
caused airplane crashes, allowed space shuttle missions to go awry, halted
trading on the stock market, and worse. Bugs can kill. Bugs can cause disasters.
The so-called year 2000 (Y2K) bug has given birth to a cottage industry of
consultants and programming tools dedicated to making sure the modern world
doesn't come to a screeching halt on the first day of the next century. [Bugs] In
a computerized embedded world, the quality and reliability of software is a
matter of life and death.
Quality means the conformance to the specified design requirement. Being
correct, the minimum requirement of quality, means performing as required
under specified circumstances. Debugging, a narrow view of software testing,
is performed heavily to find out design defects by the programmer. The
imperfection of human nature makes it almost impossible to make a moderately
complex program correct the first time. Finding the problems and get them
fixed [Kaner93], is the purpose of debugging in programming phase.

For Verification & Validation (V&V)
Just as topic Verification and Validation indicated, another important purpose
of testing is verification and validation (V&V). Testing can serve as metrics. It
is heavily used as a tool in the V&V process. Testers can make claims based on
interpretations of the testing results, which either the product works under
certain situations, or it does not work. We can also compare the quality among
different products under the same specification, based on results from the same
test.
We can not test quality directly, but we can test related factors to make quality
visible. Quality has three sets of factors -- functionality, engineering, and
adaptability. These three sets of factors can be thought of as dimensions in the
software quality space. Each dimension may be broken down into its
component factors and considerations at successively lower levels of detail.
Table 1 illustrates some of the most frequently cited quality considerations.
Functionality
Engineering (interior Adaptability (future
(exterior quality)
quality)
quality)
Correctness
Efficiency
Flexibility
Reliability
Testability
Reusability
Usability
Documentation
Maintainability
Integrity
Structure
Table 1. Typical Software Quality Factors [Hetzel88]
Good testing provides measures for all relevant factors. The importance of any
particular factor varies from application to application. Any system where
human lives are at stake must place extreme emphasis on reliability and
integrity. In the typical business system usability and maintainability are the
key factors, while for a one-time scientific program neither may be significant.
Our testing, to be fully effective, must be geared to measuring each relevant
factor and thus forcing quality to become tangible and visible. [Hetzel88]
Tests with the purpose of validating the product works are named clean tests, or
positive tests. The drawbacks are that it can only validate that the software
works for the specified test cases. A finite number of tests can not validate that
the software works for all situations. On the contrary, only one failed test is
sufficient enough to show that the software does not work. Dirty tests, or
negative tests, refers to the tests aiming at breaking the software, or showing
that it does not work. A piece of software must have sufficient exception
handling capabilities to survive a significant level of dirty tests.
A testable design is a design that can be easily validated, falsified and
maintained. Because testing is a rigorous effort and requires significant time
and cost, design for testability is also an important design rule for software
development.

For reliability estimation [Kaner93] [Lyu95]
Software reliability has important relations with many aspects of software,
including the structure, and the amount of testing it has been subjected to.
Based on an operational profile (an estimate of the relative frequency of use of
various inputs to the program [Lyu95]), testing can serve as a statistical
sampling method to gain failure data for reliability estimation.
Software testing is not mature. It still remains an art, because we still cannot
make it a science. We are still using the same testing techniques invented 20-30
years ago, some of which are crafted methods or heuristics rather than good
engineering methods. Software testing can be costly, but not testing software is
even more expensive, especially in places that human lives are at stake. Solving
the software-testing problem is no easier than solving the Turing halting
problem. We can never be sure that a piece of software is correct. We can never
be sure that the specifications are correct. No verification system can verify
every correct program. We can never be certain that a verification system is
correct either.
Key Concepts
Taxonomy
There is a plethora of testing methods and testing techniques, serving multiple
purposes in different life cycle phases. Classified by purpose, software testing
can be divided into: correctness testing, performance testing, reliability testing
and security testing. Classified by life-cycle phase, software testing can be
classified into the following categories: requirements phase testing, design
phase testing, program phase testing, evaluating test results, installation phase
testing, acceptance testing and maintenance testing. By scope, software testing
can be categorized as follows: unit testing, component testing, integration
testing, and system testing.
Correctness testing
Correctness is the minimum requirement of software, the essential purpose of
testing. Correctness testing will need some type of oracle, to tell the right
behavior from the wrong one. The tester may or may not know the inside
details of the software module under test, e.g. control flow, data flow, etc.
Therefore, either a white-box point of view or black-box point of view can be
taken in testing software. We must note that the black-box and white-box ideas
are not limited in correctness testing only.

Black-box testing
The black-box approach is a testing method in which test data are derived from
the specified functional requirements without regard to the final program
structure. [Perry90] It is also termed data-driven, input/output driven[Myers79],
or requirements-based [Hetzel88] testing. Because only the functionality of the
software module is of concern, black-box testing also mainly refers to
functional testing -- a testing method emphasized on executing the functions
and examination of their input and output data. [Howden87] The tester treats
the software under test as a black box -- only the inputs, outputs and
specification are visible, and the functionality is determined by observing the
outputs to corresponding inputs. In testing, various inputs are exercised and the
outputs are compared against specification to validate the correctness. All test
cases are derived from the specification. No implementation details of the code
are considered.
It is obvious that the more we have covered in the input space, the more
problems we will find and therefore we will be more confident about the
quality of the software. Ideally we would be tempted to exhaustively test the
input space. But as stated above, exhaustively testing the combinations of valid
inputs will be impossible for most of the programs, let alone considering
invalid inputs, timing, sequence, and resource variables. Combinatorial
explosion is the major roadblock in functional testing. To make things worse,
we can never be sure whether the specification is either correct or complete.
Due to limitations of the language used in the specifications (usually natural
language), ambiguity is often inevitable. Even if we use some type of formal or
restricted language, we may still fail to write down all the possible cases in the
specification. Sometimes, the specification itself becomes an intractable
problem: it is not possible to specify precisely every situation that can be
encountered using limited words. And people can seldom specify clearly what
they want -- they usually can tell whether a prototype is, or is not, what they
want after they have been finished. Specification problems contributes
approximately 30 percent of all bugs in software. [Beizer95]
The research in black-box testing mainly focuses on how to maximize the
effectiveness of testing with minimum cost, usually the number of test cases. It
is not possible to exhaust the input space, but it is possible to exhaustively test a
subset of the input space. Partitioning is one of the common techniques. If we
have partitioned the input space and assume all the input values in a partition is
equivalent, then we only need to test one representative value in each partition
to sufficiently cover the whole input space. Domain
testing [Beizer95] partitions the input domain into regions, and consider the
input values in each domain an equivalent class. Domains can be exhaustively
tested and covered by selecting a representative value(s) in each domain.
Boundary values are of special interest. Experience shows that test cases that
explore boundary conditions have a higher payoff than test cases that do not.
Boundary value analysis [Myers79] requires one or more boundary values
selected as representative test cases. The difficulties with domain testing are
that incorrect domain definitions in the specification can not be efficiently
discovered.
Good partitioning requires knowledge of the software structure. A good testing
plan will not only contain black-box testing, but also white-box approaches,
and combinations of the two.

White-box testing
Contrary to black-box testing, software is viewed as a white-box, or glass-box
in white-box testing, as the structure and flow of the software under test are
visible to the tester. Testing plans are made according to the details of the
software implementation, such as programming language, logic, and styles.
Test cases are derived from the program structure. White-box testing is also
called glass-box testing, logic-driven testing [Myers79]or design-based
testing [Hetzel88].
There are many techniques available in white-box testing, because the problem
of intractability is eased by specific knowledge and attention on the structure of
the software under test. The intention of exhausting some aspect of the software
is still strong in white-box testing, and some degree of exhaustion can be
achieved, such as executing each line of code at least once (statement
coverage), traverse every branch statements (branch coverage), or cover all the
possible combinations of true and false condition predicates (Multiple
condition coverage). [Parrington89]
Control-flow testing, loop testing, and data-flow testing, all maps the
corresponding flow structure of the software into a directed graph. Test cases
are carefully selected based on the criterion that all the nodes or paths are
covered or traversed at least once. By doing so we may discover unnecessary
"dead" code -- code that is of no use, or never get executed at all, which can not
be discovered by functional testing.
In mutation testing, the original program code is perturbed and many mutated
programs are created, each contains one fault. Each faulty version of the
program is called a mutant. Test data are selected based on the effectiveness of
failing the mutants. The more mutants a test case can kill, the better the test
case is considered. The problem with mutation testing is that it is too
computationally expensive to use. The boundary between black-box approach
and white-box approach is not clear-cut. Many testing strategies mentioned
above, may not be safely classified into black-box testing or white-box testing.
It is also true for transaction-flow testing, syntax testing, finite-state testing, and
many other testing strategies not discussed in this text. One reason is that all the
above techniques will need some knowledge of the specification of the
software under test. Another reason is that the idea of specification itself is
broad -- it may contain any requirement including the structure, programming
language, and programming style as part of the specification content.
We may be reluctant to consider random testing as a testing technique. The test
case selection is simple and straightforward: they are randomly chosen. Study
in [Duran84] indicates that random testing is more cost effective for many
programs. Some very subtle errors can be discovered with low cost. And it is
also not inferior in coverage than other carefully designed testing techniques.
One can also obtain reliability estimate using random testing results based on
operational profiles. Effectively combining random testing with other testing
techniques may yield more powerful and cost-effective testing strategies.
Performance testing
Not all software systems have specifications on performance explicitly. But
every system will have implicit performance requirements. The software should
not take infinite time or infinite resource to execute. "Performance bugs"
sometimes are used to refer to those design problems in software that cause the
system performance to degrade.
Performance has always been a great concern and a driving force of computer
evolution. Performance evaluation of a software system usually includes:
resource usage, throughput, stimulus-response time and queue lengths detailing
the average or maximum number of tasks waiting to be serviced by selected
resources. Typical resources that need to be considered include network
bandwidth requirements, CPU cycles, disk space, disk access operations, and
memory usage [Smith90]. The goal of performance testing can be performance
bottleneck identification, performance comparison and evaluation, etc. The
typical method of doing performance testing is using a benchmark -- a
program, workload or trace designed to be representative of the typical system
usage. [Vokolos98]
Reliability testing
Software reliability refers to the probability of failure-free operation of a
system. It is related to many aspects of software, including the testing process.
Directly estimating software reliability by quantifying its related factors can be
difficult. Testing is an effective sampling method to measure software
reliability. Guided by the operational profile, software testing (usually blackbox testing) can be used to obtain failure data, and an estimation model can be
further used to analyze the data to estimate the present reliability and predict
future reliability. Therefore, based on the estimation, the developers can decide
whether to release the software, and the users can decide whether to adopt and
use the software. Risk of using software can also be assessed based on
reliability information. [Hamlet94] advocates that the primary goal of testing
should be to measure the dependability of tested software.
There is agreement on the intuitive meaning of dependable software: it does not
fail in unexpected or catastrophic ways. [Hamlet94] Robustness testing and
stress testing are variances of reliability testing based on this simple criterion.
The robustness of a software component is the degree to which it can function
correctly in the presence of exceptional inputs or stressful environmental
conditions. [IEEE90] Robustness testing differs with correctness testing in the
sense that the functional correctness of the software is not of concern. It only
watches for robustness problems such as machine crashes, process hangs or
abnormal termination. The oracle is relatively simple, therefore robustness
testing can be made more portable and scalable than correctness testing. This
research has drawn more and more interests recently, most of which uses
commercial operating systems as their target, such as the work in [Koopman97]
[Kropp98] [Ghosh98] [Devale99] [Koopman99].
Stress testing, or load testing, is often used to test the whole system rather than
the software alone. In such tests the software or system are exercised with or
beyond the specified limits. Typical stress includes resource exhaustion, bursts
of activities, and sustained high loads.
Security testing
Software quality, reliability and security are tightly coupled. Flaws in software
can be exploited by intruders to open security holes. With the development of
the Internet, software security problems are becoming even more severe.
Many critical software applications and services have integrated security
measures against malicious attacks. The purpose of security testing of these
systems include identifying and removing software flaws that may potentially
lead to security violations, and validating the effectiveness of security
measures. Simulated security attacks can be performed to find vulnerabilities.
Testing automation
Software testing can be very costly. Automation is a good way to cut down
time and cost. Software testing tools and techniques usually suffer from a lack
of generic applicability and scalability. The reason is straight-forward. In order
to automate the process, we have to have some ways to generate oracles from
the specification, and generate test cases to test the target software against the
oracles to decide their correctness. Today we still don't have a full-scale system
that has achieved this goal. In general, significant amount of human
intervention is still needed in testing. The degree of automation remains at the
automated test script level.
The problem is lessened in reliability testing and performance testing. In
robustness testing, the simple specification and oracle: doesn't crash, doesn't
hang suffices. Similar simple metrics can also be used in stress testing.
When to stop testing?
Testing is potentially endless. We can not test till all the defects are unearthed
and removed -- it is simply impossible. At some point, we have to stop testing
and ship the software. The question is when.
Realistically, testing is a trade-off between budget, time and quality. It is driven
by profit models. The pessimistic, and unfortunately most often used approach
is to stop testing whenever some, or any of the allocated resources -- time,
budget, or test cases -- are exhausted. The optimistic stopping rule is to stop
testing when either reliability meets the requirement, or the benefit from
continuing testing cannot justify the testing cost.[Yang95] This will usually
require the use of reliability models to evaluate and predict reliability of the
software under test. Each evaluation requires repeated running of the following
cycle: failure data gathering -- modeling -- prediction. This method does not fit
well for ultra-dependable systems, however, because the real field failure data
will take too long to accumulate.
Alternatives to testing
Software testing is more and more considered a problematic method toward
better quality. Using testing to locate and correct software defects can be an
endless process. Bugs cannot be completely ruled out. Just as the complexity
barrier indicates: chances are testing and fixing problems may not necessarily
improve the quality and reliability of the software. Sometimes fixing a problem
may introduce much more severe problems into the system, happened after bug
fixes, such as the telephone outage in California and eastern seaboard in 1991.
The disaster happened after changing 3 lines of code in the signaling system.
In a narrower view, many testing techniques may have flaws. Coverage testing,
for example. Is code coverage, branch coverage in testing really related to
software quality? There is no definite proof. As early as in[Myers79], the socalled "human testing" -- including inspections, walkthroughs, reviews -- are
suggested as possible alternatives to traditional testing
methods. [Hamlet94] advocates inspection as a cost-effect alternative to unit
testing. The experimental results in [Basili85] suggests that code reading by
stepwise abstraction is at least as effective as on-line functional and structural
testing in terms of number and cost of faults observed.
Using formal methods to "prove" the correctness of software is also an
attracting research direction. But this method can not surmount the complexity
barrier either. For relatively simple software, this method works well. It does
not scale well to those complex, full-fledged large software systems, which are
more error-prone.
In a broader view, we may start to question the utmost purpose of testing. Why
do we need more effective testing methods anyway, since finding defects and
removing them does not necessarily lead to better quality. An analogy of the
problem is like the car manufacturing process. In the craftsmanship epoch, we
make cars and hack away the problems and defects. But such methods were
washed away by the tide of pipelined manufacturing and good quality
engineering process, which makes the car defect-free in the manufacturing
phase. This indicates that engineering the design process (such as clean-room
software engineering) to make the product have less defects may be more
effective than engineering the testing process. Testing is used solely for quality
monitoring and management, or, "design for testability". This is the leap for
software from craftsmanship to engineering.
Available tools, techniques, and metrics
There are an abundance of software testing tools exist. The correctness testing
tools are often specialized to certain systems and have limited ability and
generality. Robustness and stress testing tools are more likely to be made
generic.
Mothora [DeMillo91] is an automated mutation testing tool-set developed at
Purdue University. Using Mothora, the tester can create and execute test cases,
measure test case adequacy, determine input-output correctness, locate and
remove faults or bugs, and control and document the test.
NuMega's Boundschecker [NuMega99] Rational's Purify [Rational99]. They
are run-time checking and debugging aids. They can both check and protect
against memory leaks and pointer problems.
Ballista COTS Software Robustness Testing Harness [Ballista99]. The Ballista
testing harness is an full-scale automated robustness testing tool. The first
version supports testing up to 233 POSIX function calls in UNIX operating
systems. The second version also supports testing of user functions provided
that the data types are recognized by the testing server. The Ballista testing
harness gives quantitative measures of robustness comparisons across operating
systems. The goal is to automatically test and harden Commercial Off-TheShelf (COTS) software against robustness failures.
Software Installation/Uninstallation Testing
August 30th, 2007 — Automation Testing, Installation Testing, Types of testing
Have you performed software installation testing? How was the experience? Well,
Installation testing (Implementation Testing) is quite interesting part of software
testing life cycle.
Installation testing is like introducing a guest in your home. The new guest should be
properly introduced to all the family members in order to feel him comfortable.
Installation of new software is also quite like above example.
If your installation is successful on the new system then customer will be
definitely happy but what if things are completely opposite. If installation fails
then our program will not work on that system not only this but can leave user’s
system badly damaged. User might require to reinstall the full operating system.
In above case will you make any impression on user? Definitely not! Your first
impression to make a loyal customer is ruined due to incomplete installation
testing. What you need to do for a good first impression? Test the installer
appropriately with combination of both manual and automated processes on
different machines with different configuration. Major concerned of installation
testing is Time! It requires lot of time to even execute a single test case. If you are
going to test a big application installer then think about time required to perform
such a many test cases on different configurations.
We will see different methods to perform manual installer testing and some
basic guideline for automating the installation process.
To start installation testing first decide on how many different system configurations
you want to test the installation. Prepare one basic hard disk drive. Format this HDD
with most common or default file system, install most common operating system
(Windows) on this HDD. Install some basic required components on this HDD. Each
time create images of this base HDD and you can create other configurations on this
base drive. Make one set of each configuration like Operating system and file format
to be used for further testing.
How we can use automation in this process? Well make some systems dedicated for
creating basic images (use software’s like Norton Ghost for creating exact images of
operating system quickly) of base configuration. This will save your tremendous time
in each test case. For example if time to install one OS with basic configuration is say
1 hour then for each test case on fresh OS you will require 1+ hour. But creating
image of OS will hardly require 5 to 10 minutes and you will save approximately 40
to 50 minutes!
You can use one operating system with multiple attempts of installation of installer.
Each time uninstalling the application and preparing the base state for next test
case. Be careful here that your uninstallation program should be tested before and
should be working fine.
Installation testing tips with some broad
test cases:
1) Use flow diagrams to perform
installation testing. Flow diagrams simplify
our task. See example flow diagram for basic
installation testing test case.
Add some more test cases on this basic flow
chart Such as if our application is not the first
release then try to add different logical
installation paths.
2) If you have previously installed compact
basic version of application then in next test
case install the full application version on
the same path as used for compact version.
3) If you are using flow diagram to test
different files to be written on disk while
installation then use the same flow diagram
in reverse order to test uninstallation of all the installed files on disk.
4) Use flow diagrams toautomate the testing efforts. It will be very easy to
convert diagrams into automated scripts.
5) Test the installer scripts used for checking the required disk space. If installer is
prompting required disk space 1MB, then make sure exactly 1MB is used or whether
more disk space utilized during installation. If yes flag this as error.
6) Test disk space requirement on different file system format. Like FAT16 will
require more space than efficient NTFS or FAT32 file systems.
7) If possible set a dedicated system for only creating disk images. As said above
this will save your testing time.
8 ) Use distributed testing environment in order to carry out installation testing.
Distributed environment simply save your time and you can effectively manage all
the different test cases from a single machine. The good approach for this is to
create a master machine, which will drive different slave machines on network. You
can start installation simultaneously on different machine from the master system.
9) Try to automate the routine to test the number of files to be written on disk. You
can maintain this file list to be written on disk in and excel sheet and can give this
list as a input to automated script that will check each and every path to verify the
correct installation.
10) Use software’s available freely in market to verify registry changes on
successful installation. Verify the registry changes with your expected change list
after installation.
11) Forcefully break the installation process in between. See the behavior of
system and whether system recovers to its original state without any issues. You can
test this “break of installation” on every installation step.
12) Disk space checking: This is the crucial checking in the installation-testing
scenario. You can choose different manual and automated methods to do this
checking. In manual methods you can check free disk space available on drive before
installation and disk space reported by installer script to check whether installer is
calculating and reporting disk space accurately. Check the disk space after the
installation to verify accurate usage of installation disk space. Run various
combination of disk space availability by using some tools to automatically making
disk space full while installation. Check system behavior on low disk space conditions
while installation.
13) As you check installation you can test for uninstallation also. Before each new
iteration of installation make sure that all the files written to disk are removed after
uninstallation. Some times uninstallation routine removes files from only last
upgraded installation keeping the old version files untouched. Also check for
rebooting option after uninstallation manually and forcefully not to reboot.
I have addressed many areas of manual as well as automated installation
testing procedure. Still there are many areas you need to focus on depending on
the complexity of your software under installation. These not addressed important
tasks includesinstallation over the network, online installation, patch
installation, Database checking on Installation, Shared DLL installation and
uninstallation etc.
Pre-installation Tasks
2.3.1 Inventory Your Computer
Before installing FreeBSD you should attempt to inventory the components in
your computer. The FreeBSD installation routines will show you the
components (hard disks, network cards, CDROM drives, and so forth) with
their model number and manufacturer. FreeBSD will also attempt to determine
the correct configuration for these devices, which includes information about
IRQ and IO port usage. Due to the vagaries of PC hardware this process is not
always completely successful, and you may need to correct FreeBSD's
determination of your configuration.
If you already have another operating system installed, such as Windows® or
Linux, it is a good idea to use the facilities provided by those operating systems
to see how your hardware is already configured. If you are not sure what
settings an expansion card is using, you may find it printed on the card itself.
Popular IRQ numbers are 3, 5, and 7, and IO port addresses are normally
written as hexadecimal numbers, such as 0x330.
We recommend you print or write down this information before installing
FreeBSD. It may help to use a table, like this:
Table 2-1. Sample Device Inventory
Device Name
IRQ IO port(s)
Notes
Device Name
First hard disk
CDROM
Second hard disk
First IDE controller
Network card
Modem
...
IRQ
N/A
N/A
N/A
14
N/A
N/A
IO port(s)
N/A
N/A
N/A
0x1f0
N/A
N/A
Notes
40 GB, made by Seagate, first IDE master
First IDE slave
20 GB, made by IBM, second IDE master
Intel® 10/100
3Com® 56K faxmodem, on COM1
Once the inventory of the components in your computer is done, you have to
check if they match the hardware requirements of the FreeBSD release you
want to install.
2.3.2 Backup Your Data
If the computer you will be installing FreeBSD on contains valuable data, then
ensure you have it backed up, and that you have tested the backups before
installing FreeBSD. The FreeBSD installation routine will prompt you before
writing any data to your disk, but once that process has started it cannot be
undone.
2.3.3 Decide Where to Install FreeBSD
If you want FreeBSD to use your entire hard disk, then there is nothing more to
concern yourself with at this point -- you can skip this section.
However, if you need FreeBSD to co-exist with other operating systems then
you need to have a rough understanding of how data is laid out on the disk, and
how this affects you.
2.3.3.1 Disk Layouts for FreeBSD/i386
A PC disk can be divided into discrete chunks. These chunks are
called partitions. Since FreeBSD internally also has partitions, the naming can
become confusing very quickly, therefore these disk chunks are referred to as
disk slices or simply slices in FreeBSD itself. For example, the FreeBSD
utility fdisk which operates on the PC disk partitions, refers to slices instead of
partitions. By design, the PC only supports four partitions per disk. These
partitions are called primary partitions. To work around this limitation and
allow more than four partitions, a new partition type was created, the extended
partition. A disk may contain only one extended partition. Special partitions,
called logical partitions, can be created inside this extended partition.
Each partition has a partition ID, which is a number used to identify the type of
data on the partition. FreeBSD partitions have the partition ID of 165.
In general, each operating system that you use will identify partitions in a
particular way. For example, DOS, and its descendants, like Windows, assign
each primary and logical partition a drive letter, starting with C:.
FreeBSD must be installed into a primary partition. FreeBSD can keep all its
data, including any files that you create, on this one partition. However, if you
have multiple disks, then you can create a FreeBSD partition on all, or some, of
them. When you install FreeBSD, you must have one partition available. This
might be a blank partition that you have prepared, or it might be an existing
partition that contains data that you no longer care about.
If you are already using all the partitions on all your disks, then you will have
to free one of them for FreeBSD using the tools provided by the other operating
systems you use (e.g.,fdisk on DOS or Windows).
If you have a spare partition then you can use that. However, you may need to
shrink one or more of your existing partitions first.
A minimal installation of FreeBSD takes as little as 100 MB of disk space.
However, that is a very minimal install, leaving almost no space for your own
files. A more realistic minimum is 250 MB without a graphical environment,
and 350 MB or more if you want a graphical user interface. If you intend to
install a lot of third-party software as well, then you will need more space.
You can use a commercial tool such as PartitionMagic®, or a free tool such
as GParted, to resize your partitions and make space for FreeBSD.
Both PartitionMagic and GPartedare known to work on NTFS. GParted is
available on a number of Live CD Linux distributions, such
as SystemRescueCD.
Problems have been reported resizing Microsoft® Vista partitions. Having a
Vista installation CDROM handy when attempting such an operation is
recommended. As with all such disk maintenance tasks, a current set of
backups is also strongly advised.
Warning: Incorrect use of these tools can delete the data on your disk. Be sure
that you have recent, working backups before using them.
Example 2-1. Using an Existing Partition Unchanged
Suppose that you have a computer with a single 4 GB disk that already has a
version of Windows installed, and you have split the disk into two drive
letters, C: andD:, each of which is 2 GB in size. You have 1 GB of data on C:,
and 0.5 GB of data on D:.
This means that your disk has two partitions on it, one per drive letter. You can
copy all your existing data from D: to C:, which will free up the second
partition, ready for FreeBSD.
Example 2-2. Shrinking an Existing Partition
Suppose that you have a computer with a single 4 GB disk that already has a
version of Windows installed. When you installed Windows you created one
large partition, giving you a C: drive that is 4 GB in size. You are currently
using 1.5 GB of space, and want FreeBSD to have 2 GB of space.
In order to install FreeBSD you will need to either:
1. Backup your Windows data, and then reinstall Windows, asking
for a 2 GB partition at install time.
2. Use one of the tools such as PartitionMagic, described above, to
shrink your Windows partition.
2.3.4 Collect Your Network Configuration Details
If you intend to connect to a network as part of your FreeBSD
installation (for example, if you will be installing from an FTP site or an
NFS server), then you need to know your network configuration. You
will be prompted for this information during the installation so that
FreeBSD can connect to the network to complete the install.
2.3.4.1 Connecting to an Ethernet Network or Cable/DSL Modem
If you connect to an Ethernet network, or you have an Internet
connection using an Ethernet adapter via cable or DSL, then you will
need the following information:
1.
2.
3.
4.
5.
IP address
IP address of the default gateway
Hostname
DNS server IP addresses
Subnet Mask
If you do not know this information, then ask your system
administrator or service provider. They may say that this
information is assigned automatically, using DHCP. If so, make a
note of this.
2.3.4.2 Connecting Using a Modem
If you dial up to an ISP using a regular modem then you can still
install FreeBSD over the Internet, it will just take a very long
time.
You will need to know:
1. The phone number to dial for your ISP
2. The COM: port your modem is connected to
3. The username and password for your ISP account
2.3.5 Check for FreeBSD Errata
Although the FreeBSD project strives to ensure that each
release of FreeBSD is as stable as possible, bugs do
occasionally creep into the process. On very rare occasions
those bugs affect the installation process. As these
problems are discovered and fixed, they are noted in
the FreeBSD Errata, which is found on the FreeBSD web
site. You should check the errata before installing to make
sure that there are no late-breaking problems which you
should be aware of.
Information about all the releases, including the errata for
each release, can be found on the release
information section of the FreeBSD web site.
2.3.6 Obtain the FreeBSD Installation Files
The FreeBSD installation process can install FreeBSD from
files located in any of the following places:
Local Media





A CDROM or DVD
A USB Memory Stick
A DOS partition on the same computer
A SCSI or QIC tape
Floppy disks
Network



An FTP site, going through a firewall, or
using an HTTP proxy, as necessary
An NFS server
A dedicated parallel or serial connection
If you have purchased FreeBSD on CD or
DVD then you already have everything you
need, and should proceed to the next section
(Section 2.3.7).
If you have not obtained the FreeBSD
installation files you should skip ahead
to Section 2.13 which explains how to prepare
to install FreeBSD from any of the above.
After reading that section, you should come
back here, and read on to Section 2.3.7.
2.3.7 Prepare the Boot Media
The FreeBSD installation process is started by
booting your computer into the FreeBSD
installer--it is not a program you run within
another operating system. Your computer
normally boots using the operating system
installed on your hard disk, but it can also be
configured to use a “bootable” floppy disk.
Most modern computers can also boot from a
CDROM in the CDROM drive or from a USB
disk.
Tip: If you have FreeBSD on CDROM or
DVD (either one you purchased or you
prepared yourself), and your computer allows
you to boot from the CDROM or DVD
(typically a BIOS option called “Boot Order”
or similar), then you can skip this section. The
FreeBSD CDROM and DVD images are
bootable and can be used to install FreeBSD
without any other special preparation.
To create a bootable memory stick, follow
these steps:
1. Acquire the Memory Stick
Image
The memory stick image can be
downloaded from the ISOIMAGES/ directory
from ftp://ftp.FreeBSD.org/pub
/FreeBSD/releases/arch/ISOIMAGES/version/FreeBSD-8.2RELEASE-arch-memstick.img.
Replace arch and version with
the architecture and the version
number which you want to install,
respectively. For example, the
memory stick images for
FreeBSD/i386 8.2-RELEASE are
available
fromftp://ftp.FreeBSD.org/pub/Fr
eeBSD/releases/i386/ISOIMAGES/8.2/FreeBSD-8.2RELEASE-i386-memstick.img.
The memory stick image has
a .img extension. The ISOIMAGES/ directory contains a
number of different images, and
the one you will need to use will
depend on the version of
FreeBSD you are installing, and
in some cases, the hardware you
are installing to.
Important: Before
proceeding, back up the data you
currently have on your USB stick,
as this procedure will erase it.
2. Write The Image File to the
Memory Stick
Using FreeBSD To Write the
Image
Warning: The example below
lists /dev/da0 as the target device
where the image will be written.
Be very careful that you have the
correct device as the output
target, or you may destroy your
existing data.
1. Writing the Image
with dd(1)
The .img file is not a
regular file you copy
to the memory stick.
It is an image of the
complete contents of
the disk. This means
that
you cannot simply
copy files from one
disk to another.
Instead, you must
use dd(1) to write the
image directly to the
disk:
# dd if=FreeBSD8.2-RELEASE-i386-
memstick.img
of=/dev/da0 bs=64k
If an Operation
not
permitted error is
displayed, make
certain that the target
device is not in use,
mounted, or being
automounted by
some wellintentioned utility
program. Then try
again.
Using Windows® To
Write the Image
Warning: Make sure you
use the correct drive letter
as the output target, or you
may overwrite and destroy
existing data.
2. Obtaining
Image Writer
for Windows
Image Writer
for
Windows is a
free
application
that can
correctly write
an image file
to a memory
stick.
Download it
from https://la
unchpad.net/w
in32-imagewriter/ and
extract it into a
folder.
3. Writing The
Image with
Image Writer
Double-click
the Win32Dis
kImager icon
to start the
program.
Verify that the
drive letter
shown
under Device
is the drive
with the
memory stick.
Click the
folder icon and
select the
image to be
written to the
memory stick.
Click Save to
accept the
image file
name. Verify
that everything
is correct, and
that no folders
on the memory
stick are open
in other
windows.
Finally,
click Write to
write the
image file to
the drive.
To create boot floppy images, follow
these steps:
1. Acquire the Boot Floppy
Images
Important: Please note, as
of FreeBSD 8.X, floppy disk
images are no longer
available. Please see above
for instructions on how to
install FreeBSD using a
USB memory stick or just
use a CDROM or a DVD.
The boot disks are
available on your
installation media in
the floppies/ directory,
and can also be
downloaded from the
floppies
directory,ftp://ftp.FreeBS
D.org/pub/FreeBSD/releas
es/arch/versionRELEASE/floppies/.
Replace arch and version
with the architecture and
the version number which
you want to install,
respectively. For example,
the boot floppy images for
FreeBSD/i386 7.4RELEASE are available
fromftp://ftp.FreeBSD.org/
pub/FreeBSD/releases/i386
/7.4-RELEASE/floppies/.
The floppy images have
a .flp extension.
The floppies/ directory
contains a number of
different images, and the
ones you will need to use
depends on the version of
FreeBSD you are
installing, and in some
cases, the hardware you are
installing to. In most cases
you will need four
floppies, boot.flp, kern1.f
lp, kern2.flp,
andkern3.flp.
Check README.TXT in the
same directory for the most
up to date information
about these floppy images.
Important: Your FTP
program must use binary
mode to download these
disk images. Some web
browsers have been known
to use text (orASCII) mode,
which will be apparent if
you cannot boot from the
disks.
2. Prepare the Floppy Disks
You must prepare one
floppy disk per image file
you had to download. It is
imperative that these disks
are free from defects. The
easiest way to test this is to
format the disks for
yourself. Do not trust preformatted floppies. The
format utility
in Windows will not tell
about the presence of bad
blocks, it simply marks
them as “bad” and ignores
them. It is advised that you
use brand new floppies if
choosing this installation
route.
Important: If you try to
install FreeBSD and the
installation program
crashes, freezes, or
otherwise misbehaves, one
of the first things to suspect
is the floppies. Try writing
the floppy image files to
new disks and try again.
3. Write the Image Files to
the Floppy Disks
The .flp files
are not regular files you
copy to the disk. They are
images of the complete
contents of the disk. This
means that
you cannot simply copy
files from one disk to
another. Instead, you must
use specific tools to write
the images directly to the
disk.
If you are creating the
floppies on a computer
running MSDOS®/Windows, then we
provide a tool to do this
called fdimage.
If you are using the
floppies from the CDROM,
and your CDROM is
the E: drive, then you
would run this:
E:\> tools\fdimage
floppies\boot.flp A:
Repeat this command for
each .flp file, replacing
the floppy disk each time,
being sure to label the
disks with the name of the
file that you copied to
them. Adjust the command
line as necessary,
depending on where you
have placed the .flp files.
If you do not have the
CDROM, then fdimage can
be downloaded from
the toolsdirectory on the
FreeBSD FTP site.
If you are writing the
floppies on a UNIX®
system (such as another
FreeBSD system) you can
use the dd(1) command to
write the image files
directly to disk. On
FreeBSD, you would run:
# dd if=boot.flp
of=/dev/fd0
On
FreeBSD, /dev/fd0 refers
to the first floppy disk
(the A: drive). /dev/fd1 wo
uld be the B: drive, and so
on. Other UNIX variants
might have different names
for the floppy disk devices,
and you will need to check
the documentation for the
system as necessary.
How to Install Software on a Network

f you have a network of computers, from time to time you will need to perform software
upgrades and install new software onto the computers. Depending upon the size of your
network, this can take anywhere from a few minutes to a few hours. Before installing
software on a network, be sure to read the software licensing agreement. Most software
programs only permit you to install the software on one computer per license.
Difficulty:
Moderate
Instructions
1


Power on each computer within the network on which you would like to install the
software.
2
Log on to each computer with the administrator username and password. If the network
administrator has not established a username and password for the network, you will not be
prompted for a username and password.

3
Check each computer to ensure that it meets the minimum system requirements for the
software download (for example, the correct operating system, sufficient disk space and
correct processor).

4
Insert the software CD into the CD ROM drive of each computer on which you want to install
the software. Enter the software license number or product key code. This will be located in
your software package.

5
Run the software installation wizard. Some software programs may require configuration
after it has been installed.

6
Remove the software CD from the computer after the installation is complete. Restart the
computer.