TestLink is a Free, open source test case management tool? - Explain?

Testlink is a free open source test case management tool! It means that it can be freely redistributed and accessed. These kind of open source tools have been invented so to support the new environment created by the issues like:

                                            1.  Licensing

                            2.  Copyright

3                          3. Domain issues

4                          4.  Consumer issues

    

      

Concepts of Open Source Models

 -The open source models employ the concept of different agendas but concurrent with different approaches in  production. 

      - The whole open source concept works on the principle of the peer production.

      - Peer production means collaborating and bartering with the end documentation, source material, blue prints and product which are available for free to the public.

    - The source code of the testlink is made publicly available and the public is given full right for modifying, copying and redistributing it at no cost. 

   - It has evolved through the community operation which is comprised of many individual software programmers from large companies. 

       

What purposes are facilitated by Test Link?

       Testlink is an open source test management tool and provides the facilitation for purposes like:

1                                          1. Test specification

                                            2. Test planning

                                            3. Test reporting

                                            4. Tracking of the requirements

                                            5. Collaborating with the well known bug trackers

     

         

 Features of TestLink

      1.  Set urgent tests

            2.  Custom.css

            3.  Gives an option for creating new test cases and requirements.

            4.   Offers the possibility to do a quick DIFF of the 2 test case versions.

            5.   Fully supports the internet explorer 9 via ExtJS 3.4.0.

            6.  Direct links to each and every requirement can be generated.

            7.  Table ruler

            8.  The requirement versions are well supported by the internal links.

            9.  After editing the requirements and specifications, the tree can be refreshed.

          10.  The states of the tree can be stored and restored in a very reliable way.

          11.  Test result matrix facilitates the filtering by status.

          12.  Requirement revisioning.

          13.  Test case and new requirement comparison method.

          14.  PHPMAILER

          15.  Collapse and expand buttons for trees

          16.  Log messages for the history of the requirements.

          17.  MSSQL support

          18.  IE8 based event viewer

          19.  Query metrics

          20.  Improved minor usability

          21.  Improved tables via EXT- JS

          22.  Improved filters

    23. At the build level, test case execution assignment has been provided.

In spite of all such great features, currently there are two features lurking out:

               1. The debug messages interfere with the working of the reports.

               2. There are troubles going on with the updating of the test case executions. 

       

       

Benefits of TestLink

 

      1. Using the testlink, one can easily integrate one’s test scripts to get the results. 

     2. It is a test management tool that is completely independent and is very effective in managing testing cycle    in a short period of time. 

     3. It helps in cutting down the management, development and maintenance cost of your project, thus making the whole project quite affordable and feasible for you.

     4. It helps in simplifying and accelerating the whole testing process and reporting by:

                 -  Collecting and organizing all of your test cases in a dynamic way.

                 -  Tracking the metrics and the results in association with the test execution.

                 -  Capturing and reporting the details.

                 -  Customizing itself to fit your processes and requirements.

5. It overall assists you in conducting an efficient and thorough testing process and makes best use of the experience it has achieved over 100s of implementations for the clients around the world. 

6. The redistribution of this tool is governed by the GNU general public license.

What is meant by production verification testing?

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

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

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

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

About Production Verification Testing

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

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

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

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

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

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

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

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

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

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

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

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

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

Entry and Exit Criterion for Production Verification Testing

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

Entry criteria:

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

Exit Criteria:

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

What kinds of people are involved in software testing?

Software testing like any other process of the software development cycle is a very critical and important phase and so does it has been dedicated an entire cycle called software testing life cycle. Without software you will not have any direction in the way of software development.

The overall efficiency of the software testing depends a whole lot on the professionals or individuals performing it. This article is about the people who are involved with the software testing.

1. Developer: A developer as the name suggests is responsible for taking care of all the development activities like:

(a)  Preparation of the test plan before the coding of the software system or application starts.

(b) Creation of the input test data as per the various software testing methodologies are to be used.

(c)  Preparation of the documentation of the expected outcomes of the different test cases.

(d) Testing the source code according to their personally developed schemas.

(e)  Documentation of the actual test results.

(f)  Validation of the code whose actual output is same as the expected outcome.

(g)  Filling up the project documentation repository with the results of the unit testing and the test data used as input.

(h)   Active participation in the process of the code reviews to ensure that the unit testing is complete.

2. Data architect or Data Modeler: Data architect is responsible for taking care of the management of all the issues regarding the architecture and build of the software system or application:

(a)  Testing of the scripts written in data definition language (DDL) as per their personally developed schema.

(b) Filling up the project documentation repository with the tested and validate DDL scripts.

3. Senior Developer or System Tester: A team consists of more than one senior developers or system testers and they are responsible for taking care of the actual software testing of the software system or application. They share some responsibilities with the developers:

a)  Active participation in the process of the code reviews like the developers for determining that the unit testing has been completed successfully.

b)  Preparation of the test plan

c)  Creation of the test data for input to input to test cases.

d)  Preparation of the documentation of the expected outcomes of the different test cases.

e)  Implementing the code in the testing environment

f)   Execution of the work streams that are comprised of the system tests along with their scripts.

g) Validation of the actual results of the tests.

h) Creation of the defects if required for some kinds of testing techniques like fault injection techniques, in defect management tracking tools etc.

(i)  Filling up the project documentation repository with the results of the system testing and the test data used as input.

4. Data base Administrator: They share the responsibilities of the following tasks:

a) Creation of the system, quality assurance, release testing, user acceptance and integration environments.

b) Execution of the scripts written in DDL or data definition language and DML or data manipulation language in the environments as specified in the test plan.

c) Preparation of the restores and back ups.

5. Integration Tester or Senior ETL Designer: They are responsible for:

(a)    Participation in the system test reviews for ensuring the completeness of the system.

(b)   Preparation of the integration test plan.

(c)    Creation of the integration test data.

(d)   Documentation of the expected outcomes of the integration test results.

(e)    Implementing code in the integration testing environment.

(f)    Validation of the actual integration test results.

6. Quality assurance people
7. QA software tester
8. User acceptance tester
9. Release manager
10. Production support specialists

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 is the entry and exit criterion for production verification testing?

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

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

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

About Production Verification Testing

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

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

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

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

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

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

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

Entry Criteria for Production Verification Testing

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

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

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

- The documentation of the known defects is ready.

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

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

Exit Criteria for Production Verification Testing

- The processing of the migration package is complete.

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

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

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

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

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

What is the entry and exit criterion for integration testing?

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

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

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

About Integration Testing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Entry criteria for Integration testing

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

Exit criteria for Integration testing

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

What is the entry and exit criterion for regression testing?

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

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

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

About Regression Testing

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

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

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

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

How to conduct regression testing?

There are many options for conducting regression testing.

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

Importance of Regression Testing

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

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

Entry and Exit criterion for Regression testing

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

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

What 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.