The agile manifesto talks about this cooperation. I have worked with many organizations seeing a connection between the agile manifesto and how they develop their software. But when it comes to testing, the connection is lost, and they stick to having a ‘phase’ between the point when development stops and the delivery of the product to the customer. This phase is the test phase where the QA team does their ‘stuff

let‘s take a closer look at the agile manifesto, which was written in February 2001 by seventeen people that needed an alternative to the document-driven, heavy-weight software development processes that were predominant at that time.

What is agile manifesto

What make process agile are the following values:

Individuals and interactions over processes and tools• Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following Plan

One of the principal misunderstandings of the agile manifesto is the part regarding documentation. Many think that agile processes are all about coding and not documenting anything. The agile manifesto says nothing about not writing documents, and many people in the agile community want to restore the credibility lost to the methodology due to this misunderstanding. It is about finding a balance between what documentation to write, and what not to write. In many companies large amounts of documentation is written, stored in some repository, and then left where it will often remain untouched, unread and (even worse) unmaintained.

Two of the twelve principles behind the agile manifesto are:

• Working software is the primary measure of progress

• Deliver working software frequently, from a couple of weeks to a couple of months,    with a preference to the shorter time scale.

So we should deliver working software within a couple of weeks if we want to be agile. In short, we have to program and test the new features in very short time scales. Having both the development and testing teams work as one is a must and an accepted fact in the agile world.

The Agile Development Method is growing in popularity as it provides solutions that are quicker and simpler

How to test in an agile project?

Now finally the big questions: How can we make testing agile and what is agile testing?

The first thing, from my perspective, is that testing has to become a natural part of an agile project and not just a phase after the developers have stopped coding and before customers receives their software. It’s about reaching the same goal as a team, i.e. to deliver working software within as short a space of time as possible. With this short time scale, we as testers need to change our working methods. We need to step away from the nagging position we have in a waterfall process and become more active in the process of developing the software. Active does not mean that we should be sitting down hammering in code, but we should be involved from the beginning and be giving the developers feedback instantly on how the new feature works, instead of complaining at the end when everything is built.

To make this possible, we need to have frequent integration of new features, for example through nightly builds, where every morning there is new software ready to be tested. The testing should be performed manually as an exploratory test, since this is a rapid way of testing instantly, no extra documentation, no extra work, just the minimum effort required to succeed, namely testing the new features. But how can we possibly do regression testing when we have no test cases?

When I talk to fellow testers who are into classic testing, we soon run into disagreements:

• We need the test cases for regression testing later on when the product has come in to maintenance’s phase, they say.

• Let’s spend time to automate these test cases, so we don’t need to spend time running them manually later on, I reply.

Let me explain how I see things. Assume that we have a software project that is at the beginning of its life cycle. Not too complex, the GUI has started to fall in place, let’s say it is a web application. We need to start to test automatically as soon as possible, which can be easily achieved using a tool that records our clicks and keystrokes. After each nightly run of the automated tests, we then add new test cases the next morning. This means that we get some extra time to add new automated test cases, or do some exploratory testing, since we don’t need to test the existing ones manually.

The profile for an agile tester is not the same as the profile of a classic tester. I see the agile tester as a person with a more technically orientated profile, a person that enjoys developing, debugging and testing. This profile is wanted in agile projects, since it will help the developers to find where the bug is, instead of just pointing out the symptom of the bug.

In summary, in agile testing you need to start to execute tests fast. Having working software early is a key aspect, and this means you have to have testable software early. Exploratory testing is ideal for you to be able to make a fast evaluation of the software with a minimum of preparation, and experience has shown that it is also very effective for finding problems in the software. Critical parts of the software should never fail, and you need to make sure that they are not broken in the fast development cycle. Because of this, it is worth putting effort into implementing automated regression tests.

Database systems play an important role in nearly every modern organization. The ultimate objective of database analysis, design, and implementation is to establish an electronic data store corresponding to a user’s conceptual world.

Functionality of the database is a very critical aspect of application’s quality; problems with the database could lead to data loss or security violation, and may put a company at legal risk depending on the type of data being stored. Applications consist of a database and improving quality of data in an organization is often a daunting task. A database should be evaluated throughout the database development lifecycle to prepare a quality database application. Data in a database may be input from and displayed on a number of different types of Systems. Each of these types of systems has unique system limitations, which may dictate how data should be formatted in your database. A database should be evaluated based on the factors such as data integrity, consistency, normalization, performance, security and very important – the expectations of its end users.

