Explain unstructured loops in detail?

Loops are one of the most important of the languages like C and C++. They have greatly reduced the drudgery of the programmers and developers which would otherwise have made the programming of a software system or application more hectic. The necessity of the loops cannot be ignored when it comes to the repetition of a particular executable statement or a block of statements in a program. 

In other words,

Say we have the below written statement in C++ programming language that we need to print only one time:

“hello! Welcome to C++ programming”

To print it one time we shall write the code like this:

Cout<<”hello! Welcome to C++ programming\n”;

Say now you need to print this statement a 100 times! What you are going to do- write the above C++ statement a 100 times? No! Certainly not! This is unfeasible and a complete waste of time! So what is the alternative that we have? Yes of course we have the “loops”. 

Using loop we will have to write only a small code instead of writing that C++ statement again and again for 100 times. Using loop we shall write like this:

For( int i = 1; i <=100; i++ )

{

Cout<<”hello! Welcome to C++ programming\n”;

}

The above loop is a for loop and it will the statement that we wish to be printed 100 times. See to how much extent our task has been reduced! This would not have been possible without loops. 

Loops generally are classified based on their types namely in to:

1. The while loop
2. The for loop
3. The do – while loop

But based up on their structure, they are classified in to two types:

1. Structured loops and
2. Unstructured loops

This article is all about the unstructured loops. We shall discuss them in detail. 

The Unstructured Loops

- The unstructured loops can be defined as the loops that are void of a single header or a node in the control flow graph that has all the nodes dominating the whole loop body. 

- The main problem that arises with these unstructured loops is of managing them.

- Managing them is such a hectic task.

- For analyzing the unstructured loops the programmers, developers and researchers have come up with so many ways but none of them seems to be so efficient.

- One of the ways is to use a control flow graph along with the scope graph corresponding to the function containing the unstructured loop to be analyzed. 

- This method involves attaching of each and every iteration counter with each of the loop header.

- Attaching the iteration counters in such a way can cause over estimation of the control flow. 

- So to overcome this problem, the iteration counters are attached to each basic block and this helps a great deal in achieving a lot of flow information. Even this way results in some disadvantage! 

- Therefore another method of managing the unstructured loops has been developed. 

- Another method has been developed for transforming the unstructured loops in structured ones. 

- If one looks at the unstructured loop with a view of the control flow graph they seem to have entry edges to one or more than one node all over the loop. 

- In another way we can say that an unstructured consists of parts of several different loops. 

- Several structured loops can also be merged in to an unstructured loop with the help of a code size optimizing compiler.

- A straight way has been developed for the elimination of the unstructured loops which is creating a scope with a single header for each entry of the loop. 

What is meant by production verification testing?

Production verification is also an important part of the software testing life cycle like the other software testing methodologies but is much unheard of! Therefore we have dedicated this article entirely to the discussion about what is production verification testing? 

This software testing methodology is carried out after the user acceptance testing phase is completed successfully. The production verification testing is aimed at the simulation of the cutover of the whole production process as close to the true value as possible. 

This software testing methodology has been designed for the verification of the below mentioned aspects:

1. Business process flows
2. Proper functioning of the data entry functions
3. Proper running of any batch processes against the actual data values of the production process.

About Production Verification Testing

- Production verification testing can be thought of as an opportunity for the conduction of a full dress rehearsal of the changes in the business requirements if any. 

- The production verification is not to be confused from the parallel testing since there is a difference of the goal.

- We mean to say that the goal of the production verification testing is to verify that the data is being processed properly by the software system or application rather than comparing the results of the data handling of the new software system software or application with the current one as in the case of parallel testing. 

- For the production verification testing to commence, it is important that the documentation of the previous testings is produced and the issues and faults that were discovered then are fixed and closed.

- If there is a final opportunity for the determination of whether or not the software system or application is ready for the release, it is the production verification testing. 

- Apart from just the simulation of the actual production cut over, the real business activities are also simulated during the phase of the production verification testing. 

