What is the key difference between preventative and reactive approaches to testing?

There are two main approaches to testing namely:

1. Preventative approach to testing and
2. Reactive approach to testing

What is Preventive Approach to testing?

- Preventative approach to testing is analytical in nature but reactive is rather heuristic.

- The designing of the preventative tests takes place after the production of the software. 

- On the other hand, the reactive tests are designed quite early i.e., in response to the feed back or review comments given by the customers.

- But both of these tests are designed as early as possible. 

- On an overall basis, preventative tests are created earlier than the reactive tests. 

- The preventative testing approach is based up on the philosophy that the quality of the software system or application under testing can actually be improved by testing if it is done early enough during the software development life cycle.

- However, one specification is to be followed for implement this approach to testing which is that test cases should be created for the validation of the requirements before the code is written.

- Preventive approach is followed because it can be applied to all the phases of the project and not just to the code. It also reduces cost of correcting the underlying faults. 

What is Reactive approach to testing?

- Reactive approach to testing is considered to be a performance testing activity in the field of performance management. 

- The developers often do not think about the performance of the software system or application that they are developing during the early stages of the SDLC or software development life cycle. 

- More often, the performance quotient is neglected till the testing of the system is complete. 

- This is known fact that the performance of a software system or application revolves around its architecture. 

- Designing an effective architecture is a high cost activity and in some of the cases the whole system is trashed because of the presence of the huge deviations in performance factors. 

- However, waiting for problems related to the performance to surface and then dealing with them is not always the best option. 

- So, performance testing is considered to be a reactive approach to testing since the system does not gathers much importance during the early stages of the life cycle. 

- Reactive approach to testing is more of a kind of a “fix it later” approach which is less effective than the preventative approach.

- Even quality control is a reactive approach to testing. 

- Every step of the production development cycle involves quality control. 

- It is not that the developers are simply sitting idle and noting down all the areas where potential issues are suspected after the final outcome.

Importance of both the approaches

- Actually preventative and reactive approaches are considered to be two “test strategies” which are used to define the objectives of the software’s testing and how they are to be achieved. 

- These two approaches also act as a determining factor in the cost and amount of effort that is to be invested in the testing of the software system or application. 

- In preventative approach the testers are involved right from the beginning of the project. 

- The specification and preparation i.e., test planning and test design is also carried out as soon as possible. 

- Preventative approach involves activities like:

1. Reviews
2. Static analysis

- Contrary to the preventative approach, in reactive approach testers are involved late in a project.

- The test planning and designing is started after the development of the project has ended. 

- Reactive approach involves techniques like exploratory testing.

Phase 3 of Unified Process Lifecycle - Construction

Unified process has never been so late in making its mark in the field of the iterative and incremental software development approaches. The unified process has got many refinements and one of them is the rational unified process. The whole process has been divided in to 4 phases the names of which are:

1. Inception
2. Elaboration
3. Construction and
4. Transition

The third phase i.e., the construction phase is what we have discussed throughout this article. So let us see what does this phase actually consists of. This is perhaps the largest phase of the whole unified software development process.

The progress that is to be made in this phase is completely dependent on the foundation that was laid in the previous phase. We mean to say that the remaining structure of the software system is built on the baseline that was developed in the elaboration phase. 

What is the Construction Phase

- Since the construction will be based up on the architecture baseline it is required that the baseline must have been properly developed along with the addressing of the risk factors. 

- In this phase, the implementation of the features and functionality of the software system takes place in an iterative manner and involves the time boxed iterations which are generally of very short duration. 

- These iterations are developed as a time boxed series and with every iteration an executable release of the software system or application is produced. 

- It is quite customary that the full length use cases must be written during the construction phase which then serves as a beginning for a new iteration and the process continues. 

- This phase makes use of the common UML (unified modelling language) diagrams. 

- Some of the common UML diagrams that are generally used are mentioned below:

1. Activity diagrams
2. Sequence diagrams
3. Collaboration diagrams
4. State diagrams
5. Transition diagrams
6. Interaction overview diagrams and so on.

- This is the phase that witnesses a lot of coding takes place since the primary objective is to build the software system or application. 

- However, the primary focus is on the development of the features and components of the system throughout the construction of the software system or application. 

- The number of the iterations involved in the construction depends largely up on the size of the project.

- This is generally done with the purpose of dividing the use cases in to small segments that are manageable enough and lead to the production of the demonstrable prototypes. 

- This is the phase in which the first external release of the software product is produced and this stage is marked by the IOCM or initial operational capability milestone. 

Goals defined for Construction Phase

Few goals have also been defined for this phase of the unified process as mentioned below:

