All about Testing"

Some interview questions(Part 1)

2010-08-22T02:47:00.000-07:00

1. What is Alpha & Beta Testing?

Alpha: Testing of a release of a software product conducted by Testers.

Beta: Testing of a release of a software product conducted by customers.

These above two are types of Acceptance testing

2. What is Acceptance Testing?

Testing conducted to allow a customer to decide whether to accept a software product. Usually performed to confirm the software meets a set of decided acceptance criterion.

3. What is Black Box Testing?

This is the testing based on an analysis of the requirement of a piece of software without reference to its inside workings.

The purpose is to test how well the components conform to the published requirements for the component.

4. What is Ad Hoc Testing?

This is basically the testing performed beyond the specified set of requirements/test cases/use cases.

A testing period where the tester tries to “shatter/break” the system by randomly trying the application’s functionality. It can include both positive and negative testing.

5. What is Boundary Testing?

The Testing that focus on the boundary/limit conditions of the application being tested.

6. What is Agile Testing?

Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.

7. What is Application Binary Interface (ABI)?

A specification defining the requirements for portability of applications in binary form across different system platforms and environments.

8. What is Application Programming Interface (API)?

A formalized set of software calls and routines that can be referenced by an application in order to access supporting system.

9. What is Automated Software Quality (ASQ)?

The use of software tools, such as automation tools (like QTP, Selenium), to improve the software quality.

10.What is Automated Testing?

The testing using software tools which execute tests without manual involvement. Can be applied in User interface, API’s, performance, etc.

The exercise of software to control the execution of test cases/tests, the setting up of test pre-conditions, the evaluation of actual outcome to the predicted outcome, other test control & test reporting functions.

11. What you will do during the first day of job?

Just prepare this question before interview. Every person is different, think what you will do?

12. What would you like to do five years from now?

Just prepare this question before interview. Think of your priorities in the coming years.

13. What is Basic Block?

A progression of one or more successive, executable statements containing no branches or nodes.

14. What is Accessibility Testing?

To verify that a product is accessible to the people having disabilities (blind, deaf, mentally disabled).

15. What is the difference between a bug and a defect?

Bug: A mistake in a program which cause the program to perform in an unintentional/surprising manner.

Defect: If software misses some attribute/feature or function/functionality from what is there in requirement then it is called as defect.

Difference between Priority and Severity

2009-08-03T06:26:00.000-07:00

Let’s go by the dictionary definitions:
Severity – dangerous, causing fear or anxiety by threatening great harm, a dangerous operation, a grave situation, a grave illness etc
Priority - An item's relative importance, A goal of a person or an organization, Prior or antecedent in time, or preceding something else.

We can see that the two words have completely dissimilar meanings. But still there is a lot of confusion between them?

The priority is the domain of the Client and should be entered by them against each defect showing the importance of the change to them. The severity is the domain of the tester and they should be able of recording this.

The severity to the testers is the impact of the defect on the application and reflects that whether further testing could be done or not. For example, a spelling error would be deemed as a low severity by the tester (Mostly Cosmetic), but if this error occurs in the corporation name or address, this would be classed as high priority (Important) by the business point of view.
An inability to access an infrequently used menu option may be of low priority to the business, but the severity is higher since many of the important scenarios cannot be executed, and are dependent on access to the option. The mistake that we very often make many times is to suppose that the tester is also capable of recording the priority.

It may be possible for the tester to make an educated assessment, testers who have been involved with a particular application for some period of time may be able to do this, but it is necessary to have involvement in the life-cycle of a defect. When a project enters test execution, the spotlight will be on fixing defects of the highest priority.

This means that the application will be released with the minimum amount of priority defects unsolved. Care should be taken by the Project Manager to ensure that severity is not ignored. So a balanced approach is needed, which favors the business priority. At the end of the project the quantity of high severity and high priority defects should have at least been reduced, if not removed.

To summarize:
Priority = Business = Order of Fixing
Severity = Tester = Failure of Application

Requirements and Certification process

2009-07-18T05:46:00.000-07:00

Secure Software Lifecycle Professional (CSSLPCM) - How to Certify

There are four processes an aspirant must successfully complete to become a certified CSSLP:

Examination
Certificaton
Endorsement
Audit

Examination

Sign up for the examination date and location
Submit the examination fee
Declare that you minimum a 4 years of professional experience in the software development life cycle (SDLC) field or three years plus a college degree
Complete the Testing contract, attesting to the actuality of your assertions regarding professional experience, and lawfully committing to the obedience of the (ISC)² Code of Ethics
Successfully satisfy 4 questions regarding illegal account and relevant scene

Certification

To be issued a certificate, an aspirant must:

Overtake the CSSLP examination

Submit a correctly completed and executed Endorsement Form

Successfully enact an audit of their assertions regarding professional experience, if the aspirant is selected for audit

Endorsement

An aspirant that passes the CSSLP Experience Assessment must be authorized by other (ISC)² certified professional in acceptable standing before the credential can be awarded.

The endorser faculty testify that the aspirant's assertions regarding professional experience are truthful to the best of the admirer's knowledge, and that the aspirant in good status within the information security industry.

Audit

Passing aspirants will be arbitrarily selected and audited by (ISC)² Services preceding to issuance of any certificate. Quaternary certifications may result in a nominee being audited more than once.

Maintenance Requirements

Recertification is also required every 3 years, with ongoing requirements to hold your credentials in good status. This is primarily realized finished through continuing professional education [CPE], 90 credits of which are required every 3 years. An extreme of 15 CPEs must be posted during each year of the 3 year certification cycle.

CSSLPs must also pay an year book fixture fee of $100 per year.

What is Certified Secure Software Lifecycle Professional?

2009-07-18T05:43:00.000-07:00

Certified Secure Software Lifecycle Professional (CSSLP) is a new vendor-neutral application security certification governed by the non-profit International Information Systems Security Certification Consortium (commonly recognized as ISC2) intended to validate secure software development knowledge and top practices. As of October 10, 2008, (ISC)² has reported certifying 61,763 information security professionals in 133 countries. A range of organizations have expressed their support for the CSSLP, including Microsoft, Symantec, Cisco, SANS, DSCI (NASSCOM), SRA International, Software Assurance Forum for Excellence in Code (SAFE Code), Xerox, ISSA, BASDA (Business Application Software Developers’ Association), and Frost & Sullivan.

Scope of CSSLP Certification

It's no top Secret that security is not being addressed from a holistic appearance all through the software lifecycle. Whatever 80% of all security breaches are application correlate equating to more 226000000 records state unconcealed and fines movement massive amounts.

The following domains modify up the CSSLP CBK center on the requirement for building security into the SDLC:

Software Concepts - security implications in software development
Software Requirements - capturing security requirements in the requirements gathering phase
Software Design - translating security requirements into application design elements CSSLP Man
Software Implementation/Coding - unit testing for security functionality and backlash to attack, and developing secure code and use alleviation
Software Testing - Desegregated QA testing for security functionality and resiliency to bother.
Acceptance - Security suggestion in the software Acceptance phase
Deployment, Dealing, Repair and Disposal - security issues around steady state transaction and management of software

Why do I need to Certify?

There are no safeguards that the software we all rely on is secure. An ontogeny figure of world organizations and experts consider the enterprise is at odd risk because the applications being accessed on a laptop could be entrance points for possible Hack or Bug. The Gartner Group estimates that over 70% of security vulnerabilities live at the application layer.

Benefits of Certification to the Professional

A broad formation of respected organizations has uttered their backing for the CSSLP and are sending their eligible software staff through the training and examination process

Benefits of Certification to the Enterprise

Because security is often “bolted on " at the end of the SLC as a response to a threat or after an exposure, higher production costs and delays can ensue. Straitlaced education and certification are far less pricey than hiring more employees to sewing problems.

Introduction to White Box Testing process

2009-07-11T07:20:00.000-07:00

Test Plan

The test plan should manifest the test strategy. The primary reason of having a test plan is to prepare the ulterior testing process. It includes test areas enclosed, test technique execution, test case and data selection, test results validation, test cycles, and substance and exit criteria based on coverage metrics.

In common, the test plan should compound both a high-level abstract of which areas are to be tested and what methodologies are to be worn and a systemic statement of test cases, including prerequisites, setup, process, and a statement of what to care for in the test results. The high-level outline is usable for establishment, planning, and news, spell the writer elaborate descriptions are helpful to get the test process go easily.

While not all testers suchlike using test plans, they offer a quantity of benefits:

Test plans offer a handwritten of what is to be done.
Test plans ply a way to gauge growth. This allows testers to shape whether they are on schedule, and also provides a crisp way to report growth to the stakeholders.
A test manager (or alike position) is liable for processing and managing a test plan. The development managers are also component of test plan development, since the schedules in the test plan are closely fastened to that of the development schedules.
Test plans afford project stakeholders to sign off on the knowing testing sweat. This helps assure that the stakeholders agree with and faculty hold to reinforcement the test effort
Test plans support fantabulous proof for testing following releases-they can be used to evolve regression test suites and/or offer management to develop new tests.
Due to time and budget constraints, it is often unattainable to test all components of a software system. A test plan allows the analyst to succinctly trace what the testing priorities are.

Test Automation

Test automation provides automated reinforcement for the process of managing and executing tests, especially for continuation previous tests. All the tests formulated for the system should be collected into a test suite. Whenever the system changes, the suite of tests that correspond to the changes or those that say a set of regression tests can be run again to see if the software behaves as anticipated. Test drivers or suite drivers support executing test suites. Test drivers essentially exploit in setup, execution, statement, and teardown for each of the tests.

In addition to driving test execution, test automation requires any automated mechanisms to create test inputs and authorise test results. The nature of test data generation and test results validation largely depends on the software under test and on the testing intentions of particular tests. In component to test automation exercise, stubs or scaffolding development is also required. Test scaffolding provides whatever of the infrastructure required in dictate to test expeditiously.

White box testing mostly requires any software usage to sustain executing meticulous tests. This software establishes environs around the test, including states and values for data structures, runtime error solution, and acts as stubs for many outside components. Untold of what system is for depends on the software under test. Yet, as a primo preparation, it is desirable to distinguish the test data inputs from the code that delivers them; typically by swing inputs in one or writer break data files.

This simplifies test fixing and allows for reuse of test code. The members of the testing group are liable for test automation and activity software development. Typically, a member of the test a group is dedicated to the development endeavor

Test Environment

Testing requires the existence of a test environment. Establishing and managing a correct test environment is grave to the efficiency and powerfulness of testing. For articulate application programs, the test environment generally consists of a one computer, but for enterprise-level software systems, the test environs is some much difficult, and the software is ordinarily tight joined to the environment.For security testing, it is often necessary for the tester to feature many control over the environment than in many other testing activities. This is because the tester must be fit to examine and maneuver software/environment interactions at a greater level of detail, in hunt of weaknesses that could be misused by a wrongdoer.

The tester must also be competent to control these interactions. The test environment should be isolated, especially if, for lesson, a test technique produces potentially destructive results during test that might invalidate the results of any concurrent test or other action. Testing malware (spiteful software) can also be treacherous without severe isolation.The test manager is trusty for coordinative test environs thought. Depending on the type of environment required, the members of the development, testing, and build management teams are encumbered in test environs preparation.

Test Execution

Test process involves flowing test cases developed for the system and reporting test results. The prototypal measure in test execution is generally to confirm the infrastructure needed for functioning tests in the first place. This stock primarily encompasses the test environment and test automation, including stubs that might be requisite to run several components, polysynthetic data utilized for testing or populating databases that the software needs to run, and separate applications that act together with the software.The issues being wanted are those that present forbid the software under test from being executed or else make it to change for reasons not affiliated to faults in the software itself.

The members of the test squad are accountable for test execution and reportage.

Importance of Risk Analysis in White Box Testing

2009-07-11T07:16:00.000-07:00

Security is ever congener to the information and services being bastioned, the skills and resources of adversaries, and the costs of possibility sureness remedies; security is an lesson in risk management. The object of risk analysis is to resolve precise vulnerabilities and threats that subsist for the software and assess their effect.

White box testing should use a risk-based approach, grounded in both the system's exploit and the attacker's mindset. White box testing should be based on structure and design-level risk analysis. This content region gift plow how to use the results of risk analysis for white box testing, while the Architectural Risk Analysis proportionality region discusses risk analysis in detail. Risk analysis should be the guiding obligate downs all white box testing allied activities.

The pursuing paragraphs shortly innovate how the risk analysis results are utilized in white box testing. The succeeding sections deal the activities in portion. The risk analysis report, in combining with a useable rotting of the application into solon components, processes, data stores, and data communication flows, mapped against the environments crosswise which the software instrument be deployed, allows for a desktop recitation of threats and latent vulnerabilities. The risk analysis report should serve refer

The threats submit in each tier (or components).
The form of vulnerabilities that mightiness exist in apiece component.
The business impact (effect and outlay of failure of software) of risks.
The chance (probability) of the risks state realized.
Existing and advisable countermeasures to mitigate identified risks.

Use the above information from the effort reasoning report to

Grow a test strategy: Thoroughgoing testing is seldom cost-effective and often times not conceivable in finite time. Proposed testing is thus selective, and this action should be supported on risks to the system. The antecedence (or superior) of risks from the risk analysis should be the guiding determine for the focus of testing, just because highly threatened areas should be tested good. The test strategy captures all the decisions, priorities, activities, and direction of testing supported on the significance of failure of software. The succeeding divide discusses test strategy in detail.

