What is the value of a testing group? How much interaction with users should testers have, and why?

The software testing is quite a tedious work and therefore cannot be performed by a single person alone lest he is working on a very small project. A software testing team may consist of any number of software testers. Till the year of 1980 the term “software tester” was a general term and it was after that only that the software testing evolved as an individual profession. 

Software testing requires for various kinds of roles as mentioned below:

1. Manager
2. Test lead
3. Test designer
4. Tester
5. Automation developer
6. Test administrator

All these above mentioned roles constitute a complete software testing team. In this article we shall discuss about the value of the software testing team and also how much interaction with users should testers have and its need. 

Value of a Testing Group/Team

- A testing team should be independently empowered otherwise it won't be effective. 

- Managing a testing process without the use of any separate test plan and test strategy is quite a tedious job. 

- One of the typical features of an independent testing team is that it does not perform white box testing.

- Only when the defects are logged, the value of a testing team is realized by the whole development process and people involved in it. 

- A good testing team always makes sure that the software testing life cycle of the software system or application flows through the following stages:

1. Planning
2. Specifications
3. Execution and
4. Completion

- A typical testing team does not bothers itself with the quality of the code i.e., whether it is poorly written or well written as long as the required functionality is addressed by it.

Interaction of testing team with users

-For a testing team interacting with the users is quite a difficult job.

-Generally, when a detailed documentation of the software system or application is present, a very less interaction is required with the users. 

- On the other hand, when there is a lack of documentation a great user tester interaction is required. 

- However, irrespective of the availability of the documentation, a user interaction is always recommended since the actual usability, need and the functionality of the software system or application can be known only through the users.

- Most of the testing teams enforce user tester interaction and thus it is becoming quite common these days. 

- One more reason for the rise in the user tester interaction is that the more and more testing teams are following the trend of carrying out UAT or user acceptance test which involves a vigorous interaction among the testers and users and therefore increasing the margin of user tester interaction. 

- Also, it is important for the better development of a software system or application that the thoughts of the testers work in sync with the users.

- There are testers working in different situations out of which some cause problems. 

- Good testers usually have a habit of conversing in terms of the user’s thinking like:

         1. What goals they might be having? 

         2. What tasks they might want to perform? 

         3. How they might perform those tasks? And so on.

- When good testers look at a feature, user’s reaction is the first thing that comes to their mind.

- A good tester understands quite well that how the software system or application is exploited by the user, how the program will be affected by whatever the user does and what affect it will have on the user’s habits.

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

How is test driven development and documentation linked?

As we all know that the test driven development or TDD is another process in the list of the most of the popular software development processes. The topic of the test driven development is in the league of this article. 

About Test Driven Development

- The test driven development took its root from the idea of the repetition of a very short development cycles. 

- The first of all a failing automated test case is written or created by the software developer or tester which is meant to serve the purpose of defining a new function or a desired improvement. 

- Secondly a code to pass the above created test is also written by the developer. 

- This newly written code is then subjected to refactoring in order to make it meet the acceptable standards. 

- The test driven development has always been looked up as an encouragement for the simple designs and also as an inspiration for boosting up the confidence levels.

- The test driven development has always been known to be related to the concepts of the extreme programming or XP. 

- But, eventually it came to be known as a standalone process having its own ways and rights.

- The concepts of the test driven development are used by the programmers and developers as a measure for debugging the legacy code and improving it further. 

- The test driven development is usually driven by a series of automated unit tests that are written by the developer to provide definition for the requirements of the code and then the code is automatically produced. 

- These tests are constituted of the assertions of their own.

- If a test is successfully passed, the developer is confirmed of the correctness of the code and that it can be further evolved and refactored. 

The documentation forms a very important part of any development or testing and so does of the test driven development. This article has taken up the question: “how is test driven development and documentation linked?”. 

About Importance of Documentation In TDD

Now coming to the importance of documentation in the test driven development, it includes the following documents:

1. Feasibility report
2. Technical documentation
3. Operational documentation
4. Log book and so on.