1. Describing the remaining requirements that were not addressed in the preceding phases.
2. Drawing up a design for the system.
3. Ensuring that the system meets the needs of the customers and fit in to the port folio of the organization.
4. Completing component development.
5. Testing of the system and its documentation.
6. Optimizing the resources so that the development cost is reduced.
7. Achieving as much quality as possible.
8. Developing useful versions of the software product.

There is always a rush among the software development organizations to improve the software development processes they are using. Around 80- 90 % of the software failure arises due to faults that are made during the construction phase of the unified process. It is obvious that a more sensible approach will be followed out of all the options available.   

Phase 2 of Unified Process Life cycle - Elaboration

Unified process is one of the outstanding processes that follow an iterative and incremental approach for the software development. The whole process of the unified process is constituted of the 4 stages or phases namely:

1. Inception
2. Elaboration
3. Construction and
4. Transition

This article is dedicated to the second phase of the unified process i.e., the elaboration phase. So let us see what all processes are involved in this phase. 

There exists a short phase between the inception phase and the elaboration commonly knwn as the “elicitation” phase. It is sometimes regarded as apart of the elaboration phase only but to keep the elaboration phase short and simple it is often treated separately.

First let us know what is this elicitation phase? 

Elicitation addresses the below mentioned three main problems of the software development process:

1. Problem of volatility
2. Problem of scope
3. Problem of understanding

What is an Elaboration Phase?

- During this whole elaboration phase, it is required that the project team captures quite a large number of the requirements of the software system or the application. 

- But this is not to be confused with the primary goal of the elaboration phase. It is quite different. 

- The primary goal involves the addressing of the involved and known risk factors. 

- Another aspect of the primary goal is to validate the architecture model being used in the system. 

- This is done with the help of various processes like those mentioned below:

1. Creation of use case diagrams
2. Creation of class diagrams
3. Creation of class with basic notation only and
4. Creation of architectural or the package diagrams.

- All these above mentioned processes fulfil only the first aspect of the primary goal that is to identify the risk factors. 

- The second aspect is fulfilled through the implementation of an EAB or an executable architectural baseline.

- It helps greatly in validation of the system architecture. 

- This is just a partial implementation rather than being a full implementation. 

- The partial implementation is of the components that are architecturally significant like the system including the core.

- The executable architecture baseline is built out of a series of small iterations that have been time boxed so that there is the stabilization of the architecture of the system by the end of the elaboration phase. 

- The executable architectural baseline provides a means to demonstrate that the key system functionality are supported by the architecture and also exhibit proper expected behaviour when it comes to the terms like the scalability, performance and cost. 

- The outcome of the elaboration phase i.e., the elaboration phase deliverable actually serves as a plan for the construction phase that also lays down the cost estimate and the schedule estimates.

- The plan at this point needs to be credible and quite accurate since the elaboration phase experience is what on which it is dependent and also because all the significant risk factors have been addressed during this phase. 

- The ultimate purpose of this phase is to provide the software with a baseline for the architecture of the software system that serves as a foundation for the further efforts. 

Goals of Elaboration Phase

- The following are the goals of the elaboration phase:

1. To have a detailed understanding of the key requirements.
2. To mitigate significant risks.
3. To produce accurate schedule and cost estimates.
4. To design, validate and implement the architecture baseline

- The number of iterations in the elaboration phase is not fixed; it varies depending up on the factors such as the maintenance cycle and the green field development. 

Compare Test Driven Development (TDD) and Agile Model Driven Development (AMDD)?

The test driven development and the agile version of the model driven development i.e.., the agile model driven development are now much in the talks these days!! But many people get confused between the two and are not able to distinguish between them. 

This article is all about a comparison between the test driven development (TDD) and the agile model driven development (AMDD).  

"Agile model driven development involves the creation of the agile models rather than extensive models as in the case of MDD and the whole development process is driven by these models only." 

"The test driven development is not an agile method but the AMDD is and it is used for scaling the agile software development."

Stages of AMDD

 The following are the stages of the high level life cycle of the AMDD:

1. Envisioning
2. Iteration modelling
3. Model storming
4. Reviews
5. Implementation

Stages of TDD

 Below mentioned are the steps that form the short development cycles in a test driven development process:

1. Addition of a test
2. Execution of all tests in order to check the working of the new one and also for the validation of the test harness for its correct working. 
3. Execution of the automated tests and observing their success.
4. Re-factoring of code and cleaning up of the code.
5. Repetition of the whole cycle in order to improve the functionalities.

One of the common scenes during the development is of the model storming sessions. All of the team members model storm for few minutes and then get back to the coding work. The coding is done using many agile software development practices like:

1. Refactoring
2. Test first designing (TFD)

- The above two processes consume time depending up on the complexity and length of the code.

- It may take several hours to implement what has been modelled in the model storming session. 

- The test driven development is actually being implemented here since the combination of the above mentioned two processes is nothing but test driven development. 

- This is the stage where the most of the time of the development team will be spent. 

- Since this is a sort of agile software development, most of the modelling is carried out in the form of executable specifications with the help of development or customer tests. 

- All these efforts are supposed to work since with the agile development you are able to think through the cross entity issues and with the test driven development you are able to think about the much focussed issues. But you can take up only a single entity at a time. 

What more? 

- The re-factoring helps you evolve your design in small iterations to maintain the high quality of your work. 

- With the test driven development the confirmatory testing of your program’s code is done and also the detailed specifications are given. 

- The above mentioned customers tests are also the agile acceptance tests and they form a part of the detailed requirements that are tested by the developer as detailed design.

- Such tests serve as a great example of the single sourcing information.

- Single sourcing is nothing but a technique used by the developers to reduce the overall documentation and thus travel light. 

- In the whole process, the high level specifications should not be over looked. 

Explain the concepts of Directory traversal attacks?

Another name for directory traversal attack is path traversal attack and there is quite unfamiliarity among people regarding this security threat. We have dedicated this entire article to make you aware of this security threat.

What is meant by Directory Traversal Attacks?

- Directory traversal attacks involve the exploitation of the insufficient sanitization or validation of the security regarding the input data supplied by the end user.
- This results in the passing of the characters representing the traverse to parent directory to the API files.
- The directory traversal attacks are aimed at accessing a computer file that is not intended to be accessible by ordering an application to do so.
- The application acts to the commands of the attacker.
- Here, in such situations there is no fault in the program code and it works perfectly fine but, it lacks in security and that is what that is taken advantage of by the attackers.
- He/ she takes an advantage of the lack of the security of the software system or application.
- This is completely opposite to the exploitation of the bugs of a code.
- Some times directory traversal attacks are also denoted as the “_ _ / attack” (pronounced as dot dot slash attack).
- One common form of such attacks is the canonicalization attacks.
- Some other rare forms are back tracking and directory climbing etc.
- In every operating system there exists a common file that is often used by the hackers to crack the passwords.
- In some operating systems like UNIX, no such password file exists.
- Rather the passwords are stored in some shadow file which is not accessible to the users that are recognized as the unprivileged by the machine. - Password  files are useful in another way also i.e., for enumeration of the accounts on that particular machine and displays whatever are the user accounts present on the system.
- Many variations are observed in the directory traversal attacks based on the directory traversal attack strings used in different operating systems.
- Directory traversal attacks create quite a menace these days which becomes quite difficult to manage.

How to prevent directory traversal attacks?

Software engineers have formulated an algorithm for the prevention of directory traversal attacks which is like this:
- Process URI requests such that they do not invoke any file request. For example, execution of a hook in to the code.
-  Always specify the full path to the directory or file if any exists while normalizing all the characters whenever you have to process a URI request. For example, normalize %20 to spaces.
-  Assume the length of the string to be N and a normalized path exists for a document root that is fully qualified and that no files outside this are accessible.
-  Ensure that the first n characters of the string match exactly with the document root of the requested file.
-  If the above condition proves to be true allow the file to be served.
-  If the above condition is proved false, an error should be returned since the requested file is inaccessible.

An efficient control over the accessing of the web content is highly required for the effective running of the web server in a secure mode. Mostly the web servers employ either of the two security mechanisms listed below: 

1. Root directory:
This directory keeps the users bounded to the specific limits outside which nothing can be accessed. It is created in order to avoid the unauthorized access of the files containing sensitive data by unprivileged users.
2. Access control lists (ACLs): 
These lists find their use in the process of authorization.  The lists contain the information of the users who can legally access the files.

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.

How is Graphical User Interface (GUI) testing done?

The term GUI testing is a self justifying term and states that it is a testing that tests the graphical user interface of the software system or application against its specifications and requirements mentioned in the specifications documents.

This article is all about the testing of some of the aspects of a graphical user interface. All the aspects of a graphical user interface are tested using a whole lot of testing techniques.

The test cases are generated by a test designer who has all the knowledge about the application and the tests are designed as such that they cover all the functionality of the system.

1. Steps for Testing of the Text Box
- Firstly, the requirements of the text box are identified and the default values of the text box and the button are tested without any text in the text box.

- The second step is the checking of the NULL condition in which it is checked that whether or not a text of NULL value can be saved.

- Thirdly, the space condition is checked which ensures that a text box can save a space character.