For careful research on risk-based test planning:

Conclude test coverage: The higher the issue of unfortunate of certain areas (or components), the higher the test reportage should be in those areas. Risk-based testing allows for justifying the rigor of testing in a part expanse. For example, a special ingredient or functionality may feature steep danger to untrusted inputs, hence warranting unnecessary testing tending.

Develop test cases: While a test strategy targets the coverall test activities supported on risks to the system, a test case can take special concerns or risks based on the threats, vulnerabilities, and assumptions unclothed during the analysis. For monition, tests can be formed to formalize controls (or safeguards) put in abode to mitigate a certain danger.

Efforts to White Box testing

2009-07-11T07:13:00.000-07:00

Many of the artifacts germane to white box testing permit source code, a risk analysis report, security specification/requirements proof, organization certification, and quality assurance consanguine validation.

Plan documentation is requisite to turn program faculty and to produce impressive test cases that confirm program decisions and assumptions.
Architectural and design risk analysis should be the guiding oblige behind all white box testing correlative activities, including test planning, test case creation, test information selection, test technique selection, and test exit criteria selection. If a risk analysis was not realized for the system, this should be the best process performed as construct of white box testing. The pursuing divide discusses risk analysis.
Source code is the most consequential object required to action white box testing. Without access to the code, white box testing cannot be performed, since it is based on testing software lettered how the system is implemented.
Security testers should bed right to quality assurance documentation to understand the quality of the software with tenderness to its willful functionality. Quality assurance documentation should allow a test strategy, test plans, and defect reports. Load and performance tests are essential in apprehension the constraints settled on the system and the behavior of the system under stress.
Security specifications or requirements are a must, to see and pass the security functionality of the software under test.
Any unit pertinent to performance faculty should be open to white box testers.

Way to carry out White box testing

2009-07-11T07:09:00.000-07:00

The picture provides a written drawing of the security testing process. This synoptical impact applies at all levels of testing, from unit testing to systems testing. The use of this

Document does not order subscribing to a particularized testing process or methodology. Readers are urged to fit the activities described here into the process followed within their orderliness.

The plain précis of the white box testing process is as follows:

Fulfill venture reasoning to orient the complete testing operation.
Alter a tryout strategy that defines what testing activities are requisite to win testing goals.
Alter a careful endeavor system that organizes the future testing operation.
Ready the endeavor environment for tryout executing.
Penalize effort cases and communicate results.
Ready a Report.

In improver to the indiscriminate activities described above, the process draw introduces exercise cycles, reporting mechanisms, deliverables, and responsibilities.

What is white box testing?

2009-07-11T07:08:00.000-07:00

The goal of any security testing method is to ensure the hardiness of a system in the grappling of malicious attacks or regularized software failures. White box testing is performed based on the knowledge of how the system is implemented. White box testing includes analyzing assemblage feed, control flowing, information line, coding practices, and omission and error touching within the system, to check the supposed and unmotivated software behavior.

White box testing can be performed to authorize whether code effectuation follows intentional program, to confirm implemented security functionality, and to expose exploitable vulnerabilities. White box testing requires admittance to the source code. Though white box testing can be performed any reading in the life cycle after the code is formed, it is a nice drill to execute white box testing during the unit testing phase. White box testing requires knowledgeable what makes software secure or insecure, how to expect equivalent an offender, and how to use contrary testing tools and techniques.

The first step in white box testing is to apprehend and study source code, so wise what makes software secure is a fundamental duty. Support, to make tests that exploit software, a tester moldiness consider equivalent an offender. Tertiary, to action testing effectively, tester’s requisite to know the different tools and techniques usable for white box testing. The tierce requirements do not line in solitariness, but unitedly.

TestPartner - Product Preview

2009-02-21T06:33:00.001-08:00

Automated, repeatable testing with TestPartner

TestPartner is an automated testing tool that accelerates functional testing and facilitates the delivery of business-critical applications.

With TestPartner, you can more rapidly validate applications before going live, verify that application updates don't introduce regressions or even test nightly builds with automated smoke tests. TestPartner offers a storyboard-based visual approach to testing that lets application users confidently capture test scenarios. VBA scripting is available to enable advanced users to meet even the most demanding test cases. You build test assets earlier in the development life cycle, test more thoroughly and deploy applications with confidence.

TestPartner's broad environment support means that enterprises with heterogeneous environments can be confident about easily validating Microsoft, Java, web, SAP, Oracle and many other distributed technologies with speed and consistency.

Features in TestDirector 7.5

2009-02-21T06:29:00.000-08:00

Web-based Site Administrator

The Site Administrator includes tabs for managing projects, adding users and defining user properties, monitoring connected users, monitoring licenses and monitoring TestDirector server information.

Domain Management

TestDirector projects are now grouped by domain. A domain contains a group of related TestDirector projects, and assists you in organizing and managing a large number of projects.

Enhanced Reports and Graphs

Additional standard report types and graphs have been added, and the user interface is richer in functionality. The new format enables you to customize more features.

Version Control

Version control enables you to keep track of the changes you make to the testing information in your TestDirector project. You can use your version control database for tracking manual, WinRunner and QuickTest Professional tests in the test plan tree and test grid.

Collaboration Module

The Collaboration module, available to existing customers as an optional upgrade, allows you to initiate an online chat session with another TestDirector user. While in a chat session, users can share applications and make changes.

Features in TestDirector 8.0

TestDirector Advanced Reports Add-in

With the new Advanced Reports Add-in, TestDirector users are able to maximize the value of their testing project information by generating customizable status and progress reports. The Advanced Reports Add-in offers the flexibility to create custom report configurations and layouts, unlimited ways to aggregate and compare data and ability to generate cross-project analysis reports.

Automatic Traceability Notification

The new traceability automatically traces changes to the testing process entities such as requirements or tests, and notifies the user via flag or e-mail. For example, when the requirement changes, the associated test is flagged and tester is notified that the test may need to be reviewed to reflect requirement changes.

Basics of QTP

2009-02-21T06:24:00.002-08:00

QTP (QuickTest Professional) lets you create tests and business components by recording operations as you perform them in your application.

Test - A compilation of steps organized into one or more actions, which we can use to verify that our application performs as expected. A test is composed of actions (3 kinds of actions are there in QTP Non-reusable action, Reusable action and External action).

1) First step is Planning Before starting to build a test, you should plan it and prepare the required infrastructure. For example, determine the functionality you want to test, short tests that check specific functions of the application or complete site.Decide how you want to organize your object repositories.

2)Second step in QTP is Creating Tests or Components

We can create a test or component by