We can attempt to maintain the quality standards in a proactive way and it involves surveying the customer to determine their level of satisfaction with the product so that potential problems can be detected early in the development process. Once the development is over we can ensure that the database conforms to predefined standards and guidelines. It compares the required features or attributes (problem domain) with the results of development (solution domain). When deviations from the problem domain are found, they are resolved and the process is modified as needed.

The database design process is decided by finding the requirements and needs of the end user. Uncertainty about understanding the requirements can be reduced only after significant analysis and discussions with users. Once the user requirements are clear, the process of behavior implementation consists of the design and construction of a solution domain following the problem domain. Because of the difficulties associated with the changing requirements, the database developer must attempt to develop a database model which closely matches the perception of the user, and deliver a design that can be implemented, maintained and modified in a cost-effective way. Diagrammatic representation using entity-relationship diagrams, object models, data flow diagrams, allows the information described in a visual format in a meaningful way.

Database testing is one of the most challenging tasks to be done by software testing team.

A Database Tester, by understanding the referential integrity and database security, and by having a good grasp on the various technologies and data formats used to transfer and retrieving the data from the database, can test database to avoid problems. Testing should be included in various phases of database development lifecycle. The cycle typically consists\of several stages from planning to designing, testing and deployment. In the first phase of database development process, requirements are gathered; checklists can be used as part of the evaluation process for the database specification. After gathering requirement and understanding the need for the database, a preliminary list of the fields of data to be included in the database should be prepared. We should have complete information about what information is required by the client and what type of fields are required to produce that information. Next determine if the logical data model is complete and correct. Confirm the design with the business community in a design review process.

Create a logical Entity Relationship Diagram (ERD) to graphically represent the data store.

Determine if the data model is fully documented (entities, attributes, relationships) Attributes have correct data type, length, NULL status, default values. General discussion of business rules to be enforced by database level constraints should be carried out e.g.

• Not null constraints

• Check constraints

• Unique constraints

• Primary key constraints

• Foreign key constraints

Business rules to be enforced by triggers and procedures should be discussed along with the

Business rules to be enforced by application code. After this the normal forms should be tested with the help of test data. Testing physical database design includes testing table definitions,

constraints, triggers and procedures. Black Box testing techniques like Boundary value analysis can be used. We can test the table definition by testing the column definitions and constraints that have been imposed:

Database constraints can be checked as follows:

1. Primary Key- Write Test Case to insert duplicate value in Primary Key column.

2. Insert record to violate Referential Integrity Constraint.

3. Delete record to violate Referential Integrity Constraint.

4. Insert NULL value in NOT NULL column.

5. Insert values to violate check constraints by inserting values outside input domains.

For relational databases queries are written using SQL. We can test database queries by identifying different situations and data values. SQL conditions can be tested using Decision Condition Coverage:

a. Select statements use conditions in Where Clause and Having Clause for Group By columns.

I. Conditions written using AND logical operator requires (T, T), (T, F), (F, T) outcomes for two operands to be tested.

ii. Conditions written using OR logical operator requires (F, F), (T, F), (F, T) outcomes to be tested.

Testing requires that every condition affecting the result takes all possible outcomes at least once.

b. Testing SQL statements involving NULL values.

I. Requires Testing conditions with each operand in the condition taking NULL value.

ii. For a Group By Clause, NULL values have to be considered.

c. For sub queries, include test cases to return zero and more rows.

d. SQL statements like Update, Insert, and Delete also need to be tested for conditions.

Apart from testing the table definitions and SQL statements a database tester should test the triggers, procedures and functions. These objects can be unit tested by finding various paths of execution in the code and functionality can be tested by executing the code – providing required inputs and checking the output generated.

Let’s see how can we design test cases to test table definition i.e. column definitions and constraints. Refer to ‘Item’ table storing details of items in stock. Details of sales orders placed for various items are stored in another table ‘Sales’. The table definitions are as follows:

Table Definitions

To test the constraints, we can design test cases as follows:

ITEM Table

Test Case ID: TCcheck _itemcodePK

Objective: To evaluate Primary key constraint on Item code in item table.

Description: Insert two records with I001 as Item code.

Expected Result: second record should not be saved in database.

Test Case ID: TCcheck _itemcode1

Objective: To evaluate check constraint on Item code in item table.

Description: Insert a record with I001 as Item code.

Expected Result: record should be saved in database.

Test Case ID: TCcheck _itemcode2

Objective: To evaluate check constraint on Item code in item table.

