Subscribe by Email


Wednesday, February 29, 2012

What are different compatibility and intersystem defects?

WHAT IS MEANT BY SOFTWARE COMPATIBILITY?

- Software compatibility is usually described as the compatibility of a software system or application to run without any problems on any major platform.
- It means that the software system or application is compatible with the major platforms and CPU architectures such as Intel or mercury etc.
- It also refers to the compatibility of a software system with different operating systems.
- It is very difficult to develop software that is compatible with many CPU architectures since during the compilation of such a system it shows different errors for the different CPU architectures.
- But such compatible application software do exist.
- The applications are developed and compiled for the various CPU architectures and these are then made compatible to with the various different CPU architectures via the operating systems.

WHAT IS INTERPRETED SOFTWARE?
- In contrast to the compiled software, the interpreted software does not show the above drawback.
- They are very well capable of running on multiple CPU architectures.
- But here one condition has to be fulfilled i.e., the interpreter should be available for that particular type of the CPU architecture.

Software incompatibility is more frequent among the newer software versions developed for the new versions of the operating system which is found to be incompatible with the older version of that software system or application version due to a lack of some features and functionalities.

The newer versions of a software system or application that are able to work with the older versions of the operating systems are said to possess the capability of the backward compatibility.

Compatibility testing is usually carried out to test the operational environment of a software application or program. The software system or application is checked for its suitability i.e., whether or not the application will be able to perform in that environment or not.

DIFFERENT COMPATIBILITY & INTER-SYSTEM DEFECTS
Defects affecting the compatibility of a software system or application are commonly called as compatibility and inter-system defects. These are:

DEFECT #1:
After completing the installation of the application software, the user executes that application and observes that he/she is not able to access some features and functionalities and also not able to view any pictures images, icons or data.

DEFECT #2:
Some browsers may show java script errors with applications developed in java language.

DEFECT #3:
Inconsistency is observed in some elements of a web application or a web site when viewed through different browsers.

DEFECT #4:
The software program is observed to behave differently on different browsers.

DEFECT #5:
Inter-system defects like corruption of data in an NFS mounted file. Usually data is not corrupted in an NFS system.

DEFECT #6:
- In some cases, an unauthorized user is very well able to access the control to a system which uses the LDAP methodology for the authentication purpose.
- This inter-system defect is common in ensemble, UNIX clients and VMS employing LDAP authentication system, windows clients and cache file versions.

DEFECT #7:
- Encryption of data base in VMS clusters.
- In such a defect the system usually becomes inactive and does not respond.
- Like the above mentioned defect, this defect also exists in ensemble versions. - This defect usually occurs when the data base is forced to shut down without the cache being closed.

DEFECT #8:
Failure of cluster mounted data bases.

DEFECT #9:
- Defect making the application server unresponsive.
- This defect is usually encountered when there is too much ECP traffic on the application or web site.
- This defect can affect all platforms.

DEFECT #10:
- Memory defects like core dumps which are generated during the start up of the cache.
- Because of this defect in some cases the start up can fail completely.

DEFECT #11:
Speed reduction in cache making it unresponsive. This defect occurs mainly when the amount of shared memory exceeds a specified limit.


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.


Monday, February 27, 2012

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 is build verification testing technique?

Build verification test is often abbreviated to “BVT”. This test is more commonly known as “build acceptance test”. We can make out from the term itself that this test consists of test cases that are executed on the build of a software product in order to verify that the build of that particular software system or application is testable before the software product is passed on to the testing team for testing.

ABOUT BUILD VERIFICATION TEST
- The main build verification test consists of smaller test cases and these test cases exercise the functionality of the mainstream of the software system or application.
- Any further testing on a build is performed only if it passes the build verification otherwise it is simple rejected.
- In the place of this build, the testing is continued to be carried up on the previous one.
- There should be at least one build that should pass the build verification test.
- Build verification is important to be carried out prior to the commencement of the testing phase.
- It tells the software developers whether the build of the software has been rightly developed or not.
- It also tells if the build is having any major issue.
- A build verification test also avoids time being wasted by carrying out unnecessary testing on the faulty builds.
- A typical build verification test is usually automated.
- When a build is rejected during the build verification test, it is again revered back to the software developer for correcting it.

Build verification test is also called by another name “smoke testing”. In build verification testing two aspects are mainly checked:

1. Build acceptance
2. Build validation


BASIC THINGS TESTER SHOULD KNOW ABOUT BVT

1. A build verification test consists of many smaller sub tests and each one of these tests verifies one functionality of the software system or application.
2. Build verification tests are very effective in saving the efforts of the testing team.
3. The build verification testing methodology can be used to test a build even if its major functionality are not working or are broke.
4. The build verification tests are designed very carefully so as to make them cover a major part of the functionality and features.
5. A certain time limit has been set for the build verification test to 30 minutes.
6. The testing time for running build verification should not exceed this limit.
7. Build verification testing is somewhat similar to the regression testing in the way that it is carried out on each and every build.
8. Build verification test is a way to test the integrity of the software project.
9. It checks whether or not all the modules have been integrated well with each other or not.
10. Maintenance of integrity between the modules is very important since any lag in the cooperation can cause the whole system to go bizarre.
11. Initially, the build verification testing technique was employed to check whether or not all the new features, functionality and modules have been included in the project to be released or not.
12. It also checks for the correctness of the formats of the included files.
13. Even the flags associated with a file are checked.
14. You should be very careful while deciding what all the test cases have to be carried out under the build verification test.
15. Your build verification test must include all the critical test cases and these test cases should not be unstable.
16. Another point to be kept in mind is that you should have an idea of the result of the test cases that you are including in the BVT.


Sunday, February 26, 2012

What are application testing tools?

It requires some tools to carry out application testing and such testing tools are called application testing tools. Application testing tools are divided in the following sub categories:

1.Source test tools
2.Functional test tools
3.Performance test tools
4.Java test tools
5.Embedded test tools
6.Data base test tools

NEED OF APPLICATION TESTING TOOLS
- All the application softwares need to be tested before they are released to the consumers.
- For application testing either specific or particular testing tools can be used or a combination of various types of testing tools can also be used.
- Testing tools are employed to aid the tester in finding the bugs, errors or loop holes in the software system or application.
- Discovering bugs and errors at the early phases of development can avoid potential troubles.
- The bugs and errors should be resolved as soon as possible after discovering them.
- Testing can be made more effective by using proper testing tools.

TYPES OF APPLICATION TESTING TOOLS
Now let us see what all types of tools are available for application testing.

1. Source Test Tools
Tools falling under this category are used for finding bugs and errors in the source code of the application software’s program. Few popular source test tools are:

(a) Ada test: Effective for dynamic testing for applications written in Ada.
(b) AQ time: This tool tests the applications based on the languages like Visual C++, Intel C++, and visual Fortran etc. It comes with many memory usage pro-filers.
(c) CMT++: This tool is used for static testing of the application software having C or C++ as its source code language.
(d) Code Wizard: This tool has been specially designed for analyzing the applications written in C++ language.

2. Functional Test Tools
These type of tools are required to test both the functional as well as non functional requirements of the application:

(a).TEST: It is a typical unit testing tool and is used for testing classes that are based up on the .NET framework.
(b) AETG Web: This tool is very useful when it comes to the generation of the test cases. This tool has proved to be very efficient.
(c) Aberro Test: This is a typical interface testing tool. It can also be used for the verification of the requirements.
(d) Avignon Acceptance testing system
This tool basically makes use of XML language to define the language syntax and is used for writing test cases in the language of your choice.
(e) Automated test designer
This tool creates test cases based on the functional requirements of the application.

3. Performance Test Tools
As the name suggests, these tools are used for testing the performance level of the application softwares:
(a) App loader: This tool is used to carry out functional testing as well as load testing. it simulates the usage of the application. This tool is completely independent of the protocol.
(b) Bug timer: This tool is used basically for the documentation purpose of all the bugs and errors found during the performance testing of the application.
(c) Load runner: It is a load testing tool designed basically for the integrated web applications.

4. Java Test Tools
These tools test applications powered by java.
(a) Abbot: This tool tests java based GUIs.
(b) Agile test: It is used for unit testing in java applications.

5. Embedded Test Tools
These tools are used to test the application software components that are embedded in the code:
(a) Message magic: It is used for testing the subsystems.
(b) Tbrun: It is an automatic testing tool used for C, C++ etc.

6.Data Base Tools
It is used for testing data base of the application softwares:
(a) AETG: It is used to generate test cases.
(b) Data generator: It is used for generating input test data.


Saturday, February 25, 2012

What are low level and high level test cases? List out the differences?

IMPORTANCE OF TEST CASES
- Test cases are such an important part of software testing that they can’t be neglected.
- Test cases form the basis of any software testing methodology.
- After all, the efficiency of the software testing depends on how effective are the test cases developed for that particular type of software testing.
- The test cases are developed keeping in mind all the important aspects of the software testing.
- Aspects like the components of the application, its attributes, its features and functionality, kind of coverage needed, aim of the testing methodology and requirements of the software system or application.
- One test case tests only one feature, functionality or aspect of the software system or application.
- It is necessary that the test case is implemented properly and according to the specifications.
- If the test case is not implemented properly then it makes no sense of testing no matter how effective and efficient is the test case.

LOW LEVEL & HIGH LEVEL TEST CASES
There are basically two types of test cases about whom we shall be discussing in this article. These are namely low level test cases and high level test cases.

DIFFERENCES BETWEEN LOW LEVEL & HIGH LEVEL TEST CASES

DIFFERENCE #1:
- Low level test cases are developed pertaining to the low level bugs in a software system or application.
- On the other hand high level test cases are concerned with the bugs of high levels.
- Wherever a low level bug is suspected in the program code a low level test case is used for testing and wherever a high level bug persists, correspondingly a high level test case is used.

DIFFERENCE #2:
- High level test cases are developed for testing the major functionalities and features in a software system or application rather than just testing high level bugs.
- Major functionality may include display, update data base, retrieval and so on. They can be rather called test cases related to functionality.
- The low level test cases can be appropriately called test cases related to the user interfaces as they are very effective in testing the application’s user interfaces besides low level bugs.

DIFFERENCE #3:
- While carrying out the software testing, the high level test cases based on the requirements test the corresponding functionality.
- Requirements need to be identified properly so that there is no faltering while performing the test. This is called high level testing.
- Similarly testing carried out using low level test cases is called low level testing and is employed to test the software system or application at the micro level i.e., the expected outcome and the actual outcome.

DIFFERENCE #4:
- Low level test cases include the following test cases:
(a) For integration testing
(b) For unit testing
- On the other hand, the high level test cases are further sub divided into the following test cases:
(a) Test cases for system testing
(b) Test cases for functional testing and
(c) Test cases for acceptance testing.

DIFFERENCE #5:
- The high level test cases are able to provide better test coverage.
- They don’t focus much on the features and functionality but only to the extent that they should work properly and well in accordance with each other.
- The low level test cases are focused up on each and every minor detail of the program code.
- The program is tested in depth.
- Therefore we can say that the low level testing involves more detailed work than the high level testing.

DIFFERENCE #6:
- Low level testing and high level testing belong to the category of white box testing and black box testing respectively.


Friday, February 24, 2012

What is meant by error guessing methodology?

Errors and bugs are perhaps the worst enemy of a software system or application and of course cause a lot of nuisance in the programming and give nightmares to the program developers and testers. Till date several methodologies have been developed to cope up with these errors and bugs but, the problem of errors is something which cannot be rooted. It can only be controlled.

Error guessing and error seeding are two such technologies about which we will be discussing in this article.

CHARACTERISTICS OF ERROR GUESSING
- Error guessing is a self explaining term.
- It can be thought of as a software testing methodology or technique that employs test cases to dig out the bugs buried in the software program.

DIFFERENCE BETWEEN ERROR GUESSING & OTHER SOFTWARE TESTING METHODOLOGIES

Then what is the difference between error guessing and other software testing methodologies? Though they may seem similar, there is a considerable difference which lies in the composition of the test cases.

DIFFERENCE #1:
- The test cases used in other types of software testing methodologies are based up on the requirements specifications of the software system or the application. - But, in error guessing, the test cases involved are based up on the past experiences of the testing as well as on the experience of the program that is to undergo testing.

DIFFERENCE #2:
- These test cases are created by the tester who has been involved in the whole programming of the software system or application.
- The tester has a past experience of the older versions of the programs so that he can easily put forth the situations and conditions that can cause the system failure or give rise to errors like null pointers, division by zero or use of parameters that are invalid.
- Error guessing methodology like exploratory testing does not follow any explicit rules or regulations.
- The tester is free to choose the basis to base the test cases on whether be it on functional or non functional requirements, experience, and situation and so on.

ASPECTS USED BY TESTERS IN USING ERROR GUESSING
Testers who have an experience of using error guessing make use of the below mentioned aspects:

1. Knowledge about the methods and techniques used in the AUT like implementation technology and designing method etc.
2. Past experience of software testing in different phases. Such experience is required during the phase of the regression testing.
3. Past experience of testing similar software system or applications and a knowledge of the factors that caused defects in them.
4. Knowledge of typical errors like those mentioned above in the article which are implemented unknowingly in the code.
5. General Thumb rules of heuristics.