- Since it is the full rehearsal of the production phase and business activities, it should serve the purpose of the identification of the unexpected changes or anomalies presiding in the existing processes as a result of the production of the new software system or application which is currently under the test. 

- The importance of this software testing technique cannot be overstated in the case of the critical software applications.

- For the production verification testing, the testers need to remove or uninstall the software system or application from the testing environment and reinstall it again as it will be installed in the case of the production implementation.

- This is for carrying out a mock test of the whole production process, since such kind of mock tests help a lot in the verification of the interfaces, existing business flows. 

- The batch processes continue to execute alongside those mock tests. 

- This is entirely different from the parallel testing in which both the new and the old systems run besides each other.

- Therefore in parallel testing, the mock testing is not an option to provide accurate results for the data handling issues since the source data or data base has a limited access. 

Entry and Exit Criterion for Production Verification Testing

Here we list some of the entry and exit criteria of the production verification testing:

Entry criteria:

1. The completion of the User acceptance testing is over and has been approved by all the involved parties.
2. The documentation of the known defects is ready.
3. The documentation of the migration package has been completed, reviewed and approved by all the parties and without fail by the production systems manager.

Exit Criteria:

1. The processing of the migration package is complete.
2. The installation testing has been performed and its documentation is ready and signed off.
3. The documentation of the mock testing has been approved and reviewed.
4. A record of the system changes has been prepared and approved.

Explain Test plan, Test Strategy and Test Scenario?

The concept of software testing seems like an amalgam of similar terms, all mixed up in to each other. We all get confused sometimes between the different but similar sounding terms. 

For greater understanding of the software testing, one needs to know exactly what all the inclusive terms mean and how and where they are used or implemented. This piece of writing is dedicated to the cause of removal of such confusions. In this article we are going to clear three major concepts of software testing namely test plan, test strategy and test scenarios.

1. Test Plan

- It does the same as a normal plan would do i.e., detail out a systematic approach to the accomplishment of a certain task.

- For the test plan the task is the successful completion of a particular software testing. 

- A test plan gives a detailed approach of all the processes or activities to be undertaken during the testing.

- A test plan marks the work flow of the software testing mechanism. 

- A test plan states the strategy to be followed to make the software testing successful.

- It provides a means to check whether or not the software system or application meets all the requirements and specifications as mentioned by the client or the customer in the documentation. 

- The test plan is usually created by the testers.

- A typical test plan includes the following fields:

      (a)  Compliance test or design verification: performed on the product samples while the actual product is in development stage.

   (b)  Production test or manufacturing: performed during the assemblage process of the product for assuring quality and performance.       

      (c)  Commissioning test or acceptance: performed while the product is being installed.

      (d)  Repair test or servicing: performed during the product’s service life.

      (e)   Regression test: performed on an existing version of the product to ensure the working of the functionalities.

               

- The level of the design of the test plan depends on the complexity level of the software system or application. 

- For more complex systems high level test plans are created. 

- Apart from the above mentioned tests, a typical test plan must cover about the test methodologies, test coverage and test responsibilities. - It also states what all requirements are to be verified in the testing.

2. Test Strategy

- Test strategy forms an essential part of the test plan. 

- To put it simply we can say that the test strategy is nothing but a superficial sketch or outline of the actual test plan of the software development cycle. 

- A test strategy is developed just to inform the project developers about the approach that is to be followed during the testing. 

- The key components of a typical test strategy are objectives of the testing, test methods, test duration, resource requirements and test environment. 

- Test strategies give the description of the risk mitigation, tests to be carried out and not to forget the entry and exit criteria for the tests. 

- For each level of software testing, an individual test strategy is created.

3. Test Scenario

- Test scenarios form an essential component of the scenario testing. 

- These test scenarios provide a hypothetical measure to help the tester out of some complex problem encountered during the testing. 

- The main characteristics of a typical scenario are its complexity, credibility, motivational story with a reasonable outcome. 

