athos
/
baangt


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332
							

<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
  <meta charset="utf-8">
  
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  
  <title>Types of tests &mdash; baangt 1.1.1 documentation</title>
  

  <script type="text/javascript" src="_static/js/modernizr.min.js"></script>
  
    
      <script type="text/javascript" id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
        <script type="text/javascript" src="_static/jquery.js"></script>
        <script type="text/javascript" src="_static/underscore.js"></script>
        <script type="text/javascript" src="_static/doctools.js"></script>
        <script type="text/javascript" src="_static/language_data.js"></script>
    
    <script type="text/javascript" src="_static/js/theme.js"></script>

    
  <link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
  <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
  <link rel="stylesheet" href="_static/theme_overrides.css" type="text/css" />
    <link rel="index" title="Index" href="genindex.html" />
    <link rel="search" title="Search" href="search.html" />
    <link rel="next" title="Special functions in datafiles" href="DataFile.html" />
    <link rel="prev" title="How to create a simple API Test" href="SimpleAPI.html" /> 
</head>

<body class="wy-body-for-nav">

   
  <div class="wy-grid-for-nav">
    
    <nav data-toggle="wy-nav-shift" class="wy-nav-side">
      <div class="wy-side-scroll">
        <div class="wy-side-nav-search" >
          

            <a href="index.html" class="icon icon-home"> baangt
          

          </a>

          
<div role="search">
  <form id="rtd-search-form" class="wy-form" action="search.html" method="get">
    <input type="text" name="q" placeholder="Search docs" />
    <input type="hidden" name="check_keywords" value="yes" />
    <input type="hidden" name="area" value="default" />
  </form>
</div>

          
        </div>

        <div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
          
            
              <p class="caption"><span class="caption-text">Contents:</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="Installation.html">   Installation</a></li>
<li class="toctree-l1"><a class="reference internal" href="OverviewUsage.html">   Overview</a></li>
<li class="toctree-l1"><a class="reference internal" href="simpleExample.html">   First Steps</a></li>
<li class="toctree-l1"><a class="reference internal" href="Structure.html">   Structure</a></li>
<li class="toctree-l1"><a class="reference internal" href="ParametersConfigFile.html">   Parameters</a></li>
<li class="toctree-l1"><a class="reference internal" href="SimpleAPI.html">   First API Test</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">   Types of Tests</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#increment-testing">Increment testing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#heartbeat-and-alive-testing">Heartbeat and Alive-Testing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#regression-testing">Regression testing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#performance-testing">Performance testing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#end-to-end-e2e-testing">End to End (E2E) Testing</a></li>
<li class="toctree-l2"><a class="reference internal" href="#lifecycle-tests-of-business-objects">Lifecycle tests of business objects</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#time-travel-tests">Time travel tests</a></li>
<li class="toctree-l3"><a class="reference internal" href="#cradle-to-the-grave">Cradle to the grave</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#no-oversimplification">No oversimplification</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="DataFile.html">   Data file</a></li>
<li class="toctree-l1"><a class="reference internal" href="SaveResults2Database.html">   Results in Database</a></li>
<li class="toctree-l1"><a class="reference internal" href="HistoryAndReasons.html">   History</a></li>
<li class="toctree-l1"><a class="reference internal" href="contributors.html">   Contributions</a></li>
<li class="toctree-l1"><a class="reference internal" href="changelog.html">   Changelog</a></li>
<li class="toctree-l1"><a class="reference internal" href="PlannedFeatures.html">   Planned Features</a></li>
<li class="toctree-l1"><a class="reference internal" href="BrowserDrivers.html">   Browser Drivers</a></li>
<li class="toctree-l1"><a class="reference internal" href="Variables.html">   Variables</a></li>
<li class="toctree-l1"><a class="reference internal" href="SendStatistics.html">   Results</a></li>
<li class="toctree-l1"><a class="reference internal" href="Datagenerator.html">DataGenerator</a></li>
<li class="toctree-l1"><a class="reference internal" href="Datagenerator.html#input-file">Input File</a></li>
<li class="toctree-l1"><a class="reference internal" href="Datagenerator.html#data-type">Data Type</a></li>
<li class="toctree-l1"><a class="reference internal" href="Datagenerator.html#all-data-types-format">All Data Types Format</a></li>
<li class="toctree-l1"><a class="reference internal" href="Developer.html">   For Developers</a></li>
<li class="toctree-l1"><a class="reference internal" href="baangt-Plugin.html">What is a baangt-plugin</a></li>
<li class="toctree-l1"><a class="reference internal" href="baangt-Plugin.html#how-to-make-a-baangt-plugin">how to make a baangt-plugin</a></li>
<li class="toctree-l1"><a class="reference internal" href="baangt-Plugin.html#how-the-baangt-plugin-work">how the baangt-plugin work</a></li>
<li class="toctree-l1"><a class="reference internal" href="baangt-Plugin.html#how-to-replace-the-existing-plugin-by-your-own-one">how to replace the existing plugin by your own one</a></li>
<li class="toctree-l1"><a class="reference internal" href="articles/Articles.html">   :subheader: Articles</a></li>
<li class="toctree-l1"><a class="reference external" href="http://www.baangt.org">   Web</a></li>
</ul>
<p class="caption"><span class="caption-text">Autodocs:</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="docs/baangt.base.html">Autodocs</a></li>
<li class="toctree-l1"><a class="reference internal" href="docs/modules.html">Modules</a></li>
</ul>

            
        </div>
      </div>
    </nav>

    <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">

      
      <nav class="wy-nav-top" aria-label="top navigation">
        
          <i data-toggle="wy-nav-top" class="fa fa-bars"></i>
          <a href="index.html">baangt</a>
        
      </nav>


      <div class="wy-nav-content">
        
        <div class="rst-content">
        
          