ADVANTAGES OF ERROR GUESSING
- Error guessing when implemented properly can gradually increase the efficiency and effectiveness of your software testing life cycle.
- The error guessing skills of a tester gradually improve with the gradual experience of software testing.
- Error guessing is the easiest software technology that a tester can ever use.
- It is just like a guessing game, you guess where all the errors might be hidden.
- This methodology does not require any specially designed tools.
- Error guessing involves seeding out of errors.
- Error guessing methodology can be applied while carrying all other software testing techniques so as to get much better outcomes since the error guessing helps a great deal in improving the quality of the test cases.
- Error guessing is a technique that roots those defects that appear to be an intuition in the AUT.


Thursday, February 23, 2012

What is meant by severity of a bug? What are different types of severity?

We all know what a software bug is! It is a flaw, error or mistake in the software system or application that can cause it to crash or fail. Pretty much simple!
But very few of us are actually aware about the severity of a bug i.e., how much destruction it can cause to a software system or application.

- Bugs are of course results of the mistakes made by the software programmers and developers while coding the software program.
- Sometimes incorrect compilation of the source code by the program can also cause bugs.
- A buggy program is very hard to clean.
- Bugs can have a chain reaction also i.e., one bug giving rise to another and that in turn giving rise to one more bug and so on.
- Each bug has its own level of severity that it causes to the software system or application.
- While some bugs can work out total destruction of the program, there are some bugs that do not even come in to detection.
- Some bugs can cause the program to go out of service.
- In contrast to these harmful bugs, there are other bugs which are useful such as security bugs.

WHAT IS SEVERITY OF A BUG & ITS TYPES

-"Severity can be thought of as a measure of the harm that can be caused by a bug."
- Severity is an indication of how bad or harmful a bug is.
- The higher the severity of a bug, the more priority it seeks.
- Severity of the bugs of software can sometimes be used as a measure of its overall quality.
- Severity plays a major role in deciding the priority of fixing the bug.
- It is important that the severity of the bugs is assigned in a way that is logical and easy to understand.

There are several criteria depending on which the severity of a bug is measured. Below mentioned is one of the most commonly used ranking scheme for measuring severity of bugs:

1.Severity 1 Bugs
bugs coming under this category cease the meaningful operations that are being operated by a software program or application.

2.Severity 2 Bugs
Bugs coming under this category cause the failure of the software features and functionalities. But, still the application continues to run.

3.Severity 3 Bugs
Bugs coming under this category can cause the software system or application to generate unexpected results and behave abnormally. These bugs are responsible for inconsistency of the software system.

4.Severity 4 Bugs
Bugs coming under these categories basically affect the design of a software system pr application.

COMPONENTS OF SEVERITY
Severity has two main components namely the following:

1. Impact
- It is a measure of the disruption that is caused to the users when they encounter a bug while working.
- There is a certain level to which there is an interference with the user performing a task.
- Even the impact is classified in to various levels.

2. Visibility
- It is the measure of the probability of encountering the bug in future or we can say that it is measure of the closeness of a bug to the execution path.
- It is the frequency of the occurrence of a bug.

The severity is calculated as the product of both the impact as well as visibility. A measure of perceived quality and usefulness of the software product is given by the severity. Therefore it would not be wrong to say that the severity provides an overall measure of the quality of the software system or application.


Wednesday, February 22, 2012

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

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

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

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

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

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

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

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

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

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

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

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

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

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


What is meant by defect leakage?

Defects can be defined as any discrepancies that can disrupt the functioning of a software system or application and often they are known to give nightmares and headaches to the software testers.

WHAT ARE DEFECTS?
- Defects are responsible for the production of incorrect or unexpected results and abnormal behavior of the software program.
- Defects are a consequence of the mistakes made by the software developers.

It is very difficult to set straight a buggy program. There are so many concepts that revolve around these defects. One of such concepts is defect leakage and we will be discussing it here in this article.

DEFECT LEAKAGE
- You can imagine water leaking out of a container having holes in it. We can take the defect leakage in the same context and define it.
- The defect leakage can be thought of as a phenomenon in which the defects leak out in the entire software system or application.
- It is due to the presence of the means for the escape of the defects.
- No present software testing methodology is so efficient that it can discover or dig out all the errors and bugs.
- Even after many times of rigorous testing still many bugs remain in the software system or application hidden and undiscovered.
- These defects are discovered later during the latter stages of the software development life cycle.
- Such defects are said constitute the defect leakage factor.
- Tracking the defect leakage is very time consuming process as well as effort consuming process.

APPROACHES FOR FINDING DEFECT LEAKAGE

APPROACH #1:
- The commonly followed approach for finding the defect leakage is the matrix method.
- The defect leakage can be tracked down using a standard matrix provided you can spare much of your time for following this approach.
- You will require to analyze all the defects and determine where actually the defect would have been discovered when those stages were in progress.
- Defect leakage indicates a lot about your programming efficiency and testing skills.
- If a lot of gap exists in your findings then it indicates that your testing and programming efficiency is quite low.
- In some cases it happens that you find defect leakage in the unit level which you could have discovered then and there itself and if not there at least that could have been caught at the level of the integration testing.
- The gap here that we are talking about is nothing but the difference between the actual defect logging time and ideal defect logging time.
- Defect leakages add to greater headaches than the usual defects so try avoiding them as far as possible by following a proper testing strategy and an effective test plan.
- All you need to do is to keep all your processes systematic and organized.
- If you are having a lack of time and need a fast completion of your testing work, then there is a greater probability that you may leave many bugs and errors here and there and later have problems with the defect leakages.

APPROACH #2:
- Another approach that you can follow is using a defect tracking automated system.
- This system files up a detection phase whenever a bug is logged.
- This bug is then rectified in the injection phase.
- Following this approach you can easily define the bug slippage also.
- You can also define the areas in which improvement is needed.
- This approach requires appropriate categorization of the defect injection phase.
- The categorization depends on the perception of the tester.
- A leaked defect is the one that could not be discovered during the usual testing but showed up during the production of the software.
- The documentation for the defect leakage is not produced by the quality assurance people.
- The reason why a defect was missed during the testing is often probed by the program managers.


Tuesday, February 21, 2012

Explain the differences between SDLC and STLC?

SDLC (software development life cycle) and STLC (software testing life cycle) are two one of the most important cycles in the development of any software system or application. There is much confusion about these two topics and often characteristics of one are mistaken for the other. This article seeks to make the differences between the two confusing concepts clear.

DIFFERENCES BETWEEN SDLC AND STLC

