What is CPU Scheduling Criteria?

Scheduling is an essential concept that serves in the multitasking, multiprocessor and distributed systems. There are several schedulers available for this purpose. But these schedulers also require a criterion up on which they can decide how to schedule the processes. In this article we discuss about these scheduling criteria. Today a number of scheduling algorithms are available and all these have different properties. This is why these may work up on different scheduling criteria. Also the chosen algorithm may favor one class of processes more than the other.

What Criteria is used by algorithms for Scheduling?

Below mentioned are some of the criteria used by these algorithms for scheduling:
1. CPU utilization:
- It is a property of a good system to keep the CPU as busy as possible all the time.
- Thus, this utilization ranges from 0 percent to 100 percent.
- However, in the systems that are loaded lightly, the range is around 40 percent and for the systems heavily loaded it ranges around 90 percent.

2. Throughput:
- The work is said to be done if the CPU is busy with the execution of the processes.
- Throughput is one measure of CPU performance and can be defined as the number of processes being executed completely in a certain unit of time.
- For example, in short transactions throughput might range around like 10 processes per second.
- In longer transactions this may range around only one process being executed in one hour.

3. Turnaround time:
- This is an important criterion from the point of view of a process.
- This tells how much time the processor has taken for execution of  a processor.
- The turnaround time can be defined as the time duration elapsed from the submission of the process till its completion.

4. Waiting time:
- The amount of time taken for the process for its completion is not affected by the CPU scheduling algorithms.
- Rather, these algorithms only affects the time when the process is in waiting state.
- The time for which the process waits is called the waiting time.

5. Response time:
- The turnaround is not a good criterion in all the situations.
- The response time is favorable in the case of the interactive systems.
- It happens many a times that a process is able to produce the output in a fairly short time compared to the expected time.
- This process then can continue with the next instructions.
- The time taken for a process from its submission till production of the first response is calculated as the response time and is another criterion for the CPU scheduling algorithms.

All these are the primary performance criteria out of which one or more can be selected by a typical CPU scheduler. These criteria might be ranked by the scheduler depending up on their importance. One common problem in the selection of performance criteria is the possibility of conflict ion between them.
For example, increasing the number of active processes will increase the CPU utilization but at the same time will decrease the response time. This is often desirable to produce reduction in waiting time and turnaround time also. In a number of cases the average measure is optimized. But there are certain cases also where it is more beneficial to optimize the maximum or the minimum values.
It is not necessary that a scheduling algorithm that maximizes the throughput will decrease the turnaround time. Out of a mix of short and long jobs, if a scheduler runs only the short jobs, it will produce the best throughput. But at the same time the turnaround time for the long jobs will be so high which is not desirable.

Document Restructuring - an activity involved in software re-engineering process model.

Software re- engineering process model is a generic one and consists of 6 major steps:

1. Inventory analysis
2. Documentation reconstruction
3. Reverse engineering
4. Code re- structuring
5. Data re- structuring
6. Forward Engineering

This article is dedicated to the discussion regarding the second step of the software re- engineering process model i.e., the documentation reconstruction. 

Why Documentation Reconstruction is important?

It has been observed from the inventory analysis of many organizations that most of the documentation attached with the software systems or applications is either outdated or does not pertain to the documentation standards or refers to the earlier versions of the particular software system or application. 

In such cases, reconstructing the entire software documentation becomes very necessary. The need for re- engineering is felt in three typical situations:

1. When the changes made to a system are confined only to the sub system, there is a need to re- engineering the sub system.

2. When the software as well as the hardware support becomes obsolete.

3. When the tools required for supporting the re- structuring are available.

When it comes to restructuring the documentation the below mentioned options are available to the developers:

1. Keep the weak documentation itself.
2. Update those parts of the documentation that are needed.
3. Rewrite the whole documentation on the “essential minimum requirements” for the critical systems.

- Any existing documentation of the software under re- engineering process is gathered and copies of any required third party software are obtained. 