a) Either recording a session on your application or Web site.

As we navigate through the application or site, QuickTest graphically displays each step we perform as a row in the Keyword View. The Documentation column of the Keyword View also displays a description of each step in easy-to-understand sentences. A step is something that causes or makes a change in your site or application, such as clicking a link or image, or submitting a data form.

OR b) Build an object repository and use these objects to add steps manually in the Keyword View or Expert View. We can then modify your test or component with special testing options and/or with programming statements.

3)Third step is Inserting checkpoints into your test or component. A checkpoint is a verification point that compares a recent value for a specified property with the expected value for that property. This enables you to identify whether the Web site or application is functioning correctly.

4)Fourth step is

Broaden the scope of your test or component by replacing fixed values with parameters.To check how your application performs the same operations with different data you can parameterize your test or component.When you parameterize your test or component, QuickTest substitutes the fixed values in your test or component with parameters. Each run session that uses a different set of parameterized data is called an iteration.

We can also use output values to extract data from our test or component. An output value is a value retrieved during the run session and entered into the Data Table or saved as a variable or a parameter. We can subsequently use this output value as input data in your test or component.

We can use many functional testing features of QuickTest to improve your test or component and/or add programming statements to achieve more complex testing goals.

5)Fifth step is running the test

After creating test or component, we run it. Run test or component to check the site or application. When we run the test or component, QuickTest connects to your Web site or application and performs each operation in a test or component, checking any text strings, objects, or tables you specified. If we parameterized the test with Data Table parameters, QuickTest repeats the test (or specific actions in your test) for each set of data values we defined.Run the test or component to debug it. We can control the run session to identify and eliminate defects in the test or component. We can use the Step Into, Step Over, And Step Outcommands to run a test or component step by step. We can also set breakpoints to pause the test or component at pre-determined points. We can view the value of variables in the test or component each time it stops at a breakpoint in the Debug Viewer.

6)Sixth step is analyzing the results

After we run test or component, we can view the results. View the results in the Results window.After running the test or component, we can view the results of the run in the Test Results window. We can view a summary of the results as well as a detailed report. Report defects identified during a run session. If Quality Center is installed, we can report the defects fond out to a database. We can instruct QuickTest to automatically report each failed step in the test or component, or we can report them manually from the Test Results window.

Comparison of Agile Testing with other methods

2009-02-21T06:24:00.001-08:00

Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive". Agile methods exist on the "adaptive" side of this continuum.

Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

Agile methods have much in common with the "Rapid Application Development" techniques from the 1980/90s as espoused by James Martin and others

What is Agile Testing?

2009-02-21T06:21:00.000-08:00

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.

Agile methods are a family of development processes, not a single approach to software development. In 2001, 17 prominent figures in the field of agile development (then called "light-weight methodologies") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They created the Agile Manifesto, widely regarded as the canonical definition of agile development, and accompanying agile principles.

Some of the principles behind the Agile Manifesto are:

Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Even late changes in requirements are welcomed
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances

The publishing of the manifesto spawned a movement in the software industry known as agile software development.

In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people — management experts, this time — and wrote an addendum, known as the PM Declaration of Interdependence.

Solid State Group Uses uTest for Software Testing of Social Networking Site

2009-02-21T05:59:00.000-08:00

uTest today announced that Solid State Group, a content management, web applications and services consultancy, is using uTest for a professional social networking website. In addition to the flexibility of uTest's Software-as-a-Service (SaaS) platform and the ability to meet tight deadlines, Solid State sees the global community of testers(uTesters) as a huge draw.

"Sometimes team members are too close to the project to pick up every single error, which is why it helps to have a fresh set of eyes dedicated to finding bugs and delivering a high-quality application," said Felicity Stone, QA Project Manager, Solid State Group. "uTest's unique platform affords us the opportunity to test across a vast number of platforms and environments and access to a global network of testing professionals that makes our job a lot easier. uTest simply provides us the confidence that we are releasing a thoroughly tested product to our customers."

This is the second release cycle for which Solid State Group has deployed uTest's services. Previously, the company was performing all testing in-house until they decided that a third party review would greatly benefit them and their customers. With uTest driving the testing, Solid State Group is able to allow its staff to focus on other areas of application development.

"The business value Solid State obtains from uTest's services is further validation of the strength of our service, and the fact that they are a repeat customer is highly rewarding," said Doron Reuveni, chief executive officer, uTest. "It's wonderful that they are able to utilize our skilled testing community to obtain the superior quality and results they strive to deliver to their customers."

The uTest model represents an evolution in traditional software application testing. By offering virtual on-demand software testing services and a Pay-for-Performance business model, uTest provides its clientele a tremendous resource, with flexibility regarding platform, environment, geographic location and budget. The uTester Community of 9,000+ highly skilled software professionals across nearly 140 countries, delivers unparalleled real-world testing throughout product development lifecycles.

uTest offers two pricing models, On-Demand and Annual Subscription. Both options reflect the unique Pay-for-Performance and Pay-per-Bug model. For more information please visit www.utest.com or contact the sales office at (800) 445-3914. Additionally, to view a demo of uTest's services, please visit http://www.utest.com/solutions_watch_a_demo.htm.

HCL Launches First of Its Kind On-Demand Software Testing Lab

2009-02-21T03:44:00.000-08:00

HCL Technologies Ltd. ("HCL"), India's leading global IT Services Company, today announced the launch of an innovative on-demand software testing lab at Software 2008 that allows Independent Software Vendors (ISVs) to reduce their software testing cycle times and lower their capital expenditure on testing hardware and software.

"Our experience working with more than 100 customers over the last several years has shown us that developing and maintaining in-house testing expertise leads to high capital costs to setup the infrastructure, and high resource costs due to the cyclical demand," says G.H. Rao, Corporate Vice President, R&D Services, and HCL. "To enable our customers to address these challenges, we are making an investment of USD 6 million to setup a first-of-its-kind on-demand software testing lab."

The on-demand software testing lab includes a state-of-the art testing laboratory in India with 300 high-end servers of all popular makes (such as HP, Sun, Dell, IBM) with single/multiple CPUs provisioned with leading software testing tools. Customers can setup, provision, perform and manage testing on the lab -- all from a remote location through a secured communication channel.

The testing lab is complemented by a pool of specialized testing professionals that provides niche testing services such as performance benchmarking and capacity planning, high availability testing, firewall testing and security protocol testing etc. The testing service also includes an in-house developed IP on test automation -- Automation+ -- a testing framework that automates the entire test cycle including test environment setup and configuration, installs related applications and identifies the required automated test suites to be run on the installed software.

The on-demand software testing lab will provide a competitive edge to ISVs by enabling them to improve their products and take them to the market faster. This also helps them address a wider market through certification across various platforms, such as operating systems and browsers, further enhancing the revenue potential.