- The documentation in test driven development is another source of support to the developers as well as the users.

- It provides all the crucial information required to set up a uniform environment in which the software system or application is to be operated. 

- In case of a break down when the person in charge is not available, the users experience down time and most of their resources are wasted. In such situations, there is only one thing that can save one’s precious time and efforts and that thing is nothing but the documentation. 

- It provides all the information and guidelines that are required to fix an issue. 

- The format of the documentation does not matter much as much as it content matters.

- Documentation is vital to any software development process and not particularly to the test driven development.

- Documentation is an effective mean for streamlining the test driven development process. 

- Apart from all this, documentation has got an important role to play in the business.

- Document is needed in the test driven development since it helps in codifying the procedure for the development of the software system or application. 

- The documentation provides effective protection during the audits to the test driven development.

- It is important that the documentation is developed alongside the development of software system or application. 

- Documentation will be effective if it is considered to be a part of the work and not a hindrance to it. 

What are the items covered in a test plan?

One cannot expect the two cycles namely the STLC or software testing life cycle and the SDLC or software development life cycle to succeed without a test plan. Like a lamp is needed to guide one along a dark path, similarly a test plan guides the whole software testing process in to the right direction and keeps the whole development process on track.

Without a test plan you won’t be able to know that whether or not you are building the right software artefact and even if you are building the right one, are you building it in the right way? ; realizing later will prove to be a heavy burden for you and also it will cost you double the initial cost.

What does a test plan do?

- The test plan covers up various aspects of the process of software testing.

- To say it simple, a test plan lays out a systematic approach for the process of software testing of a proposed software system or application.

- By looking at the test plan one gets to what will be the work flow and how it will take place.

- Preparation of a test plan involves the documentation of the strategy that is to be followed during the testing process.

- Firstly the users’ requirements documentation prepared in the requirements analysis phase is studied thoroughly and understood by the test engineers and then they figure out all the possible methods and techniques that can be employed to satisfy all the requirements.

- Finally, all the requirements that can be incorporated in to the software are listed and those which cannot be are informed to the user.

- Accordingly, the requirements are resolved and a test plan is formulated for achieving all the objectives.

Items covered in test plan

A typical test plan has to have one or more of the below mentioned items according to the norms and responsibilities levied on the organization:

(a) Compliance test or design verification
- This is the first step in the testing process and involves the development of the smaller units or modules of the software system or application after they have been approved by the senior developers or testers.

- In this, the objectives of the software system are established and defined. But, it is not defined how that system will be designed or achieved.

- It also involves the generation of user requirements documentation.

(b) Production test or manufacturing
- This step is executed when the software product is being assembled and for the purposes of controlling the quality.

(c) Commissioning test or acceptance
- This step is carried out before the final product is released to the client or the users.

(d) Repair test
It can be performed any time during the service life of the software.

(e) Regression test

Test plan according to IEEE 829 standard

The level of the design of the test plan depends on the complexity of the software program. IEEE has laid down what all the items are to be covered by a test plan via the 829 standard for software test documentation:

- Test plan identifier
- Background
- Introduction
- Assumptions
- Test items
- Features to be tested: functionalities and requirements that have to be tested.
- Features not to be tested: functionalities and requirements that don’t have to be tested with reasons.
- Approach: description of the data flow, live execution, simulation and philosophy behind it.
- Item pass/fail criteria: expected outcomes and tolerances.
- Suspension criteria and resumption criteria: description of the check points.
- Test deliverable
- Testing tasks
- Environmental needs
- Responsibilities
- Staffing and training needs
- Schedule
- Risks and contingencies
- Approvals

What are different design specifications while drawing a test plan?

When a development team is working on a project, how do they ensure that the functionality is being coded correctly? Design specification documentation serves this purpose.

What are Design Specifications?

- A design specification document must be free of any ambiguities and should be complete, since an incomplete design specification document full of ambiguities can have you reaching for the costly rewrites.