DIFFERENCE #1:
- The systems development life cycle is one of the major concepts in the field of information systems, software and systems engineering, that one needs to understand really well.
- It can be thought of as a process following which the creation or alteration of the information systems, methodologies and other methods takes place.
- It is a cycle that is followed to keep the development of a software system or application on track.
- On the other hand, software testing life cycle is an integral part of the software development life cycle and takes care of the software testing activities.

DIFFERENCE #2:
- All these development and testing processes are not just one single activity.
- They comprise of many constituent activities that are employed for multiple tasks.
- The software development life cycle is comprised many types of different methodologies for software development.
- Usually these software development methodologies together constitute the framework for the software system or application through which the entire development process can be planned and controlled.
- In contrast to the software development life cycle, software testing life cycle is comprised of the activities for testing and certifying the final software product.

DIFFERENCE #3:
- The software development life cycle constitutes the following processes:
(a) Analysis
(b) Design
(c) Implementation
(d) Testing and
(e) Evaluation
- The software testing life cycle constitutes the following processes:
(a) Requirement analysis
(b) Test analysis
(c) Test case development
(d) Environment set up
(e) Test execution
(f) Test cycle closure
Each of the above mentioned processes under software testing life cycle is provided with an entry criteria as well as exit criteria.

DIFFERENCE #4:
- The control of the software development life cycle is taken by the system analyst and is employed for the creation of an information system.
- This cycle also involves other activities like training, validation and stake holder ownership.
- The SDLC takes care of the quality of the software system under development and ensures that it is always maintained at a high level and also that all the user expectations are satisfied.
- It also makes sure that the project is completed with a stipulated period of time as well as budget.
- Similarly the STLC takes care of the successful completion of the software testing.

DIFFERENCE #5:
- The phase of requirements gathering in software development life cycle can be compared with the requirement analysis in the software testing life cycle.

DIFFERENCE #6:
Various methodologies have been designed to implement software development life cycle like:
(a) Spiral
(b) Water fall
(c) Agile software development
(d) Synchronize and stabilize
(e) Rapid prototyping
(f) Incremental etc.
The software testing life cycle is implemented only in two ways i.e., either manually or through automation.

DIFFERENCE #7:
- The software development life cycle is managed by the system and on the other hand, the software testing life cycle is managed by the project manager.
- He/ she is the one who decides the time period for the completion of testing and allots the budget.
- The following aspects are also identified:
(a) Scope of testing
(b) Approach to be followed
(c) Associated risks
(d) Resources
(e) Time schedule

These were some of the basic differences between the SDLC and STLC. Though having many different aspects, these two cycles have many things in common.


What is meant by application testing cycle?

An application testing cycle states what all the activities are to be carried out in the testing. Although different organizations might be following different procedures or test plans for testing the software applications, they all follow the same application testing cycle. They draft their plans based on a common testing cycle. This is basically done to maintain the standards of testing.

APPLICATION TESTING CYCLE
The application testing cycle that we are going to discuss here is a typical test cycle for the organizations that base their application’s development on water fall model.

1. Analysis of Requirements
- Since this is the first phase in the development cycle of an application, the testing should begin from here itself.
- After the identification of the requirements of the application, the testers and developers together determine what all the requirements should be tested.

2. Drawing up the Test Plan
- The whole testing is planned and it includes the test plan, the test strategy and test environment creation.
- Testing is a very complex process.
- Therefore a plan is needed so that there is no messing around.
- The test plans are usually of a high level.

3. Development of Test
- A procedure for carrying out the test is designed.
- Other things like test cases, test scenarios, test scripts and test input data are also made ready.
- This phase also includes the verification of the test cases.
- The automated test cases are scripted.
- This phase is commonly called as the construction and the verification phase.

4. Execution of the Test
- The test cases are executed by the tester as per the test plan and any error or bug found is reported and documented at the same time.

5. Reporting of Test
- A final report on the carried out test is prepared which contains all the observations made and also the testing details.
- This report is submitted to the development team.

6. Analysis of the Test Results
- The results of the test are then analyzed by the whole development team in the presence of the client.
- The client and the development team together decide which issues are to be resolved and which are to be rejected.
- Risks to the application are identified and a risk assessment is prepared.
- Features and functionalities of the application software are validated.

7. Retesting of the Defects
- After resolving all the issues stated by the client, they are once again reviewed by the development if in case they have caused some other bug.
- This is commonly called as resolution testing.

8. Regression Testing/Final Testing
- This is the last but one phase of the application testing cycle and very important.
- This testing is done after making all the major as well as minor fixes in the application in order to ensure that the application is still working properly.
- If any changes are made to the application, at the same time the documentation is also updated.
- The verification of the application is done under the production conditions.
- Metrics of the test efforts are also prepared in this phase.

9. Closure of the Test
- As we know that for every test exit criteria is defined.
- When the test meets these criteria the testing is declared close and all the reports and documentations are archived.
- These archived reports are used for future reference.
- A line of attack is identified and used to prevent such similar bugs and errors in the future applications.
- The whole testing process is evaluated and ways are sort to make it better.
- The test environment is cleaned up and the restoring of all the testing machines and tools to the baseline is also done.


Monday, February 20, 2012

What are Application Testing Methodologies?

First of all, lets be clear with what is application testing actually.
- It is simply the testing of application software. But, it is not so easy to carry out as it sounds like.
- To develop good application software, great efforts and skills are required both of development and testing.
- Testing is needed to check the quality status of application software.
- This is indeed very important for quality assurance and to see that if the application software is meeting the expectations of the consumers or not.

WHY IS TESTING METHODOLOGY IMPORTANT?
- It is obvious that all the aspects of application software cannot be discovered by following just one testing methodology.
- One has to employ many testing methodologies in order to discover most of the hidden bugs and errors.
- Many methodologies have been developed for testing application software.
- Discovery of flaws is the primary aim of any software testing methodology.
- Criticism is yet another aim.

APPLICATION TESTING METHODOLOGIES

1.BOX TESTING TECHNIQUES
- White Box Testing
It includes techniques that are used to test the program or algorithmic structures and working of that particular software application in opposition to its functionalitY or the results of its black box tests.
a) API testing
b) Fault injection
c) Code coverage: Code coverage can be defined as a measure to measure the extent to which the source code of a software system has been tested.
d) Mutation testing
e) Static testing

- Black Box Testing
a) Equivalence partitioning
b) Boundary value analysis
c) Pair wise testing
d) Fuzz testing
e) Exploratory testing
f) Model based testing
g) Specification based testing