About HCL Technologies

HCL Technologies is one of India's leading global IT Services companies, providing software-led IT solutions, remote infrastructure management services and BPO. Having made a foray into the global IT landscape in 1999 after its IPO, HCL Technologies focuses on Transformational Outsourcing, working with clients in areas that impact and re-define the core of their business. The company leverages an extensive global offshore infrastructure and its global network of offices in 18 countries to deliver solutions across select verticals including Financial Services, Retail & Consumer, Life Sciences & Healthcare, Hi-Tech & Manufacturing, Telecom and Media & Entertainment (M&E). For the quarter ended 31st March 2008, HCL Technologies, along with its subsidiaries had last twelve months (LTM) revenue of US $ 1.8 billion (Rs. 7083 crores) and employed 49,802 professionals.

About HCL Enterprise

HCL Enterprise is a $4.8 billion (Rs. 19,640 crores) leading Global Technology and IT Enterprise that comprises two companies listed in India - HCL Technologies Ltd. and HCL Info systems Ltd. The 3-decade-old enterprise, founded in 1976, is one of India's original IT garage start-ups. Its range of offerings spans Product Engineering, Custom & Package Applications, BPO, IT Infrastructure Services, IT Hardware, Systems Integration, and distribution of ICT products. The HCL team comprises approximately 55,703 professionals of diverse nationalities, who operate from 18 countries including 360 points of presence in India. HCL has global partnerships with several leading Fortune 1000 firms, including leading IT and Technology firms. For more information, please visit www.hcl.in.

Other product or service names mentioned herein are the trademarks of their respective owners.

For details, contact:
Citigate Cunningham for HCL Technologies
Susan Vander May
415-618-8721
Email Contact

Basics of Silk test

2009-02-15T07:31:00.000-08:00

1) What is SilkTest?

Ans. SilkTest is a software testing automation tool developed by Segue Software, Inc.

2) What is the Segue Testing Methodology?

Ans. Segue testing methodology is a six-phase testing process:

1. Plan - Determine the testing strategy and define specific test requirements.

2. Capture - Classify the GUI objects in your application and build a framework for running your tests.

3. Create - Create automated, reusable tests. Use recording and/ or programming to build test scripts written in Segue's 4Test language.

4. Run - Select specific tests and execute them against the AUT.

5. Report - Analyze test results and generate defect reports.

6. Track - Track defects in the AUT and perform regression testing.

3) What is SilkTest Host?

Ans. SilkTest Host is a SilkTest component that manages and executes test scripts. SilkTest Host usually runs on a separate machine different than the machine where AUT (Application Under Test) is running.

4) What is SilkTest Agent?

Ans. SilkTest Agent is a SilkTest component that receives testing commands from the SilkTest Host and interacts with AUT (Application Under Test) directly. SilkTest Agent usually runs on the same machine where AUT is running.

5) What is 4Test?

Ans. 4Test is a test scripting language used by SilkTest to compose test scripts to perform automated tests. 4Test is an object-oriented fourth-generation language. It consists of 3 sets of functionalities:

1. A robust library of object-oriented classes and methods that specify how a testcase can interact with an application’s GUI objects.

2. A set of statements, operators and data types that you use to introduce structure and logic to a recorded testcase.

3. A library of built-in functions for performing common support tasks.

6) What is the DOM browser extension?

Ans. Document Object Model (DOM) browser extension is a SilkTest add-on component for testing Web applications. DOM browser extension communicates directly with the Web browser to recognize, categorize and manipulate objects on a Web page. It does this by working with the actual HTML code, rather than relying on the visual pattern recognition techniques currently employed by the Virtual Object (VO) extension.

7) What is the VO browser extension?

Ans. Virtual Object (VO) browser extension is a SilkTest add-on component for testing Web applications. VO browser extersion uses sophisticated pattern recognition techniques to identify browser-rendered objects. The VO extension sees Web pages as they appear visually; it does not read or recognize HTML tags in the Web application code. Instead, the VO extension sees the objects in a Web page; for example, links, tables, images and compound controls the way that you do, regardless of the technology behind them.

8) Is there any problem in using scripts created on v6.0 to 6.5 or higher versions?

Ans. Moving from lower to higher version should not be a problem.... This is a general statement and cannot be true at all instances. I faced problems with scripts working in 6.5 not running in 7.0 because some of the recognition patterns used each changed. And in some situations, finally landed two paths of the script to perform same action based on version. PS: Did not encounter any problems from 6.0 to 6.5.

9) What is SilkTest project?

Ans. A SilkTest project is a collection of files that contains required information about a test project.

10) How to create a new SilkTest project?

Ans. 1. Run SilkTest.

2. Select Basic Workflow bar.

3. Click Open Project on the Workflow bar.

4. Select New Project.

5. Double click Create Project icon in the New Project dialog box

6. One the Create Project dialog box, enter your project name, and your project description.

7. Click OK.

8. SilkTest will create a new subdirectory under SilkTest project directory, and save all files related to the new project under that subdirectory.

Jonckers Successfully Deploys Borland(R) SilkTest(R) and Automates Software Testing

2009-02-15T07:16:00.000-08:00

Jonckers Translation &Engineering, Microsoft Service Vendor of the Year 2007, today announced the successful adoption of Borland(R) SilkTest(R) for automated software testing. Borland SilkTest was evaluated over several months in a pilot functional testing project after being chosen from a competitive selection process.

Jorge Estevez, Group Engineering Manager for Jonckers stated, "The adoption of Borland SilkTest offers our clients the ability to quickly and cost-effectively release dependable products to their global markets. Investing in this technology is critical to the long-term success of
Jonckers and the localization industry at large, Borland's product proved to be far ahead of its competition both during the pilot evaluation and in ongoing customer projects."

Wolfgang Karas, Regional MD at Borland Software, said, "Jonckers is a valued partner and a recognized innovator in the localization industry, and Effective software testing is a vital component of their products
Dependability. The challenge for software delivery teams is to balance cost and time to market with dependable quality. It is our understanding that Jonckers selected SilkTest because it helps them effectively address this Challenge -- which in turn leads to greater customer loyalty."

New automated testing processes have now been rolled out across Jonckers' global testing centers in the Czech Republic, Vietnam and China. Estevez noted, "Being able to scale software testing in this way means we can pass on financial benefits to our customers, strengthening our
commitment to provide the most cost effective solutions possible in our market place."

A white paper on the benefits of Automated Testing is available for download at http://www.jonckers.com.

About Jonckers

Jonckers, MS Service Vendor of the Year 2007, is focused on delivering software, eLearning and multimedia localization services to the world's best companies. Jonckers achieves localization excellence through an ERP controlled global network of wholly owned offices spanning Asia, Europe and the US allowing Jonckers to deliver low cost global resources without
sacrificing quality. Please visit http://www.jonckers.com for more information.