Description: Insert a record with I555 as Item code.

Expected Result: record should be saved in database.

Test Case ID: TCcheck _itemcode3

Objective: To evaluate check constraint on Item code in item table.

Description: Insert a record with invalid Item code as I000.

Expected Result: error message should be displayed.

Test Case ID: TCcheck _itemcode4

Objective: To evaluate check constraint on Item code in item table.

Description: Insert a record with I556 as Item code.

Expected Result: error message should be displayed.

Test Case ID: TCcheck _Description1

Objective: To evaluate NOT NULL constraint on description column in item table.

Description: Insert a record with no value for description column.

Expected Result: error message should be displayed.

Test Case ID: TCcheck _price

Objective: To evaluate check constraint on price column in item table.

Description: Insert a record with price=-10.

Expected Result: error message should be displayed.

Test Case ID: TCcheck _delete

Objective: To evaluate referential integrity constraint on item code column

in item table.

Description: insert a record in sales table with item code I001. Delete

record from item table where item code=I001.

Expected Result: error message should be displayed.

SALES Table

Test Case ID: TCcheck _itemcode

Objective: To evaluate references constraint on itemcode column in sales table.

Description: Insert a record with item code not existing in item table.

Expected Result: error message should be displayed.

Test Case ID: TCcheck _orderID

Objective: To evaluate check constraint on Order_ID column in salestable.

Description: Insert a record with Order_ID as 1001.

Expected Result: error message should be displayed.

Now consider a requirement for displaying details of all the items for which qty ordered is>10. We can find the required details by writing

SQL query:

Select item_codefrom sales where qty>10

To test this query we can prepare a test sales table having records with qty>10. When executed, this query should return all the matching records. Similarly we can check the query by preparing a table not having any matching records.

Software development is often a balanced exercise in time and quality management. For most companies it is a constant struggle to complete tasks on time and within budget, usually resulting in quality being neglected. When applications are finally released into production, users are often confronted with only basic functionalities or even the complete omission of functionalities due to the lack of development time.

How do you set up or improve your software testing process to reduce the business risk of poor application implementation? Here are a few simple tips to get you ahead in quality, saving you time and money:

1. Start early and be prepared!

The key to a successful software development project is preparation. Projects often start as simple ideas with enthusiastic developers committing hours of effort prior to in-depth investigation, this results in unforeseen problems causing delays and project overrun. Testing should be introduced from the outset, this way you have an objective look at the project feasibility and its risks prior to committing valuable effort. In addition the test or quality department should be involved at an early stage to review requirements and design documentation. Reviewing helps to highlight defects and if conducted early in the process will save money by reducing the cost of expensive repairs or corrections. Defects found in the requirements phase are on average 100 times cheaper to correct than the same defects found in production. Preparing your test execution is paramount to getting your project completed in the shortest possible timescale. Valuable time can be saved during the test execution phase by specifying your test scripts and creating a test scenario before the application under test is delivered.

2. Select a testing method which fits your needs

Iterative development, e.g. V-Model, Agile, Extreme Development… Each Software development process needs its own adapted test process; select the testing method correct for

your application. You and your management team will benefit from a process that not only reveals the business/project risks but provides the comfort of knowing that the testing team has mitigated these risks. Pay attention to your project specific characteristics, there is no such thing as a ‘universal test approach’. Processes that work for one company or project may be totally inappropriate for another.

• Do you need to react quickly and make lots of changes?

• Is the goal of the project to add functionality to an existing application?

Many different aspects of your development process can influence the correct choice of the testing approach. No matter which direction you choose, ensure that your test process is structured and started at an early stage.

3. Be objective

The test team should have an autonomous role within the organization as it is often difficult to work within the project itself. Some project managers tend to neglect the test teams advise when their project deadline is at stake and quality is no longer important. When there is a delay in a development, many project leaders also have a tendency to use the time allocated for test execution to perform further development activities, hence testing is usually skipped and not just postponed. This can have serious consequences for the overall quality of the project which often ends-up in rework when the application is placed in production. The additional work results in delays and further cost to the overall project. When your organization is large enough (i.e. multiple IT projects per year) you can even consider setting up a test factory, a separate department conducting independent and uniform testing of all your existing applications and new projects.

4. Review, review, review, review …

Testing should start early in the development process, you cannot afford to wait for code to start testing your application. Make sure you start reviewing your documents right from the outset; as well reviewed documents tend to result in 65% less defects being carried forward into later phases of the development cycle. This can amount to huge saving of time and money. Don’t ‘just send’ your documents asking colleagues to review them without explanation or preparation, instead give individuals specific assignment on the documents that you want them to review.

