Unix Introduction

UNIX is a computer Operating System which is capable of handling activities from multiple users at the same time.UNIX commands can often be grouped together to make even more powerful commands.

Parts of Unix Operating System:

The UNIX operating system comprises three parts: The kernel, the standard utility programs, and the system configuration files.

kernel:

The kernel is the core of the UNIX operating system. Basically, the kernel is a large program that is loaded into memory when the machine is turned on, and it controls the allocation of hardware resources from that point forward.

Standard utility programs

These programs include simple utilities like cp, which copies files, and complex utilities, like the shell that allows you to issue commands to the operating system.

System configuration files:

The system configuration files are read by the kernel, and some of the standard utilities.

Types of UNIX:

There are many different versions of UNIX.
Sun Solaris
GNU/Linux
MacOS X

An UNIX Terminal window will then appear with a % prompt, waiting for you to start entering commands.

UNIX was originally developed at Bell Laboratories as a private research project by a small group of people. Read all about the history of its creation.

we shall use the following typographical conventions:

Characters written in bold typewriter font are commands to be typed into the computer as they stand.

Characters written in italic typewriter font indicate non-specific file or directory names.

Words inserted within square brackets [Ctrl] indicate keys to be pressed.

Don't forget to press the [Enter] key: commands are not sent to the computer until this is done.

The UNIX operating system is made up of three parts; the kernel, the shell and the programs.

The kernel

The kernel of UNIX is the hub of the operating system: it allocates time and memory to programs and handles the filestore and communications in response to system calls.

As an illustration of the way that the shell and the kernel work together, suppose a user types rm myfile (which has the effect of removing the file myfile). The shell searches the filestore for the file containing the program rm, and then requests the kernel, through system calls, to execute the program rm on myfile. When the process rm myfile has finished running, the shell then returns the UNIX prompt % to the user, indicating that it is waiting for further commands.

The shell

The shell acts as an interface between the user and the kernel. When a user logs in, the login program checks the username and password, and then starts another program called the shell. The shell is a command line interpreter (CLI). It interprets the commands the user types in and arranges for them to be carried out. The commands are themselves programs: when they terminate, the shell gives the user another prompt (% on our systems).

Filename Completion - By typing part of the name of a command, filename or directory and pressing the [Tab] key, the tcsh shell will complete the rest of the name automatically. If the shell finds more than one name beginning with those letters you have typed, it will beep, prompting you to type a few more letters before pressing the tab key again.

History - The shell keeps a list of the commands you have typed in. If you need to repeat a command, use the cursor keys to scroll up and down the list or type history for a list of previous commands.

Listing files and directories

ls (list)

When you first login, your current working directory is your home directory.

% ls (short for list)
The ls command lists the contents of your current working directory.

ls does not, in fact, cause all the files in your home directory to be listed, but only those ones whose name does not begin with a dot (.) Files beginning with a dot (.) are known as hidden files and usually contain important program configuration information. They are hidden because you should not change them unless you are very familiar with UNIX!!!

To list all files in your home directory including those whose names begin with a dot, type
% ls -a

mkdir (make directory)

We will now make a subdirectory in your home directory to hold the files you will be creating and using in the course of this tutorial. To make a subdirectory called unixstuff in your current working directory type

% mkdir unixstuff

To see the directory you have just created, type
% ls

Changing to a different directory

cd (change directory)
The command cd directory means change the current working directory to 'directory'. The current working directory may be thought of as the directory you are in, i.e. your current position in the file-system tree.
To change to the directory you have just made, type
% cd unixstuff
Type ls to see the contents (which should be empty)

In UNIX, (.) means the current directory, so typing
% cd .
NOTE: there is a space between cd and the dot
means stay where you are (the unixstuff directory).
This may not seem very useful at first, but using (.) as the name of the current directory will save a lot of typing, as we shall see later in the tutorial.

(..) means the parent of the current directory, so typing
% cd ..

Pathnames
pwd (print working directory)
Pathnames enable you to work out where you are in relation to the whole file-system. For example, to find out the absolute pathname of your home-directory, type cd to get back to your home-directory and then type % pwd

Testing Interview Questions and Answers

Q. What is Agile Testing and how is it different to traditional waterfall or the V model?

Agile Testing is testing practice that follows the principles of agile software development. Agile testing involves all members of an agile team with special skills and expertise to ensure business value is delivered at frequent intervals.

The big difference is that in Agile environment, testing is not a phase, it is an activity parallel to development.

In agile environment, small features of software are delivered frequently, so testing activity should be parallel to development activity. Testing time is short as we are only testing small features.

In the waterfall model, there is a testing phase at the end of the development so, testing is a big effort done after the whole application is developed. Testing time is long as we have to test the whole application.

Q: What is your approach when requirements change continuously?

This question can be asked if you are interviewed for an agile QA position where requirements are likely to change frequently during development. Although a complete change in requirement is possible, most of the time, it is the technical details that are subject to change. e.g. the intent of the requirement or behaviour of the feature is the same but implementation details can change

A: Some possible answers can be:

• Write generic test plans and test cases which focus on the intent of the requirement rather than its exact details
• Work very closely with the product owners or business analysts to understand the scope of change so testing can be updated
• Make sure the team understands the risks involved in changing requirements especially towards the end of sprint
• If you’re going to automate this feature, it is best to wait until the feature is stable and requirements are finalized
• Negotiate to see if the changes can be kept to a minimum and/or implement the changes in next sprint.
• 
  

Can you explain defect age and defect spoilage?

Defect age is also called a phase age or phage. One of the most important things to remember in testing is that the later we find a defect the more it costs to fix it. Defect age and defect spoilage metrics work with the same fundamental, i.e., how late you found the defect. So the first thing we need to define is what is the scale of the defect age according to phases. For instance, the following table defines the scale according to phases. So, for instance, requirement defects, if found in the design phase, have a scale of 1, and the same defect, if propagated until the production phase.
Once the scale is decided now we can find the defect spoilage. Defect spoilage is defects from the previous phase multiplied by the scale. For instance, in the following figure we have found 8 defects in the design phase from which 4 defects are propagated from the requirement phase. So we multiply the 4 defects with the scale defined in the previous table, so we get the value of 4. In the same fashion we calculate for all the phases. That's the spoilage.

Can you explain how the number of production defects is measured?

This is one of the most effective measures. The number of defects found in a production is recorded. The only issue with this measure is it can have latent and masked defects which can give us the wrong value regarding software quality.

Can you explain DRE?

DRE (Defect Removal Efficiency) is a powerful metric used to measure test effectiveness. From this metric we come to know how many bugs we found from the set of bugs which we could have found. The following is the formula for calculating DRE. We need two inputs for calculating this metric: the number of bugs found during development and the number of defects detected at the end user but the success of DRE depends on several factors. The following are some of them:

• Severity and distribution of bugs must be taken into account.
• Second, how do we confirm when the customer has found all the bugs. This is normally achieved by looking at the history of the customer.