\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={Testability Assessment Model for Object Oriented Software based on Internal and External Quality Factors},
 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{2015-01-15 (revised: 15 January 2015)}
\def\TheID{\makeatother }
\def\TheDate{2015-01-15}
\title{Testability Assessment Model for Object Oriented Software based on Internal and External Quality Factors}
\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]{Harsha  Singhani}

             \author[2]{Dr. Pushpa R.  Suri}

             \affil[1]{  Kurukshetra University}

\renewcommand\Authands{ and }

\date{\small \em Received: 16 December 2014 Accepted: 5 January 2015 Published: 15 January 2015}

\maketitle


\begin{abstract}
        


Software testability is coming out to be most frequent talked about subject then the underrated and unpopular quality factor it used to be in past few years. The correct and timely assessment of testability can lead to improvisation of software testing process. Though many researchers and quality controllers have proved its importance, but still the research has not gained much momentum in emphasizing the need of making testability analysis necessary during all software development phases. In this paper we review and analyse the factors affecting testability estimation of object oriented software systems during design and analysis phase of development life cycle. These factors are then linked together in the form of new assessment model for object oriented software testability. The proposed model will be evaluated using analytical hierarchical process (AHP).

\end{abstract}


\keywords{software testability, testability factors, object oriented software testability assessment model.}