Have someone check the technical aspects, another, the documents on a higher level and yet another against the layout standards used within the company. This way you can avoid holding review meetings where only grammar mistakes have been highlighted. Reviewing is an exhausting task, so only reviews for short periods, one hour maximum, at a review rate of 10 pages for the period, make sure you are not disturbed. Avoid doing reviews in a crowded or noisy office environment, close your e-mail…. Make sure you become an expert in your reviewing methods. It takes time to learn ‘how’ to review and code in a professional and organized way.

5. Prioritize

It is generally accepted that testing everything is impossible. In a normal application or system, there are far too many functionalities and to many possibilities to test every single one of them. An application can take several man years to test so it is important to test those aspects of your application where the risk of damage or frequency of use is expected to be the highest. A thorough risk assessment should be performed before setting up the test strategy. Select test techniques according to the risks you want to reduce. Build a strategy based on the risks that are involved in the project. Remember: No Risk, No Test.

6. Measure!

Two important questions which should be posed.

• What do you know about your testing process?

• What do you want to know about your testing process?

Most of the time, it’s easy to establish the cost to solve a defect in your application (at different stages), but what is the cost and how efficient is your team in finding these defects? The key to answering these questions is: – start measuring. Gather data to monitor your test process, efficiency and effectiveness of your test department. Utilize metrics which provide the information you need to know about your process, i.e. test scenario density, defect density, number of defects found in the first month of production, etc…

The question is often asked ‘When is the best time to start measuring?’ In our experience, NOW is a good time to establish metrics, the sooner you start collecting data the faster you can start improving.

7. Know when to stop testing.

When can you suspend test execution? As a rule, you should stop ’Bug Hunting’ when the cost of finding an additional defect is no longer in balance with the risk you’re exposed to. Under normal circumstances, you need to set exit criteria to decide in advance when testing should stop, for example, define a criteria that will stop testing when 90% of the available test scripts has been executed with a maximum of 5 open defects. Make sure your project criteria are clearly defined. Discuss your exit criteria at the start of the test project and incorporate them within your test plan, this will avoid discussions at a later date. When no exit criteria are defined, testers tend to continue testing until all defects have been found or solved.

8. Preserve.

The strength of software testing partially lies in the structured preservation of test ware.

On completion of testing, take some time to evaluate and assess your deliverables and preserve them for future use. Test cases should be stored in such a way that they can be reused in later projects- or even during the maintenance phase. You should always have your ‘old’ test cases ready for immediate re-use, this way you can save 30% to 50% in overall test effort.

9. Communicate

In many companies there is an ‘It is not MY responsibility’ attitude. Communication is poor between the end-users, architects, developers, testers and management. Too often this kind of behavior leads to misinterpretation in requirements, unwanted functionalities and unsatisfied end-users. Communication is key to ‘quality’. Listen to the end-users and get involvement of the complete team to obtain the best results. Be diplomatic and have constructive discussions.

Software development is constantly balancing budget, quality and scope.

10. Last but not least: keep it simple!

Often companies become lost in administrative procedures when considering testing. An efficient test process should excel in its simplicity, no mountains of red tape, nor tedious ways of giving your quality team and developers a hard time. Choose an approach that fits your project or company and does the job: assuring quality for your applications.

HAPPY TESTING !!!

Accessibility of deliverable

Make sure that all documents, both procedures and templates, are easily accessible for all testers and other stakeholders. An intranet page is a very effective way to provide a clear, preferably graphical structure, allowing users to easily access and download the documents they need. In one project we depicted the documentation structure as a graphical presentation of a ‘pyramid’, with the overall process at the top, and all related and supporting documents, such as work instructions and templates in the basis. This test framework became a familiar artifact in the quality system and soon everybody recognized and used ‘The Pyramid’ on the intranet as the starting point in their search for a document or template.

The change process

Deployment is the most difficult and time consuming part of the improvement project. You can publish a procedure or template, but that doesn’t mean that it will be immediately used by everyone. Often the problem in improvement projects is not the availability of documentation but the lack of adherence to the described way of working. To achieve a maturity level, at least 80% of the people in the organization should work according the documented process. If existing procedures are not followed, try to solve the root cause first. Only when it’s clear why current processes are not being followed is it worthwhile to change and enforce them.