- The scenarios are usually lengthy as compared to the length of the test cases probably because of more number of steps are present in a test scenario. 2 or more scenarios together make up a scenario file. 

What is the entry and exit criterion for system testing?

Scientifically, the term system testing is looked up as the testing of both the components of the system i.e., software and hardware. It has been categorized as one of the software testing techniques under the category of black box testing, and so this eliminates the need of any knowledge regarding the internal structure and design of the source code.

The system testing is carried out on an integrated, complete and finished software system or artefact because after the completion of the system only, it can be checked for its ability to cooperate according to the specified conditions and requirements.

This article states the entry and exit criteria for a software system or application to undergo system testing.

About System Testing

- The system testing is all aimed at the detection of all the discrepancies, defects and constraints lurking in the software system or application.

- System testing takes up the job for dealing with the inconsistencies and flaws that are present in the system software which is in turn constituted up of integrated software and hardware components.

- System testing is carried out in concern for the detection of defects within present within the assemblages i.e., inter- assemblages representing the software system or application as a whole entity.

- You don’t have to worry if you already have your software incorporated successfully with the appropriate hardware system, it can be still served as input to the test.

- The software system itself is an integrated part of any other software or hardware system and has dealt with the system integration testing successfully can also be considered as an input for the system testing.

- Being very non similar to the integration testing and unit testing, the system testing takes the whole software system or application as one unit or module for testing.

- We can say that in a way the system testing is a means to explore the functionality of a software system.

- For carrying out system testing there are two options: either you carry it out before you software system or application is assembled or after the system has been finished and completed.

- While carrying out the system testing, you should always make sure you are strictly following the defined systematic procedures.

- Only specifically designed test cases should be used for performing system testing.

- System testing holds the responsibility for dealing with the basic and important contexts namely:
1. Functional requirement specification (FRS) and
2. System requirement specification (SRS).

- System testing does not only deal with the testing of the design of the software system but, also its features as expected by the customers and behaviour.

Entry criteria for System Testing

1. All the units must have passed the unit testing and that too with successful grades.

2. All the modules or units must have successfully passed the integration testing with good grades.

3. Their should be a resemblance between the surrounding environment and the production environment.

4. The following steps should have been followed during the system testing:

- Creation of the system test plan.
- Creation of the test cases.
- Creation of the scripts for building the environment.

Exit Criteria for System Testing

1. All the requirements specifications mentioned in the documentation have been met.

2. The issues have the severity level of 1 and 2 have been resolved.

3. The application is now working as per the expectations of the users.

4. ll the issues related to the critical defects must have been fixed and closed.

5. All the necessary documentations (like quick start guide, final publications draft etc) have been reviewed.

What is the entry and exit criterion for user acceptance testing?

The acceptance is quite an important choice for the clients or the customers. It plays a very important role when it comes to the addressal of the issues related to the acceptance of the software system or application by the client or the customer.

Like any other testing, the acceptance testing also has some of its pre defined entry and exit criteria that a software system or application needs to satisfy before it can undergo the acceptance testing process.

This article is focussed up on those entry and exit criteria only but first let us take a glimpse of what acceptance testing really is so that it becomes easy for us to understand the entry and exit criterion for the acceptance testing.

About User acceptance Testing

- For the field of software engineering, this kind of testing has been termed as the user acceptance testing since it is carried out in order to obtain confirmation from the user or the client that the developed software system or application meets its specified and agreed up on requirements and specifications.

- This confirmation is provided by the SME or the subject matter expert who is the owner of the software system or application under testing after carrying out several trials and reviews.

- The user acceptance is therefore one of the final software testing methodologies that is carried out before handing over the software system or application to its owner.

- The user acceptance testing is preferably carried out via the users of that software system or application which are in the contact of the client or mentioned in the users requirements specification document.

- As many as the formal tests required are created by the test developer or designer based on the different levels of the severity of the errors and flaws.

- Typically, for an ideal acceptance testing the test designer should handle the creation of the formal system and integration test cases for the same software system or application.