Borland, SilkTest and all other Borland brand and product names are service marks, trademarks or registered trademarks of Borland Software Corporation or its subsidiaries in the United States and other countries.

LoadRunner Vuser Technology

2009-02-01T07:32:00.000-08:00

The actions that a Vuser performs during the scenario are described in a Vuser script. When you run a scenario, each Vuser executes a Vuser script. The Vuser scripts include functions that measure and record the performance of the server during the scenario.

To measure the performance of the server, you define transactions. Transactions measure the time that it takes for the server to respond to tasks submitted by Vusers. For instance, you can define a transaction that measures the time it takes for the server to process a request to view the balance of an account and for the information to be displayed at the ATM.

You insert rendezvous points into Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct multiple Vusers to perform tasks at exactly the same time. For example, to emulate peak load on the bank server, you insert a rendezvous point to instruct 100 Vusers to simultaneously deposit cash into their accounts.

You use the LoadRunner Controller to manage and maintain your scenarios. Using the Controller, you control all the Vusers in a scenario from a single workstation.

When you execute a scenario, the LoadRunner Controller distributes each Vuser in the scenario to a host . The host is the machine that executes the Vuser script, enabling the Vuser to emulate the actions of a human user

Vuser Types

LoadRunner has various types of Vusers. Each type is designed to handle different aspects of today's client/server architectures. You can use the Vuser types in any combination in a scenario in order to create a comprehensive client/server test. The following Vuser types are available:

GUI (Windows and UNIX)

RTE (Windows and UNIX)
Database (CtLib, DbLib, Informix, Oracle, and ODBC)
Web
TUXEDO
APPC
Windows Sockets
Baan
Java
DCOM
PeopleSoft

What is Client/Server Load Testing?

2009-02-01T07:18:00.000-08:00

Modern client/server architectures are complex. While they provide an unprecedented degree of power and flexibility, these systems are difficult to test. Whereas single-user testing focuses primarily on functionality and the user interface of a single application, client/server testing focuses on performance and reliability of an entire client/server system.

For example, a typical client/server testing scenario might depict 200 users that login simultaneously to a system on Monday morning: What is the response time of the system? Does the system crash? To be able to answer these questions-- and more--a complete client/server performance testing solution must

Test a system that combines a variety of software applications and hardware platforms
Determine the suitability of a server for any given application
Test the server before the necessary client software has been developed
Emulate an environment where multiple clients interact with a single server application
Test a client/server system under the load of tens, hundreds, or even thousands of potential users

Introduction to Load Runner

2009-02-01T07:16:00.000-08:00

LoadRunner is an industry-leading performance and load testing product by Hewlett-Packard (since it acquired Mercury Interactive in November 2006) for examining system behavior and performance, while generating actual load. LoadRunner can emulate hundreds or thousands of concurrent users to put the application
Through the rigors of real-life user loads, while collecting information from key infrastructure components (Web servers, database servers etc). The results can then be analyzed in detail, to explore the reasons for particular behavior.

LoadRunner is divided up into 3 smaller applications:

The Virtual User Generator allows us to determine what actions we would like our Vusers, or virtual users, to perform within the application. We create scripts that generate a series of actions, such as logging on, navigating through the application, and exiting the program.

The Controller takes the scripts that we have made and runs them through a schedule that we set up. We tell the Controller how many Vusers to activate, when to activate them, and how to group the Vusers and keep track of them.

The Results and Analysis program gives us all the results of the load test in various forms. It allows us to see summaries of data, as well as the details of the load test for pinpointing problems or bottlenecks.

Consider the client-side application for an automated teller machine (ATM). Although each client is connected to a server, in total there may be hundreds of ATMs open to the public. There may be some peak times — such as 10 a.m. Monday, the start of the work week — during which the load is much higher than normal. In order to test such situations, it is not practical to have a testbed of hundreds of ATMs. So, given an ATM simulator and a computer system with LoadRunner, one can simulate a large number of users accessing the server simultaneously. Once activities have been defined, they are repeatable. After debugging a problem in the application, managers can check whether the problem persists by reproducing the same situation, with the same type of user interaction.

India all set to rule software testing market

2009-01-04T03:01:00.000-08:00

India is all set to become a leader in the software testing market with an increasing number of software development companies outsourcing their software testing work here. Industry analyst firm Gartner has pegged the worldwide software testing market at $13 billion and the global market for outsourced testing services to be around $6.1 billion, of which India is expected to corner a 70% share.

Software testing implies checking any IT system prior to implementation for multiple aspects like functionality, reliability, usability, security, compliance and performance. Market players like Hexaware and AppLabs believe that the need for outsourcing software testing has grown due to the high level of complexity and multiple intersection points in modern software.

“The winning combination of cost, communication, exposure to various domains, testing principles and test tools gives a clear edge to India in software testing,” said Hexaware Technologies global delivery head and chief software architect Ramanan RV. While software services are growing at an average of about 10-12% globally, testing is growing at over 50% every year. The market opportunity for Indian offshore testing companies is seen at around $8 billion by year-end, from $2-3 billion a year ago.

“Indian businesses have matured in terms of making IT central to all business processes. Hence, there is a very high level of business dependence on error-free software code,” said AppLabs president and CEO Makarand Teje.

A global case in point is eBay, which experienced a 22-hour outage of its website in 1999 due to software flaws. It cost eBay $5 million in revenue and an 11% drop in share price. The outage affected 1.2 million customers who were either trying to sell or buy something on the website.

Along with the growth witnessed in off shoring of software testing to India, the average deal size of such projects is also on the rise. A few years ago, the average deal size for an outsourced testing project was about $50,000-60,000, requiring a few testers. That has now grown to about $2-4 million per project.

According to Gartner, India will require around 18,000 testing professionals every year over the next three years to fulfill the demand seen in the software testing market.

How to apply for Software Testing Certification exam?

2009-01-04T01:59:00.000-08:00

Many readers don’t know how to apply and prepare for these Testing and QA certifications. I will briefly guide here about the certifications available and the locations where you can give the exams.

Certifications In software testing some history:

In 1980 Quality Assurance Institute (QAI) established an association to represent Quality Assurance professionals. Currently many beginners and advanced level certifications are offered by QAI. Certifications like CSQA (Certified Software Quality Analyst), CSTE (Certified Software Test Engineer), CSPM (Certified Software Project Manager) and Some Advanced level certifications like CMST (Certified Manager of Software Testing), CMSQ (Certified Manager of Software Quality).

Normally people having these certifications are recognized as proficient in Quality Assurance. (As what they believe) But there is definitely a plus when it’s comes to your promotion. Other advantage of having certification what I feel is you will brush up the testing knowledge and methodologies while preparing for exam.