The throughput time of the change process does not only depend on the amount of changes, but also on the organization, its culture and the running development project(s). It may be wise to look for a suitable pilot project to see if the changes have the intended effects and if the procedures are really feasible in day-today practice. But such a pilot candidate must be available – preferably in one of its early stages – and willing to participate. Also in an ad-hoc culture, where local heroes have a large influence, changes leading to a more structured and disciplined way of working may not be directly embraced. When applying changes, be prepared for resistance. Don’t change more than necessary, take small steps and communicate the changes as often as needed and in any way you can think of. An improvement project is not successful until it has been deployed by people motivated to improve.

Statistics are important information. From the statistics below, you can see that Internet Explorer is the most common browser. However, Firefox has become quite popular as well. Anyhow in future IE will disappear, because Firefox is very quickly eat-up IE market, sooner or later Firefox will be the top browser. Ok let be a side.

Now we will come to testing web application in multiple IE, Every time you install a newer version of Internet Explorer, Windows has a tendency to overwrite previous versions. Because each IE version has its own JavaScript engines. so there is a tool to test multiple IE it is called a s IETester. IETester is a free Web Browser that allows you to have the rendering and JavaScript engines of IE8 beta 1, IE7 IE 6 and IE5.5 on Vista and XP, as well as the installed IE in the same process.

#!/bin/ksh

username=’root’;
password=’xxxxxxxx’;
hostname=’0.0.0.0′;
command=’mysqldump’;
database=’mysql’;
dump_file=’XXXX.sql’;
CURRENT=$(date -d”$CURRENT +$MINUTES minutes”);
GetTableData=( users columns_priv host );

echo show tables | mysql -u $username -p$password -h $hostname $database > /tmp/$CURRENT.txt

#  -e   Allows utilization of the new, much faster INSERT syntax.

if [ -e $dump_file ];
then

# rm – remove files or directories, -r, -R, –recursive remove the contents of directories recursively, -f, –force ignore nonexistent files, never prompt
rm -rf $dump_file
fi

while read TABLENAME
do
echo -n  “Backing up Tables From “  “  $database ” “   $TABLENAME”
for i in  $TABLENAME
do
for tableCheck   in “${GetTableData[@]}”
do
# x is  Deprecated, renamed to –lock-all-tables.
if [ "x$TABLENAME" == "x${tableCheck}" ]
then
backup=1;
break;
fi
done
done

if [ "$backup" = "0" ];
then
echo “                  [ Only Sturcture... ]“;
$command $database  -u $username -p$password -h $hostname $i -d >>$dump_file
else
echo “                  [ DATA and Sturcture .. ]“;
$command $database  -u $username -p$password  -h $hostname $i  >>$dump_file
fi

backup=0
done< /tmp/$CURRENT.txt
echo
echo “++++++++++++++++++++++++++++++++++++++++”
echo  $database “DB Backup Taken Successfully”
echo “++++++++++++++++++++++++++++++++++++++++”
echo
exit;

1. Focus on well documented Functional Requirements

Without well documented Functional Requirements, there is potential for a system to be delivered which does not meet the customer’s expectations. For example, perhaps it does not work as they believe it should – even though the development team believe that they have worked in line with the requirements as documented. This can lead to development rework, which is likely to delay the release, increase costs, and create discord between the customer and the software team.

2. Ensure all Non Functional Requirements are clearly defined early

Many organizations focus solely on the Functional aspect of systems – WHAT it does – rather than the Non-Functional – HOW it does it. Non-Functional elements comprise everything from performance to security to usability.

Without clear, early definition of Non-Functional requirements, it is possible that a system could be delivered which does exactly what the customer wants – but is difficult to use, slow, insecure, unreliable, or is not scalable. Once again, this can lead to development rework – although some non-functional areas are so integral to the design of the product, it can be difficult to correct them without starting the project again.

3. Ensure change control procedures are in place

Without Change Control, system development can find itself in an uncertain and constantly changing state. For example, development may be initially performed against what is believed to be the final version of a requirements document. However, more changes might be made to the requirements whilst development continues, each change without a proper impact assessment.

As there is no procedure for consulting with or informing development of the changes, it may not be the case that the knowledge of the changes is passed on in a timely fashion. Additionally, the impact of some changes might be so large that they cannot be incorporated into the software easily at a late stage. In this case, if the changes are deemed to be vital, major development rework might have to take place. For these reasons, every change should be strictly controlled. Change can be allowed, but should only take place after a full impact assessment to see how it will affect the project timescales and costs.