- The user acceptance testing serves as a means of final verification of the well functioning of the software system or application by creating the real world conditions for the its usage as it will used by the customer and required business function under process.

- The system needs to perform as intended because then only it can be subjected to its reasonable extrapolation in the process of product at the same level of the stability and reliability.

- Unlike other software testing methodologies, the test cases of the user acceptance testing do not serve to identify the simple problems, errors and show stopper defects (system crashes, failures and hangs etc).

- It is so because all such defects are fixed by the testers and developers in the earlier stages of the software testing life cycle.

- There is another reason for this testing to be performed which is to give confidence and assurance to the client or the customer that the system will perform well in the production phase.

- Some contractual or legal requirements are also signed at the end of the acceptance testing.

Entry Criterion for User Acceptance Testing

1. The transition meeting of the integration testing must be signed off.
2. The functional requirements and the business requirements have been met and verified in the integration testing.
3. The test cases for the user acceptance testing are ready to be executed.
4. The test environment for the UAT should be ready.
5. Required access of the resources for testing should be granted.
6. All the critical bugs have been previously addressed.
7. The reports of the previous testing should be handed over to the client.

Exit Criterion for User Acceptance Testing
1. No defects are found.
2. Defects with the medium priority are found.
3. There is no hindrance in the business process.
4. The UAT meeting is signed off.

What is the entry and exit criterion for unit testing?

First let us brief up ourselves with what the concepts of the unit testing and then we shall proceed further in discussing about the entry and exit criterion for unit testing.

About Unit Testing

- Unit testing is a self explanatory term.

- It involves the testing of the smallest units or modules of the software system or application in order to determine whether or not they are working properly and in the desired manner.

- Since this testing methodology is employed for testing the smallest individual unit of the software system or application, hence it got the name “unit testing”.

- If the program or application has been developed using procedural programming oriented language then the entire module is treated as units in the unit testing or else in general, the individual procedures and functions are the units.

- For the applications and softwares in which objected oriented programming has been implemented, the entire application’s interface.

- The test cases for the unit testing are created by the white box testers since they have an in depth knowledge of the software system or application.

- Sine the units are tested in isolation with the other units and independently, hence the test cases created for unit testing are also independent in nature.

Unit Test Case

- A unit test case can be assisted in unit testing by using substitutes like those mentioned below:
1. Mock objects
2. Methods stubs
3. Test harnesses
4. Fakes and so on.

- The test cases for the unit testing are both written and executed by the software developers.

- This ensures that the source code is at par with the design and architecture of the software system or application and works as accordingly as specified.

- The test cases can be implemented in two ways i.e., manually or through the use of automation tools as a part of build automation.

Entry Criterion for Unit Testing

- The functional specifications requirements of the software system or application under test need to be frozen.

- The technical design specifications need to complete and approved. They should have been released.

- The system specifications document also should be complete, approved and released.

- No issue should be pending in the query issue register regarding the requirements under the unit testing.

What else unit testing involves?

- Apart from just testing the modules, the unit testing involves the verification of the requirement specifications in regard with the finalized design and functional specifications requirements.

- For harnessing the maximum benefits of the unit testing, all of the requirements specifications should be signed off.

- Unit testing is said to be complete when the source code is complete and that too according to the specifications.

- All the design specifications should meet the design standards and the entire unused variable, code files should have been removed from them.

- The code documentation including the commenting and AOT documentation must also be complete and approved.

- To put it simple the code should be in such a state so as to be released to the customers or the clients.

Exit Criterion for Unit Testing

- All the units have successfully passed the unit test.

- The code is complete according to the requirements.

- No elements and features are missing.

- The possible errors and warnings have been resolved. This criterion is optional since most of the times it’s not possible to remove all of the errors.

- Code optimization for all the three tiers has been done.

- There is no error in the performance optimization.

- All label files have been created.

- All unused files have been removed.

- Redundant code is removed.

What is the entry and exit criterion for production verification testing?

Some entry and exit criteria have been predefined for all the software testing methodologies and in the same way some criterion have been defined for the production verification testing also.