- Grey Box Testing
As the grey colour is made from the combination black and white colours, so does grey box testing is made from a combination of both white box testing as well as black box testing.
- Visual Testing
As the name suggests, non destructive testing techniques do not involve vigorous checking of the software structure.
- Unit Testing
- Integration Testing
The units or modules are combined and tested.
- System Testing
- System Integration Testing

- Regression Testing
It basically discovers and unhide the hidden and new errors and flaws.

- Acceptance Testing
There should be some kind of testing that looks in to the contract and verifies whether or not all the requirements have been met. Acceptance testing serves the purpose right. Acceptance is a composition of 3 kinds of tests namely Physical tests, Chemical tests and Performance tests.

- Alpha Testing
The purpose of checking the application software before the release is served by alpha testing on the basis of:
a) Service level agreement or SLA as it is abbreviated.
b)Requirements
c)Specifications
d)Defect rate efficiency (known as DRE in short form).

- Beta Testing
Beta testing is carried out after the successful completion of the alpha testing.
- Performance Testing

- Usability Testing
Usability testing can be defined as a technique which is used in interaction design. This designing is centred around the user and accounts for the evaluation of the software system, application or product by testing it out on the software product users.

- Security Testing
Security testing as its name suggests can be defined as a process to determine that whether or not a software or information system or application is capable of protecting data and keeping it secure.

- Internationalization
Internationalization can be defined as a process of coding and designing a product. This coding is done in such a way that it can perform well almost on any platform after modification for use in different regional standards and languages.
- Localization


Sunday, February 19, 2012

What is application testing? What are the different categories of the applications?

Application testing as the term itself suggests is all about the testing of a software application. Application testing is carried out on the basis of the scenarios developed by the analysis team.

ABOUT APPLICATION TESTING
- Application testing usually checks out all the aspects of a software application but, mainly focuses upon the features, functionalities and limitations of the software application.
- The software application needs to pass al the tests listed in the scenarios to be ready for the release.
- This is needed because the scenarios form a part of requirements documentation and are considered to means for measuring success.

DIFFERENCE BETWEEN APPLICATION & OTHER TYPES OF TESTING
- Application testing is a bit different from the other types of testings.
- Application testing is controlled with the help of the scripts whose basic purpose is to keep the software system running according to some parameters and checks the outcomes.
- On the other hand other types of testing are usually programmed like unit testing and internal testing.
- In the past years, the scripts used to run the application were prepared manually i.e., they were hand written.
- But today many methodologies have been developed to automate the application testing.

PROBLEM FACED BY APPLICATION TESTING
- Most of the applications today make use of the graphical user interface (GUI), which though being a smart way to establish a relation between the user and computer; poses a problem for the application testing.
- These GUI systems comprise of event loops which involve mouse and keyboard signals etc.
- These signals have screen coordinates associated with them.
- These screen coordinates help in relating the event to the concerned object.
- In some rare cases the object is located at some different coordinates.
- This leads to the change of the coordinates in the loop of the events.

DIFFERENT CATEGORIES OF APPLICATIONS
- A computer performs a particular task ordered by the user by means of the software applications.
- Different applications have different purposes.
- Therefore based on the purpose they are classified into the following criteria: (a) General purpose software applications: As the name suggests these software applications are used for a more general purpose i.e., purposes that are required to be fulfilled by almost everyone. This category includes application softwares like web browsers, word processors, spreadsheets etc.

(b) Specific purpose software applications:
These application software is used to carry out more specific tasks like trunk scheduling, accounting, editing photos and so on.

KINDS OF APPLICATION SOFTWARE
There are many kinds of application software available today like:
- Free application software
- Business application software
- Application softwares for children
- Communication application software
- Computer aided manufacturing application software
- Data management application software
- Desktop publishing application software
- Desktop widgets
- Editing application software
- Educational applications software
- Entertainment application software
- Genealogy application software
- Government application software
- Graphics application software
- Industrial application software
- Knowledge representation application software
- Language application software
- Legal application software
- Library and information science application software
- Multimedia application software
- Music application software
- Personal information manager application software
- Computer programming and testing tools
- Religious software applications

ADVANTAGES OF APPLICATIONS
- No software system is complete without applications.
- Applications add features and functionality to a software system.
- Furthermore managing a software system with a number of small particular applications is easier to mange rather than one big complex software program.
- They reduce our burden to a great extent.
- Without the applications we would have to perform all the tasks manually which will require a great deal of our precious time and efforts.


Saturday, February 18, 2012

What are different tips to estimate testing time?

Time is a very important factor when it comes to the success of any matter. Therefore, timing plays a great role in the successful completion of a software project. It would not be wrong to say that the time estimation like other aspects of the software engineering forms an equally important part of the whole software development cycle.

BENEFITS OF KEEPING TIME ESTIMATION

- Keeping time estimation before the start of the software project keeps the whole development cycle on track.
- This doesn’t let your time get wasted.
- Since, there is a time limit; you have to complete the project within that time period.
- Furthermore, if you complete your projects on time, your clients will be impressed and your reputation will build up which in turn will fetch you more projects.
- An experienced software developer might be able to make better time estimations as compared to the one who is fresh in the industry.
- One who has worked up on various different software projects certainly must be having an idea of the time that will be taken up by the testing process.

TIPS FOR ESTIMATING TESTING TIME ARE:
Testing time cannot be estimated blindly. It should be done accurately and it should be realistic.

1. BUFFER TIME
- Your time estimation should involve some buffer time.
- But, keep in mind that it should be realistic.
- The role of the buffer is to help in case you have an unexpected delay in the software testing process.
- This buffer time accounts for the lost time.
- Apart from providing time for coping up with delays, a buffer also helps in providing the maximum coverage for the testing processes.

2. TIME TAKEN BY BUG CYCLE
- Never forget that this time estimation also includes the time that will be taken up by the bug cycle.
- You may estimate some time for a cycle, but remember that the actual cycle can very well require much more time.
- This problem should be avoided.
- As we all know that the testing process depends on the structure and design of the program.
- The more good the structure and design is, less will it take time.
- If the structure of the program itself is not good then more and more time will be required to fix the subsequent problems and this leads to the over run of the time estimation.

3. INCLUDE UNEXPECTED LEAVES
- The estimated testing time should also have a place for the unexpected leaves.
- Some members of the software development may require a leave until the completion of the project.
- This will help to keep your testing time estimation realistic.

4. AVAILABILITY OF RESOURCES
- You should keep in mind the availability of the resources for the time period within which you have to complete your project.
- If in case you get short of any of the resources you can update your testing time estimations accordingly.
- This is another measure to keep your time estimation realistic.