- Fourth, the boundary value condition is checked in which the minimum and maximum text holding value of the text box is tested.

2. Steps for Testing of the Radio Buttons

- Radio buttons are the buttons that are used in making a selection in the lists that contains options that mutually exclusive and only one option has to be selected.

- In the radio button testing it is tested that whether or not clicking on one of the options deselects the other one.

3. Steps for Testing of the Command Buttons

- The working of the command button i.e., whether or not it is following the command which has been evoked. The execution of the command is also tested.

4. steps for Testing of the Aesthetic Conditions

Aesthetic conditions regarding the colour of the background, resizing of the screen, color of the field prompts, font of the text, spelling of the prompts etc are tested using appropriate testing methodologies.

5. Testing of the validation conditions
This testing tests the validation process of the GUI using various white box testing techniques.

6. Steps for Testing of the Usability Conditions

- Usability conditions of the GUI of the applications are tested by the users since a direct input is obtained from the users and is focussed up on the capacity of the product to match with the standards specified by the user.

- Usability refers to the ease of use of any software artefact and it gives a measure of the ease with which the interaction between the user and the application takes place.

- Testing the usability conditions often helps the developers to understand the needs of the customers and helps in focussing the whole development process towards the needs of the customers.

- The rate of the sales and the task completion increases and the number of enquiries in the call center is also reduced.

- Usability is also an effective technique to increase the experience of the end user making it easier to understand and more intuitive.

- The usability testing can also be carried out by the expert evaluators instead of making users do that. The below mentioned aspects are tested:
(a) Performance
(b) User friendliness
(c) Efficiency
(d) Visual design
(e) Consistency

7. Steps for Testing of Data Integrity Conditions

- This era is marked by the increasing demands for the accountability and mobility and thus data integrity conditions need to be tested.

- This is done by using different white box testing techniques for different conditions.

8. Steps for Testing of the Data field checks and Alpha field checks

It is tested whether or not the data fields accept the data of their specified type.

What are three main purposes of software testing?

It is a world wide established fact that the software testing has proved all the way very effective in improving the satisfaction of the clients and customers by delivering them a software product that is quite free of defects, errors and bugs.

Only the stable, error free and reliable software systems and applications are accepted in to the business. There is no place for the unstable and buggy software systems.

WHAT HAPPENS IF TESTING IS NOT DONE PROPERLY?

- There is a substantial increase in the chances of the failure of a software system or application if it is not tested or tested only up to a small extent.

- This in turn increases the rates of wastage of time as well as one’s precious efforts.

- The rework and rewrites and their maintenance cost the organization so much and also annoys the customers and clients.

- If a software system fails, it only gives an indication towards the inadequacy of the efficiency of the system and a lack of testing.

- The failure of the software systems or applications can cost too much in certain cases where very sensitive and critical matters are dependent on the working of the software.

- Software testing has been scientifically defined as a process that deals with the verification and validation of the software system or application.

- It ensures whether or not the system meets all the requirements specifications that have been used all along its development cycle to guide its designing and makes sure that the software system or application is working as expected by the makers.

THREE MAIN PURPOSES OF SOFTWARE TESTING

Three main purposes of the software testing have been laid down as mentioned below:

1. Verification
This purpose deals with the verification of the development process of the software system or application and ensures that the software is being developed or built in the right way.

2. Validation
This is all about making sure that the right software artefact is being produced.

3. Defect finding verification
This is for the purpose of ensuring that the software system or application that is being built, meets the technical specifications and requirements stated for it by the customer or the clients. It also checks out for the variation of the defect range between the actual outcome and the expected outcome.

BENEFITS OF SOFTWARE TESTING

- Software testing has very well taken up the responsibility for ensuring that the software system or application meets the business requirements as specified for it and thus whether or not works as expected.

- The compatibility of the software system or application with a range of different platforms is also evaluated and the performance rating is given.

- Whether the software system or application should be released or not, is determined on the basis of the results of the software testing.

- Software testing has a whole lot of benefits, the greatest ones being the saving of the time and efforts which are indeed very priceless commodities.

- Defects, bugs and errors if detected earlier eat up less time and money and reduce development time and also if the application or system is kept error free in the beginning itself, then less problems will be faced in the future development phases.

Software failures as mentioned above can give rise to life threatening issues to the:

- People (for example, control system failure resulting in a plane crash, life support system failure in hospitals causing deaths)

- Environment (for example, a software failure causes the harmful radiations and chemicals to be released in to the environment and thus affecting the whole eco system)

- Companies (for example, some times the software might do the bill incorrectly due to some discrepancy in it causing the company a great money loss) and so on.