4. Ensure strict Configuration Management is in place for code, data and documentation

Without Configuration Management, a high quality of testing is impossible. This is because there cannot be high levels of confidence that the right version of the software or documentation is being tested, or that the right version will be released to the customer.

Organizations with poor Configuration Management might test one version of a product, and yet perhaps release a slightly different version – a version which then enters the field UNTESTED. It is viewed as untested, as potentially major faults may have been introduced which change the behavior of parts of the system from that which was intended – or, in some cases, even disabling the entire system.

5. Focus quality approach on product risks, focus on preventing rather than detecting defects

It has been proven many times that the later in the software development lifecycle that a defect is found, the more costly it is to rectify it. For example, correcting a mistake in a requirements document before development begins is a far quicker and cheaper activity than correcting the software after it has been developed against the faulty requirements document.

6. Begin UAT (User Acceptance Testing) test design during requirement definition

If an organization is using the ‘V-model’ of software development correctly, then the test team should be involved with the project from the very beginning – during the requirements definition. Not only can the testers use their expertise and experience to help assess whether or not particular requirements are testable or not, but they can also start to design the relevant tests, which helps to ease the test schedule later.

In this scenario, the User Acceptance Tests should correspond directly to the user requirements. This is because the requirements are the items that the user wishes to see in the system, and the tests represent the way that the system is proved to meet those requirements. It clearly follows that the best time to write the UAT is when the requirements are being constructed.

7. Begin system test design during the system design stage

It is important that the system is designed to be easily testable, if possible. This can only occur if testing expertise is involved in the system design stage. Collaboration between the testers and the system designers can help ensure that the system produced fulfills this aim. During this early involvement, the testers can also start to construct the System Tests, which helps ease the testing schedule. An additional benefit to this approach is the enhanced team collaboration between the system design and testing team.

8. Focus test effort on unit test where it is cheaper

As previously stated, correcting defects earlier in the software development life cycle is far easier, quicker and cheaper than otherwise. Given this axiom, it is surprising that many organizations spend little or no time on unit testing activities – often with the reasoning that “our developers develop, and our testers test”.

However, not only does this approach mean that potential defects reach later stages of testing than they should, it is possible that they may not be found at all – as later stages of testing normally perform different testing activities, in different ways, to those used in unit testing.
9. Plan test approach using risk to define focus of test effort

Test time is often limited, due to reasons like fixed release dates, or late software delivery from the development team. This can often mean that not all tests that were originally planned are carried out.

In this scenario, it is vital that those elements of the system that are considered critical to product success have been tested. Therefore, the approach to testing should always be to focus effort on the ‘highest risk’ areas of the system first. Following this, medium risk and low risk areas of the system can be tested, in turn, as time permits.

This risk-based approach ensures that, when under time pressures, the areas of the system which remain untested (and potentially flawed) are the lowest risk areas possible from those that are left to be tested.
10. Use tools to test for functional and non functional errors very early on when they are cheaper and more effective at removing errors, and throughout the life cycle

If an automated test set is created and maintained, it can be repeatedly utilized from an early stage of the software development life cycle, as a ‘smoke test’. This method has the potential to find a lot of defects quickly at an early stage, saving time in later test phases.

Additionally, sometimes specific tools may indicate flaws in the system design – which should be exposed as early as possible. For example, early performance testing on parts of the system that are available might reveal a poorly-designed module, which would hinder the system beyond the tolerance levels of the user when released.

In this way, the module is easily identified, isolated, and fixed or replaced – an activity that would be much harder if performance testing was only conducted when the system was about to be delivered to the customer.

Notice the term “systems” rather than “programs.” The former, more general term allows flexibility in modeling what we have to test, from a single line of code to a functional module, an application, or a suite of interacting applications and the platforms on which they work. The scope of the effort affects the techniques we choose and the ways in which we use them.

Function testing involves identifying each function and then testing it independently. A function causes the system under test to exercise some behavior, either changing

or maintaining the system’s state. The object is to ensure that each function does what it should, but also that it doesn’t do what it shouldn’t. For each function, we need a reliable oracle—a principle or mechanism that will allow us to recognize a problem.

Function testing is good for identifying the capabilities of a system, but the technique has weaknesses, too. First, unless we choose our models carefully, the number of unction’s in a system could be intractably large. To be effective, we need to make pragmatic choices about the scale of our functional tests. Second, function tests are intended to test each function in isolation, but some of the riskiest areas of any system are in the interactions between functions. Third, some defects may depend upon exercising a function more than once.