5. COMPARISON BETWEEN OLDER & NEWER VERSION OF SOFTWARE
- You can sometimes compare this software version with its older version for the test outputs.
- This will save your precious time.
- This is termed as parallel testing.
- Based on the testing time estimation of the older version you can decide time estimation for the upcoming version.

6.COUNT YOUR MISTAKE & REVIEW
- It is a universal fact that everybody makes mistakes.
- So, there is possibility that you may make some mistake while estimating the testing time.
- So don’t forget to review it once and make any changes if required.
- Always keep in mind that changing testing time estimations can have a bad effect on your reputation.
- So don’t make changes unless very much required.

7. COUNT YOUR EXPERIENCE
- You can very well employ your past experience to make wise time estimations.

8. EVALUATE YOUR TEAM EFFICIENCY
Know the work efficiency of your team members.


Friday, February 17, 2012

What is the relationship between a developer and a tester? Who is responsible for a good software quality?

Success of a project depends on the development team. The working efficiency of the team depends on its individual members and of course on the quality of the relationships that they are maintaining. By a good relation among the team members we mean the team spirit, comradeship and communication between them. All these qualities give rise to a good team.

In a software development cycle the relationship between a program developer and tester is very crucial. Since the two processes i.e., the development of the software system or application and its testing are inter- dependent on each other.

Successful completion of both these processes is crucial to any software development cycle.

POSITION OF A DEVELOPER?

The software developers fall under the following three categories:
1. Computer programmers
2. Software applications developers and
3. Software systems developers


- Software or a program developer as we know is the one who is concerned with the development of a software system or application.
- He/ she takes care of all the phases of the software development cycle.
- His/ her work includes research, planning development, designing and developing the software system or application.
- Sometimes it may also include the facets of testing the software.
- Program developers are at the center of the whole development process and are involved with management of the software project and its programming.

POSITION OF A TESTER
- He/ she is the person involved with the testing facets of a software system or application.
- Their job is to provide the details about the quality of the software system or application to the stake holders.
- He/ she is responsible for executing the software program with the intention of discovering bugs and errors in it.

RELATIONSHIP BETWEEN DEVELOPER AND TESTER
- The relationship between a tester and a developer should be excellent.
- It is obvious that both the software developers and the software testers work for improving the quality of the software.
- Quality of software includes the design of the software system, actual core implementation, requirements, gap analysis, specifications analysis, development of prototypes, feasibility analysis, documentation, testing, software pre release and post release activities and not to forget the maintenance of the entire software system or application.

But, it is often seen that the relationships between the developers and testers are not so good. This is probably because of the roles of these two.

- Their work often clashes.
- It is obvious that something in the process of development will certainly have bugs.
- It becomes important to decide if this bug is to be left or it is to be fixed. - At this point usually the relationship between the two worsens.
- After all, it is the duty of the testers to identify the bugs in the program.

Matters like these should not hamper the relationship between the developers and the testers as it is crucial for the development.

- Team work and better individual understanding is the best solution for this kind of problem.
- Maintain the quality of software is not just the responsibility of a software tester or developer.
- It is responsibility of the whole development team.
- Therefore every stake holder holds the responsibility for the quality of the software product from the programmer to the customer.

Testers are usually held responsible for the quality sine they are the one who are responsible for finding out the weaknesses of the software and the testers accuse the developers for putting up a bad code. This puts a bad impact on the whole development team since the team spirit is lost.


What is a template for a test plan?

Testing is responsible for checking the quality level of a program and effective testing requires an effective and efficient test plan.

HOW SHOULD A TEST PLAN BE?
- The test plan should be practical so that it can be easily implemented.
- A test plan is prepared keeping in view the test approach which is suitable for a particular kind of software testing.
- The other important things that are kept in mind while drawing out the test plan are functional specs, design specs and requirements.
- The test plan is a way of implementing the test approach.
- It makes use of test cases specifically designed for a kind of particular testing.

DOCUMENTATION OF TEST PLAN
The test plan is also documented and the documentation serves the following purposes:

1. It gives the details about the test approach used to test the software system or application.
2. The different aspects of a software system or application are identified.
3. The procedure to be followed for the testing is specified.
4. The tools to be used in the software testing are also mentioned in the documentation.
5. The resources to be used in the testing of the software product are specified.
6. The scheduling plan for the test plan is listed.
7. Sometimes it may also include the contact information of the people who are involved in the whole testing process.
8. It lists all the risks that may affect the software and also mentions their effect on the software.
9. The contingency plan is also included.
10.The test plan also specifies the bugs and errors and procedures to manage them.
11.The criterion for the development of the software is specified.

The scheduling plan or the test schedule is prepared by the lead tester. It is based up on the project schedule prepared by the product manager. A test plan template is like a sample on which you can build up your own test plan.

BASIC TEST SAMPLE
1. Introduction
The introduction part covers up the description of the documentation, schedules and other related documents.
(a) Description:
- This documentation contains a test plan for the project: “project name” which has been produced by both quality control and quality assurance.
- The test plan enlists and describes the test strategy and also the test approach.
- Quality assurance has been used for validating the quality of this software product prior to its release.
- Apart from software product, there are other resources which are required for successful execution of this software project.
- The “ project name” aims at improving the development strategy, maintenance and deployment by providing the following new features:

(b) Schedule: (schedule coverage and information based on the estimates of the quality assurance.)
(c) Related documents: (related documents attached to the documentation like design specifications list and functional and non functional specifications list.)

2. Resource Requirements:
It describes all the hardware and software components of the software product.
(a) Hardware:(hardware requirements of the project)
(b) Software:(software requirements of the project and tools used in the testing of the software)
(c) Staffing:(list of the names of the people who are involved in the project along with their responsibilities and what all trainings are required.)

3. Aspects to be tested and test approach: (provides the list of the aspects tested).
4. Aspects not to be tested.
5. Test outcomes
6. Risks
7. Exit criteria


Thursday, February 16, 2012

What are different manual testing challenges?

Everything in this world has got some positive sides and some negative sides, some advantages and some disadvantages, and of course challenges! This holds utterly true with the technology too. Manual testing being so unsophisticated faces challenges too.

WHAT IS MEANT BY MANUAL TESTING?

- Manual testing involves a tester who is supposed to carry out the testing processes manually for finding out the errors and bugs.
- The tester here tests a software system or application with a view of an end user.
- All the features and functionalities of the software system or application are exploited to the most possible extent.
- As the tester cannot mentally track the whole testing process, he follows a written test plan.
- This also ensures that no important test case is missed.
- Even today after the invention of many modern testing technologies, most of the software engineering projects rely on manual testing since it involves a rigorous testing procedure.
- Manual testing works a long way in digging out more defects.
- In a typical manual testing a high level testing plan is followed.
- All the resources like software licenses and skilled people and computers are identified.
- The test cases are written in detail along with the procedure to be followed and the expected outcome.
- Different test cases are assigned to different testers who carry out the testing manually.
- A detailed test report is prepared.
- Manual testing demands skills because without skill the tester might falter.