- A good design specification follows a pyramidal approach i.e., from the top it provides a complete and broad overview of the software system or application and its components and at the lower levels it provides a detailed overview of the primary components of the application.

- The details should be as much required by the development team.

- Most of the software developers tend to work with design specifications documents which include detailed description of every function, sample screen shots, layouts of the data base as well as reports.

- Many a times it happens so that the client does not provides sufficient detail; in such a case the developer responds in writing asking as many questions required getting a detailed overview of the project.

- These questions are supposed to enquire in depth regarding the design specifications of the application under development.

- Writing an effective and a self sufficient design specification document is an art in itself.

- If you find it difficult to write a design specification document, you can first write a basic outline and then fill it up based up on the needs of the client as well as the skills of the developers.

- Coming up with a document that fits the requirements and needs of both the client and the developer is quite a difficult and requires a lot of struggle.

- There is no need to show the entire specification document to the client or the customer since they won’t understand it.

- Some organizations even take up the extraneous effort for creating two design specifications documents.

- One contains only a broad overview of the application for the customers and clients while the other one consists of detailed description of the application and its primary components meant for the developers.

- There are some artistic developers who themselves like to fill up the details for the design specifications after knowing what functions are to be performed by the application.

- To make it easier, you can start off with a high level description of the design specifications followed by signing off by the client.

- Then you can go for writing second file with more detailed descriptions.

- Keep the design specification document updated as regularly as possible.

- IEEE has come forward to help in this regard and it has laid down “IEEE 1016- 1998 standard” for specifying a structure for the SDD or software design description.

What should a design specification include?

According to IEEE standard, the design specifications must include at least the following:

1. Introduction: It includes
(a) overview of the design and
(b) Requirements traceability matrix

2. System architectural design: It includes (a) discussion regarding the alternative designs
(b) Chosen system architecture
(c) System interface description

3. Detailed description of the application components

4. User interface design: It includes
(a) description of the interface
(b) Objects and events (actions)
(c) Screen image

5. Additional information

After completing writing down the design specifications, you should compulsorily have it signed off by the client or the customer so as to have a proof that they abide by everything that is there in the specifications document.

This also provides coverage to your bases and enforces that the customer reads the whole specifications document. The design specifications should also be reviewed by the quality assurance people since a good design specification helps in creating better test cases.

What are different functional specifications while drawing a test plan?

The successful completion of the software testing cycle depends entirely up on the quality of its test plan. Any test plan is composed of certain specifications which are not to be missed if you want your plan to be effective. Specifications are of two types namely:

1. Functional specifications and
2. Design specifications.

What are functional specifications?

- Functional specifications which are nothing but a formal document that is created for the purpose of describing a detailed overview of the software system’s or application’s intended functions and capabilities.

- It describes in detail the appearance of the software application as well as how it is to interact with the users.

- The functional specifications can be thought of as guidelines or references by the program developers and programmers while the development of the software is in progress.

- The functional specifications for the software system or application that are equipped with some windows and dialogs are aimed at showing the visual appearance of its user interface and also to give a detailed description of all the possible inputs from the users and the reactions of the application to them.

- A functional specification may or may not include a formal description of the dependency of the application on other programs or applications, usability criteria and user tasks.

- To define a functional specification formally we can say that it is to describe the solution technically and is also used as a representation of the contract between a client and project development team.

- It forms the basis for building any application.

What are different functional specifications while drawing a test plan?

- While drawing the test plan, the program manager baselines the functional specifications which are placed under the change control since it sustains all the information that is needed to design the solution.

- Functional specifications seek to incorporate logical, physical and conceptual designs in to the solution for making it more efficient.

- All the high level design decisions regarding the network configurations and server management should also be included under the functional specifications.

What aspects should a functional specification include?

A typical functional specification describes the following aspects:

1. Summary of the project scope (as agreed up on the by both parties in a business context).

2. Any additional requirements

3. The design of the solution

4. Specifications of the components that form a part of the solution

5. Features:
Documentation of all the planned features along with their quantitative specifications such as performance metrics, concurrent user capacity, and data base capacity and so on.