How to test software requirements specification?

Software requirements specifications is often called “SRS” in its short form. We
can simply put it as a specific requirement for a software system or application.

PURPOSE OF SOFTWARE REQUIREMENTS SPECIFICATION

- These requirements specifications give a view of how exactly the system should and how it should behave.
- The software requirements specification comes with a set of cases describing all the possible interactions of the users with the software system or application.
- Such test cases have been termed as ‘use cases”.
- The software requirements specifications contains both kinds of requirements i.e., functional requirements as well as non functional requirements.
- Software requirements specification is an important sub field under the software engineering field.
- The software requirement specification provides a way to enlist all the requirements necessary for the development of the software project in one place.
- It deals with the following issues with regard to the software system or application:


1. Specification
2. Elicitation
3. Analysis and
4. Validation


OVERVIEW OF SOFTWARE REQUIREMENT SPECIFICATION

1.Introduction
This mentions the purpose of the software along with its scope, definitions, a brief overview and a set of references.

2.Overall Description
This section of the SRS describes the perspective, functions, user characteristics, constraints, dependencies and assumptions of the software application.

3. Specific Requirements
This is the most important part of an SRS and includes description of functions, interfaces, logical data base requirements, performance requirements, design constraints and key features.

HOW TO PRODUCE AN EFFECTIVE SOFTWARE REQUIREMENTS SPECIFICATION?

- For producing an effective software requirements specification, you need to test it.
- Therefore a software requirements specification testing has been designed.
- It is popularly known as requirements analysis.
- Requirements analysis analyzes all those tasks that help in identifying the requirement specifications of the software system as well as the requirements specifications itself.
- This actually forms the initial stage of the requirements engineering which is again concerned with the above listed activities.
- The analysis of the requirements specification is crucial for any software system or application.
- All the identified requirements should have the following properties:


1.Actionable
2.Can be documented
3.Testable
4.Traceable
5.Measurable and
6.Defined


PHASES OF SOFTWARE REQUIREMENTS SPECIFICATION TESTING
The software requirements specification testing comprises of the following three phases:

#1. Elicitation of the Requirements:
- This phase involves the identification of the requirements of the consumers.
- This process of communicating with the users and gathering requirements is very well known as requirements gathering.

#2. Analysis of the Requirements:
- This phase involves the determination of the clarity, completeness, ambiguity, contradiction of the requirements.
- If issues are found, they are resolved.

#3. Recording of the Requirements
- There are various ways in which the requirements might be documented.
- Whatever the way maybe, it should be clear and concise.
- Some commonly used methods are: natural language documents, user stories, process specifications and use cases.

What is the difference between conventional and unconventional testing?

Conventional testing and unconventional testing are a less heard testing methodology. Before we discuss about these two methods, let's discuss about the “quality management system” or QMS as it is called in its short form.

QUALITY MANAGEMENT SYSTEM
- Quality management system can be thought of as an organizational structure which states and manages the processes, procedures and resources to be implemented for better quality management.
- Earlier random sampling and simple statistics were used for predicting the output of a test in production line.
- But eventually by the end of the 19th century the entering the data manually for these test cases was considered to be a costly method.
- Later in the 21st century the quality management system succeeded in overcoming this problem.
- It came with a new transparent and sustainable technology which gradually achieved a wide customer satisfaction.

CONVENTIONAL AND UNCONVENTIONAL TESTING
- Conventional testing is nothing but a similar initiative of quality management system.
- Conventional testing is entirely based up on the standards and conventions of the testing as defined by the quality management system.
- It is a way of maintaining the testing standards.
- Since the conventional testing is guided by some conventions, hence it was named so.
- Unconventional testing, we can say just by looking at the name that it doesn’t follow any conventions.

DIFFERENCES BETWEEN CONVENTIONAL & UNCONVENTIONAL TESTING

DIFFERENCE #1:
- In conventional testing, only features and functionality of a software system or application are tested by the engineer in charge of the testing cycle.
- In unconventional testing, only the documentation is verified on the basis of the quality assurance principles.

DIFFERENCE #2:
- In unconventional testing, the documentation is tested from the starting phase of SDLC (systems development life cycle) by the testers of quality assurance.
- Conventional testing comes into play only during the testing phase of the systems development life cycle.

DIFFERENCE #3:
- In conventional testing, the developed components of the application are checked by the tester for whether they are working according to the expectations of the consumers or not.
- A typical unconventional testing starts from the coding phase of the systems development life cycle.

DIFFERENCE #4:
- Unconventional testing keeps a track of the whole software development process on the basis of the quality assurance principles i.e. whether or not the software has been developed according to the guidelines and specifications provided by the client company.
- The conventional testing is focused more up on the functionality of the software system or application.