- All the associated data files and the source code files that are required for the execution of the software system or application are documented and this documentation forms the baseline for the existing version of the software system or application. 

Why Documentation is necessary?

- Documentation forms a very important part of the entire re- engineering process since like other resources it is also a primary resource of information regarding the software system or application. 

- Documentation serves as a potential support for the future maintenance of the software system or application. 

- Documentation should be self sufficient enough to the extent that any developer having knowledge of that programming language must be able to speed up the work with the code in a short period of time using the documentation. 

What is to be contained in the documentation depends pretty much up on the type of the software system or application that is being re- engineered and also on the contents of the previously existing documentation. 

- However, the documentation must contain description of the changes that were introduced during the process of re- engineering. 

- The documentation must also highlight the details of the configuration plan and baselines of the software system or application that were created for the re- engineering process. 

- Other aspects to be included are mentioned below:

1. Steps to verify which version of the software system or application is installed.
2. How to install/ uninstall the software application.
3. How to use the software system or application (a quick guide).
4. Overview of the design of the software system or application.
5. How to build the application software ready for the release.

- After re- engineering process is complete the same documentation must be update and if no documentation exists, one should be created. 

- After the re- engineering the re- engineered software system or application is baselined along with this documentation and the project log and is now considered to be ready for the release. 

Inventory Analysis - an activity involved in software re-engineering process model.

The software re- engineering process model over the years has proved to be a very effective process in bringing the poorly maintained and controlled code to an acceptable standard. This model consists of the below mentioned 5 steps:

1. Inventory analysis
2. Document reconstruction
3. Reverse engineering
4. Code re- structuring
5. Data re- structuring
6. Forward Engineering

In this article we have discussed about the first step of the process i.e., inventory analysis in detail. 

Characteristics of Inventory Analysis

- It is obvious for every organization to maintain an inventory of all the software systems or applications it has developed whether they are active or not.

- An inventory is like a spreadsheet containing details of the software system or application against its name. 

- In inventory analysis, the software systems and applications are sorted out on the basis of the following criteria:

1. Business criticality
2. Longevity
3. Current maintainability and
4. Local criteria

- This step of the software re engineering process model helps the team to identify what all the software systems or applications require to be re- engineered.  

- Firstly, a table is build that lists all the software applications.

- After this a list of criteria is established on the basis of the criteria like few of which have been mentioned below:

1. Name of the software system or application.
2. Year of its creation.
3. Number of changes or modifications it had gone through since its creation.
4. Effort applied in making those modifications.
5. Effort applied in making the last of the modifications.
6. Date on which the last modification was made.
7. The systems in which the application now resides.
8. Other applications with which this application shares the interface.

- The primary purposes of this step is prioritizing all of them and analyze them so as to select the candidates for re- engineering. 

- The steps for the creation of an effective inventory are:

1. Preparing for data collection
2. Collecting the data
3. Deciding the criteria
4. Allocation

- It has not been wrongly said that “well begun is half done” since the organization may have to suffer a huge set back if it chose wrong candidates for re- engineering. 

- So selecting the candidates for re- engineering during the stage of inventory analysis holds importance. 

- The inventory analysis is a very generic process.

- The inventory analysis looks up with the details of all small and big aspects of the software systems and applications and therefore it becomes easy to select which candidates really need re- engineering.

- Usually the software systems or applications which have not been updated since a long time and are no more accepted and are undocumented are given the first priority.

- Such software systems and applications often have documentation associated with them that is either not updated or relates to the previous versions of the particular software system or application. 

- Problems with the selected candidates are identified and they are carried forward to the next step of the software re- engineering process model. 

- Before you start the restructuring of the code it is necessary that the objectives of the re- engineering are defined. 

- Re- engineering actually consists of 11 steps but they are shortened down to 5 major steps. - The detailed steps are:

1. Identifying the existing documentation
2. Verifying the identified code
3. Familiarising with the existing software
4. Identifying the re- engineering requirements
5. Drawing up the re- engineering plan
6. Producing a test plan, test script and test data.
7. Producing test results for original software and the ported version.
8. Restructuring the code
9. Testing the code
10. Updating the documentation

What are different kinds of soft skills to be a successful tester / test manager?

Soft skill can be defined as a sociological term that plays a very important role in the success and personality development of an individual and can be related to his/ her following aspects:

1. Emotional intelligence quotient
2. Personality traits
3. Communication
4. Languages
5. Social graces
6. Friendliness
7. Attitude (whether pessimistic or optimistic) and
8. Personal habits and so on.

Why Soft Skills important?

- Soft skills in a way complement the IQ i.e., intelligence quotient of a person.

- IQ is included in the hard skills of a person.

- All these skills form an essential part of the occupational requirements for a job.

- A tester or test manager also needs to incorporate all these attributes in himself/ herself in order to be successful and enhance his interactions with the fellow team members, career prospects and also the job performance.

- The soft skills of a tester/ test manager can be related to his/ her ability of interacting effectively with the clients, customers and co workers.

- The soft skills of each and every individual combined together contribute to the success of the organization which can’t be ignored.

- This is the reason why the soft skills are being focussed up on as equally as the hard skills.

Soft skills are considered to be as the behavioural competencies and are more commonly known as the interpersonal skills and include:
1. Conflict resolution
2. Conflict negotiation
3. Communication skills
4. Creative problem solving
5. Selling skills
6. Strategic thing
7. Influencing skills
8. Team building etc.

Another Soft Skill

- Ability to participate actively in the group discussions is also an essential soft skill that companies seek in the testers and test managers.
- It is often the first criteria for the selection.
- Good communication and group discussion skills are the must software skills for the testers.
- The best thing about the soft skills is that they are honed for the professional needs but they eventually affect ones personal life in all the aspects.

So instead of just honing the technical skills, the testers require to focus up on building up their soft skills. But here we do not mean to say that the hard skills should be undermined. A tester cannot survive his job if he is not good at his technical skills. You need to strike a balance between both the hard and soft skills to make yourself a successful tester.

Some Important Soft Skills
Here are some important soft skills:

1. Discipline and perseverance
These two soft skills are psychological tools to persevere and make your efforts more productive. It increases the quality of your work and helps you focus well.

2. Reading skills
Reading skill may sound odd here but its importance will be realised as you deal on with the large amount of specifications and information every day. Testers have to deal with large chunks of information and a hell lot of documentations every day and so honing this soft skill becomes apparently necessary.

3. Negative thinking
Now you must be wondering what this is for. Well, negative thinking though works badly for the real aspects of life but it really helps a lot in testing while using tactics like negative testing, exploratory testing, fault injection techniques etc, since in such testing techniques, the tester to consider all the things by which the program can be affected.

4. Communication and interpersonal skills

5. Time management skills
These are needed since you need to make most of your time.

6. Effort prioritization
This is needed to assign importance to the tasks so that you an finish up all of them efficiently without messing up.

7. Attitude

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.

What is meant by novice testers? How should they perform software testing?

WHO IS A NOVICE TESTER?

- A novice tester as we all know is a tester who is new in the field of software testing.
- He does not have any past experience and they have so many queries about the matters regarding the software testing field.
- They also have many doubts regarding the work that they have to do.
- Though being a novice tester, he/ she must be well versed with the basic principles of the field and disciplines to be followed.

Here I’m going to discuss some ways to help novice testers in improving their software testing skills. Follow the tips being mentioned and get great benefits:

1. HAVE FULL INFORMATION ABOUT THE APPLICATION

- Have full information about the application that you are going to test.
- You should understand what are its requirement functionalities and non requirement functionality.
- Performing software testing without the knowledge of the software program or application will lead you nowhere.
- Lack of understanding will not be able to decide that whether the output that you have obtained is correct or not.
- You will not be able to tell if the functionality under test is working properly or not.
- You will not be able to notice the absence of any functionality.
- Therefore, having a full detail of the software program or application under testing is necessary.