6. Security requirements:
Specifications regarding the strength of security concerning the functions that involve working with sensitive data like transactions. The encryption standards that have been implemented in the security mechanism should also be mentioned along with the location and type of the security mechanisms.

7. Legal requirements:
These must be clearly stated along with the custom codes to me business policy, custom user scenario or a governmental requirement etc.

8. Risk assessment:
This documentation must include the descriptive details about:
- potential vulnerabilities,
- mitigation strategies and
- the impact of the above strategies and vulnerabilities on the application.

There should be no ambiguity in the description of the above stated aspects and the quantitative measurements should be used wherever possible.

What aspects should a functional specification should not include?

Now we list the aspects that should not be included in the functional specifications:
1. Detailed data base schema
2. Details of the software architecture
3. Details about the programming language

Data base details suffice the purpose of the functional specifications and save the development team from extraneous efforts.
The functional specifications are changed only with the due permission of the client. Functional specifications are the living documents i.e., they are continuously updated throughout the development cycle and show how a solution can be deployed in a timely and cost effective manner.

What should a test plan test?

It is common tendency of us to chalk out a plan before we start doing any task! Why do we make plans? Simply because we don’t want our process or task to go astray. We want to keep a track of the processes and make sure that they are being guided in to the right direction and also most of the errors and faults are avoided.

Same philosophy holds hundred percent true for the software testing life cycle also. It also requires a test plan to prevent itself from going astray and slip out of track! To say it scientifically, we mean that a test plan is required for determining whether the software system or application meets the specifications and requirements listed for it or not?

WHAT SHOULD A TEST PLAN DO?

- A test plan is prepared by the test engineers after struggling with all the requirements of the testing phase and the software and after assessing all the risks associated with the project.

- As a normal plan would do i.e., test plan details out a systematic approach to the accomplishment of a certain task, so does a test plan with the only difference being the task.

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

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

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

- A test plan states the strategy to be followed to make the software testing successful or in other words we can say that it provides a means to check whether or not the software system or application meets all the requirements and specifications as mentioned by the client or the customer in the documentation.

ITEMS OF A TEST PLAN

A typical test plan has to have one or more of the below mentioned items according to the norms and responsibilities levied on the organization:

(a) Compliance test or design verification
- This is the first step in the testing process and involves the development of the smaller units or modules of the software system or application after they have been approved by the senior developers or testers.
- In this the objectives of the software system are established and defined. But, it is not defined how that system will be designed or achieved.
- It also involves the generation of user requirements documentation.

(b)Production test or manufacturing
This step is executed when the software product is being assembled and for the purposes of controlling the quality.

(c) Commissioning test or acceptance
This step is carried out before the final product is released to the client or the users.

(d) Repair test
It can be performed any time during the service life of the software.

(e) Regression test

WHAT ITEMS ARE COVERED IN A TEST PLAN VIA IEEE 829 STANDARD?

IEEE has laid down what all the items are to be covered by a test plan via the 829 standard for software test documentation:
1. Test plan identifier
2. Background
3. Introduction
4. Assumptions
5. Test items
6. Features to be tested: Functionalities and requirements that have to be tested.
7. Features not to be tested: Functionalities and requirements that don’t have to be tested with reasons.
8. Approach: description of the data flow, live execution, simulation and philosophy behind it.
9. Item pass/fail criteria: expected outcomes and tolerances.
10.Suspension criteria and resumption criteria: description of the check points.
11.Test deliverables
12.Testing tasks
13.Environmental needs
14.Responsibilities
15.Staffing and training needs
16.Schedule
17.Risks and contingencies
18.Approvals

One cannot expect the two cycles namely the STLC or software testing life cycle and the SDLC or software development life cycle to succeed without a test plan.

Explain the concepts of (Institute of Electrical and Electronics Engineers) IEEE 829 standard?

The contributions in the field of electrical and electronics engineering by the IEEE or the institute of electrical and electronics engineers are not hidden from the world. The institute has its official head quarters situated in the city of New York.