Domain testing focuses on clarifying and simplifying the testing effort by classifying things associated with the system. Identifying equivalence classes— groups of things that we deem interchangeable for the purposes of a given test—is the key task in domain testing. Practically anything to do with the system—input and output data, platforms, peripherals, users, functions— can be classified by some criterion. Good domain testing involves selecting items from the identified classes such that we cover the territory (e.g., normal data values vs. exceptional data values, representative platforms vs. unusual platforms, or expert users vs. novice users). If we observe clear divisions between classes in defined ranges, such as elements on a number line, we might test at the boundaries between them, where some theories of error suggest that mistakes are most likely to occur and easiest to detect. Boundary analysis— a subset of domain testing—may reduce the number of tests we believe we need, but some classifications don’t have clear linear boundaries. To do domain testing well, we must develop skill at dividing and conquering the data and at identifying risk.

Stress testing is the process of overfeeding or starving the system, or both. This includes overwhelming the system with input, tasks, or users, or removing resources like memory, disk space, network bandwidth, or connectivity. The system under test can be anything from a single input field to the entire business process. We use stress testing to better understand the capacities and limitations of the system, looking for bottlenecks, constraints, and dependencies. The goal is to fix intolerable weaknesses in the program and prepare for and mitigate the tolerable weaknesses.

Flow testing involves running the system without halting or resetting it. When designing a system, we typically simplify by describing single transactions or events in isolation from each other. Flow testing introduces the system to a more realistic, complex world, where transactions happen in sequence, concurrently, or with interruptions. Good flow testing doesn’t decompose the system as function testing does, or undermine it as stress testing does. Instead flow tests model realistic system operation, ensuring that things are done correctly and in the right order.

With scenario testing, we test to a compelling story about the system and its users. Powerful scenarios motivate interest and empathy. Scenario tests include use cases; user stories; the birth, life, and death of a piece of data within the system; and soap opera tests, which posit highly improbable but possible scenarios. Scenario testing tends to find more business-facing bugs than developer-facing bugs.

In claims testing, we seek what anyone (a requirements author or marketer) or anything (a help file or a shrink-wrapped box) says about the system, and we test that claim’s validity. Requirements documents and specifications are the most obvious sources, but we can also test claims made in emails and conversations, sales and marketing materials, end-user documentation, and tutorials. Some claims might be inaccurate, but if we identify where the claim and the system are inconsistent, the project team can fix one or the other.

User testing tells us to test with real users or real-user models. A user, in Rapid Testing parlance, is anyone who might use the system or have an interest in the test effort. I regularly run an exercise in which Rapid Testers try to identify all of the project’s user roles; we don’t stop until we reach thirty. We tend to focus our modeling on end-users (or their managers or customers), but we might also perform tests to serve the interests of the help desk, training staff, or chief financial officer. We’ll also perform some security testing because black hat hackers are potential users (or abusers) of the system.

Risk-based testing posits the harm that could come to some person if a threat were to expose some vulnerability in the system; we recognize or imagine a risk and perform tests to reveal it. I’ve found three useful ways to generate risk-based test ideas:

ü     Consider something that could go wrong, such as a programming error or an ambiguous requirement.

ü     Contemplate the consequences of something going wrong, such as a phone call to the help desk or a front-page story in the San Jose Mercury News.

ü     Determine what the development organization is prepared to risk (e.g., “A bug fix this late might have undesirable side effects; we’ll risk leaving it in”).

Automatic testing allows us to run a test zillions of times or in a zillion variations. The principal virtues of automatic testing are speed, precision, and repetition. However, test automation is software development, which can be tricky and expensive. We should balance the cost of repetition with the value of the problems it finds. Some tests we run repeatedly; others aren’t even worth running twice.

The boundaries between techniques are sometimes blurry, and our definitions are somewhat open. When the name of a given technique suggests multiple interpretations, Rapid. No single technique can reveal all of the information that we seek about a system, but a variety of techniques will reveal more bugs—and more varieties of bugs.

Testing For Developers

When we testers find yet another “Did you even run this?” bug, it’s easy to believe developers purposely inject bugs just to taunt us. I have worked with a lot of developers over the years, and I’ve found that they generally do try to test their code but simply don’t know how to go about doing so effectively.

As testers gain experience they build up a checklist of common problems, classes of bugs that crop up over and over, and areas that tend to be troublesome. Developers don’t have our experience, so they don’t have anything similar.