<div role="navigation" aria-label="breadcrumbs navigation">

  <ul class="wy-breadcrumbs">
    
      <li><a href="index.html">Docs</a> &raquo;</li>
        
      <li>Types of tests</li>
    
    
      <li class="wy-breadcrumbs-aside">
        
            
            <a href="_sources/TestTypes.rst.txt" rel="nofollow"> View page source</a>
          
        
      </li>
    
  </ul>

  
  <hr/>
</div>
          <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
           <div itemprop="articleBody">
            
  <div class="section" id="types-of-tests">
<h1>Types of tests<a class="headerlink" href="#types-of-tests" title="Permalink to this headline">¶</a></h1>
<p>No matter if your organization is agile or waterfall oriented or follows one of the many hybrid variants. Sooner or later
you’ll have an increment - an outcome from your software developers or customizers. You paid for it. You want it in production.
But will it work? Will there be any unwanted side effects to existing functionality?</p>
<div class="section" id="increment-testing">
<h2>Increment testing<a class="headerlink" href="#increment-testing" title="Permalink to this headline">¶</a></h2>
<p>Usually an increment is tested manually by human testers who are not identical with the developers.</p>
<p>Depending on maturatiy of your organization and many other factors, the testers will be more or less clearly instructed,
what to test. They might have written business requirements and deduct the test cases themselves. In ideal setups they
were part of the development lifecycle, know the deviations from original requirements, pitfalls and workarounds and can
adjust their test expectation accordingly.</p>
<p>Unless you’re in a greenfield situation where the whole system landscape needs to be tested and retested for months or years
your Testers will focus on testing the increment - not so much the existing functionality, which used to work fine already.</p>
<p>Use <code class="docutils literal notranslate"><span class="pre">baangt</span></code> already in preparation of this test phase. Create all the test cases, that you plan to execute. Create all
the data combinations, that you’ll want to have tested. Once the functionality is there, record the most complex scenario
in the recorder. Instead of testing 100s of cases manually, you’ll need only one recording and the prepared dataset. Start
the TestRunExecution, sit back and wait for the results. Simple like that.</p>
</div>
<div class="section" id="heartbeat-and-alive-testing">
<h2>Heartbeat and Alive-Testing<a class="headerlink" href="#heartbeat-and-alive-testing" title="Permalink to this headline">¶</a></h2>
<p>Alive-Testing is usually done with just one quick test case in all stages (Dev, Pre-Quality and Quality-System). It will
show general availability of the landscape and applications running on it. Alive-Tests with some APIs could run for instance
every 5 minutes.</p>
<p>Heartbeat tests are a smaller subset of regression tests. E.g. if you have 10.000 testcases in regression tests, you’d
use a few hundred for heartbeat tests. They’d usually run a few times per day on Pre-Quality- and once per day on
Quality-System) and of course in the build pipeline.</p>
</div>
<div class="section" id="regression-testing">
<h2>Regression testing<a class="headerlink" href="#regression-testing" title="Permalink to this headline">¶</a></h2>
<p>If you followed through on Increment testing imagine the joy of the next release! You’ll have the increment tested and run
all test cases of previous increments as well. That’s called regression testing. If you did everything well use the results
of regression tests and increment tests as rock-solid base for your decision whether to move on to production or not.</p>
</div>
<div class="section" id="performance-testing">
<h2>Performance testing<a class="headerlink" href="#performance-testing" title="Permalink to this headline">¶</a></h2>
<p>So you did regression and increment tests, moved to production and receive countless complaints from users, that the
performance of the system is too slow. Additionally there are now bugs that appear due to timeout situations. Damn.</p>
<blockquote>
<div><p><strong>What happened?</strong></p>
</div></blockquote>
<p>You tested only for functionality, but not for load. With a few simple adoptions to your test cases you can simulate any
number of users. To achieve realistic performance testing you’ll need more hardware for testing than for regression and
increments. But you’ll use the same tool: <code class="docutils literal notranslate"><span class="pre">baangt</span></code>.</p>
<p>As of today (Jan 2020) <code class="docutils literal notranslate"><span class="pre">baangt</span></code> does not provide infrastructure monitoring. In order to analyze the results of your
performance tests you’ll need additional tools, but <code class="docutils literal notranslate"><span class="pre">baangt</span></code> will give indications, which components or which functionalities
need a closer look by your experts.</p>
</div>
<div class="section" id="end-to-end-e2e-testing">
<h2>End to End (E2E) Testing<a class="headerlink" href="#end-to-end-e2e-testing" title="Permalink to this headline">¶</a></h2>
<p>Whenever you have more than one system/microservice dealing with a process, you’ll need E2E-Testing. Of course E2E-Tests
are more complex than just running test cases against one functionality and compare results to the expected values and
behaviour. In larger organizations you’ll want to have E2E-Regression tests before you release increments to production.
<code class="docutils literal notranslate"><span class="pre">baangt</span></code> follows a structure of TestCaseSequences where you combine multiple single Testcases into one Sequence, which
is exactly tailored to run E2E Tests.</p>
</div>
<div class="section" id="lifecycle-tests-of-business-objects">
<h2>Lifecycle tests of business objects<a class="headerlink" href="#lifecycle-tests-of-business-objects" title="Permalink to this headline">¶</a></h2>
<p>Lifecycle tests come in basically two variations, but can be combined - depending on the requirements of the business.
Many industries deal with objects, that follow a certain (long) life cycle. The life cycle can go over years or decades.
These tests are complex and cost a lot of time and effort.</p>
<div class="section" id="time-travel-tests">
<h3>Time travel tests<a class="headerlink" href="#time-travel-tests" title="Permalink to this headline">¶</a></h3>
<p>Often companies have “Time travel” system landscapes, where they
create copies of the whole system landscape (or large parts of the core systems), change the system time on all servers
and run tests subsequently with different dates. <code class="docutils literal notranslate"><span class="pre">baangt</span></code> does not support this type of testing out of the box. But
we provide a functionality to “Pause” Testcase and TestCaseSequence execution. You can easily subclass the corresponding
master classes and create your own mechanism, when to pause a Testcase or TestCaseSequence.</p>
</div>
<div class="section" id="cradle-to-the-grave">
<h3>Cradle to the grave<a class="headerlink" href="#cradle-to-the-grave" title="Permalink to this headline">¶</a></h3>
<p>Another common form of lifecycle tests. In this case the system time remains basically the same, but the test cases are
created in a sequence to follow the birth of an object until it’s deletion. This might be a material, which get’s created,
production recipe created, work planned, sales contract and order created, produced, delivered, invoiced, paid and
revenue calculated. In service industries C2G-Tests are designed around a customer. <code class="docutils literal notranslate"><span class="pre">baangt</span></code> fully supports complex
testcaseSequences running on multiple technologies (Web, API, etc.) also in asynchronous scenarios, for instance if you
need to wait for nightly batch processing of a mainframe.</p>
</div>
</div>
<div class="section" id="no-oversimplification">
<h2>No oversimplification<a class="headerlink" href="#no-oversimplification" title="Permalink to this headline">¶</a></h2>
<p>Please don’t get me wrong. Just because we have a great tool, it doesn’t mean that testing will happen by itself. There’s
still a lot of expert work needed for Testdesign, Stagedesign, Creation and maintenance of Testsets, creation and
maintenance of test data sets, deployment strategies. <code class="docutils literal notranslate"><span class="pre">baangt</span></code> provides efficient ways to work, but work still needs
to be done.</p>
</div>
</div>


           </div>
           
          </div>
          <footer>
  
    <div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
      
        <a href="DataFile.html" class="btn btn-neutral float-right" title="Special functions in datafiles" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
      
      
        <a href="SimpleAPI.html" class="btn btn-neutral float-left" title="How to create a simple API Test" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left"></span> Previous</a>
      
    </div>
  

  <hr/>

  <div role="contentinfo">
    <p>
        &copy; Copyright 2020, Bernhard Buhl

    </p>
  </div>
  Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/rtfd/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>. 

</footer>

        </div>
      </div>

    </section>

  </div>
  

  <script type="text/javascript">
      jQuery(function () {
          SphinxRtdTheme.Navigation.enable(true);
      });
  </script>

  
</body>
</html>