For a software system or application to process from one phase of the software testing life cycle to the other one, it has to satisfy all the exit criteria of the previous software testing methodology and entry criteria of the software testing methodology that it is about to undergo.

So this article states the entry and exit criteria for the production verification testing and before that we have given a discussion about the production verification testing.

About Production Verification Testing

- Production verification is also an important part of the software testing life cycle like all the other software testing methodologies and is carried out after the successful completion of the user acceptance testing phase.

- The entire production verification testing deals with the simulation of the cutover of the whole production process as close to the true value as possible.

- Production verification testing also serves as an opportunity for the conduction of a full real like full dress rehearsal of the changes in the business requirements if any.

- The production verification is not like the parallel testing since there is a difference of the goal.

- The goal of the production verification testing is to verify that the data is being processed properly by the software system or application rather than comparing the results of the data handling of the new software system software or application with the current one as in the case of parallel testing.

- This software testing methodology has been designed for the verification of the following aspects:
a) Proper running of any batch processes against the actual data values of the production process.
b) Business process flows
c) Proper functioning of the data entry functions

Here we list some of the entry and exit criteria of the production verification testing:

Entry Criteria for Production Verification Testing

- For the production verification testing to commence it is important that the documentation of the previous testings is produced and the issues and faults that were discovered then are fixed and closed.

- If there is a final opportunity for the determination of whether or not the software system or application is ready for the release, it is the production verification testing.

- The completion of the User acceptance testing is over and has been approved by all the involved parties.

- The documentation of the known defects is ready.

- The documentation of the migration package has been completed, reviewed and approved by all the parties and without fail by the production systems manager.

- For the production verification testing, the testers need to remove or uninstall the software system or application from the testing environment and re-install it again as it will be installed in the case of the production implementation.

Exit Criteria for Production Verification Testing

- The processing of the migration package is complete.

- Apart from just the simulation of the actual production cut over, the real business activities are also simulated during the phase of the production verification testing.

- Since it is the full rehearsal of the production phase and business activities, it should serve the purpose of the identification of the unexpected changes or anomalies presiding in the existing processes as a result of the production of the new software system or application which is currently under the test.

- The installation testing has been performed and its documentation is ready and signed off.

- The documentation of the mock testing has been approved and reviewed.

- A record of the system changes has been prepared and approved.

What is the entry and exit criterion for integration testing?

Integration testing as we know is the second main software testing methodology in the software testing life cycle or STLC after unit testing. It is succeeded by the system testing and system integration testing substantially.

Like for every other testing methodology, a software system or application can undergo testing only after passing some pre- defined entry criteria and for exiting the testing phase also it needs to pass some pre- defined exit criteria in integration.

This article is focussed up on the entry and exit criterion for the integration testing. But, let us brief up ourselves with the concepts of integration testing so that it becomes easy for us to define with the entry and exit criteria defined for integration testing.

About Integration Testing

- Integration testing is sometimes abbreviated as I & T i.e., integration and testing.

- Integration testing has been named so because it involves the integration of the software system or application modules before carrying out the testing on them.

- Thus, we can say that the it is contrary to the unit testing since here it involves the testing of the system modules as groups of two or more modules rather than carrying out testing on them as individual modules like in the case of unit testing.

- Integration testing is often carried out after the unit testing but before the validation testing.

- Only those individual system modules which have passed the unit testing with successful grades can be considered as a valid input for the test cases created for the integration testing.

- Though, in some cases there might be some exception if error present in any individual module can only be rectified in the later stages of the testing cycle.

- When the groups or aggregates of the modules pass the integration testing, then only they can be moved further for the system testing and system integration testing.

- The reliability requirements, performance requirements and the functional requirements that have been specified for the major design items are what are tested by the integration testing.

- By major design items, here we mean the group of units or modules or assemblages.

- These assemblages or groups of units are put together via their interfaces by implementing the black box testing techniques and the faults and errors are simulated according to the proper defined parameters and the input data values.

