\documentclass[11pt,twoside]{article}\makeatletter

\IfFileExists{xcolor.sty}%
  {\RequirePackage{xcolor}}%
  {\RequirePackage{color}}
\usepackage{colortbl}
\usepackage{wrapfig}
\usepackage{ifxetex}
\ifxetex
  \usepackage{fontspec}
  \usepackage{xunicode}
  \catcode`⃥=\active \def⃥{\textbackslash}
  \catcode`❴=\active \def❴{\{}
  \catcode`❵=\active \def❵{\}}
  \def\textJapanese{\fontspec{Noto Sans CJK JP}}
  \def\textChinese{\fontspec{Noto Sans CJK SC}}
  \def\textKorean{\fontspec{Noto Sans CJK KR}}
  \setmonofont{DejaVu Sans Mono}
  
\else
  \IfFileExists{utf8x.def}%
   {\usepackage[utf8x]{inputenc}
      \PrerenderUnicode{–}
    }%
   {\usepackage[utf8]{inputenc}}
  \usepackage[english]{babel}
  \usepackage[T1]{fontenc}
  \usepackage{float}
  \usepackage[]{ucs}
  \uc@dclc{8421}{default}{\textbackslash }
  \uc@dclc{10100}{default}{\{}
  \uc@dclc{10101}{default}{\}}
  \uc@dclc{8491}{default}{\AA{}}
  \uc@dclc{8239}{default}{\,}
  \uc@dclc{20154}{default}{ }
  \uc@dclc{10148}{default}{>}
  \def\textschwa{\rotatebox{-90}{e}}
  \def\textJapanese{}
  \def\textChinese{}
  \IfFileExists{tipa.sty}{\usepackage{tipa}}{}
\fi
\def\exampleFont{\ttfamily\small}
\DeclareTextSymbol{\textpi}{OML}{25}
\usepackage{relsize}
\RequirePackage{array}
\def\@testpach{\@chclass
 \ifnum \@lastchclass=6 \@ne \@chnum \@ne \else
  \ifnum \@lastchclass=7 5 \else
   \ifnum \@lastchclass=8 \tw@ \else
    \ifnum \@lastchclass=9 \thr@@
   \else \z@
   \ifnum \@lastchclass = 10 \else
   \edef\@nextchar{\expandafter\string\@nextchar}%
   \@chnum
   \if \@nextchar c\z@ \else
    \if \@nextchar l\@ne \else
     \if \@nextchar r\tw@ \else
   \z@ \@chclass
   \if\@nextchar |\@ne \else
    \if \@nextchar !6 \else
     \if \@nextchar @7 \else
      \if \@nextchar (8 \else
       \if \@nextchar )9 \else
  10
  \@chnum
  \if \@nextchar m\thr@@\else
   \if \@nextchar p4 \else
    \if \@nextchar b5 \else
   \z@ \@chclass \z@ \@preamerr \z@ \fi \fi \fi \fi
   \fi \fi  \fi  \fi  \fi  \fi  \fi \fi \fi \fi \fi \fi}
\gdef\arraybackslash{\let\\=\@arraycr}
\def\@textsubscript#1{{\m@th\ensuremath{_{\mbox{\fontsize\sf@size\z@#1}}}}}
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\def\abbr{}
\def\corr{}
\def\expan{}
\def\gap{}
\def\orig{}
\def\reg{}
\def\ref{}
\def\sic{}
\def\persName{}\def\name{}
\def\placeName{}
\def\orgName{}
\def\textcal#1{{\fontspec{Lucida Calligraphy}#1}}
\def\textgothic#1{{\fontspec{Lucida Blackletter}#1}}
\def\textlarge#1{{\large #1}}
\def\textoverbar#1{\ensuremath{\overline{#1}}}
\def\textquoted#1{‘#1’}
\def\textsmall#1{{\small #1}}
\def\textsubscript#1{\@textsubscript{\selectfont#1}}
\def\textxi{\ensuremath{\xi}}
\def\titlem{\itshape}
\newenvironment{biblfree}{}{\ifvmode\par\fi }
\newenvironment{bibl}{}{}
\newenvironment{byline}{\vskip6pt\itshape\fontsize{16pt}{18pt}\selectfont}{\par }
\newenvironment{citbibl}{}{\ifvmode\par\fi }
\newenvironment{docAuthor}{\ifvmode\vskip4pt\fontsize{16pt}{18pt}\selectfont\fi\itshape}{\ifvmode\par\fi }
\newenvironment{docDate}{}{\ifvmode\par\fi }
\newenvironment{docImprint}{\vskip 6pt}{\ifvmode\par\fi }
\newenvironment{docTitle}{\vskip6pt\bfseries\fontsize{22pt}{25pt}\selectfont}{\par }
\newenvironment{msHead}{\vskip 6pt}{\par}
\newenvironment{msItem}{\vskip 6pt}{\par}
\newenvironment{rubric}{}{}
\newenvironment{titlePart}{}{\par }

\newcolumntype{L}[1]{){\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{){\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{){\raggedleft\arraybackslash}p{#1}}
\newcolumntype{P}[1]{){\arraybackslash}p{#1}}
\newcolumntype{B}[1]{){\arraybackslash}b{#1}}
\newcolumntype{M}[1]{){\arraybackslash}m{#1}}
\definecolor{label}{gray}{0.75}
\def\unusedattribute#1{\sout{\textcolor{label}{#1}}}
\DeclareRobustCommand*{\xref}{\hyper@normalise\xref@}
\def\xref@#1#2{\hyper@linkurl{#2}{#1}}
\begingroup
\catcode`\_=\active
\gdef_#1{\ensuremath{\sb{\mathrm{#1}}}}
\endgroup
\mathcode`\_=\string"8000
\catcode`\_=12\relax

\usepackage[a4paper,twoside,lmargin=1in,rmargin=1in,tmargin=1in,bmargin=1in,marginparwidth=0.75in]{geometry}
\usepackage{framed}

\definecolor{shadecolor}{gray}{0.95}
\usepackage{longtable}
\usepackage[normalem]{ulem}
\usepackage{fancyvrb}
\usepackage{fancyhdr}
\usepackage{graphicx}
\usepackage{marginnote}

\renewcommand{\@cite}[1]{#1}


\renewcommand*{\marginfont}{\itshape\footnotesize}

\def\Gin@extensions{.pdf,.png,.jpg,.mps,.tif}

  \pagestyle{fancy}

\usepackage[pdftitle={3W's of Static Software Testing Techniques},
 pdfauthor={}]{hyperref}
\hyperbaseurl{}

	 \paperwidth210mm
	 \paperheight297mm
              
\def\@pnumwidth{1.55em}
\def\@tocrmarg {2.55em}
\def\@dotsep{4.5}
\setcounter{tocdepth}{3}
\clubpenalty=8000
\emergencystretch 3em
\hbadness=4000
\hyphenpenalty=400
\pretolerance=750
\tolerance=2000
\vbadness=4000
\widowpenalty=10000

\renewcommand\section{\@startsection {section}{1}{\z@}%
     {-1.75ex \@plus -0.5ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
     {-1.75ex\@plus -0.5ex \@minus- .2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\Large}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
     {-1.5ex\@plus -0.35ex \@minus -.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\large}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
     {-1ex \@plus-0.35ex \@minus -0.2ex}%
     {0.5ex \@plus .2ex}%
     {\reset@font\normalsize}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
     {1.5ex \@plus1ex \@minus .2ex}%
     {-1em}%
     {\reset@font\normalsize\bfseries}}


\def\l@section#1#2{\addpenalty{\@secpenalty} \addvspace{1.0em plus 1pt}
 \@tempdima 1.5em \begingroup
 \parindent \z@ \rightskip \@pnumwidth 
 \parfillskip -\@pnumwidth 
 \bfseries \leavevmode #1\hfil \hbox to\@pnumwidth{\hss #2}\par
 \endgroup}
\def\l@subsection{\@dottedtocline{2}{1.5em}{2.3em}}
\def\l@subsubsection{\@dottedtocline{3}{3.8em}{3.2em}}
\def\l@paragraph{\@dottedtocline{4}{7.0em}{4.1em}}
\def\l@subparagraph{\@dottedtocline{5}{10em}{5em}}
\@ifundefined{c@section}{\newcounter{section}}{}
\@ifundefined{c@chapter}{\newcounter{chapter}}{}
\newif\if@mainmatter 
\@mainmattertrue
\def\chaptername{Chapter}
\def\frontmatter{%
  \pagenumbering{roman}
  \def\thechapter{\@roman\c@chapter}
  \def\theHchapter{\roman{chapter}}
  \def\thesection{\@roman\c@section}
  \def\theHsection{\roman{section}}
  \def\@chapapp{}%
}
\def\mainmatter{%
  \cleardoublepage
  \def\thechapter{\@arabic\c@chapter}
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \pagenumbering{arabic}
  \setcounter{secnumdepth}{6}
  \def\@chapapp{\chaptername}%
  \def\theHchapter{\arabic{chapter}}
  \def\thesection{\@arabic\c@section}
  \def\theHsection{\arabic{section}}
}
\def\backmatter{%
  \cleardoublepage
  \setcounter{chapter}{0}
  \setcounter{section}{0}
  \setcounter{secnumdepth}{2}
  \def\@chapapp{\appendixname}%
  \def\thechapter{\@Alph\c@chapter}
  \def\theHchapter{\Alph{chapter}}
  \appendix
}
\newenvironment{bibitemlist}[1]{%
   \list{\@biblabel{\@arabic\c@enumiv}}%
       {\settowidth\labelwidth{\@biblabel{#1}}%
        \leftmargin\labelwidth
        \advance\leftmargin\labelsep
        \@openbib@code
        \usecounter{enumiv}%
        \let\p@enumiv\@empty
        \renewcommand\theenumiv{\@arabic\c@enumiv}%
	}%
  \sloppy
  \clubpenalty4000
  \@clubpenalty \clubpenalty
  \widowpenalty4000%
  \sfcode`\.\@m}%
  {\def\@noitemerr
    {\@latex@warning{Empty `bibitemlist' environment}}%
    \endlist}

\def\tableofcontents{\section*{\contentsname}\@starttoc{toc}}
\parskip0pt
\parindent1em
\def\Panel#1#2#3#4{\multicolumn{#3}{){\columncolor{#2}}#4}{#1}}
\newenvironment{reflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemsep}{0pt}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\itshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{sansreflist}{%
  \begin{raggedright}\begin{list}{}
  {%
   \setlength{\topsep}{0pt}%
   \setlength{\rightmargin}{0.25in}%
   \setlength{\itemindent}{0pt}%
   \setlength{\parskip}{0pt}%
   \setlength{\itemsep}{0pt}%
   \setlength{\parsep}{2pt}%
   \def\makelabel##1{\upshape ##1}}%
  }
  {\end{list}\end{raggedright}}
\newenvironment{specHead}[2]%
 {\vspace{20pt}\hrule\vspace{10pt}%
  \phantomsection\label{#1}\markright{#2}%

  \pdfbookmark[2]{#2}{#1}%
  \hspace{-0.75in}{\bfseries\fontsize{16pt}{18pt}\selectfont#2}%
  }{}
      \def\TheFullDate{2011-04 2011-03-05 (revised: April 2011 05 March 2011)}
\def\TheID{\makeatother }
\def\TheDate{2011-04 2011-03-05}
\title{3W's of Static Software Testing Techniques}
\author{}\makeatletter 
\makeatletter
\newcommand*{\cleartoleftpage}{%
  \clearpage
    \if@twoside
    \ifodd\c@page
      \hbox{}\newpage
      \if@twocolumn
        \hbox{}\newpage
      \fi
    \fi
  \fi
}
\makeatother
\makeatletter
\thispagestyle{empty}
\markright{\@title}\markboth{\@title}{\@author}
\renewcommand\small{\@setfontsize\small{9pt}{11pt}\abovedisplayskip 8.5\p@ plus3\p@ minus4\p@
\belowdisplayskip \abovedisplayskip
\abovedisplayshortskip \z@ plus2\p@
\belowdisplayshortskip 4\p@ plus2\p@ minus2\p@
\def\@listi{\leftmargin\leftmargini
               \topsep 2\p@ plus1\p@ minus1\p@
               \parsep 2\p@ plus\p@ minus\p@
               \itemsep 1pt}
}
\makeatother
\fvset{frame=single,numberblanklines=false,xleftmargin=5mm,xrightmargin=5mm}
\fancyhf{} 
\setlength{\headheight}{14pt}
\fancyhead[LE]{\bfseries\leftmark} 
\fancyhead[RO]{\bfseries\rightmark} 
\fancyfoot[RO]{}
\fancyfoot[CO]{\thepage}
\fancyfoot[LO]{\TheID}
\fancyfoot[LE]{}
\fancyfoot[CE]{\thepage}
\fancyfoot[RE]{\TheID}
\hypersetup{citebordercolor=0.75 0.75 0.75,linkbordercolor=0.75 0.75 0.75,urlbordercolor=0.75 0.75 0.75,bookmarksnumbered=true}
\fancypagestyle{plain}{\fancyhead{}\renewcommand{\headrulewidth}{0pt}}

\date{}
\usepackage{authblk}

\providecommand{\keywords}[1]
{
\footnotesize
  \textbf{\textit{Index terms---}} #1
}

\usepackage{graphicx,xcolor}
\definecolor{GJBlue}{HTML}{273B81}
\definecolor{GJLightBlue}{HTML}{0A9DD9}
\definecolor{GJMediumGrey}{HTML}{6D6E70}
\definecolor{GJLightGrey}{HTML}{929497} 

\renewenvironment{abstract}{%
   \setlength{\parindent}{0pt}\raggedright
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
   \textcolor{GJBlue}{\large\bfseries\abstractname\space}
}{%   
   \vskip8pt
   \textcolor{GJMediumGrey}{\rule{\textwidth}{2pt}}
   \vskip16pt
}

\usepackage[absolute,overlay]{textpos}

\makeatother 
      \usepackage{lineno}
      \linenumbers
      
\begin{document}

             \author[1]{Dr. SHEIKH UMAR FAROOQ S. M. K.  QUADRI}

             \author[2]{Dr. SHEIKH UMAR FAROOQ S. M. K.  QUADRI}

             \affil[1]{  University of Kashmir}

\renewcommand\Authands{ and }

\date{\small \em Received: 29 January 2011 Accepted: 22 February 2011 Published: 5 March 2011}

\maketitle


\begin{abstract}
        


No fault detection technique is capable of finding all classes of fault in software, so we have to use variety of techniques that will help us to ensure that a variety of faults are found, resulting in more effective testing. As we know dynamic testing can only be applied to code; using static techniques becomes imperative to ensure V&V process is more efficient and effective. Before using any technique we should have profound knowledge of that technique. In this paper, we present an in-depth review of all static testing techniques. The goal of this paper is to look at the technical aspects of static techniques and to highlight their importance in STLC.

\end{abstract}


\keywords{S tatic Techniques, Reviews, Static Analysis .}

\begin{textblock*}{18cm}(1cm,1cm) % {block width} (coords) 
\textcolor{GJBlue}{\LARGE Global Journals \LaTeX\ JournalKaleidoscope\texttrademark}
\end{textblock*}

\begin{textblock*}{18cm}(1.4cm,1.5cm) % {block width} (coords) 
\textcolor{GJBlue}{\footnotesize \\ Artificial Intelligence formulated this projection for compatibility purposes from the original article published at Global Journals. However, this technology is currently in beta. \emph{Therefore, kindly ignore odd layouts, missed formulae, text, tables, or figures.}}
\end{textblock*}


\let\tabcellsep& 	 	 		 
\section[{INTRODUCTION}]{INTRODUCTION}\par
oftware testing is the process of executing a program or system with the intent of finding errors \hyperref[b0]{[1]} \hyperref[b1]{[2]}. Software testing is commonly known as a test to evaluate and then guarantee the level of quality of software, or to verify if there are no risks. Software testing is also used to test the software for other software quality factors like reliability, usability, integrity, security, capability, efficiency, portability, maintainability, compatibility etc \hyperref[b2]{[3]}. Effective software testing will contribute to the delivery of reliable and quality oriented product, more satisfied user, lower maintenance and more correct and reliable results \hyperref[b3]{[4]}. To perform software testing we have wide variety of testing techniques \hyperref[b4]{[5]} \hyperref[b5]{[6]}. Perhaps at present the single most important thing to understand is that the best testing technique is no single testing technique. Because each testing technique is good at finding one specific class of defect, using just one technique will help ensure that many (perhaps most but not all) defects of that particular class are found. Unfortunately, it may also help to ensure that many defects of other classes are missed! Using a variety of techniques will therefore help ensure that a variety of defects are found, resulting in more effective testing \hyperref[b6]{[7]}.\par
As we know testing only code is not sufficient enough to guarantee that all faults and flaws in the software system are identified, so using techniques other than dynamic testing techniques becomes essential. This not only guarantees that different classes of faults are identified, but it also makes sure that they are identified before going in the following phases in software development life cycle, thereby saving the overall software cost. In addition to that using such techniques can also ensure that we are not missing any requirement or violating any procedure. We all know prevention is better than cure; Static testing is about prevention, while dynamic testing is about cure. In this paper, besides providing a review of static techniques, we will also look at the technical aspects of static testing techniques. Besides that we will also look at their importance and their use in software testing life cycle. 
\section[{II.}]{II.} 
\section[{Terminology Used}]{Terminology Used}\par
The Terminology used in this paper is adopted from  {\ref [8]}. Following terms are mainly used in this paper. Error: The difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. Fault (Defect): Abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function. Note: Can also be defined thus: A requirements, design, or implementation flaw or deviation from a desired or intended state \hyperref[b7]{[9]}. Failure: The inability of a system to perform its required functions within specified performance requirements. Note: Failures are either random (in hardware) or systematic (in hardware or software) III. 
\section[{STATIC TESTING TECHNIQUES}]{STATIC TESTING TECHNIQUES}\par
In each testing type there are many software testing techniques that are used to test a system \hyperref[b8]{[10]}. Testing techniques refer to different methods or ways of testing particular features of a computer program, system or product. Software testing techniques are diverse methods to do software testing and authenticate them. Based on whether the actual execution of software under evaluation is needed or not, there are two major categories of quality assurance activities: static and dynamic \hyperref[b9]{[11,}\hyperref[b10]{12]}. Static techniques are concerned with the analysis and checking of system representations such as the requirements documents, design diagrams and the program source code, either manually or automatically, without actually executing the code \hyperref[b11]{[13]}. Documentation in the form of text, models or code are analyzed, often by hand. In a number of cases, e.g. in the compilation of program code, tools are used \hyperref[b13]{[14]}. Figure \hyperref[fig_1]{1}   One important thing about static techniques is that in contrast to dynamic testing they help us to find defects rather than failures.Types of defects that are easier to find during static testing are:\par
? Deviations from standards.\par
? Missing requirements.\par
? Design defects.\par
? Non-maintainable code.\par
? Inconsistent interface specifications.\par
? Programming errors (e.g. Infinite Loops)\par
The main disadvantage of static testing is that ? They do not take the interaction of the program's input parameters into consideration, and this can determine the run-time behavior of a Real-Time System. Thus, static techniques give the very loose time bounds which may be retrieved from the test program's structure (source code or object code) \hyperref[b16]{[18]}. ? It is often hard to obtain suitable external user information for static testing as proposed in \hyperref[b17]{[19]}. Usually this type of information is difficult to assess as the complexity of most systems prohibits the estimation of internal parameter values, loop bounds or the complete dynamic behavior. It is important that the assessment of the run-time behavior, which is particularly tedious, should be undertaken by a testing tool rather than a human tester. ? The information provided is not always precise since it is usually based on an approximation IV. 
\section[{Static Techniques Classification}]{Static Techniques Classification}\par
Static techniques can be grouped under two categories:\par
1. Reviews 2. Analysis. 
\section[{a) Reviews}]{a) Reviews}\par
A review is a fundamental technique that must be used throughout the development lifecycle. Basically a review is any of a variety of activities involving evaluation of technical matter by a group of people working together  {\ref [20]}. A major portion in static software testing is carried out with the help of reviews. It is not necessary that all below mentioned reviews will be performed, if more than one type of review is used, the order may vary. For example, an informal review may be carried out before a technical review, or an inspection may be carried out on a requirements specification before a walkthrough with customers. Reviews can be of following types: i.\par
Informal Review A review done by peers in an informal fashion without any documented findings or process. An informal review involves two or more people looking through a document or codes that one or the other of them has written. The purpose is still to detect defects, but there are usually no check-lists used and the result does not need to be documented. \hyperref[b18]{[21]}. This is what we all do all the time, mostly without thinking about it as a review: asking a colleague or a friend to look at something we have produced. The objectives of informal reviews are very individual, depending on the author's needs. It could be everything from finding spelling and grammar mistakes, to the structure of the product, to the actual contents from a professional point of view. An informal review follows no formal documented process. The participants are normally just the author and one or two reviewers \hyperref[b0]{[1]}. The reviewer(s) are usually chosen by the author. This type of static testing can be performed on any document at any state during its production. The author decides when he or she would like an informal review to take place. The review is done according to the reviewer's perception. The author typically gets feedback in either pure verbal form or in the form of notes scribbled on the document under testing. The result of an informal review varies and is very much dependent on the review skills of the chosen reviewer(s). The author decides when the review is over. He or she may correct the document as he or she seems fit; there are no obligations following an informal review. There are a few disadvantages connected with informal reviews: ? Dependency of the reviewers' reviewing skill, but that can easily be overcome by finding the right reviewers for the job. ? There are usually no records kept of the reviews and hence no data available for calculation of effectiveness.\par
The benefits of informal reviews should, however, not be underestimated. Even though the reviews are informal they are very useful. In most companies no material must be delivered to another without having at least been through an informal review.\par
ii. 
\section[{Walkthrough}]{Walkthrough}\par
A form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems"  {\ref [22]}. In a walkthrough, a group of developers-with three or four being an optimal number-performs the review. Only one of the participants is the author of the program. The other participants are selected from different departments and backgrounds. A walkthrough is characterized by the author of the document under review guiding the participants through the document and his or her thought processes, to achieve a common understanding and to gather feedback. The content of the document is explained step by step by the author, to reach consensus on changes or to gather information \hyperref[b0]{[1]}. It involves the author presenting his or her material to a selected group of participants in order to get them involved in the test basis more quickly as a result. Questions and explanations are welcomed during the meeting. The purpose is more one of creating a common picture, than of identifying defects, but the technique is still counted as static testing. Scenarios and dry runs may be used to validate the content. Within a walkthrough the author does most of the preparation. The participants, who are selected from different departments and backgrounds, are not required to do a detailed study of the documents in advance \hyperref[b19]{[23]}. Because of the way the meeting is structured, a large number of people can participate and this larger audience can bring a great number of diverse viewpoints regarding the contents of the document being reviewed as well as serving an educational purpose. If the audience represents a broad cross-section of skills and disciplines, it can give assurance that no major defects are 'missed' in the walk-through. A walkthrough is especially useful for higher-level documents, such as requirement specifications and architectural documents. Advantages of walkthroughs are ? This process frequently exposes a batch of errors, allowing the errors to be corrected later as a whole. ? Walkthroughs, result in lower debugging (errorcorrection) costs, because when an error is found it is usually precisely located in the code. ? Walkthrough is an excellent tool for collaboration where joint decisions can be made by the tea. Each and every member present must be involved in making decisions \hyperref[b20]{[24]}. ? Walkthrough is also useful for training the entire team at one time. Test Scenarios and designs are generally subjected to walkthrough.\par
? People understand what they can expect from the document/approach under consideration. ? Problems can get recorded and suggestions can be received from the team for improving the work product further. Despite having so many advantages, Walkthroughs do have following disadvantages \hyperref[b20]{[24]}: ? Availability of people can be an issue when teams are large. Multi locations and distributed teams are major challenges in walkthrough. It is more formal than peer and procuring people can be a challenge. ? Team members may not be experts in giving comments and may need some training and basic knowledge about the project, artifact under walkthrough and so on. ? Time can be a constraint where schedules are tight.\par
iii. 
\section[{Technical Review}]{Technical Review}\par
As the name suggests, a technical review focuses on the technical parts of the project like architecture and program design \hyperref[b21]{[25]}. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. Technical reviews may also provide recommendations of alternatives and examination of various alternatives \hyperref[b22]{[26]}. Here, primarily the technical experts and the architects take part together with other developers. This type of review is led by a trained moderator and comprises of experts from the team itself. The purpose is both to evaluate choices of solution, and compliance with standards and other documentation. The result is often documented in a log. Technical reviews are less formal and there is little or no focus on defect identification on the basis of referenced documents, intended readership and rules. In practice, technical reviews vary from quite informal to very formal. iv. 
\section[{Inspection}]{Inspection}\par
The most formal review technique is called an inspection and is strictly governed. The method was developed by Michael E. Fagan at IBM.30 \hyperref[b22]{[26]} and has since been improved \hyperref[b23]{[27]} and adapted by many major software companies. An inspection is a set of procedures and error-detection techniques for group code reading \hyperref[b0]{[1]}. Led by a trained moderator and involves peers to examine the product. The document under inspection is prepared and checked thoroughly by the reviewers before the meeting, comparing the work product with its sources and other referenced documents, and using rules and checklists. An exit criterion is defined and a formal follow-up is carried out on the documented findings. Metrics are calculated and analyzed to optimize the process. The participants prepare themselves carefully by examining selected areas according to role descriptions and check-lists. At the review meeting all points of view are recorded and how they are to be addressed can be discussed. On the other hand, the problems are solved afterwards. In the inspection meeting the defects found are logged and any discussion is postponed until the discussion phase. This makes the inspection meeting a very efficient meeting. Since the way of working is formal, only a limited amount of material is examined on each occasion, mostly no more than a dozen pages, depending on the test basis \hyperref[b21]{[25]}. For this type of review to be effective requires the participants to be trained, check-lists to be compiled, and the review meeting itself to be chaired by an experienced moderator. The reason for carrying out inspections can be explained by using Weinberg's concept of egoless engineering \hyperref[b18]{[21]}. Weinberg refers to the human tendency to self-justify actions. Because of this tendency, many engineering organizations have established independent test groups that specialize in finding defects. Similar principles have led to the introduction of inspections and reviews in general. Depending on the organization and the objectives of a project, inspections can be balanced to serve a number of goals. For example, if the time to market is extremely important, the emphasis in inspections will be on efficiency. In a safety-critical market, the focus will be on effectiveness. Advantages of Inspection are \hyperref[b20]{[24]}: ? Expert's opinion is available as they are present during review. Subject-matter experts can clarify many issues. ? Inspection must be time effective as availability of experts is limited. There is always a time pressure for inspection. ? Defects are recorded but solution is not given by subject-matter experts. This helps the organization to initiate own action plan for fixing the defects.\par
Inspection has got following disadvantages:\par
? Manual process with strict guidelines ? Time-consuming (expensive)\par
? Tedious and error-prone (cannot be done full-time)\par
? Inspections increase costs early in the software process ? Precise standards or guidelines must be available and inspection team members must be familiar with them ? Not incremental (repeated inspection costs same as first one) v. 
\section[{Management Review}]{Management Review}\par
Management reviews are conducted by management representatives to evaluate the status of work done and to make decisions regarding downstream activities  {\ref [29]}. A systematic evaluation of a software acquisition, supply, development, operation, or maintenance process performed by or on behalf of management that monitors progress, determines the status of plans and schedules, confirms requirements and their system allocation, or evaluates the effectiveness of management approaches used to achieve fitness for purpose \hyperref[b22]{[26]}. The primary objective is to find defects in the documents under static testing. The secondary objective is to monitor progress according to the current plan, to assess status, and to make necessary decisions about any actions to take accordingly, including changes in resources, time, and/or scope/quality and updating the plan accordingly. The scope and the quality are usually expressed in terms of requirements to fulfill. Management reviews are usually planned to take place at certain times in the development life cycle, typically in connection with defined milestones, that is, transfer from one development phase to the next. Management review is a review type performed on management documents. This may be project related plans like\par
? Project management plans, including schedules and resources A management review is performed using all appropriate information about the status of the project and the product, like progress and status reports concerning both technical and financial aspects and incident reports \hyperref[b25]{[30]}. The roles that should be filled for a management review are the decision maker (the owner of the plan), the leader, reviewers, and a recorder. The reviewers are relevant stakeholders and should include management and technical staff involved in the execution of the planned activities. For the management review of a test plan the reviewers should include the test manager, the project manager (higher management), and the people involved in the testing activities. The total number of participants should be within 3-10 people. The management review process is also fairly formal. The leader schedules the preparation and the review meeting and presents the plan and any other information to the reviewers. The reviewers are usually expected to be prepared, that is to know the current plan and any deviations from it, before the review meeting is held. At the review meeting the plan is checked for compliance with other plans and consistency with reality \hyperref[b26]{[31]}. The performance of management procedures being applied may also be assessed. Conclusions about what should be changed in the plan and what should not be are reached before the end of the meeting. A report is written after the review meeting summarizing the action items defined and the issues to be resolved, if any. In some cases measurements related to the time and effectiveness of the review are reported. The benefits of management reviews are many. A plan that is agreed on by all relevant stakeholders has a higher probability of being followed than a plan without such an agreement. The disadvantages of management reviews are few. The outcome depends on the reviewers, but these are usually sufficiently committed. If reporting of measurements is not imposed it is difficult to calculate the effectiveness of the technical reviews, but the measurements are not difficult to obtain \hyperref[b25]{[30]}.\par
vi. 
\section[{Audit}]{Audit}\par
Audit is by far the most formal static testing technique. They are conducted by personnel external to a project to evaluate compliance with specifications standards contractual agreements or other criteria  {\ref [32]}. Audits may be either internal or external. Internal audits are performed by auditors from the organization, but external to the project under audit. External audits are performed by auditors entirely external to the organization, usually from some sort of authority organization. Auditors must have a special education and certification to perform official audits. Audits are usually performed late in the development life cycle, just before release of the product and/or close down of the project. Smaller audits may be performed in connection with other important milestones. The primary objective of an audit is to provide an independent evaluation of an activity's compliance to applicable process descriptions, contracts, regulations, and/or standards \hyperref[b22]{[26]}. Any document, technical as well as managerial, can be part of an audit. In an audit a number of documents, if not all documents, will usually be evaluated and their consistency as well as their collective compliance to the basis material checked. A lead auditor is responsible for the audit, and he or she also acts as moderator. The lead auditor and any other participating auditors collect evidence of compliance through document examination, interviews, and walkthroughs of documents of special interest. The audit leader decides when the audit should take place, and the documents will be audited in the state they are in at the time of the audit. The result of an audit is a report in which the findings are summarized in the form of lists of observations, deviations, recommendations, and corrective actions to be taken, as well as a pass/fail statement \hyperref[b25]{[30]}. The disadvantages of audits are that they are expensive and the least effective static testing type. On the other hand, audits are usually performed because they are mandatory in some context and therefore serve a different purpose than pure defect.\par
Different People are involved in review process at different stages of the review; their names can change as per the review type. Table \hyperref[tab_1]{1} shows different stages in a review process (formal). Table \hyperref[tab_2]{2} shows the persons usually involved in a review process. 
\section[{Stage Description Planning}]{Stage Description Planning}\par
Selecting the personnel, allocating roles; defining the entry and exit criteria for more formal review types (e.g. inspection); and selecting which parts of documents to look at. 
\section[{Kick-off}]{Kick-off}\par
Distributing documents; explaining the objectives, process and documents to the participants; and checking entry criteria (for more formal review types). 
\section[{Individual Preparation}]{Individual Preparation}\par
Work done by each of the participants on their own before the review meeting, noting potential defects, questions and comments. Review Meeting Discussion or logging, with documented results or minutes (for more formal review types). The meeting participants may simply note defects, make recommendations for handling the defects, or make decisions about the defects. 
\section[{Rework}]{Rework}\par
Fixing defects found, typically done by the author. Follow-up Checking that defects have been addressed, gathering metrics and checking on exit criteria (for more formal review types). The writer or person with chief responsibility for the document(s) to be reviewed Reviewers Individuals with a specific technical or business background (also called checkers or inspectors) who, after the necessary preparation, identify and describe findings (e.g. defects) in the product under review. Reviewers should be chosen to represent different perspectives and roles in the review process, and should take part in any review meetings. Scribe (Recorder) Documents all the issues, problems and open points that were identified during the meeting. Looking at documents from different perspectives and using checklists can make reviews more effective and efficient, for example, a checklist based on perspectives such as user, maintainer, tester or operations, or a checklist of typical requirements problems. Static analysis is a fault-detection technique, which evaluates a system or component based on its form, structure, content, or documentation \hyperref[b27]{[33]}. Static analysis is used to monitor whether an object under analysis meets uniform expectations around security, reliability, performance, and maintainability. Static analysis is performed to improve and ensure the intrinsic quality of software programs. Static Analysis can reduce defects by up to a factor of six \hyperref[b28]{[34]}. (See figure  {\ref 2}). The important thing for the tester is to be aware that the static analysis measures can be used as early warning signals of how good the code is likely to be when it is finished. Static Analysis has got following advantages:\par
? Early detection of defects prior to test execution \hyperref[b13]{[14]}.\par
? Early warning about suspicious aspects of the code or design, by the calculation of metrics, such as a high complexity measure \hyperref[b13]{[14]}. ? Identification of defects not easily found by dynamic testing. ? Detecting dependencies and inconsistencies in software models, such as links \hyperref[b13]{[14]}. ? Improved maintainability of code and design.\par
? Prevention of defects provided that engineers are willing to learn from their errors and continuous improvement is practiced of defects. Typical defects discovered by static analysis include \hyperref[b15]{[17]} Figure  {\ref 2}: Static Analysis Potential Benefits \hyperref[b28]{[34]}.\par
Static Analysis is done using following approaches i. 
\section[{Coding Standards}]{Coding Standards}\par
This type of static analysis is conducted to verify adherence to coding standards. The first action to be taken is to define or adopt a coding standard \hyperref[b13]{[14]}. Usually a coding standard consists of a set of programming rules (e.g. 'Always check boundaries on an array when copying to that array'), naming conventions (e.g. 'Classes should start with capital C') and layout specifications (e.g. 'Indent 4 spaces'). It is recommended that existing standards are adopted. The main advantage of this is that it saves a lot of effort. An extra reason for adopting this approach is that if you take a well-known coding standard there will probably be checking tools available that support this standard. It can even be put the other way around: purchase a static code analyzer and declare (a selection of) the rules in it as your coding standard  {\ref [36]}. Without such tools, the enforcement of a coding standard in an organization is likely to fail. There are three main causes for this: the number of rules in a coding standard is usually so large that nobody can remember them all; some context-sensitive rules that demand reviews of several files are very hard to check by human beings; and if people spend time checking coding standards in reviews, that will distract them from other defects they might otherwise find, making the review process less effective.\par
ii. 
\section[{Code Metric}]{Code Metric}\par
The code metrics helps to measure structural attributes of the code. When the system becomes increasingly complex, it helps to decide the design alternatives, more so while redesigning portions of the code \hyperref[b13]{[14]}. Performing static code analysis, usually information is calculated about structural attributes of the code, such as comment frequency, depth of nesting, cyclomatic number and number of lines of code. This information can be computed not only as the design and code are being created but also as changes are made to a system, to see if the design or code is becoming bigger, more complex and more difficult to understand and maintain. The measurements also help us to decide among several design alternatives, especially when redesigning portions of existing code. There are many different kinds of structural measures, each of which tells us something about the effort required to write the code in the first place, to understand the code when making a change, or to test the code using particular tools or techniques.\par
Experienced programmers know that 20\% of the code will cause 80\% of the problems \hyperref[b30]{[37]}, and complexity analysis helps to find that all-important 20\%, which relate back to the principle on defect clustering. Complexity metrics identify high risk, complex areas. c) Code Structure There are many different kinds of structural measures, each of which tells us something about the effort required to write the code in the first place, to understand the code when making a change, or to test the code using particular tools or techniques. It is often assumed that a large module takes longer to specify, design, code and test than a smaller one \hyperref[b31]{[38]}. But in fact the code's structure plays a big part.\par
There are several aspects of code structure to consider:\par
? Control flow structure; ? Data flow structure; ? Data structure. 
\section[{i. Control Flow Analysis}]{i. Control Flow Analysis}\par
A control flow is an abstract representation of all possible sequence of events (paths) in the execution through a component or a system. This aspect of structure reflects the iterations and loops in a program's design \hyperref[b32]{[39]}. If only the size of a program is measured, no information is provided on how often an instruction is executed as it is run. Control flow analysis can also be used to identify unreachable (dead) code. It is worthy of note that most software code metrics are strongly related to the concept of structure of software code, e.g. number of nested levels or cyclomatic complexity \hyperref[b33]{[40]}. Control flow goes through basis blocks or nodes of code being executed as an entity, with an entry point in the beginning and only there, and with an exit point in the end and only there. The control goes from the starting point and is transferred from one block to another to the end. It can be very useful to draw a control flow graph from the code (or the requirements). It gives an overview over the decisions points, branches, and paths in a piece of code, and its inherit complexity. Some extracts of control flow graphs are shown here: Static analysis tools may be used to draw control flow graphs of larger pieces of code. It is, however, a good idea to train drawing these, because they give a good understanding of how the code is structured. A control flow graph does not necessarily give an idea of what the code is actually doing, but that is not important anyway. We as testers should concentrate on the structure, not the functionality. Static analysis tools can find faults in the control flow, typically:\par
? "Dead" code (i.e., code that cannot be reached during execution) ? Uncalled functions and procedures Both dead code and uncalled functions are quite often found in legacy systems \hyperref[b25]{[30]}. Undocumented changes and corrections have caused some code to be circumvented but not removed. The cause of the change is since forgotten, but nobody maintaining the code has had the courage (or initiative) to get the unused code removed. Such unused areas do not present direct risks. They do however disturb maintenance, and they may unintentionally be invoked with unknown consequences.\par
ii. Data Flow Analysis Data-flow analysis is a technique for gathering information about the possible set of values calculated at various points in a computer program \hyperref[b34]{[41]}. Data flow structure follows the trail of a data item as it is accessed and modified by the code. Using data flow measures it is shown how the data act as they are transformed by the program. Defects can be found such as referencing a variable with an undefined value and variables that are never used. The normal life cycle for a data item, a variable, consists of the phases:\par
? Declaration-Space is reserved in memory for the variable value ? Definition-A value is assigned to the variable ? Use-The value of the variable is used ? Destruction-The memory set aside for the value of the variable is freed for others to use Data-flow analysis derives information about the dynamic behavior of a program by only examining the static code  {\ref [42]}.\par
Static analysis can find anomalies in the data flow in relation to the variable life cycle. Anomalies may, for example, be:\par
? Use before declaration ? Use before definition ? Redefinition before use ? Use after destruction If a variable is defined and then redefined before use, is it because the first or the second definition is superfluous, or is it because a usage statement is missing? Some programming languages permit variables to be used before they are declared; in this case the first usage will be treated as an implicit declaration. The phases "definition" and "use" may be repeated many times during the life of a variable. Two different kinds of usage are defined in data flow analysis (see Figure \hyperref[fig_4]{4}  When the final test procedures are designed from the test cases, they will of course follow a path in the control flow through the code. There are a few pitfalls that we need to be aware of in connection with data flow analysis. Data items (variables) may be composed of a number of single variables. An important problem concerning data flow analysis is that sometimes static analysis tools will report a large number of anomalies that are not in fact caused by anything being wrong. These "false alarms" may hide the real problems in the sheer number of alarms.\par
iii. Data Structure Analysis Data structure refers to the organization of the data itself, independent of the program. When data is arranged as a list, queue, stack, or other well-defined structure, the algorithms for creating, modifying or deleting them are more likely to be well-defined, too. Thus, the data structure provides a lot of information about the difficulty in writing programs to handle the data and in designing test cases to show program correctness. That is, sometimes a program is complex because it has a complex data structure, rather than because of complex control or data flow. The process of identifying data structures requires human interpretation and intuition  {\ref [45]}. Data Structure Analysis is necessary as it greatly affects the performance of the algorithm which accesses it. Efficient storage greatly improves the performance of the overall system.\par
V. 
\section[{Conclusion}]{Conclusion}\par
In this paper we presented an in-depth review of static software testing techniques. We observed that using static techniques can be very useful and can yield excellent results if implemented in right manner in SDLC. One thing we have to make sure is that we use correct static technique at correct place (which technique to use, where to use it in SDLC). We should also acquaint ourselves well with details of static techniques (what is technique all about) then only can we select appropriate technique and implement that properly. We should also keep one thing in mind that static techniques and testing (dynamic) are complementary and not opposing verification techniques, so we should use static techniques to supplement testing process; Static techniques are about prevention while dynamic testing is about cure.\begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-2.png}
\caption{\label{fig_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3}\includegraphics[]{image-4.png}
\caption{\label{fig_2}Figure 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-5.png}
\caption{\label{fig_3}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4}\includegraphics[]{image-6.png}
\caption{\label{fig_4}Figure 4 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.2011160714285714\textwidth}P{0.6488839285714285\textwidth}}
Role\tabcellsep Role\\
Name\tabcellsep \\
\multicolumn{2}{l}{Manager Decides on the execution of reviews,}\\
\tabcellsep allocates time in project schedules and\\
\tabcellsep determines if the review objectives have\\
\tabcellsep been met.\\
\multicolumn{2}{l}{Moderator The person who leads the review of the}\\
\tabcellsep document or set of documents, including\\
\tabcellsep planning the review, running the meeting,\\
\tabcellsep and follow-up after the meeting. If\\
\tabcellsep necessary, the moderator may mediate\\
\tabcellsep between the various points of view and is\\
\tabcellsep often the person upon whom the success\\
\tabcellsep of the review rests.\\
Author\tabcellsep \end{longtable} \par
 
\caption{\label{tab_1}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{}
\end{longtable} \par
  {\small\itshape [Note: b) Static Analysis]} 
\caption{\label{tab_2}Table 2 :}\end{figure}
 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques ©2011 Global Journals Inc. (US)} 			\footnote{3W's of Static Software Testing Techniques} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[ IEEE Standard for Software Reviews]{b22}\label{b22} 	 		\textit{},  	 	 		\textit{IEEE Standard for Software Reviews}  		 	 	 (IEEE Computer Society) 
\bibitem[Pearson ()]{b12}\label{b12} 	 		\textit{},  		 			Pearson 		.  		2008. 864.  	 
\bibitem[Farooq et al. (2010 8)]{b6}\label{b6} 	 		‘610.12-1990 IEEE Standard Glossary of Software Engineering Terminology’.  		 			S U Farooq 		,  		 			S M K Quadri 		,  		 			Nesar Ahmad 		.  		 \xref{http://dx.doi.org/Identifier:10.1109/IEEESTD.1990.101064}{Identifier:10.1109/IEEESTD.1990.101064}.  	 	 		\textit{the Proceedings of 6th JK Science Congress},  				 (Srinagar)  		2010 8. IEEE Computer Society.  	 	 (Decisive Factors for Selecting Software Testing Techniques) 
\bibitem[Frankl and Weyuker ()]{b5}\label{b5} 	 		‘A formal analysis of the fault-detecting ability of testing methods’.  		 			P G Frankl 		,  		 			E J Weyuker 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		1993. 19  (3)  p. .  	 
\bibitem[Koza and Puschner ()]{b16}\label{b16} 	 		‘Calculating the maximum execution time of real-time programs’.  		 			C Koza 		,  		 			P Puschner 		.  	 	 		\textit{Real-Time Systems},  				1989. 1 p. .  	 
\bibitem[Fagan ()]{b23}\label{b23} 	 		‘Design and code inspections to reduce errors in program development’.  		 			M Fagan 		.  	 	 		\textit{IBM Syst. j}  		1976. 15  (3)  p. .  	 
\bibitem[Ryber ()]{b21}\label{b21} 	 		‘Essential Software Test Design’.  		 			Torbjörn Ryber 		.  	 	 		\textit{Fearless Consulting},  				2007.  	 
\bibitem[Farooq and Quadri ()]{b3}\label{b3} 	 		 			Farooq 		,  		 			S M K Quadri 		.  	 	 		\textit{Effectiveness of Software Testing Techniques on a Measurement Scale},  				2010. 3 p. .  	 
\bibitem[Graham et al. ()]{b13}\label{b13} 	 		 			Dorothy Graham 		,  		 			Van Veenendaal 		,  		 			Erik 		,  		 			Isabel Evans 		,  		 			Black Rex 		.  		\textit{Foundations of Software Testing: ISTQB Certification},  				 (Thomson)  		2006. 258.  	 
\bibitem[Hass ()]{b25}\label{b25} 	 		\textit{Guide to Advanced Software Testing},  		 			A M Hass 		.  		2008. ARTECH HOUSE, INC.  	 
\bibitem[Pham ()]{b33}\label{b33} 	 		\textit{Handbook of reliability engineering},  		 			Hoang Pham 		.  		2003. Springer-Verlag London. ISBN p. .  	 
\bibitem[Farooq et al. ()]{b8}\label{b8} 	 		‘Identifying some problems with selection of software testing techniques’.  		 			S U Farooq 		,  		 			Quadri 		,  		 			Smk 		.  	 	 		\textit{Oriental Journal of Computer Science \& Technology}  		2010. 3  (2)  p. .  	 
\bibitem[IEEE Standard 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology IEEE ()]{b27}\label{b27} 	 		‘IEEE Standard 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology’.  	 	 		\textit{IEEE}  		1990.  	 
\bibitem[Marchewka (2006)]{b26}\label{b26} 	 		‘Information Technology Project Management’.  		 			Jack T Marchewka 		.  		 \url{http://en.wikipedia.org/wiki/Software\textunderscore audit\textunderscore review}  	 	 		\textit{Software Audit Review}  		2006. 27 Dec 2010. John Wiley and Sons.  	 	 (INC.) 
\bibitem[Limaye ()]{b20}\label{b20} 	 		 			M Limaye 		.  		\textit{Software Testing: Principles, Techniques and Tools},  				 (Tata McGraw-Hill)  		2007.  	 
\bibitem[Living Glossary Standard for Software Component Testing (2011)]{b34}\label{b34} 	 		‘Living Glossary’.  		 \url{http://www.gerussell.com/technique\textunderscore data\textunderscore structure\textunderscore analysis.htm}  	 	 		\textit{Standard for Software Component Testing},  				10 Jan 2011 42. Jan 2011 43. Jan 2011 44. Jan 2011 45. 17 Jan 2011. p. 16.  	 	 (Technique -Data Structure Analysis) 
\bibitem[Hoffer ()]{b19}\label{b19} 	 		\textit{Modern Systems Analysis and Design},  		 			J Hoffer 		.  		2008. Pearson Education India.  	 
\bibitem[Chen and Yu ()]{b4}\label{b4} 	 		‘On the expected number of failures detected by sub domain testing and random testing’.  		 			T Y Chen 		,  		 			Y T Yu 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		1996. 22  (2)  p. .  	 
\bibitem[Ould ()]{b9}\label{b9} 	 		 			M Ould 		,  		 			Unwin 		,  		 			C 		.  		\textit{Testing in software development},  				1986. Cambridge Univ. Press.  	 
\bibitem[Park (1993)]{b17}\label{b17} 	 		‘Predicting program execution times by analyzing static and dynamic program paths’.  		 			C Y Park 		.  		 \url{http://www.test-resources.info/iseb-software-testing-review-process.php}  	 	 		\textit{Real-Time Systems},  				1993. 17 Dec 2010. 5 p. .  	 	 (Review process) 
\bibitem[Leveson ()]{b7}\label{b7} 	 		\textit{Safeware},  		 			Nancy Leveson 		.  		1995. Addison-Wesley Publishing Company.  	 
\bibitem[Sommerville]{b11}\label{b11} 	 		\textit{Software Engineering},  		 			I Sommerville 		.  		 	 
\bibitem[Gilb and Graham ()]{b24}\label{b24} 	 		‘Software Inspection’.  		 			Tom Gilb 		,  		 			Dorothy Graham 		.  		 \url{http://www.geekinterview.com/question\textunderscore details/70152}  	 	 		\textit{Types of Review}  		1993 29. 22 Dec 2010. Addison Wesley Longman, Inc.  	 
\bibitem[Jones (2010)]{b28}\label{b28} 	 		\textit{Software quality in 2010: Software Productivity Research LLC A survey of the state of art},  		 			Capers Jones 		.  		/2010-11/Jones-Nov-2010. Jan 2011.  	 	 (www.sqgne.org/presentations) 
\bibitem[Lerner (2010)]{b14}\label{b14} 	 		\textit{Software Reliability Methods},  		 			Sorin Lerner 		.  		 \url{http://cseweb.ucsd.edu/classes/sp06/cse291a/sorin-intro.ppt}  		11 Dec 2010.  	 
\bibitem[Roper ()]{b10}\label{b10} 	 		\textit{Software Testing},  		 			M Roper 		.  		1994. McGraw-Hill. 149.  	 
\bibitem[Quadri et al. (2010)]{b2}\label{b2} 	 		‘Software Testing -Goals, Principles, and Limitations’.  		 			S M Quadri 		,  		 			Farooq 		,  		 			Su 		.  	 	 		\textit{International Journal of Computer Applications}  		September 2010. 6  (9)  p. .  	 
\bibitem[Ainapure]{b31}\label{b31} 	 		\textit{Software testing and quality assurance},  		 			B S Ainapure 		.  		Technical Publications. p. .  	 
\bibitem[Naik and Tripathy]{b32}\label{b32} 	 		\textit{Software testing and quality Assurance},  		 			Kshirasagar Naik 		,  		 			Priyadarshi Tripathy 		.  		John Wiley \& sons, Inc.  	 
\bibitem[Edward ()]{b30}\label{b30} 	 		\textit{Software Testing in the Real World},  		 			Kit Edward 		.  		2006.  	 
\bibitem[Moonen (2011)]{b29}\label{b29} 	 		\textit{Static Analysis for Software Verification},  		 			Leon Moonen 		.  		 \url{http://www.uio.no/studier/emner/matnat/ifi/INF4290/v10/undervisningsmateriale/INF4290-StaticAnalysis.pdf}  		Jan 2011.  	 
\bibitem[Sasidhar (2010)]{b15}\label{b15} 	 		\textit{Static Techniques},  		 			K N Sasidhar 		.  		 \url{http://www.scribd.com/doc/4548375/Static-Testing-Techniques}  		10 Dec 2010.  	 
\bibitem[Myers]{b0}\label{b0} 	 		\textit{The art of software testing},  		 			Glenford J Myers 		.  		New York: Wiley.  	 	 (Publication info. Physical description: xi, 177 p.: ill. ; 24 cm) 
\bibitem[Hetzel ()]{b1}\label{b1} 	 		‘The Complete Guide to Software Testing’.  		 			William C Hetzel 		.  	 	 		\textit{QED Information Sciences},  				 (Wellesley, Mass)  		1988.  	 	 (2nd ed. Publication info. Physical description: ix, 280 p.: ill; 24 cm) 
\bibitem[Weinberg ()]{b18}\label{b18} 	 		‘The psychology of computer programming’.  		 			Gerald M Weinberg 		.  		 \xref{http://dx.doi.org/Identifier:10.1109/IEEESTD.2008.4601584}{Identifier:10.1109/IEEESTD.2008.4601584}.  	 	 		\textit{IEEE Standard for Software Reviews and Audits}  		1998. IEEE Computer Society. 292 p. .  	 	 (Digital Object) 
\end{bibitemlist}
 			 		 	 
\end{document}