CHALLENGES FACED IN MANUAL TESTING

1. Manual testing cannot be used to test out the whole application. It can only be used for some parts. The test cases are so large in numbers that it becomes impossible to execute all of them manually. If you were to execute all of those test cases, testing will take too much of time. You won’t be able to complete the testing within the stipulated period of time.

2. Always pay attention to the company defined processes. You should be well informed with the purpose these processes serve. Often following the company defined processes leas to incomplete software testing. The company processes often don’t keep up with the tester’s methodologies or test plan.

3. Manual testing requires good skills. The main skills required are of trouble shooting, analyzing and communication.

4. As the tester gets more hold of the software system or application testing, more and more test cases and errors and bugs come in to the scene and it become pretty much difficult to keep on testing the software system or application further. This is where the regression testing comes in to the play.

5. You should be careful while choosing the team members. They all should be skilled. Unskilled testers can further aggravate the problem rather than simplifying it. This also leads to inappropriate testing.

6. Manual testing should be governed by the time constraint. There is no time for executing each and every test case. The tester usually focuses on the completion of the task rather than focusing on the quality of the testing. There are a whole lot of the tasks to be performed like executing, documentation, automation and reviewing the test scenario.

7. The problem of sorting the test cases according to the priority often comes in way while following the manual testing. Defining a criterion for the sorting of the test cases well in accordance to the priority.

8. In manual testing the requirements of the software system or application are often misunderstood.

9. The reuse of test scripts is a difficult task in manual testing.

These challenges require analyzing skills rather than any other kind of skills.


What are different automated testing challenges?

Automated testing though being a modern testing methodology, faces challenges. Test automation is used whenever a large number of test cases are to be executed. A huge number of test cases cannot be executed manually.

AUTOMATED TESTING
- In automated testing, an automation tool or software is employed to handle the execution of the test cases.
- Such software even compares the actual outcome to the expected outcome.
- It efficiently generates the test data and also the preconditions.

MANUAL AND AUTOMATED TESTING
- Test automation process is mainly used to automate a manual testing process which is typically a much formalized one.
- Although manual testing is way more effective than the automated testing, it consumes too much of time and requires a larger effort.
- Though, manual testing is able to discover more errors and bugs, there are certain kinds of bugs that cannot be discovered up by manual testing.
- For automated testing a computer program is written that will take up the whole testing process which otherwise would have required manual work.
- Manual testing sounds like quite a drudgery! Isn’t it?
- Once the automated software is ready, the test cases can be executed quickly and can also be repeated any number of times without much fuss.
- Automated testing proves to be time, efforts and cost effective method for the software projects that are way too lengthy and need more maintenance.

CHALLENGES FACED IN AUTOMATED TESTING
Test automation tools are expensive and therefore they are employed in certain definite combinations with the manual testing. There are few challenges faced in automated testing:

1. COST EFFECTIVE
One of the challenges that automated testing faces is that it becomes cost effective only when used in the long term i.e., for regression testing of a software system or application.

2. Requirements
- The requirements for a software system or application are identified from the user stories.
- User stories are basically a description like of the software product.
- These requirements are sorted according to the priority as follows:

(a) High priority Requirements
These are the most critical requirements of a software system or application and have to be included in to the software before it is released to the public.
(b) Medium priority Requirements
These requirements are not so critical to the software system or application and hence can be worked around later. But, it should be done before the implementation.
(c) Low priority Requirements
These requirements are added just to enhance the overall quality of the software system or application. But, the software can do without these requirements.

After sorting up on the requirements in the order of their priority, the iterations for the release are planned and each iteration release takes about 1-2 months. Meanwhile too much of change occurs in the requirements of the software. Many a times such changes cause the iterations to bump. This is indeed a great challenge that hinders the implementation of the automating processes.

3. Tools
- The traditional tools don’t seem to work for all kinds of automated testing processes.
- For example, the traditional tools cannot be used for the agile automation process since they are capable of solving only the traditional problems.
- This makes it difficult to implement the automation in the early stages of the testing cycle.
- The deployment of the automated testing processes become simpler only after the whole software comes to the verge of completion since by then many issues had been settled.
- So, making a wise selection of tools is crucial for the automation and also poses a big challenge.

4. Effective resource management as the program grows poses another problem.
5. Lack of effective communication among the team members.


Wednesday, February 15, 2012

What are different aspects of bucket testing?

WHAT IS MEANT BY BUCKET TESTING?

1. Bucket testing is often known by many other names like split testing and A/ B testing.
2. Bucket testing is often considered to be a market testing methodology.
3. The bucket testing methodology is used to compare a variety of baseline control samples with the single variables test samples.
4. This is done for improving the responding rates of the whole mechanisms.
5. Bucket testing is a direct mail strategy which is classic in nature.
6. Bucket testing has been employed in the interactive space to make use of features like landing pages, emails and banner ads etc.
7. Improvements can be made by testing the elements such as following:
- Layouts
- Colors
- Images and
- Text
8. One cannot expect the other elements to show the same improvement.
9. By observing the outcomes of the tests one can analyze that which elements are effective at making great improvements.
10.They are easy to identify.
11.The tester has to provide different samples of the test and controls in order to check out that which single variable is responsible for the improvement.
12.In order to make the test more effective, it has to be distributed to a sufficient audience such that any meaningful difference can be pointed out between the features and the controls.
13.Bucket testing is completely different from the multi- variate testing.
14.The multi- variate testing employs the statistical modeling using which many variables can be tested in the samples.

Today there are several companies that make use of this bucket testing like:
- Zynga
- Netflix
- Google
- Microsoft
- BBC
- Amazon. Com and
- eBay
and many other companies are using this bucket testing to make effective marketing decisions and this method is gaining popularity.

It has proven to be a good methodology for maximizing the profits. Other than this, the following companies are also making use of the bucket testing tools:
- Omniture test
- Omniture target
- Google web site optimizer
- Personyze

TYPES OF BUCKET TESTING

With improving technology many types of bucket testing have been developed and are mentioned below:
1. Multi- variate Testing
this testing is a designed experiment and has been developed whenever isolation of effects is required from two or more than two factors is required.

2. Multi- variant Testing
This type of testing is similar to the multi- variate testing.

3. A/ B/ N Testing
This type of bucket testing involves more than two options or cells denoted by ‘N’.

4. A/ B/.. Z Testing
This type of testing is same as the A/ B/ N testing as described above.