It emerged as a non profit organization and since then is comprised of professionals from the fields of electrical and electronics engineering. The main aim of the association has always been to continually make excellent technological advancements in the field of electrical and electronics engineering.

ABOUT IEEE & IEEE 829

- IEEE currently has been reported to have around 40,00,00 members world wide and across 160 plus countries.

- Around 45 percent of the member population is from other countries besides United States.

- The history of the IEEE dates back to the 19s. IEEE was started as a non profit association in the New York City in the year of 1963.

- It was formed as a resultant the merging of 2 great individual non- profit institutes of that time namely the American Institute of electrical engineers (AIEE) and the institute of radio engineers (IRE).

- AIEE and IRE were formed in 1884 and 1912 respectively and in 1963 they merged together to give rise a new association i.e., institute of electrical and electronics engineers.

- Since then, IEEE has given so many standards for many fields like electrical, electronics and software testing etc.

- One such standard given in the field of software testing is “IEEE 829 – 1998” often called as “829 standard for software test documentation”.

- This standard has been designed especially for the documentation of the whole software testing process.

- It specifies what all documents are to be included in the currently defined 8 stages of the software testing cycle.

- Each stage has been stated with its individual document specifications.

- The IEEE 829 – 1998 standard just not specifies the documents to be produced but also lays down their formats.

But, it does not give any clear answer for whether or not all of the specified documents should be produced? Not only this, it also does not states what all content is to be included in these documents.

WHAT DOCUMENTS ARE PRODUCED?

As per the standard, the below mentioned documents are to be produced:

1. Test plan
The document that gives the management features of the testing cycle and includes:
(a) How the testing will be carried out?
(b) System under test or SUT configurations
(c) Who will carry out the testing?
(d) Estimated time
(e) Test coverage and quality level of the testing

2. Test design specification
The document listing all the detailed conditions as well as results and passing criteria.

3. Test case specification
The document specifying the input data for test cases.

4. Test procedure specification
The document having detailed description on how to run each and every specified test case and also describes the set up conditions and the steps to follow.

5. Test item transmittal report
The document giving the reports of one stage of the testing cycle after its completion.

6. Test log
The document maintaining the records of the test cases i.e., their title, executor, and final status i.e., pass or fail.

7. Test incident report
The document detailing the observations of the test cases that didn’t pass. It gives the causes of the failures of the test case and the expectations. The failure of a test case is often treated as an incident rather than a fault.

8. Test summary
The document providing a brief report of the whole testing cycle and also covers up the aspects that were not covered up in any of the above listed documents like software quality, quality of the testing efforts etc.

What is evolutionary requirements analysis?

Requirements analysis is of many types depending up on which development process or methodology is being followed. This article has been written about a type of requirements analysis known as “evolutionary requirements analysis”. But, before going on to the main discussion we will first brief up ourselves with the concepts of a general requirements analysis.

WHAT IS REQUIREMENTS ANALYSIS?

- Requirements analysis is a means of encompassing the tasks that are used in the determination of the conditions and the needs of the new software system or application under development.

- Even the various requirements of the stake holders that conflict with each are taken in to account in the requirements analysis.

- The stake holders here can be either the users or the beneficiaries.

- Requirements analysis actually fall under the category of the requirements engineering but it is a common and frequent requirement of all the other branches of the engineering.

- It encompasses with the below mentioned activities:
1. Eliciting
2. Analyzing
3. Documenting
4. Validating
5. Management of the software system

- With a proper requirements analysis only a proper base version of the software system or application can be created which other wise would be an impossible job.

- For a requirement of the software system or application to be taken in to consideration under the requirements analysis it should possess the below mentioned characteristics:
1. It should have been documented.
2. It should be actionable and active.
3. It should be measurable.
4. It should be traceable by the testing methodologies
5. It can be related to the identified business opportunities, activities or needs.
6. It should have been sufficiently defined with details for the designing of the software system or application.