There are some prerequisite you should meet before applying for these software Testing certifications. These depend on the certification you are applying for plus some common prerequisites like:

4 years degree from reputed college + 2 years of IT experience OR
3 years degree + 3 years UT experience OR
2 years degree + 4 years IT experience OR
6 years IT experience OR

AND Should be worked in IT field for the last 18 months.

To apply for the certification fill out the form available at Testing certification application form. Please check which certification you want to pursue and then fill the form accordingly.

Please note that the application fee for any fresh certification is US $350 in which you can also get the exam guide CD. You must mail or fax the above filled application form to the appropriate address provided in the application form with your fees payment.

Note that these certifications exams are conducted in the location of your choice. Your application is first reviewed by QAI board and on approval further notes are sent to the local exam centers approved by QAI. You can check the current year schedule and locations of testing certification here.

For example if you want to give software testing certification exam in India, Pune center (MIT college) you must fill the application form before 15th October 2009 and can give the exam on 15th December 2009. Total 2 retakes are allowed for any certification. If you still not cleared the exam then forget about the testing certifications and even Testing.

More guides on available certifications and filling the form can be found here

Software Testing Models

2008-12-28T02:57:00.000-08:00

One doesn't have to spend much time in the software industry to become familiar with several software development models. Some of the most commonly known include waterfall, iterative, test-first or test-driven development (TFD or TDD), and Extreme Programming (XP). Interestingly, one needs to have a rather diverse set of software development experiences and needs to pay rather close attention to those experiences to realize that there are just as many models for testing software as there are for developing software -- and that the testing model a particular project follows need not be dictated by the software development model.

Categories of testing activities

To aid in this discussion, let's agree to think about software testing in terms of five general categories of activities:

1. Researching information to improve or enhance testing -- This information may come from specifications, use cases, technical design documentation, contracts, industry standards, competing applications, or almost anything else that is likely to improve a tester's ability to test the software deeper, faster or better.

2. Planning and/or designing tests -– This category would encompass such activities as writing test cases, developing test strategies, writing test plans, creating manual test scripts and preparing test data.

3. Scripting and/or executing tests –- Here is where tests are actually executed and/or automated. This is what most non-testers think of when they hear someone talk about software testing.

4. Analyzing test results and new information –- Not all tests produce results that clearly pass or fail. Many tests result in data that can only be understood by human judgment and analysis. Additionally, changing specifications, deadlines or project environments can make a test that had been clearly passing fail without anything changing in the software. This category is where this type of analysis occurs.

5. Reporting relevant information -- Reporting defects and preparing compliance reports are what come to mind first for most people, but a tester may need to report all kinds of additional information.

Again, these five categories are intended to be simple in order to make our discussion about testing models easier. They aren't intended to supplant your current terminology.

Testing waterfall-style

Just like developing software using the waterfall model, testing waterfall-style is a fundamentally linear process except for a minimal feedback loop created by the need to fix some of the problems in the software that are indicated by failing tests. Visually, that feedback loop is equivalent to the small eddy current at the bottom of a real waterfall.

Waterfall-style testing is rarely chosen voluntarily anymore. It is commonly a side effect of some logistical challenge that kept the testers from being able to interact with the application or the developers prior to the first -- and what they hope will be the only -- build of the software. Waterfall testing is occasionally appropriate for situations where it is reasonable to hope the software will "just work," such as applying a service release or a patch to a production application.

Testing, iterative-style

Iterative testing is similar to iterative development in that many of the test iterations happen to coincide with development releases. In that regard, it is like a bunch of waterfall testing cycles strung end to end. Testing iterations differ from development iterations in that there can be iterations prior to the first software build, and there can be multiple test iterations during a single software build. Another difference is that unlike a development iteration, a test iteration can seamlessly abort at any point during the iteration to return to a research mode. While a development iteration can also abort and restart at any time, doing so is quite likely to jeopardize the project schedule.

Iterative software testing is extremely common in the commercial market, though it has many variants. The V-Model, the spiral model, and Rational Unified Process (RUP) based testing are all derivatives of an iterative testing approach. Iterative testing generally works well on projects where software is being developed in pre-planned, predictable increments and on projects where the software is being developed and released in such rapid or unpredictable cycles that it is counter productive for testers to plan around scheduled releases.

Testing, agile-style

Agile-style testing more or less eliminates the element of pre-determined flow from the test cycle in favor of shifting among the five basic activities whenever it adds value to the project to do so. For example, while analyzing the results of a test, the tester may realize that his test was flawed and move directly back to planning and designing tests. In a waterfall or iterative flow, that test redesign would wait until after the current results were reported and preparations were being made for the next test iteration.

Agile-style testing can be implemented as an overall approach or as a complement to any other testing approach. For example, within an iterative test approach, a tester could be encouraged to enter a period of agile testing, side-by-side with a developer, while tracking down and resolving defects in a particular feature.

Agile-style testing is significantly more common than most people realize. As it turns out, this model is what is going on in the heads of many testers all the time, regardless of the external process they are following. Be that as it may, this approach isn't very popular with managers and process improvement specialists because it is misunderstood by many non-testers and few testers following this process are able to express what they are doing in a manner that gives stakeholders confidence that they are actually doing organized and thoughtful testing.

For more information Try Googling it!

IEEE 829 Compliant Test Plan Template

2008-12-28T02:37:00.000-08:00

You have read about how to write a good test plan, now let's go through the 16 clauses of the IEEE 829 plan standard that are as follows:

1. Test plan identifier.
2. Introduction.
3. Test items.
4. Features to be tested.
5. Features not to be tested.
6. Approach.
7. Item pass/fail criteria.
8. Suspension criteria and resumption requirements.
9. Test deliverables.
10. Testing tasks.
11. Environmental needs.
12. Responsibilities.
13. Staffing and training needs.
14. Schedule.
15. Risks and contingencies.
16. Approvals.

These can be matched against the five characteristics of a basic plan, with a couple left over that form part of the plan document itself.

Scope

Scope clauses define what features will be tested. An aid to doing this is to prioritize them using a technique such as MoSCoW.

3. Test Items: The items of software, hardware, and combinations of these that will be tested.

4. Features to Be Tested: The parts of the software specification to be tested.

5. Features Not to Be Tested: The parts of the software specification to be excluded from testing.

Resource

Resource clauses give the overall view of the resources to deliver the tasks.

11. Environmental Needs: What is needed in the way of testing software, hardware, offices etc.

12. Responsibilities: Who has responsibility for delivering the various parts of the plan.

13. Staffing And Training Needs: The people and skills needed to deliver the plan.

Time

Time clauses specify what tasks are to be undertaken to meet the quality objectives, and when they will occur.