5. A/ B/ A Testing
- This type of bucket testing involves only two variables but in repetition.
- One of the options or cells is repeated.

USES AND ADVANTAGES OF BUCKET TESTING

- Bucket testing is being largely used by the web sites which cater to more traffic.
- It is employed for evaluating any feature of a web site usually exposing it to a small part of the total audience.
- Then the effects on the audience are measured.
- Earlier bucket testing was used as the uniform independent sampling of the whole audience.
- This sampling was considered to be enough for producing an audience that can be used to generate a statistical data corresponding to the whole audience.
- Bucket testing holds good for social networking sites also like for example, testing a new feature that will affect only the user and his/ her friends.
- This type of testing involves much of the complex processes.
- In such a case uniform sampling method is not going to work.
- The sample should be constructed as per the structure of the user’s account.
- This is in a way helps in overcoming the challenges of the combination problems.


What are the tips needed by web application against SQL attacks?

SQL injection attacks are one of the top 10 security vulnerabilities for web sites and applications as it has been declared by the open source web security. Being such a great threat, few measures have been designed to curb this SQL injection attack thing.

FACTORS CONTRIBUTING TO SQL INJECTION ATTACKS
SQL injection attacks are so very common these days. It is probably due to two main factors:

- The prevalence of the vulnerabilities related to SQL injection attacks are significant.
- The target of the SQL injection attacks i.e., web site’s or web application’s data base appears very attractive and useful to the attackers since it contains all the critical as well as sensitive data of the site or the application.

SQL INJECTION MEASURES
Here we are going to discuss those SQL injection measures.
- First thing to avoid the SQL injection attacks is to understand how exactly these attacks occur.
- An SQL injection attack occurs whenever a query is created by the dynamic data base of the web site.
- These queries contain nothing but the input entered by the user.
- When you know what actually is making it easy for the attackers to carry out an SQL injection attack on a web site or web application, it seems very easy to avoid the SQL injection attacks.

HOW TO AVOID SQL INJECTION ATTACK
There are 2 ways for avoiding the attacks which have been discussed below:

1. Dynamic queries should not be written. Some alternative for dynamic queries can be used.
2. The input supplied by the end user for malicious SQL statements. Queries containing such statements should be prevented from entering in to the data base as it will affect the code logic used in the query.

The above two ways can be used with any of the available programming languages and also with data bases of any type.

DEFENSE TECHNIQUES TO AVOID SQL ATTACKS
There are some primary defense techniques which you can follow to avoid SQL injection attacks. They have been stated below:

Defense 1:
- Escaping the input supplied by the user.
- Here the query statements are already prepared by the web site or web application developer.
- These queries are very easy to understand and also do not require much efforts like the dynamic queries.
- This method is implemented as follows.
- The developer is first asked to define the code for all the SQL statements.
- The defined code is then passed in to the respective parameter later when required.
- This technique grants the data base the ability to distinguish between the data and the code irrespective of what data the user has entered.

Defense 2:
- The web sites and web applications can make use of pre- designed queries or parametric queries.
- This approach is used when the other two fail.
- But, this is not much strong as the other two approaches.

Defense 3:
- The web sites and web applications can make use of pre- designed procedures.
- They are implemented in a way similar to that of the prepared statements.

In addition to these primary defense techniques, there are some additional defense measures which can be followed as well if you are not satisfied with the security offered by the primary defense techniques:

ADDITIONAL DEFENSE MEASURES

- Provide the least valued privileges.
- The web site or application developer can carry out a white list check for validation of the input queries. This proves to be effective since the non validated parameter which when appended to a query generated by the user, allows the attacker to inject the malicious SQL statements in to the data base of that particular web site or application. This method of injecting SQL statements in to the data base is used quite often by the attackers.


Tuesday, February 14, 2012

What are different aspects of SQL injection attacks?

SQL is the most rated vulnerability of today’s software world. SQL injection is emerging as a popular means for harming the security of the websites.

How exactly an SQL injection attack takes affect?

- In an SQL injection attack, some statements written in SQL language are inputted in a web form.
- This is done to obtain a web site that will carry out operations on the data base.
- Such obtained web sites through SQL injections are often badly designed.
- The attacker uses this badly designed web site to get the access of the data base contents.
- The web site can be used to carry out other operations also as desired by the attacker.
- It is a kind of code injection technique and is often employed for exploiting the security vulnerability in the software of the web site.

An injection attack occurs through two common mistakes which are:

1. Incorrect filtering of the user input for escape characters in string literals which are embedded in the SQL statements. Here becomes a scope for the potential manipulation of SQL statements. The manipulation is done by the end user who is using the data base.

2. The unexpected execution of the input entered by the user that has not been strongly typed. This is referred to as incorrect type handling. The constraints are left unchecked.

What can a SQL injection attack do?

- The SQL commands designed by the attacker are injected in to the data base of the web site or application via a web form through any of the two methods.
- These commands are capable of changing the content of the data base or they can even dump to the attacker’s wish.
- SQL injections attacks can even attack SQL databases rather than only attacking the web sites or web applications.
- SQL injection attacks can be prevented by the use of structured query language which is well designed and defined.
- Such attacks are usually aggressive. SQL injection attack is abbreviated to SQLIA.

According to a research, under normal usage an application experiences 71 attempts per hour in contrast to the 800- 1000 attempts per hour under a direct attack.

SQL injection attack has been declared by open web application security project as one of the top 10 vulnerabilities. It can be divided into 5 sub categories as listed below:

- Classic SQL injection attack
- Interactive SQL injection attack
- Inference SQL injection attack
- Compounded SQL injection attack and
- DBMS specific SQL injection attack

Types of SQL Injection Attack

- Classic SQL injection attack is not feared today since it has become out- dated.
- But, still many web sites and web applications are precautious against it.
- Inference SQL injection attack continues to be a great threat.
- Attackers mostly prefer this method since it is very flexible in deployment and dynamic in nature.
- Compounded SQL injection attack is a new kind of SQLIA.
- It is resultant of combination of SQL injection and web applications such as:

a) DOS attacks + SQL injection
b) DNS hijacking + SQL injection
c) Improper authentication + SQL injection
d) XSS + SQL injection


- A representation of compounded SQL injection attack is provided by the storm worm.
- The DBMS specific SQL injection attack is often considered as supportive.
- There is another kind of SQL injection called blind SQL injection attack which is used to defend a web site or application on verge of being attacked.
- The results of the SQL injection attack are made invisible to the attacker.
- This injection attack is time intensive.

Today several automated tools have also been developed for automation of these attacks. But, that also requires the location of the target information.


Facebook activity