If developers don’t know how to test very well, and testers have a simple checklist we use to find the most common bugs, then giving our checklist to developers should help out both sides.

That’s my theory anyway, and this is my checklist. I’m testing it right now with my developers. Test it with yours/yourself and let me know what happens!

• Customize This List: If you get a bug, determine what test (or even better, what general class of tests or testing technique) would have caught the bug, then add it to this list.
• Use Your Tester: Brainstorm tests with your tester. Review your (planned/actual) tests with your feature team. Coordinate your testing with your tester, especially with respect to tests they have already written/are currently writing.
• Focus On Your Customer: Think, “Where would the presence of bugs hurt our customers the most?”, then let your answers drive your testing.
• Test Around Your Change. Consider what it might affect beyond its immediate intended target. Think about related functionality that might have similar issues. If fixing these surrounding problems is not relevant to your change, log bugs for them. To quote a smart person I know, “Don’t just scratch it. What’s the bug bite telling you?”
• Use Code Coverage. Code coverage can tell you what functionality has not yet been tested, but don’t just write a test case to hit the code. Instead, let it help you to determine what classes of testing and test cases that uncovered code indicates you are missing.
• Consider Testability. Hopefully you have considered testability throughout your design and implementation process. If not, think about what someone else will have to do to test your code. What can you do / do you need to do in order to allow proper, authorized verification?

Ways To Find Common Bugs:

• • Reset to default values after testing other values (e.g., pair wise tests, boundary condition tests).
  • Look for hard coded data (e.g., “c:\temp” rather than using system APIs to retrieve the temporary folder), run the application from unusual locations, open documents from and save to unusual locations.
  • Run under different locales and language packs.
  • Run under different accessibility schemes (e.g., large fonts, high contrast).
  • Save/Close/Reopen after any edit.
  • Undo, Redo after any edit.
• Test Boundary Conditions: Determine the boundary conditions and equivalency classes, and then test just below, at, in the middle, and just above each condition. If multiple data types can be used, repeat this for each option (even if your change is to handle a specific type). If multiple data types can be used, repeat this for each option. For numbers, common boundaries include:
  • smallest valid value
  • at, just below, and just above the smallest possible value
  • -1
  • 0
  • 1
  • some
  • many
  • at, just below, and just above the largest possible value
  • largest valid value
  • invalid values
  • different-but-similar data types (e.g., unsigned values where signed values are expected)
  • for objects, remember to test with null and invalid instances
• Other Helpful Techniques:
  • Do a variety of smallish pair wise tests to mix-and-match parameters, boundary conditions, etc. One axis that often brings results is testing both before and after resetting to default values.
  • Repeat the same action over and over and over, both doing exactly the same thing and changing things up.
  • Verify that every last bit of functionality you have implemented discussed in the spec matches what the spec describes should happen. Then look past the spec and think about what is not happening but should.
• “But a user would never do that!”: To quote Jerry Weinberg, When a developer says, “a user would never do that,” I say, “Okay, then it won’t be a problem to any user if you write a little code to catch that circumstance and stop some user from doing it by accident, giving a clear message of what happened and why it can’t be done.” If it doesn’t make sense to do it, no user will ever complain about being stopped.

The ISTQB was officially founded as an International Testing Qualifications Board in Edinburgh in November 2002. The ISTQB is responsible for the “ISTQB Certified Tester”, which is an international qualification scheme and the qualifications in the scheme are based on a syllabus. There is an examination covering the contents of the syllabus. After the examination, each successful participant receives the “ISTQB-Certified-Tester” certificate. There are two level of exam:

ISTQB Foundation Level

• Basics of Software Testing
• Testing in the Software Development Lifecycle
• Test Management
• Static Testing
• Dynamic Testing
• Test Tools

ISTQB Advance Level

The Advance Level is aimed at experienced test professionals. This level shows that the person has detailed knowledge regarding testing and skills to apply this knowledge in practice. The requirements for this level are available through the detailed syllabus.

The prerequisites for applying for the exam are as follows:

• Clearing the Foundation Level exam of ISTQB
• Two years of experience as a software tester

The exam has three sublevels:

• Technical Tester
• Functional Tester
• Test Manager

ISTQB Certification Docs

ISTQB Syllabus for Foundation and Advanced

Syllabus Foundation

Syllabus Advanced

Constitution

Glossary Current

Foundation Level Chapters 1-6

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Sample Question paper and dumps for Foundation Level

Sample Paper 1

Sample Paper 2

Sample Paper 3