10. Testing Tasks: The tasks themselves, their dependencies, the elapsed time they will take, and the resource required.

14. Schedule: When the tasks will take place.

Often these two clauses refer to an appendix or another document that contains the detail.

Quality

Quality clauses define the standard required from the testing activities.

2. Introduction: A high level view of the testing standard required, including what type of testing it is.

6. Approach: The details of how the testing process will be followed.

7. Item Pass/Fail Criteria: Defines the pass and failure criteria for an item being tested.

9. Test Deliverables: Which test documents and other deliverables will be produced.

The associated article on test documentation gives details of the IEEE 829 documentation.

Risk

Risk clauses define in advance what could go wrong with a plan and the measures that will be taken to deal with these problems. An outline of risk management is in an associated article.

8. Suspension Criteria And Resumption Requirements: This is a particular risk clause to define under what circumstances testing would stop and restart.

15. Risks And Contingencies: This defines all other risk events, their likelihood, impact and counter measures to over come them.

Plan Clauses

These clauses are parts of the plan structure.

1. Test Plan Identifier: This is a unique name or code by which the plan can be identified in the project's documentation including its version.

16. Approvals: The signatures of the various stakeholders in the plan, to show they agree in advance with what it says.

For more information try Googling it!

What are IEEE 829 Test Plan Standards?

2008-12-28T02:30:00.001-08:00

Recently I have been searching a lot on testing jargons and come across a list of IEEE 829 Test Plan Standards as it was something which is not known generally.

This could be the list of standards to make your test plan IEEE 829 compliant as per the source.

1. Test plan identifier

2. Introduction

3. Test Items

4. Features to be tested.

5. Features not to be tested.

6. Approach

7. Item pass/fail criteria.

8. Suspension criteria and resumption requirements.

9. Test deliverables.

10. Testing tasks.

11. Environmental needs.

12. Responsibilities.

13. Staffing and training needs.

14. Schedule.

15. Risks and contingencies.

16. Approvals.

For more information try Googling it!

WIPRO is the Best Software testing Company

2008-12-14T01:28:00.000-08:00

IT major Wipro Technologies has won the best practice award for software testing, set up by the US-based International Institute for Software Testing (IIST), the company announced here Friday.

The company's testing services division was given the award for innovating a statistical tool that reduces the time taken to test a product.

'As part of our proprietary tools suite code-named StORM (statistics, operations, research, matrix), the tool helps us to reduce test case development effort by about 30 percent,' Wipro vice-president and testing services' head C.P. Gangadharaiah said in a statement.

With over 10 years of experience in independent testing services, Wipro is the largest third-party offshore testing service provider worldwide.

It has also set-up the first wireless fidelity (Wi-Fi) pre-certification and certification lab at its Bangalore campus.

The IT bellwether offers software testing services to global customers in partnership with other leading vendors such as Hewlett-Packard, IBM and Microsoft.

'The award is one of the initiatives we have taken to advance the software testing profession and encourage IT firms to adopt best practices. The award also enables firms to share their best practices with the software testing community,' IIST chairman Magdy Hanna said.

Wipro was chosen for the award out of 36 technology firms worldwide that were short-listed by the institute.

Win Runner Frequently Asked Questions Continued......

2008-12-06T07:37:00.000-08:00

1) How does WinRunner evaluates test results?
Ans.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window.

2) Have you performed debugging of the scripts?
Ans.
Yes, I have performed debugging of scripts. We can debug the script by executing the script in the debug mode. We can also debug script using the Step, Step Into, Step out functionalities provided by the WinRunner.

3) How do you run your test scripts?
Ans.
We run tests in Verify mode to test your application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.

4) How do you analyze results and report the defects?
Ans.
Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages. If mismatches are detected at checkpoints during the test run, you can view the expected results and the actual results from the Test Results window. If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window. This information is sent via e-mail to the quality assurance manager, who tracks the defect until it is fixed.

5) What is the use of Test Director software?
Ans.
TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.

WinRunner Frequently Asked Questions

2008-12-06T07:21:00.000-08:00

1) How you used WinRunner in your project?
Ans. Yes, I have used WinRunner for creating automates scripts for GUI, functional and regression testing of the AUT.

2) Explain WinRunner testing process?
Ans.
WinRunner testing process involves six main stages:
i. Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
ii. Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.
iii. Debug Test: run tests in Debug mode to make sure they run smoothly
iv. Run Tests: run tests in Verify mode to test your application.
v. View Results: determines the success or failure of the tests.
vi. Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window.

3) What in contained in the GUI map?
Ans.
WinRunner stores information it learns about a window or object in a GUI Map. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description. There are 2 types of GUI Map files.
i. Global GUI Map file: a single GUI Map file for the entire application
ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.

4) How does WinRunner recognize objects on the application?
Ans.
WinRunner uses the GUI Map file to recognize objects on the application. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested.

5) Have you created test scripts and what is contained in the test scripts?
Ans.
Yes I have created test scripts. It contains the statement in Mercury Interactive’s Test Script Language (TSL). These statements appear as a test script in a test window. You can then enhance your recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator.

Different Software Testing Techniques

2008-11-29T07:28:00.000-08:00

Black box testing - Internal system design is not considered in this type of testing. Tests are based on requirements and functionality.

White box testing - This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing - Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

Integration testing - Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing - This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.

Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

Regression testing - Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.

Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.

Load testing - Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

Performance testing - Term often used interchangeably with ’stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.

Alpha testing - In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.

Beta testing - Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

Happy Testing!!!

Want more information Try googling it

Just a brief introduction about software testing!

2008-11-29T06:30:00.000-08:00

There are many published definitions of software testing, however, all of these definitions Boil down to essentially the same thing: software testing is the process of executing Software in a controlled manner, in order to answer the question "Does the software Behave as specified?"

Software testing is often used in association with two Terms:

Verification: It is the checking or testing of items, including software, for conformance and consistency with an associated specification. Software testing is just one kind of verification, which also uses techniques such as reviews, analysis, inspections and walkthroughs.

Validation: Validation is the process of checking that what has been specified is what the User actually wanted.

Or in Layman's Language we can say it as

Validation: Are we doing the right job?

Verification:Are we doing the job right?

What is a BUG?

The term bug is often used to refer to a problem or fault in a computer. There are software bugs and hardware bugs. The term originated in the United States, at the time when pioneering computers were built out of valves, when a series of previously inexplicable faults were eventually traced to moths flying about inside the computer.

A couple of URL's that could come in as handy:

http://en.wikipedia.org/wiki/Software_testing

http://en.wikipedia.org/wiki/Scenario_test

http://en.wikipedia.org/wiki/Test_suite

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Test_script

http://en.wikipedia.org/wiki/Regression_testing

Want more information Try googling it !