If we see concept wise, three major activities are involved in any requirements analysis which are:

1. Eliciting Requirements
This activity is involved with the identification of the various kinds of requirements that have been derived from several sources like:
(a) Business process documentation,
(b) Project documentation
(c) Project charter,
(d) Interviews of the stake holders,
(e) User stories and so on.
This step is often known as the “requirements gathering”.

2. Analyzing Requirements
This step is involved with the determination of the level of correctness of the stated requirements in the requirements list on the grounds of the following factors:
(a) Clarity
(b) Completeness
(c) Consistency
(d) Unambiguity
(e) Resolution of any apparent conflicts and so on.

3. Recording Requirements
This step is involved with the documentation of the requirements in various forms like:
(a) Summary list
(b) Natural language documents
(c) User stories
(d) Use cases
(e) Process specifications and so on.

EVOLUTIONARY REQUIREMENTS ANALYSIS

- Requirements analysis is quite a time consuming as well as an arduous process for which many types of psychological skills have to be exercised.

- With the new environment, changing of the requirements and the stake holders is obvious, and so it becomes extremely important to keep the requirements updated by identifying the needs of the stake holders.

- It should also be determined that up to what level did the stake holders understood the implications of the program.

- The evolutionary requirements analysis is often abbreviated to “ERA”.

- As the term itself states, the evolutionary computing techniques are used in the automatic selection of the machine and human agents in the model of the software system so as to match the requirements which are non functional.

- The aspects such as the performance, reliability and cost of many different software systems are analyzed via the execution of the model variants along with the scenarios.

- Out of all, the software systems which perform better are selected in order to obtain an optimal solution.

Why is documentation so important for software testing?

IMPORTANCE OF DOCUMENTATION

- Software documentation like other kinds of documentation is just a piece of plane text.
- Though just being plain text, its importance in the field cannot be neglected.
- You must have observed that whenever you purchase some software or application it comes with a documentation which contains user’s manual also.
- It is obvious that you must be using this user’s manual to understand and use the software better.
- The manual might have always helped you in diagnosis of your system whenever it might have had a break down, crash or hang.
- Documentation is a great help as it helps us in operating the software system or application.
- Documentation helps different people in different ways.
- Documentation has a very important role to play in the field of software engineering.

TYPES OF DOCUMENTATION

1.Requirements Documentation
- This documentation states all the requirements of a software system or application be it functional requirements or non functional requirements.
- Apart from the requirements it also states the features, functionalities, capabilities, attributes and characteristics of a software system or application. - This type of documentation serves as a foundation for the other documentations.

2. Technical Documentation
- This documentation contains the written code of the program and algorithm implemented.
- It also provides knowledge about the user interface of the software system or application.
- It also gives information about the APIs.

3. Marketing Documentation
- This documentation gives tip and information for marketing the software product.

4. Architectural Documentation
- This documentation is all about the internal structure of the software system or application.
- It explains how a particular software system or application is related to the environment and on what principles the construction of the program is based.

5. End user Documentation or User’s Manual
- This document is popularly known as user’s manual.
- It contains all type of knowledge that a user might need to operate the software system or for trouble shooting.

SOME FACTS ABOUT DOCUMENTATION
- Documentation introduces the software system or application to the user.
- It contains details about the software.
- Documentation can be thought of as a verified and validated agreement between the product developer and the buyer i.e., client.
- Documentation is modular in nature.
- It serves as road map for the user.
- It is said that if something is not present in the writing, it actually never happened.
- Documentation serves as a proof.
- If you don’t make a write up about the software, the client or the users will think that you are just making up the facts and if the things are there, they might have been done by some body else.
- You need to document every aspect of your software so that if later any dispute arises, none will be able to testify your work and decisions.
- Information contained in the documentation is very crucial and important.
- The software engineering industry is so documentation intensive.

Let us say that you have a program that got some problem like it crashed or hanged and the person in charge of the software is not available. Neither you know the structure and design of the program nor do you have any idea of how to mend the fault in the program. So what you will do in such a case?