2. KNOWLEDGE ABOUT DOMAIN

- Like about software program or application, you should also have knowledge about your domain.
- Knowing about one’s domain solves many problems.
- Once you know about your domain, you will be able to suggest better solutions for the errors and bugs in the program.
- The more you keep your solutions in the limits of the domain, the more value your suggestions will get.
- Don’t just catch the bug; provide them counter measures also to curb them.
- Another problem that will be solved is of test cases.
- You will have better criteria to design your test cases up on.
- Your test cases will be capable of providing enough coverage to the code.

3. KEEP YOURSELF UP-TO-DATE WITH AVAILABLE TECHNOLOGIES

- Keep learning about the available technologies in the field as well as keep yourself updated with the new upcoming technologies.
- Come out with new practical ways for providing better solutions to the testing problems rather than just relying on the knowledge from the books.
- Learn with experience more than books.
- Design your own working procedures.
- It is not necessary to stick to the old pre designed procedures until and unless you don’t have an option.
- Keep rejuvenating your existing knowledge.

4. AVOID MAKING ASSUMPTIONS

- Don’t make assumptions. Assumptions don’t work for software testing.
- Never assume that the software program or application will be error free.
- This will be a mistake and will lead you to serious consequences.
- It is the duty of tester to look for bugs and errors.
- You cannot make sure that a program or application is error free and there is no need for testing.

5. GIVE YOUR BEST IN DISCOVERING ERRORS

- Testing an application over and over again still won’t make it 100 percent error free.
- Keep on discovering errors and bugs and give your best in correcting them.
- Have a priority list which will guide you about the testing sequence i.e., which functionality is to be tested first and so on.

6. DO NOT LIMIT YOUR THINKING

- Always think that you’re the end user and perform testing.
- Don’t limit your thinking to the designation of a tester but, think like a user also.
- This helps in many ways.
- You will be able to make out that what functionality IS important and need to be introduced in the software program or application that were missing previously.
- Think how this software application will be used by the user and what can be his expectations.
- All this will help you in making your software user friendly.

What are different characteristics of Compliance testing?

Compliance testing perhaps sounds a very rare kind of testing, less often heard about. It can be defined as the audit of a software system or application which is carried out against well known criteria.

There are many kinds of compliance testing and some are even developed as per the requests of the customers or the clients. Basically the compliance tests are of the following types:

Systems in Development
It refers to the compliance testing in which the verification of the fact that the intended software system or application under development meets the lock down standards, configurations and specifications as requested by the client or the customer is done.

Operating systems and applications
- It refers to the compliance testing in which the verification of the fact that an operating system and software system or applications have been configured and designed appropriately and properly as per the requirements, specifications and lock down standards given by the clients and the customers is done.

- Thus, this kind of compliance testing provides robust, adequate and efficient controls to ensure the availability, integrity and confidentiality of the software system or application is not affected during its normal usage and is maintained throughout the whole working process.

Management of IT and enterprise architecture
- It refers to the compliance testing in which the verification of the fact that the all the in-place IT management infrastructure aspects of the software system or the application have been put in their appropriate place is done.

- This is generally done to ensure that the audit, change in controls, security procedures and business continuity have been documented, formulated and put in their proper place and remain effective.

Inter- connection Policy
It refers to the compliance testing in which the verification of fact that the business continuity controls and adequate security measures that govern the connection of the software system with other systems like the systems for tele- communication, extranets, intranets, internet and so on, have been put in their appropriate place, have been cross checked with the specifications and requirements stated by the clients and the customers and have been fully documented is carried out.