\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
estability is one of the qualitative factors of software engineering which has been accepted in  {\ref McCall} and Boehm software quality model, which build the foundation of ISO 9126 software quality model. Formally, Software testability has been defined and described in literature from different point of views IEEE \hyperref[b0]{[1]} defines it as "The degree to which a system or component facilitates the establishment of test criteria and performance of tests to determine whether those criteria have been met" and ISO \hyperref[b1]{[2]} has defined software testability as functionality or "attributes of software that bear on the effort needed to validate the software product".\par
In this paper we have proposed a testability evaluation model for assessment during design and analysis phase based on external quality factors and their relation with internal object oriented programming features which affect testability as shown earlier in our work \hyperref[b7]{[7]}.This paper is organized as follows: Section2 gives brief overview of software testability related work. Section3 gives the details of internal object oriented features needed for testability assessment followed by section 4 which gives the details of external quality factors linked and affected due to these features. Section 5 describes the proposed assessment model. It is followed by conclusion and future scope in section 6. 
\section[{II. Software Testability Related Work}]{II. Software Testability Related Work}\par
Software Testability actually acts as a software support characteristic for making it easier to test. As stated by Binder \hyperref[b8]{[8]} and Freedman \hyperref[b9]{[9]} a Testable Software is one that can be tested easily, systematically and externally at the user interface level without any adhoc measure. Whereas Voas \hyperref[b10]{[10]} describe it as complimentary support to software testing by easing down the method of finding faults within the system by focussing more on areas that most likely to deliver these faults. Hence, over the years Testability has been diagnosed as one of the core quality indicators, which leads to improvisation of test process. The insight provided by testability at designing, coding and testing phase is very useful as this additional information helps in product quality and reliability improvisation  {\ref [11][12]}. All this has lead to a notion amongst practitioners that testability should be planned early in the design phase though not necessarily so. As seen by experts like Binder it involves factors like controllability and observability i.e. ability to control software input and state along with possibility to observe the output and state changes that occur in software. So, overall testable software has to be controllable and observable \hyperref[b8]{[8]}. But Year 2015 
\section[{( )}]{( )} 
\section[{C}]{C}\par
The testability research actually is done from the prospect of reducing testing effort and testing cost which is more than 40\% of total development cost of any software \hyperref[b2]{[3]}. Still, the research in the field of testability has not been done in much detail. It mainly affects the efficiency of overall software development team from project managers, software designers to software testers. As they all need testability assessment in decision making, software designing, coding and testing \hyperref[b3]{[4]}.So keeping that in mind, we will take this study further. As discussed in our previous work about testability and testability metrics \hyperref[b5]{[5]}, \hyperref[b6]{[6]}, it has been found that testability research has taken a speed up in past few years only and much of the work has been done using various object oriented software metrics. over the years more such quality factors like understandability, traceability, complexity and testsupport capability have contributed to testability of a system \hyperref[b3]{[4]}.\par
Software testability measurement refers to the activities and methods that study, analyze, and measure software testability during a software product life cycle. Unlike software testing, the major objective of software testability measurement is to find out which software components are poor in quality, and where faults can hide from software testing. In the past, there were a number of research efforts addressing software testability measurement. Now these measurements can be applied at various phases during software development life cycle of a system. The studies mostly revolve around the measurement methods or factors affecting testability along with how to measure software testability at various phases like Design Phase \hyperref[b8]{[8]}, \hyperref[b12]{[12]}- \hyperref[b17]{[18]} and Coding Phase \hyperref[b18]{[19]}- \hyperref[b21]{[22]}. Lot of stress has been given upon usage of object oriented metrics for object oriented software testability evaluation during these researches. The metrics investigated related to object oriented software testability assessment mostly belong to static software metrics category. These metrics were mostly adapted from CK \hyperref[b22]{[23]}, MOOD \hyperref[b24]{[24]}, Brian \hyperref[b25]{[25]}, Henderson-Sellers \hyperref[b26]{[26]} metric suite along with others \hyperref[b27]{[27]}. Lot of empirical study has been done by researchers like Badri \hyperref[b28]{[28]}, Bruntink \hyperref[b29]{[29]} and Singh \hyperref[b30]{[30]} in showing the correlation of these metrics with unit testing effort. Few studies done by Baudry and Genero \hyperref[b31]{[31]}- \hyperref[b34]{[34]} have been focussed on UML diagram features from software testability improvisation prospect as found during review of these design diagrams. All this work has been explained in depth in our previous research work \hyperref[b3]{[4]}, \hyperref[b5]{[5]}.\par
We would take this study further keeping focus mainly on object oriented system as object oriented technology has become most widely accepted concept by software industry nowadays. But testability still is a taboo concept not used much amongst industry mainly due to lack of standardization, which may not be imposed for mandatory usage but just been looked upon for test support \hyperref[b35]{[35]}. We would actually like to propose a model for testability evaluation based on key programming features and quality factors which in turn make testing easier or difficult within this software. We have followed the steps as mentioned below to formalize the model:\par
? Identification of internal design features for object oriented software testability assessment\par
? Identification of static metrics out of many popular metrics for each of these.\par
? Identification of external factors affecting software testability.\par
? Establishing link between theses external quality factors and internal features which are evaluated through selected object oriented metrics. ? Establishing link between testability and these identified external factors which indirectly link it to identified internal features. ? The Model is followed with evaluation using AHP technique. 
\section[{III. Testability Factors Identification}]{III. Testability Factors Identification}\par
Before proposing the testability assessment model we have to first identify the key object oriented programming features which affect the testability at internal level. As already known the object oriented programming is based on three core concepts-Inheritance, Encapsulation and Polymorphism. Where, Inheritance is a mechanism for code reuse and to allow independent extensions of the original software via public classes and interfaces. Whereas, Polymorphism mainly provides the ability to have several forms, and Encapsulation an after effect of information hiding is actually play significant role in data abstraction by hiding all important internal specification of an object and showing only external interface. Now, a programming without these characteristics is distinctly not objectoriented that would merely be programming with some abstract data types and structured coding \hyperref[b36]{[36]}. But these are not the only factors directing the course of testing in object oriented software, along with them three more identified features namely coupling, cohesion and size complexity. All these features and their influence on testability has already been highlighted in our previous work \hyperref[b3]{[4]}, \hyperref[b5]{[5]}. Hence these six identified object oriented programming core features would be necessarily required to assess testability for object oriented software at design level. All these internal quality characteristics -Encapsulation, Inheritance, Coupling, Cohesion, Polymorphism and Size \& Complexity are as defined below in Table \hyperref[tab_0]{1along} with details of their specific relation on testability. The relation between these features and testability has been build based on thorough study of many publications \hyperref[b1]{[2]}, \hyperref[b19]{[20]}, \hyperref[b35]{[35]}, \hyperref[b38]{[38]}, \hyperref[b39]{[39]} Cohesion is one of the measures of goodness or good quality in the software as a cohesive module is more understandable and less complex. Low cohesion is associated with traits in programming such as difficult to maintain, test, reuse, and even understand. 
\section[{Size \& Complexity}]{Size \& Complexity}\par
It's the measure of size of the system in terms attributes or methods included in the class and capture the complexity of the class.\par
Size \& Complexity has a significant impact on understandability, and thus testability or maintainability of the system. 
\section[{Polymorphism}]{Polymorphism}\par
Polymorphism allows the implementation of a given operation to be dependent on the object that "contains" the operation such that an operation can be implemented in different ways in different classes.\par
Polymorphism reduces complexity and improves reusability. More use of polymorphism leads more test case generation \hyperref[b29]{[29]}. Now all the above mentioned key features can be measured by many object oriented metrics options available as discussed earlier in our previous article \hyperref[b6]{[6]}. Most of these metrics are accepted by practitioners on 'heavy usages and popularity' and by academic experts on empirical (post development) validation. But to keep study simple from further evaluation perspective we have suggested the few basic but popular metrics amongst testability researchers. Out of all the popular metrics suites discussed in our previous work \hyperref[b41]{[41]} few of these static metrics are as explained below in Table2 have been suggested for the evaluation of each of these feature and their effects on any object oriented software testability at design time.\par
As described in Table2 below for Encapsulation evaluation number of methods metrics (NOM) is being suggested by many researchers for the effect of information hiding on testability \hyperref[b15]{[16]}, \hyperref[b42]{[42]}. So we kept it for encapsulation evaluation for our model too. Inheritance is evaluated either using Number of Children metrics (NOC) or Depth of Inheritance Tree (DIT) two of the most popular and efficient inheritance metrics \hyperref[b21]{[22]}, \hyperref[b36]{[36]}, \hyperref[b41]{[41]}, \hyperref[b42]{[42]}. For Coupling we suggested coupling between objects (CBO) and for cohesion Li \& Henry Cohesion between Methods metrics version (LCOM). These two were the most sought after and unparalleled metrics available for assessing coupling and cohesion effect on testability as per literature study and popularity amongst industry practitioners \hyperref[b10]{[10]}, \hyperref[b19]{[20]}, \hyperref[b21]{[22]}, \hyperref[b24]{[24]}, \hyperref[b37]{[37]}, \hyperref[b43]{[43]}.Though Size \& Complexity can be easily measured by many metrics in this category such as number of classes (NOC) ,number of attributes (NOA), weighted method complexity (WMC) metrics but due to its significant role, popularity and association in number of test case indication pointed WMC is most appropriate \hyperref[b8]{[8]}, \hyperref[b28]{[28]}, \hyperref[b44]{[44]}. Polymorphism is one of the underlying factors affecting testability but as quite stressed by early researchers like Binder and others \hyperref[b8]{[8]}, \hyperref[b25]{[25]} as it results in testability reduction ,we suggest chose polymorphism factor metrics (POF/PF) one of the quick and reliable polymorphism evaluation method for testability assessment. Our proposed testability model is based on Dromey's software quality model \hyperref[b39]{[39]} which has been a benchmark in use for various quality features as well as many testability models so far. So, as discussed above we have already highlighted all the internal design features from testability perspective as pointed by many researchers. These features directly or indirectly affect the quality factors which further make software may or may not more testable. The studies indicate encapsulation promotes efficiency and complexity. Inheritance has a significant influence on the efficiency, complexity, reusability and testability or maintainability. While low coupling is considered good for understandability, complexity, reusability and testability or maintainability, whereas higher measures of coupling are viewed to adversely influence these quality attributes. Cohesion is viewed to have a significant effect on a design's understandability and reusability. 
\section[{Global Journal of C omp uter S cience and T echnology}]{Global Journal of C omp uter S cience and T echnology}\par
Size \& Complexity has a significant impact on understandability, and testability or maintainability. Polymorphism reduces complexity and improves reusability. Out of six identified features four features have been proposed in MTMOOD testability model \hyperref[b15]{[16]}, which does not cover the polymorphism and size \& complexity feature, which have also been found as essential internal features by many researchers in testability study \hyperref[b14]{[15]}, \hyperref[b21]{[22]}, \hyperref[b36]{[36]}, \hyperref[b37]{[37]}. These six object oriented features play a very significant role in testability improvisation directly or indirectly through other quality factors.\par
All the above mentioned studies lead to mainly six identified external quality factors to assess testability for object oriented software. These factors are -Controllability, Observability, Complexity, Understandability, Traceability and Built-in-Test. Most of these factors were pointed in Binder's \hyperref[b8]{[8]} research work on testability. Many other researchers established these factors relation too with testability as mentioned below in table \hyperref[tab_2]{3}.We have identified these factors keeping in mind significant role in testability as found out in our previous research work and surveys e have identified These factors get directly or indirectly affected by all of the above mentioned internal features and further complicate or reduce the task of testing hence reducing or increasing overall testability of the software. Controllability is an important index of testability as it makes testing easier \hyperref[b9]{[9]}, \hyperref[b47]{[47]}- \hyperref[b49]{[49]}. 
\section[{Observability}]{Observability}\par
Software observability indicates how easy to observe a program in terms of its operational behaviours, input parameters, and outputs. In the process of testing, there is a need to observe the internal details of software execution, to ascertain correctness of Observable software makes it feasible for the tester to observe the internal behaviour of the software, to the required degree of details, Hence observability increases testability in the system \hyperref[b9]{[9]}, \hyperref[b47]{[47]}, \hyperref[b49]{[49]}.\par
12 Global Journal of C omp uter S cience and T echnology Volume XV Issue V Version I Year ( )C\par
processing and to diagnose errors discovered during this process possibility to observe the output and state changes that occur in software. 
\section[{Complexity}]{Complexity}\par
It is basically described as the difficulty to maintain, change, understand and test software.\par
High Complexity of the system is actually an indicator of decreased system testability \hyperref[b43]{[43]}, \hyperref[b42]{[42]}, \hyperref[b50]{[50]}, \hyperref[b51]{[51]}. Understandability It is the degree to which the component under test is documented or self-explaining.\par
An understandable system is easily testable and [14], \hyperref[b52]{[52]}- \hyperref[b54]{[54]}. Traceability It is the degree to which the component under test is traceable in other words the requirements and design of a given software component match.\par
A non-traceable software system cannot be effectively tested, since relations between required, intended and current behaviours of the system cannot easily be identified \hyperref[b8]{[8]}, \hyperref[b44]{[44]}. Built In Test(BIT)\par
Built in testing involves adding extra functionality within system components that allow extra control or observation of the state of these components.\par
BIT actually provides extra test capability within the code for separation of test and application functionality which makes software more testable by better controllability and improved observability \hyperref[b8]{[8]}, \hyperref[b18]{[19]}, \hyperref[b55]{[55]}, \hyperref[b56]{[56]}.\par
Now after listing all the internal object oriented programming features which directly affect testability and all external quality factors which are also indicators of testable software, we have to identify the link between the two. As found on the basis of above literature survey the influence of all internal features over external quality features is briefly explained below in Table \hyperref[tab_3]{4} below: â??" Low I -High U â??" Low Cp- High U ? High Ch- High U â??" Big size - Low U - Traceability (T) â??" High E - Low T - â??" High Cp- Less T - â??" Low Size - More T - Built In test (BIT) ? High E -More BIT - ? High Cp- More BIT â??" High Ch- Less BIT - -\par
The table actually elaborates the contribution of each of these internal programming features towards the six major quality factors which are directly linked to testability. Hence we may say that Testability requires Low Coupling, Adequate Complexity, Good Understandability, High Traceability, Good observability, Adequate control and more Built in test. In spite of having lot of measurement techniques for testability evaluation using some or the factor or few of the above mentioned metrics, testability has not yet been found to be evaluated from these factor perspectives. The study still does not show an elaborative impact of all of them together for testability improvisation or test effort reduction which is what motivated us for proposing this new model.\par
So, the proposed testability assessment model with respect to internal design features using static metrics is based on six above mentioned object oriented features from testability perspective as pointed in Binders research too \hyperref[b8]{[8]}. The proposed model is as follows:  
\section[{Global}]{Global} 
\section[{Conclusion \& Future Scope}]{Conclusion \& Future Scope}\par
In this paper an evaluation model for testability assessment during design and analysis phase based on external factors and their relation with internal object oriented programming features has been proposed. These factors directly or indirectly affect testability and can be used for software testability measurement. On the basis of detailed study we may say that Testability requires Low Coupling, Adequate Complexity, Good Understandability, High Traceability, Good observability, Adequate control and more Built in test.\begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}CFigure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-3.png}
\caption{\label{figure3}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{1} \par 
\begin{longtable}{P{0.85\textwidth}}
10\end{longtable} \par
  {\small\itshape [Note: C]} 
\caption{\label{tab_0}Table 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{2} \par 
\begin{longtable}{P{0.85\textwidth}}
Year 2015\\
Volume XV Issue V Version I\\
( )\end{longtable} \par
  {\small\itshape [Note: C]} 
\caption{\label{tab_1}Table 2 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{3} \par 
\begin{longtable}{P{0.09639175257731958\textwidth}P{0.01533505154639175\textwidth}P{0.6396907216494845\textwidth}P{0.09858247422680412\textwidth}}
External\tabcellsep Factors\tabcellsep Definition\tabcellsep Significant Testability Relation in\\
\multicolumn{2}{l}{Affecting Testability}\tabcellsep \tabcellsep Literature\\
\multicolumn{2}{l}{Controllability}\tabcellsep It is the ability to control software input and\tabcellsep \\
\tabcellsep \tabcellsep state. During software testing, some conditions\tabcellsep \\
\tabcellsep \tabcellsep like disk full, network link failure etc. are difficult\tabcellsep \\
\tabcellsep \tabcellsep to test. Controllable software makes it possible\tabcellsep \\
\tabcellsep \tabcellsep to initialize the software to desired states, prior\tabcellsep \\
\tabcellsep \tabcellsep to the execution of various tests.\tabcellsep \end{longtable} \par
 
\caption{\label{tab_2}Table 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{4} \par 
\begin{longtable}{P{0.1597911227154047\textwidth}P{0.1154046997389034\textwidth}P{0.15091383812010442\textwidth}P{0.10652741514360312\textwidth}P{0.102088772845953\textwidth}P{0.008877284595300261\textwidth}P{0.05326370757180156\textwidth}P{0.1531331592689295\textwidth}}
\tabcellsep \tabcellsep \multicolumn{2}{l}{Affecting Testability}\tabcellsep \tabcellsep \tabcellsep \\
\tabcellsep Encapsulation\tabcellsep Inheritance\tabcellsep Coupling\tabcellsep \multicolumn{2}{l}{Cohesion}\tabcellsep Size (S)\tabcellsep Polymorphism\\
\tabcellsep (E)\tabcellsep (I)\tabcellsep (Cp)\tabcellsep \multicolumn{2}{l}{(Ch)}\tabcellsep \tabcellsep (P)\\
Controllability (Ct)\tabcellsep â??"\tabcellsep \tabcellsep â??"\tabcellsep ?\tabcellsep \tabcellsep \tabcellsep â??"\\
\tabcellsep High E-Low Ct\tabcellsep -\tabcellsep High Cp -\tabcellsep \multicolumn{2}{l}{High Ch-}\tabcellsep -\tabcellsep High P-Low Ct\\
\tabcellsep \tabcellsep \tabcellsep Low Ct\tabcellsep \multicolumn{2}{l}{High Ct}\tabcellsep \\
Observability (O)\tabcellsep â??"\tabcellsep ?\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep â??"\\
\tabcellsep High E -Low O\tabcellsep High I -High O\tabcellsep -\tabcellsep -\tabcellsep \tabcellsep -\tabcellsep High P-Low O\\
Complexity (Cx)\tabcellsep \tabcellsep â??"\tabcellsep ?\tabcellsep â??"\tabcellsep High\tabcellsep ?\tabcellsep â??"\\
\tabcellsep -\tabcellsep Low I -High\tabcellsep High Cp-\tabcellsep \multicolumn{2}{l}{Ch -}\tabcellsep Big S-\tabcellsep High P -\\
\tabcellsep \tabcellsep Cx\tabcellsep More Cx\tabcellsep \multicolumn{2}{l}{Reduce Cx}\tabcellsep More Cx\tabcellsep Reduce Cx\\
Understandability\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
(U)\tabcellsep -\tabcellsep \tabcellsep \tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
 
\caption{\label{tab_3}Table 4 :}\end{figure}
 			\footnote{© 2015 Global Journals Inc. (US) 1} 			\footnote{© 2015 Global Journals Inc. (US)} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Radatz et al. ()]{b0}\label{b0} 	 		\textit{},  		 			J Radatz 		,  		 			A Geraci 		,  		 			F Katki 		.  	 	 		\textit{IEEE Standard Glossary of Software Engineering Terminology}  		1990. 610 p. .  	 	 (IEEE Std) 
\bibitem[Softw and Eng ()]{b23}\label{b23} 	 		\textit{},  		 			Softw 		,  		 			Eng 		.  		1994. 20 p. .  	 
\bibitem[Henderson and Sellers ()]{b26}\label{b26} 	 		\textit{},  		 			B Henderson 		,  		 			Sellers 		.  		1996. New Jersey: Prentice Hall.  	 	 (Object-Oriented Metric) 
\bibitem[Booch et al. ()]{b36}\label{b36} 	 		\textit{},  		 			G Booch 		,  		 			R A Maksimchuk 		,  		 			M W Engle 		,  		 			B J Young 		,  		 			J Conallen 		,  		 			K A Houston 		.  	 	 		\textit{Object-Oriented Analysis and Design with Applications}  		2007. Addison Wesley. 1  (11) .  	 
\bibitem[Int and Conf ()]{b4}\label{b4} 	 		\textit{},  		 			Int 		,  		 			Conf 		.  	 	 		\textit{Comput. Appl. Syst. Model. Proc}  		2010. 15.  	 	 (Iccasm) 
\bibitem[Mouchawrab et al. (2005)]{b25}\label{b25} 	 		‘A measurement framework for object-oriented software testability’.  		 			S Mouchawrab 		,  		 			L C Briand 		,  		 			Y Labiche 		.  	 	 		\textit{Inf. Softw. Technol}  		April. 2005. 47 p. .  	 
\bibitem[Nazir et al. ()]{b52}\label{b52} 	 		‘A Metrics Based Model for Understandability Quantification’.  		 			M Nazir 		,  		 			R A Khan 		,  		 			K Mustafa 		.  	 	 		\textit{J. Comput}  		2010. 2  (4)  p. .  	 
\bibitem[Chidamber and Kemerer]{b22}\label{b22} 	 		‘A Metrics Suite for Object Oriented Design’.  		 			S R Chidamber 		,  		 			C F Kemerer 		.  	 	 		\textit{IEEE Trans}  		 	 
\bibitem[Dromey ()]{b39}\label{b39} 	 		‘A Model for Software Product Quality’.  		 			R G Dromey 		.  	 	 		\textit{IEEE Transactions on Software Engineering}  		1995. 21 p. .  	 
\bibitem[Genero et al. ()]{b32}\label{b32} 	 		‘A survey of metrics for UML class diagrams’.  		 			M Genero 		,  		 			M Piattini 		,  		 			C Calero 		.  	 	 		\textit{J. Object Technol}  		2005. 4  (9)  p. .  	 
\bibitem[Badri et al. ()]{b21}\label{b21} 	 		‘An empirical analysis of a testability model for object-oriented programs’.  		 			M Badri 		,  		 			A Kout 		,  		 			F Toure 		.  	 	 		\textit{ACM SIGSOFT Softw. Eng. Notes}  		2011. 36  (4)  p. 1.  	 
\bibitem[Badri et al. ()]{b46}\label{b46} 	 		‘An empirical analysis of lack of cohesion metrics for predicting testability of classes’.  		 			L Badri 		,  		 			M Badri 		,  		 			F Toure 		.  	 	 		\textit{Int. J. Softw. Eng. its Appl}  		2011. 5  (2)  p. .  	 
\bibitem[Voas et al. ()]{b50}\label{b50} 	 		‘An Empirical Comparison of a Dynamic Software Testability Metric to Static Cyclomatic Complexity’.  		 			J M Voas 		,  		 			J M Voas 		,  		 			K W Miller 		,  		 			K W Miller 		,  		 			J E Payne 		,  		 			J E Payne 		.  	 	 		\textit{Proc. 2nd Int\&apos;l. Conf. Softw. Qual. Manag},  				 (2nd Int\&apos;l. Conf. Softw. Qual. Manag)  		1994. p. .  	 
\bibitem[Bruntink and Vandeursen ()]{b29}\label{b29} 	 		‘An empirical study into class testability’.  		 			M Bruntink 		,  		 			A Vandeursen 		.  	 	 		\textit{J. Syst. Softw}  		2006. 79 p. .  	 
\bibitem[Genero et al.]{b45}\label{b45} 	 		\textit{An Empirical Study to Validate Metrics for Class Diagrams},  		 			M Genero 		,  		 			M Piattini 		,  		 			C Calero 		.  		 	 
\bibitem[Nazir and Mustafa ()]{b42}\label{b42} 	 		‘An Empirical Validation of Testability Estimation Model’.  		 			M Nazir 		,  		 			K Mustafa 		.  	 	 		\textit{Int. J. Adv. Res. Comput. Sci. Softw. Eng}  		2013. 3  (9)  p. .  	 
\bibitem[Khalid et al. ()]{b43}\label{b43} 	 		‘Analysis of object oriented complexity and testability using object oriented design metrics’.  		 			S Khalid 		,  		 			S Zehra 		,  		 			F Arif 		.  	 	 		\textit{Proceedings of the 2010 National Software Engineering Conference on -NSEC '10},  				 (the 2010 National Software Engineering Conference on -NSEC '10)  		2010. p. .  	 
\bibitem[Goel et al. ()]{b48}\label{b48} 	 		‘COTT -A Testability Framework for Object-Oriented Software Testing’.  		 			A Goel 		,  		 			S C Gupta 		,  		 			S K Wasan 		.  	 	 		\textit{Int. Jounal Comput. Sci}  		2008. 3  (1)  p. .  	 
\bibitem[Patidar et al. ()]{b7}\label{b7} 	 		‘Coupling and Cohesion Measures in Object Oriented Programming’.  		 			M Patidar 		,  		 			R Gupta 		,  		 			G Chandel 		.  	 	 		\textit{Int. J. Adv. Res. Comput. Sci. Softw. Eng}  		2013. 3  (3)  p. .  	 
\bibitem[Saaty ()]{b57}\label{b57} 	 		‘Decision making with the analytic hierarchy process’.  		 			T L Saaty 		.  	 	 		\textit{Int. J. Serv. Sci}  		2008. 1  (1)  p. 83.  	 
\bibitem[Mulo ()]{b14}\label{b14} 	 		\textit{Design for testability in software systems},  		 			E Mulo 		.  		2007.  	 
\bibitem[Binder ()]{b8}\label{b8} 	 		‘Design For Testabity in Object-Oriented Systems’.  		 			R Binder 		.  	 	 		\textit{Commun. ACM}  		1994. 37 p. .  	 
\bibitem[Fernando ()]{b27}\label{b27} 	 		‘Design Metrics for OO software system’.  		 			A Fernando 		.  	 	 		\textit{ECOOP'95, Quant. Methods Work},  				1995.  	 
\bibitem[Esposito ()]{b12}\label{b12} 	 		\textit{Design Your Classes For Testbility},  		 			D Esposito 		.  		2008.  	 
\bibitem[Badri (2012)]{b28}\label{b28} 	 		‘Empirical Analysis of Object-Oriented Design Metrics for Predicting Unit Testing Effort of Classes’.  		 			M Badri 		.  	 	 		\textit{J. Softw. Eng. Appl}  		July. 2012. 05 p. .  	 
\bibitem[Sheppard and Kaufman ()]{b35}\label{b35} 	 		‘Formal specification of testability metrics in IEEE P1522’.  		 			J W Sheppard 		,  		 			M Kaufman 		.  	 	 		\textit{IEEE Autotestcon Proceedings. IEEE Syst. Readiness Technol. Conf. (Cat. No.01CH37237)},  				2001. 2001. p. .  	 
\bibitem[Bach ()]{b54}\label{b54} 	 		\textit{Heuristics of Software Testability},  		 			J Bach 		.  		2003. p. 2003.  	 
\bibitem[Voas and Miller ()]{b11}\label{b11} 	 		‘Improving the software development process using testability research’.  		 			J M Voas 		,  		 			K W Miller 		.  	 	 		\textit{Softw. Reliab. Eng}  		1992. ?, 1992.  	 
\bibitem[Baudry et al. ()]{b31}\label{b31} 	 		‘Improving the testability of UML class diagrams’.  		 			B Baudry 		,  		 			Y Le Traon 		,  		 			G Sunye 		.  	 	 		\textit{First Int. Work. onTestability Assessment}  		2004. IWoTA 2004. 2004.  	 	 (Proceedings.) 
\bibitem[Kansomkeat et al. ()]{b49}\label{b49} 	 		‘INCREASING CLASS-COMPONENT TESTABILITY’.  		 			S Kansomkeat 		,  		 			J Offutt 		,  		 			W Rivepiboon 		.  	 	 		\textit{Proceedings of 23rd IASTED International Multi-Conference},  				 (23rd IASTED International Multi-Conference)  		2005. p. .  	 
\bibitem[Jeon ()]{b55}\label{b55} 	 		\textit{Increasing the Testability of Object-Oriented Frameworks with Built-in Tests},  		 			T Jeon 		.  		2002. p. .  	 	 (Building) 
\bibitem[Briand et al. ()]{b37}\label{b37} 	 		‘Investigating quality factors in objectoriented designs: an industrial case study’.  		 			L C Briand 		,  		 			J Wust 		,  		 			S V Ikonomovski 		,  		 			H Lounis 		.  	 	 		\textit{Proc. 1999 Int. Conf. Softw. Eng. (IEEE Cat. No.99CB37002)},  				 (1999 Int. Conf. Softw. Eng. (IEEE Cat. No.99CB37002))  		1999.  	 
\bibitem[ISO/IEC 9126: Software Engineering Product Quality ()]{b1}\label{b1} 	 		\textit{ISO/IEC 9126: Software Engineering Product Quality},  				2002.  	 
\bibitem[Mathur ()]{b2}\label{b2} 	 		 			A P Mathur 		.  		\textit{Foundations of Software Testing, Second. Pearson},  				2013.  	 
\bibitem[Baudry and Le Traon ()]{b33}\label{b33} 	 		‘Measuring design testability of a UML class diagram’.  		 			B Baudry 		,  		 			Y Le Traon 		.  	 	 		\textit{Inf. Softw. Technol}  		2005. 47  (13)  p. .  	 
\bibitem[Mayer and Hall ()]{b24}\label{b24} 	 		‘Measuring OO systems: a critical analysis of the MOOD metrics’.  		 			T Mayer 		,  		 			T Hall 		.  	 	 		\textit{Proc. Technol. Object-Oriented Lang. Syst. TOOLS}  		1999. 29.  	 
\bibitem[Khan and Mustafa ()]{b15}\label{b15} 	 		‘Metric based testability model for object oriented design (MTMOOD)’.  		 			R A Khan 		,  		 			K Mustafa 		.  	 	 		\textit{ACM SIGSOFT Softw. Eng. Notes}  		2009. 34  (2)  p. 1.  	 
\bibitem[Nguyen et al. ()]{b47}\label{b47} 	 		 			T B Nguyen 		,  		 			M Delaunay 		,  		 			C Robach 		.  	 	 		\textit{Testability Analysis of Data-Flow Software},  				2005. 116 p. .  	 
\bibitem[Khan and Khan ()]{b51}\label{b51} 	 		‘Object Oriented Design Complexity Quantification Model’.  		 			S A Khan 		,  		 			R A Khan 		.  	 	 		\textit{Procedia Technol}  		2012. 4 p. .  	 
\bibitem[Suri and Singhani ()]{b6}\label{b6} 	 		‘Object Oriented Software Testability ( OOSTe ) Metrics Analysis’.  		 			P R Suri 		,  		 			H Singhani 		.  	 	 		\textit{Int. J. Comput. Appl. Technol. Res}  		2015. 4  (5)  p. .  	 
\bibitem[Suri and Singhani ()]{b5}\label{b5} 	 		‘Object Oriented Software Testability Survey at Designing and Implementation Phase’.  		 			P R Suri 		,  		 			H Singhani 		.  	 	 		\textit{Int. J. Sci. Res}  		2015. 4  (4)  p. .  	 
\bibitem[Singhani and Suri ()]{b41}\label{b41} 	 		‘Object Oriented SoftwareTestability (OOSTe) Metrics Assessment Framework’.  		 			H Singhani 		,  		 			P R Suri 		.  	 	 		\textit{Int. J. Adv. Res. Comput. Sci. Softw. Eng}  		2015. 5  (4)  p. .  	 
\bibitem[Wang et al. ()]{b18}\label{b18} 	 		‘On testable object-oriented programming’.  		 			Y Wang 		,  		 			G King 		,  		 			I Court 		,  		 			M Ross 		,  		 			G Staples 		.  	 	 		\textit{ACM SIGSOFT Softw. Eng. Notes}  		1997. 22  (4)  p. .  	 
\bibitem[Singh and Saha ()]{b30}\label{b30} 	 		‘Predicting Testability of Eclipse: Case Study’.  		 			Y Singh 		,  		 			A Saha 		.  	 	 		\textit{J. Softw. Eng}  		2010. 4  (2)  p. .  	 
\bibitem[Fu et al.]{b3}\label{b3} 	 		\textit{Present and future of software testability analysis},  		 			J Fu 		,  		 			B Liu 		,  		 			M Lu 		.  		 ICCASM 2010 -2010.  		 	 
\bibitem[Vincent and King ()]{b56}\label{b56} 	 		\textit{Principles of Built-In-Test for Run-Time-Testability in Component-Based Software Systems},  		 			J Vincent 		,  		 			G King 		.  		2002. p. .  	 
\bibitem[Nazir and Khan ()]{b40}\label{b40} 	 		‘Software Design Testability Factors: A New Perspective’.  		 			M Nazir 		,  		 			R A Khan 		.  	 	 		\textit{Proceddings of Naional Third Conference INDIACOM},  				 (eddings of Naional Third Conference INDIACOM)  		2009. 2009. p. .  	 
\bibitem[Rosenberg and Hyatt ()]{b38}\label{b38} 	 		\textit{Software quality metrics for object-oriented environments},  		 			L Rosenberg 		,  		 			L Hyatt 		.  		1997.  	 
\bibitem[Voas and Miller ()]{b10}\label{b10} 	 		‘Software Testability : The New Verification’.  		 			J M Voas 		,  		 			K W Miller 		.  	 	 		\textit{IEEE Softw}  		1995. 12  (3)  p. .  	 
\bibitem[Bach ()]{b53}\label{b53} 	 		\textit{Test Plan Evaluation Model},  		 			J Bach 		.  		1999. p. .  	 
\bibitem[Baudry et al. ()]{b34}\label{b34} 	 		‘Testability analysis of a UML class diagram’.  		 			B Baudry 		,  		 			Y Le Traon 		,  		 			G Sunye 		.  	 	 		\textit{Proc. Eighth IEEE Symp. Softw. Metrics},  				 (Eighth IEEE Symp. Softw. Metrics)  		2002.  	 
\bibitem[Jungmayr and Pettichord ()]{b13}\label{b13} 	 		\textit{Testability during Design},  		 			S Jungmayr 		,  		 			; B Pettichord 		.  		2002. 2002. p. .  	 	 (Design for Testability. Pettichord.com) 
\bibitem[Nazir et al. ()]{b16}\label{b16} 	 		‘Testability Estimation Framework’.  		 			M Nazir 		,  		 			R A Khan 		,  		 			K Mustafa 		.  	 	 		\textit{Int. J. Comput. Appl}  		2010. 2  (5)  p. .  	 
\bibitem[Bruntink ()]{b44}\label{b44} 	 		\textit{Testability of Object-Oriented Systems : a Metrics-based Approach},  		 			M Bruntink 		.  		2003.  		 			Universiy Van Amsterdam 		 	 
\bibitem[Freedman ()]{b9}\label{b9} 	 		‘Testability of software components -Rewritten’.  		 			R S Freedman 		.  	 	 		\textit{IEEE Trans. Softw. Eng}  		1991. 17  (6)  p. .  	 
\bibitem[Harman et al. ()]{b20}\label{b20} 	 		‘Testability Transformation: Program Transformation to Improve Testability’.  		 			M Harman 		,  		 			A Baresel 		,  		 			D Binkley 		,  		 			R Hierons 		.  	 	 		\textit{Formal Method and Testing},  				2011. p. .  	 
\bibitem[Payne et al. ()]{b17}\label{b17} 	 		\textit{The above proposed model requires to be evaluated using some technique which helps in validating these criteria's, sub-criteria's and their significant quantifiable role in testability assessment. We may use one of the formal Multi criteria decision making (MCDM) technique proposed by Satty},  		 			J E Payne 		,  		 			R T Alexander 		,  		 			C D Hutchinson 		.  		1997. 7 p. .  	 	 (Design-for-Testability for Object-Oriented Software. 57] known as Analytic Hierarchy Process (AHP) 
\bibitem[Baudry et al. ()]{b19}\label{b19} 	 		‘Towards a ' Safe ' Use of Design Patterns to Improve OO Software Testability’.  		 			B Baudry 		,  		 			Y Le Traon 		,  		 			G Sunye 		,  		 			JM 		.  	 	 		\textit{ISSRE 2001. Proceedings. 12th Int. Symp},  				2001. 2001. p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