USES & LIMITATIONS OF CONVENTIONAL TESTING
- Conventional testing is being used in migration projects these days.
- It sometimes happens that the testers performing the conventional testing have a very little knowledge about that particular application software which they are testing. In that the comparison testing is employed.
- This is preferred because here it is not required that the tester should know what will be the outcome.
- This problem can be solved also if the development team has already prepared the test scripts for the tester.
- Conventional testing is a bit expensive as it requires a lot of time to test, verify and validate each and every test script.
- There will be a certain number of errors in a program that is of course obvious and depends up on the degree of complexity of the program
- Errors also depend on the kind of migration process being followed in the project.
- The aspects of the software system or application failing these tests have to be corrected and retested accordingly.

What are different objectives of software testing?

None of the processes in the world are carried out without a purpose. Every kind of software testing has got some objectives. This article discusses such objectives only.
Software testing has got several objectives. Objectives are decided on the basis of the expectations of the software developers.

- Software testing is expected to distinguish between the validations of the software system and defects present in the software system.
- It is necessary to describe the principles on which the software works and processes the data.
- It is also important for us to know the principles of different kinds of testing.
- Before creating the tests cases for testing one should decide for a proper strategy to follow so as to achieve the desired objectives.
- The tester should understand the characteristics and behavior of the tools that are being used for the test automation.
- Before testing any software system, the tester should know the problems that can cause the system to fail. Failures should be known otherwise it will be difficult to prevent the potential harm.
- When the software developer pens down the objectives of the testing, he should keep in mind the requirements of the customers.
- Apart from the requirements it is also necessary to keep knowledge about the non requirements of the users.

Both these requirements and non requirements form a major an important part of the objectives of testing. In fact, we can say that 95 % of the objectives of the testing are based on the requirements and non requirements of the user.

There is one more kind of requirements called the missing requirements.
- Missing requirements are the requirements that are needed but they are absent form both the customer’s requirements list and non requirements list.
- Only the software developer or the tester can figure out the missing requirements.
- These missing requirements also form a small part of the objectives of the testing.
- There are some requirements needed for the software system but they are almost impossible to implement.

Below mentioned are the objectives of software testing clearly and in detail:
- To check whether the system is working as required or not.
- To prove that the software system is free of any errors.
- To certify that the particular software system is correct to the best knowledge of the programmer and the tester.
- To certify that the software can be used without any fear of losing data or damage.

For achieving the objectives, testing can be done in following two ways:

Negative testing
- This testing tests for the abnormal or negative operations in the software system.
- This is carried out by using illegal or invalid data.
- In negative testing, the tester intentionally tries to make the things go wrong and checks what happens then.
- Based on the observation, improvement is made further. It checks if the program crashes or not, if the program does any unexpected thing?, whether the software system successfully achieves the target or not?

Positive testing
- In this kind of testing, the software system is operated normally with correct data input values.
- Proper test cases are used.
- This testing methodology includes testing of system software at the boundaries of the program.
- This is done to determine the correctness of the program. Actual result and the expected result is compared and it is determined whether or not the program is behaving normally?,results coincide with the expected results?, software system is still functioning properly or not?

Not to much surprise, the negative testing has got a positive side. It checks out all the flaws, errors and the discrepancies before they show up in the front of the user. After all, a testing is regarded good only if it fails the software system.

What are differences between verification and validation?

Verification and validation together can be defined as a process of reviewing and testing and inspecting the software artifacts to determine that the software system meets the expected standards.

Though verification and validation processes are frequently grouped together, there are plenty of differences between them:

- Verification is a process which controls the quality and is used to determine whether the software system meets the expected standards or not. Verification can be done during development phase or during production phase. In contrast to this, validation is a process which assures quality. It gives an assurance that the software artifact or the system is successful in accomplishing what it is intended to do.

- Verification is an internal process whereas validation is an external process.

- Verification refers to the needs of the users while validation refers to the correctness of the implementation of the specifications by the software system or application.

- Verification process consists of following processes: installation, qualification, operational qualification, and performance qualification whereas Validation is categorized into:
prospective validation
retrospective validation
full scale validation
partial scale validation
cross validation
concurrent validation

- Verification ensures that the software system meets all the functionality whereas validation ensures that functionalities exhibit the intended behavior.

- Verification takes place first and then validation is done. Verification checks for documentation, code, plans, specifications and requirements while validation checks the whole product.

- Input for verification includes issues lists, inspection meetings, checklists, meetings and reviews. Input for validation includes the software artifact itself.

- Verification is done by developers of the software product whereas validation is done by the testers and it is done against the requirements.