These were some standard compliance tests.
Apart from these there are some normal compliance tests which encompass either a few or all of the compliance tests mentioned above.
- Some lockdown policies are applied to the underlying applications or software systems and operating systems.
- Some of these policies are passed by the clients or the customers and some by the concerned parties.
- These policies can be referred and can be used as a guidelines as and when required by the customers or clients when the software testers or developers have already performed a compliance test.
- They can also be referred after the penetration testing and vulnerability assessment of the software system or application so that more security measures can be applied to the system’s enterprise in order to improve its security.

The national security agency or NSA as it is often abbreviated has provided a number of lock down policies and guidelines to increase the awareness of the security affairs that are affecting our operating systems, software systems and applications etc.
The policies cover the following:

- Database servers
(a) oracle 10g
(b) oracle 9i
(c) Microsoft SQL server

- Operating systems
(a) Apple server operating systems
(b) Apple Mac OS
(c) Microsoft Windows NT
(d) Microsoft windows XP
(e) Microsoft windows 2000
(f) Sun Solaris 8
(g) Sun Solaris 9
(h) Microsoft windows server 2003


- Routers
- Switches
- Web servers and browsers
- IP and VoIP telephony
- SQL Server 2000
- BIND
- Novell eDirectory

What are different characteristics of stability testing?

Stability testing in the context of software testing and engineering as it itself
indicates, refers to the many attempts to determine if an application will crash.

- Stability testing seeks to find a fault, an error, a bug or a reason that can render the software system or the application as non working or which can make the application lame.
- The main objective of the stability testing is to determine if there are any grounds on the basis of which the software system or application should be kept void of certification and it also aims at finding some positive point on the basis of which the software system or the application can be granted the certification.

- For a software system or application to be certified, it should be in functional state and basically stable.
- This can only be done by applying specific and suitable criteria and tests for testing functionality and stability. This is nothing but the stability testing.

There are several criteria available for stability testing. Few have been discussed below in detail:

1. Pass or fail criteria
- Each primary function tested and then the results are recorded.
- Each and every individual function is operated or executed in a way that is apparently consistent with its objective or the purpose regardless of the degree of correctness of its result or output.
- The observations are recorded for analysis.
- It is certain that out of so many functions, at least one or two primary functions will prove incapable of operating in a way that it apparently consistent to their aim or purpose.

2. Functional ability of a software system or the application
- There is for sure some impairment in any software system.
- But that does not necessarily mean that the software system is not fit for normal use.
- Any software product or application is said to work abnormally in a way that it seriously impairs it for the normal usage.

3.Disruption criteria
- The software system or the application is observed to disrupt the normal functioning of the operating system.

4.Criteria of in-operability
- No primary function of the software system or application is observed to get obstructed and become inoperable and non functional during the course of the testing.
- There is at least one primary function of the software system or application is observed to get obstructed and become inoperable and non functional during the course of the testing.

5. The software system or the application is observed to crash, fail, loose data and hang.

Some Important Points:
- Stability can be defined as the ability of a software system or application to continue functioning in the case of over time and over its full range of functionalities without crashing, failing or hanging and loss of data.

- For a tester to know whether the software system is seriously unfit for normal and regular use, he /she is required to have a knowledge of how that software system or application works in a normal environment i.e., normal user and normal usage.

- In order to carry out the stability test, the tester requires knowing the types of data values which software system or application can effectively and efficiently process.

- To test for the instability of a software system, the tester needs to use his knowledge in order to give some challenging inputs to the system to fail the system.

Define the tracking progress for an object oriented project?

For a object oriented project, tracking becomes really difficult and establishing some meaningful milestones is also a difficult task as there are many things that are happening at once. For tracking an object oriented project, following milestones are considered to be completed when the below mentioned criteria are met:

Milestone for Object Oriented Analysis is considered completed when the following conditions are satisfied :
- Every class is defined and reviewed.
- Every class hierarchy are defined and reviewed.
- Class attributes are defined and reviewed.
- Class operations are defined and reviewed.
- Classes that are reused are noted.
- The relationships among classes are defined and reviewed.
- Behavioral model is created and reviewed.

