\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={Review Paper on Various Software Testing Techniques \& Strategies},
 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{2019-01-15 (revised: 15 January 2019)}
\def\TheID{\makeatother }
\def\TheDate{2019-01-15}
\title{Review Paper on Various Software Testing Techniques \& Strategies}
\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]{Nahid  Anwar}

             \author[2]{Susmita  Kar}

             \affil[1]{  Bangladesh University of Business and Technology(BUBT).}

\renewcommand\Authands{ and }

\date{\small \em Received: 6 December 2018 Accepted: 4 January 2019 Published: 15 January 2019}

\maketitle


\begin{abstract}
        


Software testing is the process of running an application with the intent of finding software bugs (errors or other defects). Software applications demand has pushed the quality assurance of developed software towards new heights. It has been considered as the most critical stage of the software development life cycle. Testing can analyze the software item to identify the disparity between actual and prescribed conditions and to assess the characteristics of the software. Software testing leads to minimizing errors and cut down software costs. For this purpose, we discuss various software testing techniques and strategies. This paper aims to study diverse as well as improved software testing techniques for better quality assurance purposes.

\end{abstract}


\keywords{testing techniques, testing tools, verification, validation, level of testing, debugging, software testing objectives, software testing principles.}

\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 development involves developing software against a set of requirements. Software testing is needed to verify and validate that the software that has been built to meet these specifications. Software testing helps in the prevention of errors in a system. It refers to the process of evaluating the software to find out the error in it. It is also used to analyze the software for other aspects of the software like usability, compatibility, reliability, integrity, efficiency, security, capability, portability, maintainability, etc. Software testing aims at achieving specific goals and principles which are to be followed. In simple words, testing is the process of locating errors in the program. Software Testing is executing the software to (i) perform verification, (ii) to detect the mistakes and (iii) to achieve validation.\par
i. Verification: It is the process of checking the software concerning the specification. [Verification: Are we making the product, right?] ii.\par
Error Detection: It is the process of deliberately performing the wrong inputs to check the system's performance. iii.\par
Validation: It is the process of checking software concerning the customer's expectation. [Validation: Are we making the right product?] Testing is characterized as a process of assessment that either the definitive system meets it's specified fulfillments initially or not. It is mainly a system beset with the validation and verification process that whether the developed system meets the fulfillments defined by the customers. Therefore, this activity draws the difference between the actual and expected result. So, this is an analysis that provides the associates with the proper knowledge about the quality of the product. Software Testing can also be defined as a risk-based activity. The testing cost and errors can be found in a relationship in figure \hyperref[fig_0]{1}. It is apparently demonstrated that cost rises dramatically in a testing (functional and nonfunctional). The compelling testing goal is to do the optimal amount of tests so that additional testing endeavor can be minimized. From Figure \hyperref[fig_0]{1}, we can say that Software testing is an essential factor in software quality assertion. Bug: It means that when a developer makes the error while coding. It is the state which is responsible for the failure of the specific function.\par
Fault: It is the representation of the error, where representation is the mean of expression that may be diagrams, flow charts, etc.\par
Failure: Failure occurs when a fault is executed. 
\section[{b) Software Testing Objectives}]{b) Software Testing Objectives}\par
The fundamental objective of software testing is to provide a quality product regarding the reliability estimation and complete verification and validation of the product. The secondary aim of testing includes executing a program with the intent of finding errors and producing a test case which is capable of detecting the undiscovered error as yet. 
\section[{II.}]{II.} 
\section[{Literature Review}]{Literature Review}\par
In this section, we will outline the previous works of Software Testing. According to "The Theory of Software Testing", testing is the means of showing the presence of errors in the program which can either be performed manually or automatically. It also includes the basic terminology of testing such as automated testing, failure, testing team, and wrong test case selection. This paper focuses on the process that should be followed to test the performance of new software and the entire system. The conclusion of the article is the complete view of software testing, preliminary testing, and user acceptance testing. 
\section[{III.}]{III.} 
\section[{Software Testing Methodologies}]{Software Testing Methodologies}\par
The importance of software testing to software quality cannot be overemphasized. After the development of the code, it is mandatory to test the software to identify all the errors, and they must be debugged before the release of the software. Although it is impossible to identify and debug all the errors in the significant software at every phase, it is tried to remove all the mistakes as possible. Testing helps in finding the bugs; it cannot conclude that the software is bug-free. We broadly categorized testing techniques into two parts:  Internal specifications and structures of the system are created conspicuous. So, it's acutely costeffective in detecting and resolving problems. Bugs will be found before they cause bickering. Thus, we will summarize this approach as testing software with the data of its internal structure and coding. White box testing is also familiar as precise box analysis or white box analysis or glass box testing or transparent box testing, and structural testing. It's an approach for finding errors within which the tester has complete data. This technique isn't used much for debugging in large systems and networks. Different types of white box testing include basis path, loop testing, control structure testing, etc. White-box testing tests internal constructions or workings of a program because programming skills and the domestic context of the system are used to design test cases. The tester appoints inputs to apply paths through the code and finalize the appropriate outputs. This is akin to testing nodes in a circuit. White-box Testing can be used at the unit, integration and system levels of the software testing process. It usually is done at the unit level. Although this approach of testing can expose many errors, it may not identify the missing requirements and unimplemented parts of the specification. 
\section[{White-box Testing includes the following approaches:}]{White-box Testing includes the following approaches:}\par
? Application Programming Interface testing tests the application using public and private APIs by creating tests to satisfy some criteria for code coverage. ? Fault Injection Methods -Introducing faults to gauge the efficacy of testing strategies intentionally. ? Code coverage tools can assess the integrity of a test suite that was created with any method, including black-box testing. This grants the software team to check the parts of a system that are rarely tested and assures that the most important function points have been verified. ? Function coverage is the approach which informs on functions that have been executed. ? Statement coverage is the approach which informs the number of lines executed to complete the test 100 per cent. It assures that all code paths or branches are executed at least once. This helps to ensure correct functionality. 
\section[{Advantages:}]{Advantages:}\par
1. It exposes an error that is hidden in code by eliminating extra lines of code. 2. Maximum coverage is obtained during test outline writing. 3. The developer discreetly gives reasons for implementation. 
\section[{Disadvantages:}]{Disadvantages:}\par
1. An experienced tester is required to carry out this procedure because knowledge of internal structure is needed. 2. Many paths will remain untested since it is challenging to look into every pros and con. 
\section[{b) Black Box testing}]{b) Black Box testing}\par
A black box testing is a testing in which internal specifics and workings aren't known or accessible to its customer. It supports specifications and output needs. The fundamental purpose is to identify the requirements of the system. Black box testing has very little or no data on the inner logical structure of the system. Thus, it solely checks the basic features of the system. It assures that every input is appropriately accepted and outputs are correctly produced.  {\ref Black} 3. Programmer and validators both are independent of each other. 
\section[{Disadvantages:}]{Disadvantages:}\par
1. Test cases are difficult to design without fair stipulations. 2. Probability of having the repetition of tests that are already done by the programmer. 3. Here, some parts of the back end are not tested at all. 
\section[{c) Grey-Box Testing}]{c) Grey-Box Testing}\par
Gray box testing is the technique of testing the software with limited knowledge of the internal structure and design of the application. It is defined as a testing software package which has some data of its internal logic and underlying code. It uses internal information structures and algorithms. This approach holds necessary conducting integration testing between two or more modules of code written by totally different developers. This approach includes reverse engineering to work out on the boundary values. Grey box testing is unbiased and non-intrusive.\par
Grey-box Testing has the knowledge of internal data structures and algorithms for purposes of designing tests while executing those tests at the user level. The tester does not have full access to the software's source code. The following are some subtypes of grey-box testing:  
\section[{Disadvantages:}]{Disadvantages:}\par
1. Test coverage is limited because the access to source code is not available. 2. Many program paths remain untested. 3. The test cases can be redundant. 
\section[{Nonfunctional Testing Techniques:}]{Nonfunctional Testing Techniques:}\par
It is a type of testing which is performed to test various attributes of a system like stress, load, etc. Nonfunctional testing is performed at all test levels. It is concerned with the nonfunctional requirements and is explicitly modeled to assess the readiness of a system according to the various criteria which are not covered by functional testing.\par
a) Performance Testing: It assesses the entire performance of the system. It is used to evaluate the system's performance under a specific workload. b) Load testing: A load test is performed to ensure the load taking the capacity of a particular order. Load testing is performed to determine the behavior of the system under normal as well as peak load conditions. c) Endurance Testing. It is the type of testing performed to determine the system's behavior after a particular time. For example, a method is working perfectly fine in the initial first hour, but the performance decreased after three hours of execution. d) Stress Testing: It is performed to determine the system performance beyond standard operational capacity, often to a breaking point. It is concerned with the system's load taking ability. e) Security Testing: Security testing is done to assess that the system is safe or not. It is a process that is concerned with the fact that an information system protects data and maintains functionality as intended. f) Recovery Testing: Recovery testing is performed to check the recovery of the system after the crash or hardware failure. In this type, the software is forced to fail under a given circumstance and then finally, the recovery is tested.  harmony of the developed system with the various other components such as hardware, additional software, DBMS and operating system, etc.\par
IV. 
\section[{Software Testing Strategies}]{Software Testing Strategies}\par
Software Testing strategies provide a method of integrating software test case design methods into a well-planned Series of steps that can result in the successful construction of software. It provides the road map for testing. The software testing Strategy should be pliable enough to develop a customized testing approach. The software testing strategy is actually produced by project managers, software engineers, and testing specialists. There are four different types of software testing strategies: 1) Unit testing 2) Integration testing 3) Acceptance/Validation testing 4) System testing 
\section[{Unit testing}]{Unit testing}\par
Unit is the smallest testable part, i.e. the most modest collection of lines of code which can be tested. Unit testing is done by the developer as the proper knowledge about the core programming designing is required. Generally, unit testing is considered as a white-box testing class because it is partisan to evaluate the code as implemented rather than assessing conformance to some set of requirements. 
\section[{Benefits of Unit Testing:}]{Benefits of Unit Testing:}\par
1) Cost-effective testing technique.\par
2) Simple testing technique because the smallest testable unit of the code is tested here. 3) Individual parts are tested when necessary, without waiting for another part of the system. 4) Unit testing can be performed in parallel by fixing problems simultaneously by many engineers. 5) Detection and removal of defects are much costeffective compared to other levels of testing. 6) Be able to take advantage of several formal testing approaches available for unit testing. 7) Clarify debugging by limiting to a small unit the possible code areas in which to search for bugs. 8) Be able to test internal logic that is not easily reached by external inputs in the broader integrated systems. 9) Attain a high level of structural coverage of the code. 10) When debugging severe problems, it avoids lengthy compile-build-debug cycles.  
\section[{Acceptance testing}]{Acceptance testing}\par
In this approach, testing is carried out to authenticate whether the product is developed as per the standards and detailed criteria and meets all the requirements specified by the user. The user carries this Year 2 019 ( ) type of testing where the product is developed externally by the third party. Acceptance testing falls under the black-box testing approach, where the user is not very much involved in the internal working of the scheme. Acceptance testing approach is also known as validation testing, QA testing, final testing, factory acceptance testing and application testing, etc. In software engineering, acceptance testing may be executed at two different levels; one at the system provider level and another at the end-user level. 
\section[{Classification of Acceptance Testing:}]{Classification of Acceptance Testing:}\par
i. User Acceptance Testing: User acceptance testing is an essential step before the system is finally deployed to the end-user. User acceptance testing is generally done by the actual software uses to ensure that it can handle the specified task in the real world scenarios. ii. Alpha Testing \& Beta Testing: QA teams or developers generally have done this type of testing. Unit testing, Integration testing and System testing combine name as alpha testing. Alpha testing is conducted in the presence developers and in the absence of users. In this testing, the following criteria are examined such as spelling mistakes, broken lines, cloudy direction etc. After completing the alpha testing successfully, beta testing is performed. Beta testing is conducted by real users who actually handle the software in realworld scenarios. The customers provide their assessment to the developer for the outcome of the experiment. It is also known as field testing. Feedback from the users is used to improve the performance of the system/product before it is released to other users/customers. iii. Operational Acceptance Testing: Operational acceptance testing (functional preparedness testing) is an approach of assuring all the specified processes and procedures of the system are in place to allow user/tester to use it. iv. Contact and Regulation Acceptance Testing:\par
The system is tested against the required criteria as mentioned in the contract document and also proved to check if it meets all the government and local authority rules and regulations, even all the essential standards. 
\section[{System testing}]{System testing}\par
System testing is a level of software or hardware testing where testing is conducted on a complete, integrated system to assess the system's compliance with its specified requirements. System testing falls within the category of black-box testing. The purpose of system testing is to evaluate the system compliance against the specified requirements. Some of the Different types of system testing are as follows:\par
i. Recovery testing ii.\par
Security testing iii.\par
Graphical user interface testing iv.\par
Compatibility testing i. Recovery Testing: In this process of testing an application is able to recover from crashes, hardware failures and other similar problems. If recovery is automatic, re-initialization, checkpointing mechanisms, data recovery, and restart are evaluated for correctness. Recovery testing force the software to fail in a variety of ways to assess that reconstruction is performed correctly. ii. Security testing: Security testing tries to evaluate those protection mechanisms built into a system will protect it from erroneous penetration. During security testing, the tester individually desires to penetrate the system. The validator may try to acquire passwords through external clerical means; may attack the order with custom software designed to breakdown any defenses that have been constructed; may overwhelm the system, thereby denying service to others; The goal of security testing is to identify the threats in the system and measure its potential vulnerabilities. iii. Graphical user interface testing: In this testing approach, the product's graphical user interface is involved to ensure it meets its written specifications. GUI testing attempts to check the screens with the controls like menus, buttons, icons, and all types of bars -toolbar, menu bar, dialogue boxes, and windows, etc. iv. Compatibility testing: Compatibility testing is concerned with checking the system's compatibility with the rest of the environment. It checks the harmony of the developed system with the various other components such as hardware, additional software, DBMS and operating system, etc.\par
V. 
\section[{Discussion}]{Discussion}\par
In this section, the difference between testing and debugging is shown. Software testing is a process of executing a program in order to identify whether it meets the specified requirement or not. The test case design is conducted, a strategy can be defined, and results can be evaluated against prescribed expectations. Debugging is the process of fixing the problems that are found during the software testing process. It is a consequence of successful testing. That is when testing uncovers a defect, debugging is the process that leads to the removal of the error. The debugging process can be done by the programmer or the developer. Based on the defect that is reported, the developers try to find the root causes of the error to 
\section[{Global Journal of Computer Science and Technology}]{Global Journal of Computer Science and Technology}\par
Volume XIX Issue II Version I 48 Year 2 019 ( ) C make the system defect free. Debugging is done in the three phases of software development. The first one is during the coding process when the programmer translates the design into executable code. In the coding process, the errors that are made by the programmer when writing in code needs to be detected quickly and fixed before going to the next phase of development. In these cases, the developer performs unit testing to identify any defects at the module or component level. Then debugging is performed during the last stage of testing. These involve debugging multiple components or a complete system, when unexpected behavior such as wrong return codes or abnormal program termination may be found. 
\section[{VI.}]{VI.} 
\section[{Conclusion}]{Conclusion}\par
To conclude our survey, we would like to find that Software testing is an essential activity of the Software Development Life Cycle (SDLC). We can never say that a product is "Perfect". Testing is a never-ending process. Testing only shows the presence of errors, not the absence. It is time-consuming and an intensive process, therefore, upgraded techniques and innovative methodologies are necessary to maintain the quality of the software. This leads to performing Automated Testing implementation before and during the testing process. This paper aims to describe in detail various software testing techniques, the need for software testing, software testing goals, and objectives. Software testing is often less formal and meticulous than it should. In order to perform software testing effectively and efficiently, those who are involved in testing must be familiar with the basic concept, goals and principle of software testing.\par
We further discuss different software testing techniques such as white-box Testing, black-box Testing, grey-box Testing, Security testing etc. Hence, the future work in relevance with the testing process will be much more technology-dependent harnessing the simulation and automated testing model-based approach, not only expediting the testing life cycle but also providing optimum bug prevention and efficient quality assurance.\begin{figure}[htbp]
\noindent\textbf{1}\includegraphics[]{image-2.png}
\caption{\label{fig_0}Figure 1 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{23}\includegraphics[]{image-3.png}
\caption{\label{fig_1}Figure 2 :Figure 3 :}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-4.png}
\caption{\label{fig_2}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{}\includegraphics[]{image-5.png}
\caption{\label{fig_3}}\end{figure}
  \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.05967551622418879\textwidth}P{0.777787610619469\textwidth}P{0.006519174041297935\textwidth}P{0.0030088495575221236\textwidth}P{0.0030088495575221236\textwidth}}