- Verification is a kind of static testing where the functionalities of a software system are checked whether they are correct or not and it includes techniques like walkthroughs, reviews and inspections etc. In contrast to verification, validation is a dynamic kind of testing where the software application is checked against its proper execution.

- Mostly reviews form a part of verification process whereas audits are a major part of validation process.

Verification, Validation, and Testing of Engineered Systems

Fundamentals of Verification and Validation

Verification and Validation in Computational Science and Engineering

What are different methods of verification and validation?

Verification and validation together can be defined as a process of reviewing and testing and inspecting the software artifacts to determine that the software system meets the expected standards. There are various methodologies for verification different kinds of data in software applications. The different methods have been discussed below:

- File verification
It is used to check the integrity and the level of correctness of file. It is used to detect errors in the file.
- CAPTCHA
It is a kind of device that is used to verify that the user of the website is a human being and not some false program intended to hamper the security of the system.
- Speech verification
This kind of verification is used to check the correctness of the spoken statements and sentences.
- Verify command in DOS.

Apart from verification techniques for software applications there are several other techniques for verification during the development of software. They have been discussed below:

- Intelligence verification
This type of verification is used to adapt the test bench changes to the changes in RTL automatically.
- Formal verification
It is used to verify the algorithms of the program for their correctness by some mathematical techniques.
- Run time verification
Run time verification is carried out during execution. It is done to determine if the program is able to execute properly and within the specified time or not.
- Software verification
This verification type uses several methodologies for the verification of the software.

There are several other techniques used for verification in circuit development. - Functional verification
- Physical verification
- Analog verification

Verification, Validation, and Testing of Engineered Systems

Fundamentals of Verification and Validation

Verification and Validation in Computational Science and Engineering

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 are Construction Practices in Software Engineering Practice? - Part 1

In software engineering practice, construction practice includes coding and testing tasks and principles. Coding involves direct creation of source code, automatic generation of source code and automatic generation of executable code using fourth generation programming languages.

CODING PRINCIPLES

Coding principles include preparation principles, coding principles, validation principles.
Preparation principles include:
- good understanding of the problem is necessary.
- good understanding of design principles and concepts.
- choose the right programming language and environment.
- unit tests that are applied once the component you code is completed.

Coding principles include:
- choose data structures.
- constrain algorithms.
- choose software architecture and interfaces.
- nested loops should be simple and easily testable.
- conditional logic should be simple.
- variable names should be meaningful.
- code should be self documenting.

Validation principles include:
- a code walk-through is conducted.
- unit tests are performed.
- code re-factoring is done.

What are steps involved in deriving test cases? What are Validation, Alpha, Beta testing? What are test metrics?

The steps in deriving the test cases using use cases are:
- Using the RTM, the use cases are prioritized. Importance is gauged based on the frequency with which each function of the system is used.
- Use case scenarios are developed for each use case. The detailed description for each use case scenario can be very helpful in later stage.
- For each scenario, take at least one test case and identify the conditions that
will make it execute.
- Data values are determined for each test case.

After system testing is culminated, validation testing is performed which consists of a series of black box tests. It focuses on user-visible actions and user-recognizable output.
Alpha and Beta Testing are a series of acceptance tests. Alpha testing is performed in a controlled environment normally at developer's site. In alpha testing, developers record all errors and usage problems while end users use the system. Beta testing is done at customer's site and developers are not present. In beta testing, end-users records all errors and usage problems.

The amount of testing effort needed to test object oriented software can be indicated by the metrics used for object-oriented design quality. These metrics are:
- Lack of Cohesion in Methods (LCOM)
- Percent Public and Protected (PAP)
- Public Access To Data Members (PAD)
- Number of Root Classes (NOR)
- Number of Children (NOC) and Depth of the Inheritance Tree (DIT)

What are different tasks of requirement engineering - Elaboration,Negotiation,Specification,Validation,Management

Elaboration involves the information that is obtained from team during inception and elicitation is expanded and refined. It focuses on defining, redefining and refining of models. It tries to model the "WHAT" rather than the "HOW".
- Requirement is created using methods that capitalize on user scenarios.It describes how the end-users and actors interact with the system.
- The analysis model is derived from the requirements model where each scenario is analyzed to get the analysis classes.
- The requirements model and the analysis model are the main workproduct of this task.

Negotiation involves customers, stakeholders and software development team reconcile conflicts. The purpose of negotiation is to develop a project plan that meets the requirements of the user while reflecting real-world constraints such as time,people and budget. Negotiation includes:
- always remember negotiation is not completion.
- always have a strategy.
- always listen effectively.
- always focus on other party's interest.
- never make it personal.
- always be creative.
- be ready to commit.