Milestone for Object Oriented Design is considered completed when the following conditions are satisfied :
- Subsystems are defined and reviewed.
- Classes are allocated to sub systems.
- Classes allocated are reviewed.
- Tasks are allocated.
- Task allocated are reviewed.
- Design classes are created.
- These design classes are reviewed.
- Responsibilities are identified.
- Collaborations are identified.

Milestone for Object Oriented Programming is considered completed when the following conditions are satisfied :
- Classes from design model are implemented in code.
- Extracted classes are implemented.
- A prototype is built.

Milestone for Object Oriented Testing is considered completed when the following conditions are satisfied :
Debugging and testing occur in concert with one another. The status of debugging is often assessed by considering the type and number of bugs.
- The correctness of object oriented analysis and design model is reviewed.
- The completeness of object oriented analysis and design model is reviewed.
- Collaboration between class and responsibility is developed and reviewed.
- Test cases designed are conducted for each class.
- Class level tests are conducted for each class.
- Cluster testing is completed and classes are integrated.
- Tests related to system testing are established and completed.

Each of the milestone is revisited as object oriented process model is iterative in nature.

Introduction to Validation testing? What is the validation criteria?

Validation tries to uncover errors, but the focus is at the requirements level, i.e. on the things that will be immediately apparent to the end user. It begins at the end of integration testing, when all individual modules are packaged and interface errors are uncovered and corrected. In validation testing phase, testing focuses on user visible actions and output that is user recognizable. The criteria of software entering into validation phase is that it functions in a manner that is reasonably expected by the customer.

In software requirements specification, there is a section called validation test criteria. Test plan lists out the tests to be conducted and a test procedure defines test cases. These plan and procedure are designed to ensure that all the functional requirements are satisfied, behavioral characteristics are achieved, performance requirements are attained, usability is met and documentation is done.

Configuration review ensures that all elements of software configuration are properly developed, cataloged and every necessary detail is given. It is also known as audit.

Alpha testing is done at developer's site. It does not happen at usual workplace. The real users are simulated by using these techniques and carrying out tasks and operations that a typical user might perform.

Beta testing is done at end user sites. The developer is not present. It is the live application of software in an environment that is not controlled by the developer. The end user records all the problems that he faces and reports to the developer.

What is the outline of test plan? What are test specification items?

There is an outline that should be followed while writing a test plan. It consists of the following:
- The Background
- The Introduction
- The Assumptions
- The Test Items to be tested.
- The Features to be tested.
- The Features not to be tested.
- The Approach that is to be followed.
- Item Pass/Fail Criteria which is an itemized list of expected output and tolerances.
- The Suspension or Resumption Criteria.
- Test Deliverable which includes beside software, what else would be delivered?
- Testing Tasks which consists of functional and administrative tasks.
- Environmental needs like security clearance, office space and equipment, hardware and software requirements.
- Responsibilities.
- Staffing and Training
- Schedule
- Resources
- Risks and Contingencies
- Approvals

Test specifications are developed from test plan and are a part of second phase of test development life cycle. How to implement the test cases is explained through test specifications. It consists of following:
- Case Number
- Title of Test
- ProgName which consists of program name containing test.
- Author
- Date
- Background which consists of Objectives, Assumptions, References, Success Criteria.
- Expected Errors
- References
- Data that flows between the implementation under test and test engine.
- Script

Verification Strategies - Reviews - Design Review and Code Review

Design Review: A process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include critical design review, preliminary design review and system design review.Quality assurance team member leads design review. members from development team and QA team participate in the review.

Input Criteria: Design document is an essential document for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewers comments and suggestions and the re-verification whether they are incorporated in the documents.

Code Review: A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. QA team member(in case the QA team is only involved in black box testing then the development team lead chairs the review team) leads code review. Members from development team and QA team participate in the review.

Input Criteria: The Coding Standards Document and the Source file are the essential documents for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewer's comments and suggestions and the re-verification whether they are incorporated in the documents.