\tabcellsep \multicolumn{2}{l}{Review Paper on Various Software Testing Techniques \& Strategies}\tabcellsep \\
\tabcellsep \multicolumn{4}{l}{to Identify and resolve their errors early in the}\\
\tabcellsep \multicolumn{4}{l}{software development process. Static testing is}\\
\tabcellsep \multicolumn{4}{l}{performed on the documents like Software}\\
\tabcellsep Requirement\tabcellsep Specification\tabcellsep (SRS),\tabcellsep design\\
\tabcellsep \multicolumn{4}{l}{documents, source Moderators conduct the code walkthrough. In this}\\
\tabcellsep \multicolumn{4}{l}{type of formal review, a checklist is prepared to}\\
Year 2 019\tabcellsep \multicolumn{4}{l}{check the working document. ii. Walkthrough: It is not a formal process. The authors lead this process. The Author advises the participants through the document according to}\\
44\tabcellsep \multicolumn{4}{l}{his or her thought process so that they can}\\
\tabcellsep \multicolumn{4}{l}{accomplish a common perception. It is especially}\\
Volume XIX Issue II Version I Global Journal of Computer Science and Technology ( ) C\tabcellsep \multicolumn{4}{l}{useful for higher-level documents like requirement specification, etc. iii. Technical Reviews: A professional round of review is operated to check if the code is made in consonance with the technical specifications and norms which may include the test plans, test strategy, and test scripts. iv. Informal Reviews: It's the static testing technique in which the document is reviewed unofficially, and helpful comments are implemented. 2. Automated Testing (Dynamic Testing): Dynamic Testing is a kind of software testing technique in In dynamic testing, also known as validation where the actual system is considered. It requires the highly skilled professional with the proper domain knowledge. Dynamic testing involves testing the software for the input values, and output values are analyzed. Progressive testing is divided into two categories: A. White Box Testing B. Black Box Testing C. Grey Box Testing which the dynamic behavior of the code is analyzed.}\\
© 2019 Global Journals\tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
  {\small\itshape [Note: 1. Static Testing 2. Dynamic Testing 1. Manual Testing (Static Testing): It refers to the method of testing where the code is not executed. It does not require highly skilled professionals since the actual execution of the system is not done in this process. It starts with the initial phase of the Software Development Life Cycle (SDLC); hence, it is also known as verification testing. The main objective of static testing is to enhance the quality of software products by helping software professionals]} 
\caption{\label{tab_0}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.8228224917309812\textwidth}P{0.004685777287761852\textwidth}P{0.007497243660418963\textwidth}P{0.011245865490628445\textwidth}P{0.0037486218302094816\textwidth}}
\tabcellsep \tabcellsep \tabcellsep \multicolumn{2}{l}{testing at}\\
\multicolumn{5}{l}{borders, or where the extreme boundary values}\\
\multicolumn{5}{l}{are chosen. It comprises of minimum, maximum,}\\
\multicolumn{3}{l}{error values, and typical values.}\tabcellsep \tabcellsep \\
\multicolumn{5}{l}{iii. Fuzzing: This approach takes random input to the}\\
\multicolumn{5}{l}{application. It is used for characterizing}\\
\multicolumn{5}{l}{implementation bugs, using malformed or semi-}\\
\multicolumn{5}{l}{malformed data injection in an automated or}\\
\multicolumn{2}{l}{semi-automated session.}\tabcellsep \tabcellsep \tabcellsep \\
iv. Orthogonal\tabcellsep Array\tabcellsep Testing:\tabcellsep In\tabcellsep this\\
\multicolumn{5}{l}{technique, the input domain is minimal but too}\\
\multicolumn{4}{l}{large to accommodate exhaustive testing.}\tabcellsep \\
\multicolumn{5}{l}{v. Cause-Effect Graph: This testing technique begins}\\
\multicolumn{5}{l}{by generating a graph and establishing the}\\
\multicolumn{3}{l}{relation between effect and its causes.}\tabcellsep \tabcellsep \\
\multicolumn{5}{l}{vi. All Pair Testing: The main objective is to have a set}\\
\multicolumn{5}{l}{of test cases that covers all the pairs. Here, test}\\
\multicolumn{5}{l}{cases are designed to execute all possible}\\
\multicolumn{5}{l}{discrete combinations of each couple of input}\\
parameters.\tabcellsep \tabcellsep \tabcellsep \tabcellsep \\
\multicolumn{5}{l}{vii. State Transition Testing: This testing approach is}\\
\multicolumn{5}{l}{useful for the navigation of a graphical user}\\
interface.\tabcellsep \tabcellsep \tabcellsep \tabcellsep \end{longtable} \par
  {\small\itshape [Note: Black-box testing methods include: i. Equivalence Partitioning: This technique divides the input domain of a program into equivalent classes from which test cases can be derived. Thus, it can minimize the number of test cases. ii. Boundary Value Analysis: It targets the Advantages: 1. Testers do not need to know specific programming languages. Testing is done from a user's point of view. 2. It helps to find out any ambiguities or inconsistencies in the requirement specifications. Year 2 019 ( ) C]} 
\caption{\label{tab_1}}\end{figure}
 \begin{figure}[htbp]
\noindent\textbf{} \par 
\begin{longtable}{P{0.05941088367448827\textwidth}P{0.02800798801797304\textwidth}P{0.7625811283075387\textwidth}}
\tabcellsep \tabcellsep 2. a) Top-down Integration testing\\
\tabcellsep \tabcellsep b) Bottom-up Integration testing\\
\tabcellsep \tabcellsep a) Top-down Integration: It is an incremental procedure\\
\tabcellsep \tabcellsep to build a program format. Formats are integrated\\
\tabcellsep \tabcellsep by moving downward through the fabric, beginning\\
\tabcellsep \tabcellsep with the main control module. Modules subordinate\\
\tabcellsep \tabcellsep to the central control module are incorporated into\\
\tabcellsep \tabcellsep the structure in either a depth-first or breadth-first\\
\tabcellsep \tabcellsep manner. The integration activity is performed in a\\
\tabcellsep \tabcellsep series of five steps:\\
\tabcellsep \tabcellsep i. The main control format is used as a test driver,\\
\tabcellsep \tabcellsep and stubs are substituted for all components\\
\tabcellsep \tabcellsep directly subordinate to the central control\\
\tabcellsep \tabcellsep module.\\
\tabcellsep \tabcellsep ii. Depending on the integration techniques,\\
\tabcellsep \tabcellsep selected subordinate stubs are replaced one at a\\
\tabcellsep \tabcellsep time with actual parts.\\
\tabcellsep \tabcellsep iii. Tests are conducted as each element is\\
\tabcellsep \tabcellsep integrated.\\
\tabcellsep \tabcellsep iv. On completion of each set of experiments,\\
\tabcellsep \tabcellsep another stub is replaced with the real\\
\tabcellsep \tabcellsep component.\\
\tabcellsep \tabcellsep v. Regression testing may be managed to ensure\\
\tabcellsep \tabcellsep that new errors have not been introduced. It is\\
\tabcellsep \tabcellsep not as relatively straightforward as it looks. In this\\
\tabcellsep \tabcellsep logistic problem can arise. The problem occurs\\
\tabcellsep \tabcellsep when testing a low-level module that requires\\
\tabcellsep \tabcellsep checking the upper level. Stub replaces low-level\\
\tabcellsep \tabcellsep modules at the beginning of top-down testing.\\
\tabcellsep \tabcellsep So no data can flow in an upward direction.\\
\tabcellsep \tabcellsep b) Bottom-up Integration: It begins development and\\
\tabcellsep \tabcellsep testing with atomic modules. Since modules are\\
\tabcellsep \tabcellsep integrated from the bottom-up, processing required\\
\tabcellsep \tabcellsep for elements subordinate to a required level is\\
\tabcellsep \tabcellsep always available. The following steps are\\
\tabcellsep \tabcellsep implemented with bottom-up integration strategy:\\
\tabcellsep \tabcellsep i. Low-level components are combined into\\
\tabcellsep \tabcellsep clusters so that they can perform a specific\\
\tabcellsep \tabcellsep software sub-function.\\
\tabcellsep \tabcellsep ii. A driver is reported to coordinate test case input\\
\tabcellsep \tabcellsep and output.\\
\tabcellsep \tabcellsep iii. The group is tested.\\
\multicolumn{2}{l}{Unit testing techniques: Unit testing uses several effective testing techniques. The testing techniques}\tabcellsep iv. Drivers are detached, and clusters are combined moving upward in the program structure.\\
\multicolumn{2}{l}{categorize into three types:}\\
i.\tabcellsep Functional Testing\\
ii.\tabcellsep Structural Testing\\
iii.\tabcellsep Heuristic or Intuitive Testing\end{longtable} \par
 