- The inter process communication occurring as a result of the integration between the several unit groups is also tested apart from just testing the above mentioned requirements.

- The implementation of these small sub systems takes place through the interface of the input.

- A verified base is prepared on which the various assemblages are placed which is then used as a support to the integration testing test cases for the testing of the other assemblages.

- This approach has been termed as the “building block approach”. Integration testing can be implemented via any of the below mentioned approaches:
1. Big bang approach
2. Usage model testing
3. Top down approach
4. Bottom up approach
5. Sandwich testing

Entry criteria for Integration testing

- The system units or modules needed for the integration must be ready to be integrated.
- Unit testing must have been completed and closed.
- All the issues discovered during the unit testing must have been addressed and closed.
- The test scripts for the integration testing should be ready.
- The testing should be commenced as per the schedule and the plan.
- The test environment should be ready.

Exit criteria for Integration testing

- Issues discovered during the integration testing must be addressed, fixed and closed..
- 10 percent of the benchmark as decided by the QA people is supposed to be allowed for the issues that outstand.
- All the test cases must be executed and passed.
- Transition meeting should be signed off.

What is the entry and exit criterion for regression testing?

Regression testing is a very common software testing methodology and its importance is not hidden from us. Regression testing forms a part of software testing life cycle of every software system or application and project is finalised before running it at least once under the regression testing.

Like the other software testing methodologies the regression has also defined some entry and exit criteria for itself that a software system or application needs to fulfill satisfactorily to undergo regression testing.

But first we will state a brief discussion regarding the regression testing since then it will be easy for us to recognize the entry and exit criteria for the regression testing.

About Regression Testing

- Regression testing is just like the validation testing and is aimed at providing a repeatable and consistent validation of all the changes that have been made to the software system or application under its development or after its completion or after being modified.

- There are chances that at the fixation of a defect new faults and errors might be introduced in to the code of the software system or application that may cause further problems in the functioning of the software system or application.

- An uncertainty is introduced up to some level regarding the ability of the software system or application to make repetition of everything that went right till the encounter of the point of failure.

- To put it simply we can say that the regression testing is nothing but the retesting of the whole software system or application or a selected part of it that has underwent some changes or has been modified for assuring that the encountered fault does not re- occur and none of the previously properly working components of the system like features and functions do not fail as the affect of the introduced modifications.

How to conduct regression testing?

There are many options for conducting regression testing.

- It can either be conducted at the end of the development process of the software system or application.
- It can also be carried out in parallel with the substantial completion of the other software testing methodologies in different phases of the software testing life cycle.

Importance of Regression Testing

- In general, the regression testing is thought of as a quality check tool which controls the quality of the software system or application in regard to the changes made to that particular software system or application and ensures that it does not affects the working of the other previously working components.

- One extremely important point to be noted is that the regression testing is not about testing whether the discovered bugs and errors have been fixed or not but it is all about testing the software system or application up to the point at which the system is not affected by the changes made to fix the bugs.

Entry and Exit criterion for Regression testing

Now we list some of the entry criteria that an application needs to satisfy for undergoing regression testing:
1. The documentation of the defect or the bug is ready and the defect or the bug is repetitive.
2. For the purpose of the identification and tracking of the regression testing efforts, a defect tracking record or a change control has been opened.
3. The creation, review and approval of the tests that are specific to the defect have been done.

There is an only one exit criterion for the regression testing which is that the software system or application should not show any negative result i.e., malfunctioning of any component that was previously working alright before any new changes were introduced to the software system or application for fixing the bug.

What is meant by entry and exit criterion in software testing?

There is always a certain reason, condition, or basis for doing something. One cannot perform a function just like that. The action or the task performed has to have some justification that why it was done. Certain type of criterion is employed in every phase of testing. Mostly they are employed in dynamic and static testing.

WHAT ARE TESTING CRITERION?
The testing criteria have been defined in to 4 types based on the testing phases in which they are employed. These 4 types of criteria have been discussed below:

- Entry criteria
We all know that this is the initial and starting phase of any testing methodology.
- Suspension criteria
Suspension criteria comes in to the play when in a phase the testing is halted so as to get the documentation is send to the development team for verification.

- Re- suspension criteria
Re- suspension criteria are employed when there changes to be made in the documentation as indicated by the development team after the verification.

- Exit criteria
This is the last phase of any testing methodology. The testing is declared complete when these criteria are met.

WHAT IS MEANT BY ENTRY CRITERION?
- Entry criteria as we mentioned above is encountered at the starting phase of any testing methodology.
- It is a kind of document that is needed for starting the testing process.
- It contains all the necessary conditions that have to be met before a testing is commenced.
- Usually the entry criteria are placed in the “approach to test” section of the test plan.
- For every step in the testing strategy some criteria are stated so there is no wasting of time and testing takes place efficiently.
- There are so many factors to be considered while deciding the criteria.

ASPECTS OF ENTRY CRITERION
There are 3 main aspects of entry criteria that have to be considered:

1. Approved Test Plan
- The test plan has to be developed long back before the testing starts.
- Before you commence the testing, you need to get your test plan approved by all the stake holders.
- All the possible risks are identified at this stage.

2. Availability of Resources
- The testing is carried out in a proper testing environment rather than a normal user environment.
- Resources like trained professionals with good testing skills, testing environment, test input data and paper work set up should be available before the testing starts.

3. Developed Tests
- All the test cases and scripts need to be developed before the commencement of the testing and must be verified by the stake holders.

WHAT IS MEANT BY EXIT CRITERION?
Now coming to the exit criteria, it is the criteria which are required to end a test cycle. Exit criteria include:

1. Deadlines for the completion of the testing.
2. Completion of test cases with some minimum passing percentage.
3. Depletion of the test budget.
4. Specific level to be attained by the code coverage, functionality coverage and requirements coverage.
5. Reduction in the number of bugs below a certain level.
6. The end of the testing period of alpha and beta testing.

IMPORTANCE OF ENTRY & EXIT CRITERION
- Entry and exit criteria hold a great importance in the whole testing process.
- Without any entry or exit criteria you will not know when to start or end the testing or when the testing is complete.
- Entry and exit criteria save much of our efforts.
- Apart from this, the entry and exit criteria also increase the knowledge of the tester about the application.
- With the help of these criteria you can quickly move up to the different phases of the test cycle without unnecessarily wasting your time and efforts on one thing.

Introduction to Caching

Caching is a well-known concept where programs continually access the same set of instructions, a massive performance benefit can be realized by storing those instructions in RAM. This prevents the program from having to access the disk thousands or even millions of times during execution by quickly retrieving them from RAM.
A cache is made up of a pool of entries. Each entry has a datum (a nugget of data) - a copy of the same datum in some backing store. Each entry also has a tag, which specifies the identity of the datum in the backing store of which the entry is a copy.
When the cache client (a CPU, web browser, operating system) needs to access a datum presumed to exist in the backing store, it first checks the cache. If an entry can be found with a tag matching that of the desired datum, the datum in the entry is used instead. This situation is known as a cache hit. The alternative situation, when the cache is consulted and found not to contain a datum with the desired tag, has become known as a cache miss. The previously uncached datum fetched from the backing store during miss handling is usually copied into the cache, ready for the next access.
When a system writes a datum to the cache, it must at some point write that datum to the backing store as well. The timing of this write is controlled by what is known as the write policy.
- In a write-through cache, every write to the cache causes a synchronous write to the backing store.
- In a write-back (or write-behind) cache, writes are not immediately mirrored to the store. Instead, the cache tracks which of its locations have been written over and marks these locations as dirty. The data in these locations is written back to the backing store when those data are evicted from the cache, an effect referred to as a lazy write.
- No-write allocation is a cache policy which caches only processor reads, thus avoiding the need for write-back or write-through when the old value of the datum was absent from the cache prior to the write.