Specification is the final artifact or work product produced by the software engineer during requirements engineering. It serves as the foundation for design and construction of software.

In Validation,the work products produced as a consequence of requirements engineering are assessed for quality. It checks whether inconsistencies, omissions, and errors have been detected and corrected. The
review team that validates the requirements look for errors in content or interpretation,areas where clarification is required, missing information, inconsistencies,conflicting and unrealistic requirements.

Management is a set of activities that help the project team identify, control, and track requirements and their changes at any time as the project progresses.

What comprises Test Ware Development : Test Plan - Unit Test Plan

The test strategy identifies multiple test levels, which are going to be performed for the project. Activities at each level must be planned well in advance and it has to be formally documented. Based on the individual plans only, the individual test levels are carried out.
The plans are to be prepared by experienced people only. In all test plans, the (ETVX) Entry-Task-Validation-Exit criteria are to be mentioned. Entry means the entry point to that phase. Task is the activity that is performed. Validation is the way in which the progress and correctness and compliance are verified for that phase. Exit tells the completion criteria of that phase, after the validation is done.

ETVX is a modeling technique for developing worldly and atomic level models. It is a task based model where the details of each task are explicitly defined in a specification table against each phase i.e. Entry, Exit, Task, Feedback In, Feedback Out, and measures.
There are two type of cells, unit cells and implementation cells. The implementation cells are basically unit cells containing the further tasks. A purpose is also stated and the viewer of the model may also be defined e.g. to management or customer.

Types of Test Plan

Unit Test Plan (UTP)
The unit test plan is the overall plan to carry out the unit test activities. The lead tester prepares it and it will be distributed to the individual tester, which contains the following sections:

- What is to be tested?
The unit test plan must clearly specify the scope of unit testing. In this, normally the basic input/output of the units along with their basic functionality will be tested. In this case, mostly the input units will be tested for the format, alignment, accuracy and the totals.

- Sequence of testing
The sequence of test activities that are to be carried out in this phase are to be listed in this section. This includes, whether to execute positive test cases first or negative test cases first, to execute test cases based on the priority, to execute test cases based on test groups etc.

- Basic functionality of units
The independent functionalities of the units are tested which excludes any communication between the unit and other units. The interface part is out of scope of this test level.

Apart from these, the following sections are also addressed:
- Unit testing tools
- Priority of program units
- Naming convention for test cases
- Status reporting mechanism
- Regression test approach
- ETVX criteria

Validation Phase - Beta Testing - Objectives

The beta testing is conducted at one or more customer sites by the end-user of the software. The beta test is a live application of the software in an environment that cannot be controlled by the developer. The software reaches beta stage when most of the functionalities are operating. The software is tested in customer's environment, giving the user an opportunity to exercise the software, find the errors so that they could be fixed before product release. Beta testing is a detailed testing and needs to cover all the functionalities of the product and also the dependent functionality testing. It also involves the user interface testing and documentation testing. Hence, it is essential that this is planned well and the task accomplished. The test plan document has to be prepared before the testing phase is started, which clearly lays down the objectives, scope of test, tasks to be performed and the test matrix which depicts the schedule of testing.

The objectives of beta testing is to:
- evaluate software technical content.
- evaluate software ease of use.
- evaluate user documentation draft.
- identify errors.
- report errors/findings.

The role of a test lead is to provide test instruction sheet that describes items such as testing objectives, steps to follow, data to enter, functions to invoke and to provide feedback forms and comments.
The role of a tester is to understand the software requirements and the testing objectives and carry out the test cases and report defects.

Validation phase - User Acceptance Testing and Installation Testing

User Acceptance Testing occurs just before the software is released to the customer. The end-users along with the developers perform the User Acceptance Testing with a certain set of test cases and typical scenarios.

Installation testing is often the most under tested area in testing. this type of testing is performed to ensure that all installed features and options function properly. It is also performed to verify that all necessary components of the application are, indeed, installed. Installation testing should take care of the following points:
- To check if while installing product checks for the dependent software/patches.
- The product should check for the version of the same product on the target machine, say the previous should not be over installed on the newer version.
- Installer should give a default installation path.
- Installation should allow user to install at location other than the default installation path.
- Check if the product can be installed "Over the Network".
- Installation should start automatically when the CD is inserted.
- Installer should give the Remove/Repair options.
- When uninstalling, check that all the registry keys, files, DLL, shortcuts, activeX components are removed from the system.
- Try to install the software without administrative privileges.
- Try installing on different operating system.
- Try installing on system having non-compliant configuration such as less memory/RAM/HDD.