Here documentation comes to your rescue.
- You have all the necessary details and tips on how to fix a fault and also the design of the program.
- It is important that the proper documentation is made available to each and every personnel of the software development team.

What are common programming bugs every tester should know?

A programming bug as we all know is common or “one in all” term for a flaw, error or mistake in a software system or program. A bug is known for producing unexpected result always or results in the abnormal behavior of the software system or program.

CAUSES OF BUGS
- Root causes of the bugs are the faults or mistakes introduced in to the program’s source code or design and structure or its implementation.
- A program or a piece of program too much affected with bugs is commonly termed as a “buggy” program or code.
- They can be introduced unknowingly in the software system or program during the coding, specification, data entry, designing and documentation.
- Bugs can also arise due to complex interactions between the components of a complex computer program or system.
- This happens because the software programmers or developers have to combine a great length of code and therefore, they may not be able to track minor bugs.
- The discovered bugs are also documented and such documents or reports are called bug reports or trouble reports.

HOW BUGS INFECT A PROGRAM ACTUALLY?
- A single bug can trigger a number of faults or errors within the program which can affect the program in many ways.
- The degree of affecting depends on the nature of the bug.
- It can either affect the program very badly causing it to rash or hang or it may have only a subtle affect on the system.
- There are some bugs that are not detected in the entire software testing process.
- Some bug may cause a chain effect which can be described as one bug causing an error and that error causing some other errors and so on.
- Some bugs may even shut down the whole software system or application.
- Bugs can have serious impacts.
- Bugs can destroy a whole machine.
- Bugs are after all mistakes of human programmers.

TYPES OF BUGS
Bugs are of many types. There are certain types of common bugs that every programmer should be introduced with.

First we are listing some security vulnerabilities:
- Improper encoding
- SQL injection
- Improper validation
- Race conditions
- Memory leaks
- Cross site scripting
- Errors in transmission of sensitive data
- Information leak
- Controlling of critical data
- Improper authorization
- Security checks on the client side and
- Improper initialization

SOME COMMON BUGS ARE:

1. Memory leaks
- This bug is catastrophic in nature.
- It is most common in languages like C++ and C i.e., the languages which do not have automatic garbage collection feature.
- Here the rate of consumption of memory is higher as compared to rate of de- allocating memory which is zero.
- In such a situation the executing program comes to a halt because there is no availability of free memory.

2. Freeing the resource which has already been freed
- This bug is quite frequent in occurrence.
- Usually it happens that the resources are freed after allocation but here already freed resource is freed which causes an error.

3. De-referencing of NULL operator
- This bug is caused due to an improper or missing initialization.
- It an also be caused due to incorrect use of reference variables.

4. References
- Sometimes unexpected or unclear references are created during the execution which may lead to the problem of de- allocation.

5. Deadlocks
- These bugs though rare are catastrophic and are caused when two or more threads are mutually locked by each other or those threads get entangled.

6. Race conditions
- These are frequent and occur when the same resource or result is being tried to be accessed by two threads.
- The two threads are said to be racing.

What are the different tips for writing test cases?

What is the foremost thing that should be taken care of to carry out effective testing? Its test cases of course! Writing test cases without thinking is not going to help because any amount of efforts and time you waste on them, you are not going to get effective results. Writing test cases forms a major component of any software testing methodology.

SOME IMPORTANT FACTS

1. Any change in the requirements tends to affect the concerned test case as well. Since the test cases are based upon the requirements, any change in requirements is reflected in the test cases. If you make any changes to the requirements, make sure you have altered the related test case also accordingly.

2. After you finish writing your test cases, revise them twice so that any error that you didn’t notice can be found out.

3. It rarely happens that all the written test cases are executed. So keep the number of test cases limited i.e., as many as you can execute. If you have less number of test cases, you will be able to focus on them properly.

4. Some test cases demand other test cases as their prerequisites. If that is the case, then you should go through the list of test cases and decide a sequence for executing the test cases.