\caption{\label{tab_2}}\end{figure}
 			\footnote{© 2019 Global Journals Review Paper on Various Software Testing Techniques \& Strategies} 		 		\backmatter  			  				\begin{bibitemlist}{1}
\bibitem[Mohd and Khan (2010)]{b5}\label{b5} 	 		‘Different Forms of Software Testing Techniques for Finding Errors’.  		 			Ehmer Mohd 		,  		 			Khan 		.  	 	 		\textit{IJCSI International Journal of Computer Science Issues}  		May 2010. 7  (1) .  	 
\bibitem[Jangra et al. (2011)]{b6}\label{b6} 	 		‘EXPLORING TESTING STRATEGIES’.  		 			Ajay Jangra 		,  		 			Gurbaj Singh 		,  		 			Jasbir Singh 		,  		 			Rajesh Verma 		.  	 	 		\textit{International Journal of Information Technology and Knowledge Management}  		January-June 2011. 4  (1) .  	 
\bibitem[Kaner (2006)]{b0}\label{b0} 	 		‘Florida Institute of Technology’.  		 			Cem Kaner 		.  	 	 		\textit{Quality Assurance Institute Worldwide Annual Software Testing Conference},  				 (Orlando, FL.)  		November 17. 2006. November 22. 2014.  	 	 (Exploratory Testing) 
\bibitem[Mitra et al. ()]{b2}\label{b2} 	 		‘Graphical analysis of MC/DC using automated software testing’.  		 			P Mitra 		,  		 			S Chatterjee 		,  		 			N Ali 		.  	 	 		\textit{Electronics Computer Technology (ICECT), 2011 3rd International Conference on},  				2011. 3 p. .  	 
\bibitem[Glenford et al. ()]{b1}\label{b1} 	 		‘Published by’.  		 			J Glenford 		,  		 			; P Myers 		,  		 			Mathur 		.  	 	 		\textit{The Art of Software Testing, Second Edition},  				 (Hoboken, New Jersey)  		2008. Pearson/Addison Wesley.  	 	 (Foundation of Software Testing) 
\bibitem[Patton 9 ()]{b7}\label{b7} 	 		‘Software engineering, by Roger Pressman 10. IEEE Standard 829-1998’.  	 	 		\textit{IEEE Standard for Software Test Documentation},  				 			Ron Patton 9 		 (ed.)  		1998. IEEE Computer Society. p. .  	 	 (Software testing) 
\bibitem[Jovanovic (2008)]{b8}\label{b8} 	 		\textit{Software Testing Methods and Techniques},  		 			Irena Jovanovic 		.  		May 26, 2008.  	 
\bibitem[Software Testing Techniques and Strategies" Abhijit A. Sawant1, Pranit H. Bari2 and P. M]{b4}\label{b4} 	 		\textit{Software Testing Techniques and Strategies" Abhijit A. Sawant1, Pranit H. Bari2 and P. M},  				 (INDIA)  		 		 			Chawan3 Department of Computer Technology, VJTI, University of Mumbai 		 	 
\bibitem[Saglietti et al. ()]{b3}\label{b3} 	 		‘White and greybox verification and validation approaches for safety-and security-critical software systems’.  		 			F Saglietti 		,  		 			N Oster 		,  		 			F Pinte 		.  	 	 		\textit{Information Security Technical Report}  		2008. 13  (1)  p. .  	 
\end{bibitemlist}
 			 		 	 
\end{document}