5. Some test cases are dependent on each other and so it becomes difficult which one to execute first. So try to keep your test cases as much independent as possible.

Now keeping above points in mind, we define some tips for writing effective test cases that if followed will certainly reap you the expected results:

1. Keep your test cases as simple as possible. i.e., keep them to the point and precise. You should be able to integrate your test cases with the test plan.

2. Document your test cases.

3. Review all your test cases at least twice.

4. Include input test data along with the test cases because if the tester is to choose test data by himself/ herself, he/ she may omit the most important test data making the whole testing go in vain.

5. While writing test cases always keep in mind that the end user is the one who will use the AUT.

6. Pay due attention while writing the test cases because this will affect the whole testing process.

7. For every condition or assertion in the program, write a different test case so that you don’t mix up.

8. Make sure that your each test case tests only one aspect of the program. Otherwise you will have problems like over lapping and over complicated tests. If one test case focuses upon one aspect, then the code will get good coverage and tracking any error will be easy.

9. Prepare documentation for every test case. Your documentation should have assertions and description of 4 stages (set up, execution, verification, and output) of the test case.

10. Select a basis on which you want to organize your test cases like functionality or class, so that it becomes easy for you to add new test cases later. The order of your test cases should be consistent.

11. The test cases should be able to execute with a good speed, should be independent as discussed above, should be small and precise so that they can be repeated without much hassle is needed to and should be transparent. By transparency I mean that the test case should clearly state its purpose.

12. Your test cases should be reusable.

What are the tips to achieve effective software testing documentation?

As we all know that documentation is some written text that comes along with any software system or application. Though being just a plain text its importance cannot be neglected.
Without it, we won’t be able to make the full use of the software system or application. It explains us its features and functionalities and how to use it effectively. Documentation has a very important role to play in the field of software testing:

1. It gives an overview of the design or architecture of the software system or application. It explains how the software is related to the environment and what basic principles have been used in constructing the software system or application.

2. It gives technical knowledge about the concerned software system or application. It provides the documentation of the code and other legal aspects of the software.

3. It contains the algorithm used in the software system and provides explicit knowledge about the user interface of the software system or application.

4. Documentation states the requirements of the software system and functionalities whether it be functional or non functional requirements. Other aspects like capabilities, attributes and characteristics of the software system or application are also mentioned in the documentation.

5. It contains tips on how to market the product.

6. Documentation also contains end users manuals and other supportive manuals meant for support staff and administrators.
For documentation to prove effective has to be written properly in a designed way.

Writing effective documentation is also a recognized skill in the software industry. Here we are going to discuss some tips which if followed can help you improve the quality of your documentation.

1. You should be familiar with all the format types of the documents like PDF or HTML. You should be able to work with all the types. It may happen some times that when you transfer your write up to the documentation software, it may not show up exactly as you desired. So don’t waste your time by unnecessarily formatting your text. Choose your documentation software with great care.

2. Divide your documentation process into following stages:

(a) Information gathering: First gather all the information that you will need to include in your documentation.

(b) Prototyping of the documentation: In this stage you will create a list of just the topics that you have to include in the documentation in the order you desire. Your list may contain samples against each topic for your ease and convenience.

(c) Initial drafting: This stage involves writing up of all the content under the relevant topics that you have already listed. This will take up most of your time. After you are done with the writing, just review it once.

(d) Final drafting: At this stage you have to review your documentation once more so as to check whether any changes are required. The documentation is now ready.

3. It is always observed that the documentation is always processed at the end i.e., when the dead lines are nearing. This should not be done since the documentation does not get much time for effective reviewing and changes. So it becomes important that we consider the documentation from the initial stage of software development.

4. The preparation of the documentation becomes more simple and easy if your organization has an expert documentation writer. But what if you don’t have? A programmer can himself/ herself write the documentation since he/ she knows the program really well. But the documentation won’t be so effective if the programmer has not got good skills in writing.

Whatever the case maybe, always remember that the documentation does affect the user’s opinion about the program. So keep it simple, effective and impressive.