Testing Solution By Manish Bansal

Web Service Testing

2011-11-16T09:46:00.004+05:30

The great advantage of Web services is that they empower different types of entities to communicate with one another through platform-independent protocols such as SOAP, XML, and HTTP. However, the tradeoff for this flexibility is that this open, non-native traffic brings with it additional overhead. Take, for example, an enterprise that wants to use a Web service to integrate a J2EE application with a variety of client types or other applications

In this situation, many different types of clients can now access the information contained within the EJBs by going through the Web service layer. But this introduces a potential issue: a new layer of communication has been added with its own overhead and potential for failure into an application whose quality and performance was formerly under control. If the Web service layer makes the application slower or introduces quality issues it could affect application service-levels and negatively impact end users. The only way to ensure that this doesn’t happen is to test the quality and performance of these Web Services before they are deployed.

Web Services are applications that exist within a network. Since web services are being used more and more by businesses, security and testing are essential to web services. Testing ensures that SOA deployments can be reliable and successful for an enterprise. However, there are many gray areas that often occur during testing. To avoid these gray areas it is important to focus on performance, security, SOAP attachments, WSDL, and interoperability.

At a very basic level, one needs to consider how the remote method calls take place via SOAP, how the data is passed, how to test the transport layer, discovery methods, response data, scalability, performance, integrity etc.Testing Approach: Test Case Design, Test Execution shall be Top-Down and Bottom-Up respectively. Documenting test cases for the individual services can be a tedious task and subject matter experts can take part in unit testing the individual service so that they are error-free in the downstream process. This approach facilitates meeting the high-level business requirements and can also be used to create the data contents for the exchanged message. This will avoid the major pitfall of delivering a technically acceptable solution which fails to deliver business value. Once this is done, the data must be formatted into messages (XML) that express service request and replies from consumer and provider respectively.

Test tools must be used before and after publishing a web service. To do this, the WSDL must be loaded into the tool. The tool then acts as a client of the web service and sends SOAP requests. This describes a simple consumer-producer test scenario. Since web services depend on other services, the whole chain must be tested in order to find the problems. If a web service is not performing correctly, it may be due to another web service which it is attached to. This is easy to find if one simply monitors the CPU and memory statistics of each web service as the test transaction occurs. Many performance characteristics must be looked at such as response times and fail/pass ratios.

Security validation is also very important to evaluate when testing web services. This must be taken care of at the message level by using tools such as signatures and encryption. Test cases are also important to look at since a negative test case shows where the web service is inefficient.

SOAP is used to carry complex attachments through a network. These transmissions must also be evaluated to ensure that the attachment is not corrupted. To test a SOAP attachment, one can simply make sure that the upload and download values match and re-calculate the check-sum. The break point for message size must also be figured out.

WSDL acts as an important contract between the consumer and producer. However, this also provides gray area in web services testing since it is often not accessible through a firewall after handled by a partner. To avoid this dilemma, it is important to flatten the WSDL before handing it over to a trading partner. WSDL quality must also be identified.

Web Services Process Flow

2011-10-05T15:05:00.005+05:30

A service provider describes its service using WSDL. This definition is published to a directory of services. The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories can also be used. Service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service. Part of the WSDL provided by the service provider is passed to the service consumer and this tells the service consumer what the requests and responses are for the service provider.

Web Services

2011-10-05T15:00:00.004+05:30

A Web service is a method of communication between two electronic devices over a network.
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-process able format (specifically Web Services Description Language WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

The W3C also states, "We can identify two major classes of Web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations.

Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.

The full-function web services platform can be thought of as XML, HTTP, SOAP, WSDL and UDDI. At higher levels, one might also add technologies such as XAML, XLANG, XKMS, and XFS -- services that are not universally accepted as mandatory.

SOAP (Simple Object Access Protocol) is a protocol specification that defines a uniform way of passing XML-encoded data. It also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol.

UDDI (Universal Description, Discovery and Integration Service) provides a mechanism for clients to dynamically find other web services. Using a UDDI interface, businesses can dynamically connect to services provided by external business partners. A UDDI registry is similar to a CORBA trader, or it can be thought of as a DNS service for business applications.

Web Services Description Language (WSDL) is a new specification to describe networked XML-based services. It provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying protocol (such as Simple Object Access Protocol or XML) or encoding (such as Multipurpose Internet Messaging Extensions). WSDL is a key part of the effort of the Universal Description, Discovery and Integration (UDDI) initiative to provide directories and descriptions of such on-line services for electronic business.

SOA Testing Challanges

2011-10-05T14:47:00.004+05:30

When it comes to testing SOA applications, one has to look beyond functionality and performance (load) testing. SOA testing requires testing of interfaces and services that might bring together diverse systems and platforms, along with other performance (latency) and security related aspects.
One of the other challenges to be tackled in SOA Testing is the availability of the environment with the dependent underlying services and/or applications. For instance, an SOA Implementation might bring together two or more autonomous internal applications/services when composing a business process.
The availability of these internal applications/services becomes highly important during integration testing in parts as well as during end-to-end testing of the business process.
Some of the SOA Testing challenges are:
• Services that do not have a user interface
• Data driven business logic within services
• External services to the organization
• The quality of 'service' software will be vital to promote reuse and facilitate business agility. Services that have known bugs and quality issues will not be reused by the development teams. A significant increase in testing activities and test assets (functional, performance and security regression suites that include sophisticated harnesses and stubs) will be required at a service (program) level
• Predicting the future usage of services to assist with performance, load, stress, scalability
• As your SOA evolves, security testing will have a higher priority and profile within your organizations test strategy
Additional considerations:
• In SOA, Services are based on heterogeneous technologies. The ability to string together multiple types of components to form a business process requires unconstrained thinking from an architect's perspective, and test planning and scheduling complexities from a tester's perspective.
• In SOA, application logic is in the middle-tier, operating within numerous technologies, residing outside the department, or even outside the company.
• To test SOA, you need to go far beyond merely testing a user interface or browser screen. Web Services (WSDL/SOAP) will be an important component for many SOAs, but if you're only testing Web Services, you are not likely to test the entire technology stack that makes up the application. What are the transactions happening at the messaging layer? Is the right entry being reflected in the database?

Multiple Choice Testing Question Answers

2008-12-31T12:49:00.013+05:30

1 : With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.

a. True

b. False
ANSWER : b

2 : Which of the following are characteristics of testable Software ?
a. observability
b. simplicity
c. stability
d. all of the above
ANSWER : d

3 : The testing technique that requires devising test cases to demonstrate that each program function is operational is called
a. black-box testing
b. glass-box testing
c. grey-box testing
d. white-box testing
ANSWER : a

4 : The testing technique that requires devising test cases to exercise the internal logic of a software module is called
a. behavioral testing
b. black-box testing
c. grey-box testing
d. white-box testing
ANSWER : d

5 : What types of errors are missed by black-box testing and can be uncovered by white-box testing ?

a. behavioral errors

b. logic errors

c. performance errors

d. typographical errors

e. both b and d

ANSWER : e

6 : Program flow graphs are identical to program flowcharts.

a. True

b. False

ANSWER : b

7 : The cyclomatic complexity metric provides the designer with information regarding the number of

a. cycles in the program

b. errors in the program

c. independent logic paths in the program

d. statements in the program

ANSWER : c

8 : The cyclomatic complexity of a program can be computed directly from a PDL representation of an algorithm without drawing a program flow graph

.a. True

b. False

ANSWER : a

9 : Condition testing is a control structure testing technique where the criteria used to design test cases is that they

a. rely on basis path testing

b. exercise the logical conditions in a program module

c. select test paths based on the locations and uses of variables

d. focus on testing the validity of loop constructs

ANSWER : b

10 : Data flow testing is a control structure testing technique where the criteria used to design test cases is that they

a. rely on basis path testing

b. exercise the logical conditions in a program module

c. select test paths based on the locations and uses of variables

d. focus on testing the validity of loop constructs

ANSWER : c

11 : Loop testing is a control structure testing technique where the criteria used to design test cases is that they

a. rely basis path testing

b. exercise the logical conditions in a program module

c. select test paths based on the locations and uses of variables

d. focus on testing the validity of loop constructs

ANSWER : d

12 : Black-box testing attempts to find errors in which of the following categories

a. incorrect or missing functions

b. interface errors

c. performance errors

d. all of the abovee. none of the above

ANSWER : d

13 : Graph-based testing methods can only be used for object-oriented systems

a. True

b. False

ANSWER : b

14 : Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.

a. True b. False

ANSWER : a

15 : Boundary value analysis can only be used to do white-box testing.

a. True

b. False

ANSWER : b

16 : Comparison testing is typically done to test two competing products as part of customer market analysis prior to product release.

a. True

b. False

ANSWER : b

17 : Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.

a. True b. False

ANSWER : a

18 : Test case design "in the small" for OO software is driven by the algorithmic detail ofthe individual operations.

a. True

b. False

ANSWER : a

19 : Encapsulation of attributes and operations inside objects makes it easy to obtain object state information during testing.

a. True

b. False

ANSWER : b

20 : Use-cases can provide useful input into the design of black-box and state-based tests of OO software.

a. True

b. False

ANSWER : a

21 : Fault-based testing is best reserved for

a. conventional software testing

b. operations and classes that are critical or suspect

c. use-case validation

d. white-box testing of operator algorithms

ANSWER : b

22 : Testing OO class operations is made more difficult by

a. encapsulation

b. inheritance

c. polymorphism

d. both b and c

ANSWER : d

23 : Scenario-based testing

a. concentrates on actor and software interaction

b. misses errors in specifications

c. misses errors in subsystem interactions

d. both a and b

ANSWER : a

24 : Deep structure testing is not designed to

a. examine object behaviors

b. exercise communication mechanisms

c. exercise object dependencies

d. exercise structure observable by the user

ANSWER : d

25 : Random order tests are conducted to exercise different class instance life histories.

a. True

b. False

ANSWER : a

26 : Which of these techniques is not useful for partition testing at the class level

a. attribute-based partitioning

b. category-based partitioning

c. equivalence class partitioning

d. state-based partitioning

ANSWER : c

27 : Multiple class testing is too complex to be tested using random test cases.

a. True

b. False

ANSWER : b

28 : Tests derived from behavioral class models should be based on the

a. data flowdiagram

b. object-relation diagram

c. state diagram

d. use-case diagram

ANSWER : c

29 : Client/server architectures cannot be properly tested because network load is highly variable.

a. True

b. False

ANSWER : b

30 : Real-time applications add a new and potentially difficult element to the testing mix

a. performance

b. reliability

c. security

d. time

ANSWER : d

What Is WSDL?

2007-10-08T14:35:00.001+05:30

WSDL: Web Service Description Language

This New Breed of dot com needs a solution that can describe the services .the web services it offers specially this means that you need a format or some type of grammar with which you can describe the answers to the following questions.

What are the services offered in Your Online business?
How Can You Invoke Your business services?
What information do your business services need from the user when he or she invoke your Service?
How Will the user Provide the required Information?
In which Format will the services send information back to user?

Testing Definition In Simple

2007-07-23T14:53:00.000+05:30

What's Ad Hoc Testing ?
A testing where the tester tries to break the software by randomly trying functionality of software.
What's the Accessibility Testing ?
Testing that determines if software will be usable by people with disabilities.
What's the Alpha Testing ?
The Alpha Testing is conducted at the developer sites and in a controlled environment by the end user of the software
What's the Beta Testing ?
Testing the application after the installation at the client place।
What is Component Testing ?
Testing of individual software components (Unit Testing).
What's Compatibility Testing ?
In Compatibility testing we can test that software is compatible with other elements of system.
What is Concurrency Testing ?
Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.
What is Conformance Testing ?
The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.
What is Context Driven Testing ?
The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.
What is Data Driven Testing ?
Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.
What is Conversion Testing ?
Testing of programs or procedures used to convert data from existing systems for use in replacement systems.
What is Dependency Testing ?
Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.
What is Depth Testing ?
A test that exercises a feature of a product in full detail.
What is Dynamic Testing ?
Testing software through executing it. See also Static Testing.
What is Endurance Testing ?
Checks for memory leaks or other problems that may occur with prolonged execution.
What is End-to-End testing ?
Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
What is Exhaustive Testing ?
Testing which covers all combinations of input values and preconditions for an element of the software under test.
What is Gorilla Testing ?
Testing one particular module, functionality heavily.
What is Installation Testing ?
Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
What is Localization Testing ?
This term refers to making software specifically designed for a specific locality.
What is Loop Testing ?
A white box testing technique that exercises program loops.
What is Mutation Testing ?
Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources
What is Monkey Testing ?
Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.
What is Positive Testing ?
Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.
What is Negative Testing ?
Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing.
What is Path Testing ?
Testing in which all paths in the program source code are tested at least once.
What is Performance Testing ?
Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".
What is Ramp Testing ?
Continuously raising an input signal until the system breaks down.
What is Recovery Testing ?
Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
What is the Re-testing testing ?
Retesting- Again testing the functionality of the application.
What is the Regression testing ?
Regression- Check that change in code have not effected the working functionality
What is Sanity Testing ?
Brief test of major functional elements of a piece of software to determine if its basically operational.
What is Scalability Testing ?
Performance testing focused on ensuring the application under test gracefully handles increases in work load in Normal Condition.
What is Security Testing ?
Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.
What is Stress Testing ?
Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results in Abnormal Condition.
What is Smoke Testing ?
A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.
What is Soak Testing ?
Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.it means Reliability with load.
What's the Usability testing ?
Usability testing is for user friendliness.
What's the User acceptance testing ?
User acceptance testing is determining if software is satisfactory to an end-user or customer.
What's the Volume Testing ?
We can perform the Volume testing, where the system is subjected to large volume of data.

Test Plan

2007-04-20T14:35:00.000+05:30

Test Plan:- A Test Plan is What To Test ? and How To Test? The Test Plan describes the overall approach to development, integration, qualification, and acceptance testing. It describes plans for testing software systems; test environment to be used for the testing; identifies tests to be performed, and provides schedules for test activities. The software Test Plan is used by IT Manager, Test Manager, Documentation Manager, System Administrator, Technical Architect, Development Manager, Project Manager.

The Test Plan is used to perform system testing, subsystem testing, assembly testing, subassembly testing, module testing, user acceptance testing. The Test Plan includes step by step instructions for the various types of testing that will occur during the project life cycle; it also defines the required test equipment, calibration requirements, test facility requirements, and other key factors.

This is a sample of an outline for a test plan. It has been designed for medium to small test projects, and thus is fairly lightweight. It is by necessity general, because each enterprise, each development group, each testing group, and each development project is different. This outline should be used as a set of guidelines for creating your own standard template; add to it or subtract from it as you find appropriate.

Differences in Testing

2007-04-19T15:38:00.000+05:30

Difference Between White box and Black Box Testing?

Black box testing - not based on any knowledge of internal design or code. Tests are based on requirements and functionality.

White box testing - based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.

Black-box and white-box are test design methods. Black-box test design treats the system as a “black-box”, so it doesn’t explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional requirements. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box. White-box test design allows one to peek inside the “box”, and it focuses specifically on using internal knowledge of the software to guide the selection of test data. Synonyms for white-box include: structural, glass-box and clear-box. While black-box and white-box are terms that are still in popular use, many people prefer the terms "behavioral" and "structural". Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn't strictly forbidden, but it's still discouraged. In practice, it hasn't proven useful to use a single test design method. One has to use a mixture of different methods so that they aren't hindered by the limitations of a particular one. Some call this "gray-box" or "translucent-box" test design, but others wish we'd stop talking about boxes altogether. It is important to understand that these methods are used during the test design phase, and their influence is hard to see in the tests once they're implemented. Note that any level of testing (unit testing, system testing, etc.) can use any test design methods. Unit testing is usually associated with structural test design, but this is because testers usually don't have well-defined requirements at the unit level to validate .

What are unit, component and integration testing?

Note that the definitions of unit, component, integration, and integration testing are recursive:

Unit. The smallest compilable component. A unit typically is the work of one programmer (At least in principle). As defined, it does not include any called sub-components (for procedural languages) or communicating components in general.

Unit Testing: in unit testing called components (or communicating components) are replaced with stubs, simulators, or trusted components. Calling components are replaced with drivers or trusted super-components. The unit is tested in isolation.

Component: a unit is a component. The integration of one or more components is a component.

Note: The reason for "one or more" as contrasted to "Two or more" is to allow for components that call themselves recursively.

Component testing: same as unit testing except that all stubs and simulators are replaced with the real thing.

Two components (actually one or more) are said to be integrated when:

a. They have been compiled, linked, and loaded together.

b. They have successfully passed the integration tests at the interface between them. Thus, components A and B are integrated to create a new, larger, component (A,B).

Note that this does not conflict with the idea of incremental integration—it just means that A is a big component and B, the component added, is a small one.

Integration testing: carrying out integration tests.

Integration tests (After Leung and White) for procedural languages. This is easily generalized for OO(Object Oriented) languages by using the equivalent constructs for message passing. In the following, the word "call" is to be understood in the most general sense of a data flow and is not restricted to just formal subroutine calls and returns – for example, passage of data through global data structures and/or the use of pointers.

As to the difference between integration testing and system testing. System testing specifically goes after behaviors and bugs that are properties of the entire system as distinct from properties attributable to components (unless, of course, the component in question is the entire system). Examples of system testing issues: Resource loss bugs, throughput bugs, performance, security, recovery, Transaction synchronization bugs (often misnamed "timing bugs").

What's the difference between load and stress testing ?

One of the most common, but unfortunate misuse of terminology is treating “load testing” and “stress testing” as synonymous. The consequence of this ignorant semantic abuse is usually that the system is neither properly “load tested” nor subjected to a meaningful stress test.

Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, MIPS, interrupts, etc.) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). Bugs and failure modes discovered under stress testing may or may not be repaired depending on the application, the failure mode, consequences, etc. The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.

Load testing is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads are in support of software reliability testing and in performance testing. The term "load testing" by itself is too vague and imprecise to warrant use. For example, do you mean representative load," "overload," "high load," etc. In performance testing, load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions ,suffer (application-specific) excessive delay.

A third use of the term is as a test whose objective is to determine the maximum sustainable load the system can handle. In this usage, "load testing" is merely testing at the highest transaction arrival rate in performance testing.

What's the difference between QA and testing?

QA is more a preventive thing, ensuring quality in the company and therefore the product rather than just testing the product for software bugs?

TESTING means "quality control"

QUALITY CONTROL measures the quality of a product

QUALITY ASSURANCE measures the quality of processes used to create a quality product.

Testing Interview Question.

2007-04-18T20:13:00.000+05:30

1. What is Software Testing?
2. What is the Purpose of Testing?
3. What types of testing do testers perform?
4. What is the Outcome of Testing?
5. What kind of testing have you done?
6. What is the need for testing?
7. What are the entry criteria for Functionality and Performance testing?
8. What is test metrics?
9. Why do you go for White box testing, when Black box testing is available?
10. What are the entry criteria for Automation testing?
11. When to start and Stop Testing?
12. What is Quality?
13. What is Baseline document, Can you say any two?
14. What is verification?
15. What is validation?
16. What is quality assurance?
17. What is quality control?
18. What is SDLC and TDLC?
19. What are the Qualities of a Tester?
20. When to start and Stop Testing?
21. What are the various levels of testing?
22. What are the types of testing you know and you experienced?
23. What exactly is Heuristic checklist approach for unit testing?
24. After completing testing, what would you deliver to the client?
25. What is a Test Bed?
26. What is a Data Guidelines?
27. Why do you go for Test Bed?
28. What is Severity and Priority and who will decide what?
29. Can Automation testing replace manual testing? If it so, how?
30. What is a test case?
31. What is a test condition?
32. What is the test script?
33. What is the test data?
34. What is an Inconsistent bug?
35. What is the difference between Re-testing and Regression testing?
36. What are the different types of testing techniques?
37. What are the different types of test case techniques?
38. What are the risks involved in testing?
39. Differentiate Test bed and Test Environment?
40. What ifs the difference between defect, error, bug, failure, fault?
41. What is the difference between quality and testing?
42. What is the difference between White & Black Box Testing?
43. What is the difference between Quality Assurance and Quality Control?
44. What is the difference between Testing and debugging?
45. What is the difference between bug and defect?
46. What is the difference between verification and validation?
47. What is the difference between functional spec. and Business requirement specification?
48. What is the difference between unit testing and integration testing?
49. What is the diff between Volume & Load?
50. What is diff between Volume & Stress?
More Interview Testing Question http://testingsolution.blogspot.com/2006/12/more-testing-interview-question.html

Do Testers Need Programming Skills ?

2007-02-03T14:46:00.001+05:30

Do Testers Need Programming Skills ? A Good Tester Friend View.

Many freshers (especially people with Computer Science background) does not take up the first job as QA engineer and the reason they give is that many organizations give preference to people with development skills even while hiring people for testing positions. This raises the question does the testers need to be coders ? Some blogs report that organization like Microsoft hire the coders for test positions because they want to automate everything and eliminate manual testing. Automation is just one part of testing. But testers who understand programming and CS concepts have better analysis skills for testing. Testers with development skills can find the bugs earlier in development cycle and also find the cause for the bug. This also helps them in finding other places in code where there can be similar errors. I, personally feel that people with programming skills always makes better testers. Does this mean all the testers without programming knowledge be fired ?- of course not. Its always an option to have creative people as testers than bad programmers. An organization cannot have all the testers to have programming knowledge as well, with industry facing shortage of quality programmers. Microsoft seems to have found a way out of this by creating two different job profiles SDET and STE. SDET needs to have good programming skills as they are used for automation and debugging. But even this did'nt seem to have solved the problem completely. Can read more about SDET Vs STE here.

SOA- Service Oriented Architecture

2007-02-02T18:49:00.000+05:30

software vendors have been creating development and infrastructure products for the latest IT architecture style - Service Oriented Architecture (SOA). Recognizing the immense value SOA can bring to IT, companies like BEA, IBM, and Microsoft have delivered products to help customers design and build SOA-based applications. These vendor-driven initiatives are beginning to sprout actual customer-developed applications that are built on the promise of SOA, such as better flexibility, agility and reuse.

A challenge facing many organizations is how to quickly and effectively react to frequent changes in business requirements, whilst improving productivity and reducing costs. To achieve this, you need a flexible infrastructure that can meet the demands of a changing marketplace and seize emerging opportunities. To address this challenge, Service Oriented Architecture (SOA) promotes an architectural approach that replaces rigid proprietary systems with heterogeneous, "loosely-coupled" services. The Service Component Architecture (SCA), along with Service Data Objects (SDO), makes this architectural concept a reality and provides the programming model to build SOA solutions for agile businesses.

Some QTP Related Question Answers

2007-01-28T14:53:00.002+05:30

Full form of QTP ?
Quick Test Professional
What's the QTP ?
QTP is Mercury Interactive Functional Testing Tool.
Which scripting language used by QTP ?
QTP uses VB scripting.
What's the basic concept of QTP ?
QTP is based on two concept-
* Recording
* Playback
How many types of recording facility are available in QTP ?
QTP provides three types of recording methods-
* Context Recording (Normal)
* Analog Recording
* Low Level Recording
How many types of Parameters are available in QTP ?
QTP provides three types of Parameter-
* Method Argument
* Data Driven
* Dynamic
What's the QTP testing process ?
QTP testing process consist of seven steps-
* Preparing to recoding
* Recording
* Enhancing your script
* Debugging
* Run
* Analyze
* Report
DefectsWhat's the Active Screen ?
It provides the snapshots of your application as it appeared when you performed a certain steps during recording session.
What's the Test Pane ?
Test Pane contains Tree View and Expert View tabs.
What's Data Table ?
It assists to you about parameterizing the test.
What's the Test Tree ?
It provides graphical representation of your operations which you have performed with your application.
Which all environment QTP supports ?
ERP/ CRM /Java/ J2EE/ VB, .NET ,Multimedia, XML Web Objects, ActiveX controls ,SAP, Oracle, Siebel, PeopleSoft Web Services, Terminal EmulatorIE, NN, AOL .
How can you view the Test Tree ?
The Test Tree is displayed through Tree View tab.
What's the Expert View ?
Expert View display the Test Script.
Which keyword used for Normal Recording ?
F3
Which keyword used for run the test script ?
F5
Which keyword used for stop the recording ?
F4
Which keyword used for Analog Recording ?
Ctrl+Shift+F4
Which keyword used for Low Level Recording ?
Ctrl+Shift+F3
Which keyword used for switch between Tree View and Expert View ?
Ctrl+Tab
What's the Transaction ?
You can measure how long it takes to run a section of your test by defining transactions.
Where you can view the results of the checkpoint ?
You can view the results of the checkpoints in the Test Result Window.
What's the Standard Checkpoint ?
Standard Checkpoints checks the property value of an object in your application or web page.
Which environment are supported by Standard Checkpoint ?
Standard Checkpoint are supported for all add-in environments.
What's the Image Checkpoint ?
Image Checkpoint check the value of an image in your application or web page.
Which environments are supported by Image Checkpoint ?
Image Checkpoint are supported only Web environment.
What's the Bitmap Checkpoint ?
Bitmap Checkpoint checks the bitmap images in your web page or application.
Which enviornment are supported by Bitmap Checkpoints ?
Bitmap checkpoints are supported all add-in environment.
What's the Table Checkpoints ?
Table Checkpoint checks the information with in a table.
Which environments are supported by Table Checkpoint ?
Table Checkpoints are supported only ActiveX environment.
What's the Text Checkpoint ?
Text Checkpoint checks that a test string is displayed in the appropriate place in your application or on web page.
Which environment are supported by Test Checkpoint ?
Text Checkpoint are supported all add-in environments Note:
* QTP records each steps you perform and generates a test tree and test script.
* QTP records in normal recording mode.
* If you are creating a test on web object, you can record your test on one browser and run it on another browser.
* Analog Recording and Low Level Recording require more disk sapce than normal recording mode.

Capability Maturity Model Integration (CMM) Maturity Levels

2007-01-28T14:31:00.000+05:30

Capability Maturity Model Integration (CMM) Maturity Levels
The Five Maturity Levels described by the Capability Maturity Model can be characterized as per their primary process changes made at each level as follows:

1) Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
2) Repeatable Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
3) Defined The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
4) Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
5) Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

CMM-Capability Maturity Model

2007-01-09T14:54:00.000+05:30

Capability Maturity Model:The Capability Maturity Model (CMM) is a methodology used to develop and refine an organization's software development process. The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes. CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center sponsored by the U.S. Department of Defense (DoD). SEI was founded in 1984 to address software engineering issues and, in a broad sense, to advance software engineering methodologies. More specifically, SEI was established to optimize the process of developing, acquiring, and maintaining heavily software-reliant systems for the DoD. Because the processes involved are equally applicable to the software industry as a whole, SEI advocates industry-wide adoption of the CMM.
The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end.

What is CMM (SEI Capability Maturity Model)? The Capability Maturity Model for Software (CMM) is a framework that describes the key elements of an effective software process. There are CMMs for non software processes as well, such as Business Process Management (BPM). The CMM describes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process. The CMM covers practices for planning, engineering, and managing software development and maintenance. When followed, these key practices improve the ability of organizations to meet goals for cost, schedule, functionality, and product quality. The CMM establishes a yardstick against which it is possible to judge, in a repeatable way, the maturity of an organization's software process and compare it to the state of the practice of the industry. The CMM can also be used by an organization to plan improvements to its software process. It also reflects the needs of individuals performing software process, improvement, software process assessments, or software capability evaluations; is documented; and is publicly available.

Unit & Integration Testing

2007-01-05T16:27:00.000+05:30

Unit Testing

In computer programming, a unit test is a method of testing the correctness of a particular module of source code.

The idea is to write test cases for every non-trivial function or method in the module so that each test case is separate from the others if possible. This type of testing is mostly done by the developers.

Benefits

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. It provides a written contract that the piece must satisfy. This isolated testing provides four main benefits:

Encourages change

Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly (regression testing). This provides the benefit of encouraging programmers to make changes to the code since it is easy for the programmer to check if the piece is still working properly.

Simplifies Integration

Unit testing helps eliminate uncertainty in the pieces themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts will make integration testing easier.

Documents the code

Unit testing provides a sort of "living document" for the class being tested. Clients looking to learn how to use the class can look at the unit tests to determine how to use the class to fit their needs.

Separation of Interface from Implementation

Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database; in order to test the class, the tester finds herself writing code that interacts with the database. This is a mistake, because a unit test should never go outside of its own class boundary. As a result, the software developer abstracts an interface around the database connection, and then implements that interface with their own Mock Object. This results in loosely coupled code, thus minimizing dependencies in the system.

Limitations

It is important to realize that unit-testing will not catch every error in the program. By definition, it only tests the functionality of the units themselves. Therefore, it will not catch integration errors, performance problems and any other system-wide issues. In addition, it may not be trivial to anticipate all special cases of input the program unit under study may receive in reality. Unit testing is only effective if it is used in conjunction with other software testing activities.

Integration Testing

It is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing. takes as its input modules that have been checked out by unit testing, groups them in larger aggregates, applies tests defined in an Integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

Purpose

The purpose of Integration testing is to verify functional, performance and reliability requirements placed on major design items. These "design items", i.e. assemblages (or groups of units), are exercised through their interfaces using Black box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and inter-process communication is tested, individual subsystems are exercised through their input interface. All test cases are constructed to test that all components within assemblages interact correctly, for example, across procedure calls or process activations.

The overall idea, is the "building block" approach in which verified assemblages are added to a verified base which is then used to support the Integration testing of further assemblages.

White Box and Black Box Testing

2007-01-05T16:10:00.000+05:30

White Box Testing
Testing of a function with knowing internal structure of the program. Also known as glass box, structural, clear box and open box testing. A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable.
Black Box Testing
Testing of a function without knowing internal structure of the program. Black-box and white-box are test design methods. Black-box test design treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional requirements. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box. White-box test design allows one to peek inside the "box", and it focuses specifically on using internal knowledge of the software to guide the selection of test data. Synonyms for white-box include: structural, glass-box and clear-box.

While black-box and white-box are terms that are still in popular use, many people prefer the terms "behavioral" and "structural". Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn't strictly forbidden, but it's still discouraged. In practice, it hasn't proven useful to use a single test design method. One has to use a mixture of different methods so that they aren't hindered by the limitations of a particular one. Some call this "gray-box" or "translucent-box" test design, but others wish we'd stop talking about boxes altogether.

It is important to understand that these methods are used during the test design phase, and their influence is hard to see in the tests once they're implemented. Note that any level of testing (unit testing, system testing, etc.) can use any test design methods. Unit testing is usually associated with structural test design, but this is because testers usually don't have well-defined requirements at the unit level to validate.

Interview Questions

2007-01-05T15:01:00.000+05:30

Interview Question Answer By Testing Expert- Dr K.V.V.K. Prasad

Testing Scenarios :

Q: How do you know that all the scenarios for testing are covered? By using the Requirement Traceability Matrix (RTM) we can ensure that we have covered all the functionalities in Test Coverage. RTM is a document that traces User Requirements from analysis through implementations. RTm can be used as a completeness check to verify that all the requirements are present or that there is no unnecessary/extra features and as a maintenance guide to new personnel. We can use the simple format in Excel sheet where we map the Functionality with the Test case ID. 2. Complete Testing with Time Constraints :

Question: How do you complete the testing when you have a time constraint? If i am doinf regression testing and i do not have sufficient time then we have to see for which sort of regression testing i have to go 1)unit regression testing 2)Regional Regression testing 3)Full Regression testing. 3. Given an yahoo application how many test cases u can write? First we need requirements of the yahoo applicaiton. I think test cases are written aganist given requirements.So for any working webapplication or new application, requirements are needed to prepare testcases.The number of testcases depends on the requirements of the application Note to learners : A Test Engineer must have knowledge on SDLC. I suggest learners to take any one exiting application and start pratice from writing requirements. 4. Lets say we have an GUI map and scripts, a we got some 5 new pages included inan application how do we do that? By integration testing. 5. GUI contains 2 fields Field 1 to accept the value of x and Field 2 displays the result of the formula a+b/c-d where a= 0.4*x, b=1.5*a, c=x, d=2.5*b; How many system test cases would you write GUI contains 2 fields Field 1 to accept the value of x and Field 2 displays the result so that there is only one testcase to write

Quality Related Questions

2006-12-31T16:29:00.000+05:30

1. Quality means
a) conformance to requirements
b) meeting customer needs
c) both
d) none
2. AQL stands for
a)Allowable Quality Level
b)Allocated Quality Level
c) Acceptable Quality Level
d) Allowed Quality Level
3. For quality to happen, there must be well-defined standards and procedures which are followed. (True/False)
4. Many technical personnel believe that standards inhibit their creativity. (True/False)
5. Achieving quality (defect-free products and servcices) is easy. (True/False)
6. The challenge of making quality happen is
a)a miniscule challenge
b)a monumental challenge
7. Accomplishing quality requires "a thought revolution by management.". Who stated as above?
a)Dr. Malcolm Baldrige
b)Dr. Kaoru Ishikawa
c)Bill Gates
d)William J Clinton
8. Taylor approach refers to
a) Engineers create work standards and specifications. Workers merely follow.
b) Engineers create work standards and specifictions. Both engineers and workers follow.
c) Engineers create work standards and specifications and follow them.
9. In Zero defect movement all responsibilities and defects are borne by the workers.
(True/False)
10. The word "kick-off" is used in
a)Zero Defect Movement
b)Deming's Circle
c)QAI's Quality Improvement Model
11. Dr. W. Edwards Deming has stated that it takes ____________ years to change a culture from an emphasis on productivity to an emphasis on quality.
(10 years/20 years/2 to 5 years/none of these)
12. Quality means meeting requirements. This is ____________view.
(producer's /customer's )
13. Quality means fit for use. This is ________________view.
(producer's /customer's )
14. Which one of the following definitions of quality is more important.
a)Quality means meeting requirements.
b)Quality means fit for use.
15. Quality control is a ______________ function. (line/staff)
16. Quality assurance is a ____________ function. (line/staff)
17. By what other two names is PDCA process referred to?
18. What does "Going Around the PDCA Circle" connote?
19. The no of principles in Dr. W. Edwards Deming's quality principles is ____________. (8/10/12/14/16)
20. For quality to happen it is not necessary that all the Deming's principles are used concurrently. (True/False)
Hi Friends Try To Find Answers give answer in Next Post.

Levels of testing

2006-12-30T15:14:00.000+05:30

Levels of testing We divide Testing In Four Level,Unit Testing,Integration Testing, System Testing and Acceptance Testing.

Unit testing:-
Generally the code which is generated is compiled. The unit test is white box oriented and the steps can be conducted in parallel for multiple components.

1. The module Interface is tested to ensure that information properly flows into and out of the program unit under test.
2. The local data structure is examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm’s execution.
3. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit and restrict processing.
4. All the statements are executed at least once and error handling paths are tested
Integration testing:-
Integration testing is a systematic technique for constructing the program structure .After Performing Unit Testing perform integration testing. you have like
Top down :-Top down integration testing with the main routine and one or two immediate subordinate routines in the system structure it is good to have modules are integrated as they are developed, top level interfaces are tested first.
Bottom up :-Bottom up integration testing is the traditional strategy used to integrate the components of a software system into a functioning whole
Regressive testing:- Retesting the already test modules and adding new modules .Regressive testing is an important strategy for reducing side effects.
System Level Testing :

System Testing is third level of Testing In this level we check Functionility of application.

Performance testing: - Performance testing is designed to test the run time performance of software or hardware.
Recovery testing :- is a system test forces the software to fail in a variety of ways and verifies that recovery is properly performed .if recovery is automatic, re initialization , check pointing ,data recovery and restart are evaluated for correctness.
Security Testing: - Security testing attempts to verify that protection mechanisms built into a system will in fact, protect it from improper penetration.

Acceptance Testing:- When customer software is built for one customer, a series of acceptance tests are conducted to enable the customer to validate all requirements. conducted by the end user rather than software engineers, an acceptance test can range from an informal test drive to a planned and systematically executed series of tests. If software is developed as a product to be used by many customers, it is impractical to perform acceptance tests with each one. Most software product builders use a process called alpha and beta testing to uncover errors that only the end user seems able to find .

Web Testing Challenges

2006-12-28T21:33:00.000+05:30

Web Testing Challanges
Understanding the Web test process is essential for deciding how to proceed with the selection of a Web test process, automated test tools, and methodologies.
Following are several challenges that need to be considered when deciding on the Web process that is most applicable for your business:
The Web is in a state of constant change. The developer and tester need to understand how changes will affect their development and the Web sitetest process. As technology changes, testers will need to understand how this will affect them and how they will handle their testing responsibilities.
When setting up the test scenarios, the tester needs to understand how to implement different scenarios that will meet different types of business requirements. For example, is a tester testing a site with graphic user interface (GUI) buttons and text boxes or testing HyperText MarkupLanguage (HTML) code? Simulating response time by pressing buttons and inputting different values will verify if correct calculations are valid.
The test environment can be a difficult part of the setup for the tester.
You need to be aware of all of the different components that make up the environment; the networking piece can be especially difficult to simulate.
The following several considerations need to be addressed
Multiple server tiers
Firewalls
Databases
Database servers
In the test environment, it is important to know how the different components will interact with each other.
When setting up the Web testing environment, special consideration should be given to how credit card transactions are handled, carried out, and verified. Because testers are responsible for setting up the test scenarios, they will need to be able to simulate the quantity of transactions that are going to be processed on the Web site.
Security is a constant concern for business on the Internet as well as for developers and testers. There are hackers who enjoy breaking the secuiry on a Web site.

Web-based applications Present New Challanges ,Both For Developers and Testers .These challanges include .

1. Short Release Cycle
2. Constant Changing Technology
3. Possible Huge Number Of Users during Initial Website Launch.
4. Inability To control The Users Running Environment.
5.Twenty Four -24 Hour avilability of web site.

Web Test Plan

http://testingsolution.blogspot.com/2006/12/web-test-plan-development.html

Testing Related Books

Win Runner Related some Questions .

2006-12-28T11:05:00.000+05:30

Win Runner Related some Questions .

Q: What is 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. Global GUI Map file: a single GUI Map file for the entire application. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.
Q: How Win Runner identifies the GUI objects?
Ans: Win Runner identifies the objects based on their Logical name & Physical properties.
Q: What browsers are supported by Win Runner 7.x?
Ans:Win Runner 7.x supports Internet Explorer 4.x-5.5, Netscape Navigator 4.0-6.1 (excluding versions 6.0 and 6.01) and AOL 5 and 6.
Q: What is GUI Spy?
Ans: GUI Spy is an integrated tool for spying on standard, ActiveX and Java controls. It displays the properties of standard controls and the properties and methods of ActiveX and Java controls. You can copy and paste functions for activating Java methods from the GUI Spy into your test script.
Q:What is the use of GUI Map File per Test mode? Ans: This mode automatically manages GUI map files., so we do not have to load or save GUI map files in your test. GUI map files per test can be combined into the Global GUI map file if needed.
Q:What add-ins are available for Win Runner 7.x?
Ans:Add-ins are available for Java, ActiveX, WebTest, Siebel, Terminal Emulator, Forte, Oracle and PowerBuilder.
Q:Can WR automatically back up test scripts?
Ans:Yes, Win Runner 7.x can automatically create a backup copy of your test script at intervals you specify.
Q: What are the different run modes?
Ans: Three modes for running test:
Verify (default): To check your application against expected results. Win Runner compares the current response of the application to its expected response. Any discrepancies between the current and expected response are captured and saved as verification results.
Debug: The debug mode helps you identify bugs in test scripts. Running a test in the debug mode is the same as running a test in the Verify mode, expect that debug results are always saved in the debug directory.
Update: The update mode to update the expected results a test.
Q: What is GUI checkpoint?
Ans: GUI Checkpoints allows to verify the current state or attributes of GUI objects. When we insert GUI checkpoint in script, Win Runner captures the current value of the object properties and saves them in the expected result directory (exp) of the test. When we run the test Win Runner compares the current state of the object in the application to the expected state and detects and reports any mismatches.
Q: When we need to update the GUI map?
Ans: We need to update the GUI map when objects in the application have changed. This usually happens when a new major version of the application is released.
Q:What is the need for Data Driven Tests?
Ans:‘Parameterizing’ the test allows to run the same test with different data each time. In addition the test is expandable and easier to maintain.
Q:What is the purpose of the set_window function?
Ans:The set_window function sets the focus of the window in the application as well as sets the scope of the window in the GUI map.
Q: What is the difference between call() and load() function?
Ans: Call functions invokes a test from within a test script but load is used for loading a compiled module into memory.
Q:What is compiled module? Why do you create a complied module?
Ans: 1 Compiled module is library of frequently used functions. We can save user defined functions in compiled module and then call them in the test scripts.
2 Compiled module improves the organization and performance of the tests.
3 Compiled modules are debugged before using; they will require less error checking.
4 Calling a function whose is already compiled is significantly faster than interpreting a function in test script.
5 Complied module does not support analog recoding and checkpoints.
Q: How do you create user-defined functions?
Ans:User Defined functions enhance the efficiency and reliability of test scripts. Easy way to create a function is
1. Create the process by recording the TSL functions
2. Enclose it into the function header
3. Replace values with parameters
4. Declare local variable
5. Handle errors
Q: What is database checkpoint?
Ans:Database checkpoint is used to check the contents of database in different versions of the application.
Q:What do Runtime Database Record Checkpoints do?
Ans: Runtime Database Record Checkpoints enable you to check that your application inserts, deletes, updates or retrieves data in a database correctly. By mapping application controls to database fields, you can check that the values in your application are correctly read from or written to the matching database fields when you run your test.
Q:What is Startup script? What is role of Startup script?
Ans: A startup script is a test scripts that is automatically run each time we start WinRunner. We can create startup tests that load GUI map, compiled modules, configuring recording options and staring AUT.
Q: What is Function Generator and how it is used?
Ans: In Function Generator functions are grouped in categories according to the object class (list, button) or the type of function (input/output, system, file, etc).
In Function Generator we choose a function, then expand the dialog box (by pressing the Args>> button) to fill in the argument values and paste it to script.
Q:If you want to run the same script 100 times, what is the syntax? Ans: for(i=1;i<=100;i++) { TSL statements }
Q:What is a virtual object?How do you handle Virtual Objects in WinRunner?
Ans:Our applications may contain bitmaps that look and behave like GUI objects. WinRunner record operations on these objects using win_mouse_click statements. We can define these objects as virtual objects and instruct WinRunner to treat them as GUI objects when we record or run the tests. Using Virtual Object wizard we can assign a bitmap to a standard object class, define the coordinates of that object, and assign it a logical name.
Q:What are the different Checkpoints that you can insert in a WinRunner Script?
Ans: Four types of checkpoints can be added to any WinRunner script.
1. GUI Checkpoint
2. Bitmap Checkpoint
3. Database Checkpoint
4. Text Checkpoint (only for Web scripts)
Q:How do you check for the database table contents?
Ans:Using ‘Database checkpoint’
Q:How do you handle Web Exceptions?
Ans:We can instruct WinRunner to handle the appearance of specific dialog box in the web site during the test run. WinRunner contains a list of exceptions that it supports in the Web Exception Editor. We can modify the list and configure additional exceptions that we would like WinRunner to support.
Q:What is the difference between Main Test and a Compile Module file?
Ans:Main test contains the TSL script to test the AUT. Compiled module is library of frequently used functions. We can save user defined functions in compiled module and then call them in the main test scripts.
Q:How do you start client/server applications from the script?
Ans:Using following TSL function: invoke_application ( file, command_option, working_dir, show );
Q:When do you run a test in batch mode?
Ans:Batch testing is execution of a suite of test scripts towards an overall testing goal. We need to run a batch test when we want to test the overall AUT.
Win Runner Navigation
http://testingsolution.blogspot.com/2006/12/win-runner-navigation.html
Software Testing Books

Win Runner Navigation

2006-12-28T10:47:00.000+05:30

Win Runner Navigation

Using Rapid Test Script wizard

Start->Program Files->Winrunner->winruner
Select the Rapid Test Script Wizard (or) create->Rapid Test Script wizard
Click Next button of welcome to script wizard
Select hand icon and click on Application window and Cilck Next button
Select the tests and click Next button
Select Navigation controls and Click Next button
Set the Learning Flow(Express or Comprehensive) and click Learn button
Select start application YES or NO, then click Next button
Save the Startup script and GUI map files, click Next button
Save the selected tests, click Next button
Click Ok button
Script will be generated.then run the scripts.
Run->Run from top Find results of each script and select tools->text report in Winrunner test results

Using GUI-Map Configuration Tool:

Open an application.
Select Tools-GUI Map Configuration; Windows pops-up.
Click ADD button; Click on hand icon.
Click on the object, which is to be configured. A user-defined class for that object is added to list.
Select User-defined class you added and press ‘Configure’ button.
Mapped to Class;(Select a corresponding standard class from the combo box).
You can move the properties from available properties to Learned Properties. By selecting Insert button .
Select the Selector and recording methods.
Click Ok button
Now, you will observe Win runner identifying the configured objects.

Using Record-ContextSensitive mode:

Create->Record context Sensitive
Select start->program files->Accessories->Calculator
Do some action on the application.
Stop recording
Run from Top; Press ‘OK’.

Using Record-Analog Mode:

Create->Insert Function->from function generator
Function name:(select ‘invoke_application’ from combo box).
Click Args button; File: mspaint.
Click on ‘paste’ button; Click on ‘Execute’ button to open the application; Finally click on ‘Close’.
Create->Record-Analog .
Draw some picture in the paintbrush file.
Stop Recording
Run->Run from Top; Press ‘OK’.

GUI CHECK POINTS-Single Property Check:

Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
Click on’paste’ and click on’execute’ & close the window.
Create->Record Context sensitive.
Do some operations & stop recording.
Create->GUI Check Point->For single Property.
Click on some button whose property to be checked.
Click on paste.
Now close the Flight1a application; Run->Run from top.
Press ‘OK’ it displays results window.
Double click on the result statement. It shows the expected value & actual value window.

GUI CHECK POINTS-For Object/Window Property:

Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
Click on’paste’ and click on’execute’ & close the window.
Create->Record Context sensitive.
Do some operations & stop recording.
Create->GUI Check Point->Object/Window Property.
Click on some button whose property to be checked.
Click on paste.
40Now close the Flight 1a application; Run->Run from top.
Press ‘OK’ it displays results window.
Double click on the result statement. It shows the expected value & actual value window.

GUI CHECK POINTS-For Object/Window Property:

Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
Click on’paste’ and click on’execute’ & close the window.
Create->Record Context sensitive.
Do some operations & stop recording.
Create->GUI Check Point->For Multiple Object.
Click on some button whose property to be checked.
Click on Add button.
Click on few objects & Right click to quit.
Select each object & select corresponding properties to be checked for that object: click ‘OK’.
Run->Run from Top. It displys the results.

BITMAP CHECK POINT:For object/window.

Create->Insert function->Function Generator-> (Function name:Invoke_application; File :Flight 1a)
Click on’paste’ and click on’execute’ & close the window.
Create->Record Context sensitive.
Enter the Username, Password & click ‘OK’ button
Open the Order in Flight Reservation Application
Select File->Fax Order& enter Fax Number, Signature
Press ‘Cancel’ button.
Create->Stop Recording.
Then open Fax Order in Flight Reservation Application
Create->Bitmap Check->For obj.window;
Run->run from top.
The test fails and you can see the difference.

For Screen Area:

Open new Paint Brush file;
Create->Bitmapcheck point->from screen area.
Paint file pops up; select an image with cross hair pointer.
Do slight modification in the paint file(you can also run on the same paint file);
Run->Run from Top.
The test fails and you can see the difference of images.

DATABASE CHECK POINTSUsing Default check(for MS-Access only)

Create->Database Check Point->Default check
Select the Specify SQL Statement check box
Click Next button
Click Create button
Type New DSN name and Click New button
Then select a driver for which you want to set up a database & double clcik that driver
Then select Browse button and retype same DSN name and Click save button.
Click Next button & click Finish button
Select database button & set path of the your database name
Click ‘OK’ button & then Click the your DSN window ‘OK’ button
Type the SQL query in SQL box
The click Finish button Note : same process will be Custom Check Point

Runtime Record Check Point.

Repeat above 10 steps.
Type query of two related tables in SQL box Ex: select Orders.Order_Number, Flights.Flight_Number from Orders, Flights where Flight.Flight_Number=Orders.Flight_Number.
Select Finish Button
Select hand Icon button& select Order No in your Application
Click Next button.
Select hand Icon button& select Filght No in your Application
Click Next button
Select any one of the following check box 1. One match record 2. One or more match records. 3. No match record
select Finish button the script will be generated

Synchronization PointFor Obj/Win Properties:

Open start->Programs->Win Runner->Sample applications->Flight1A.
Open winrunner window
Create->RecordContext Sensitive
Insert information for new Order &click on "insert Order" button
After inserting click on "delete" button
Stop recording& save the file.
Run->Run from top: Gives your results.

Without Synchronization:

settings->General Options->Click on "Run" tab. "Timeout for checkpoints& Cs statements’ value:10000 follow 1 to 7->the test display on "Error Message" that "delete" button is disabled.

With Synchronization:

Keep Timeout value:1000 only
Go to the Test Script file, insert pointed after "Insert Order" button, press statement.
Create->Synchronization->For Obj/Window Property
Click on"Delete Order" button & select enable property; click on "paste".
It inserts the Synch statement.

For Obj/Win Bitmap:

Create-> Record Context Sensitive.
Insert information for new order & click on "Insert order" button
Stop recording & save the file.
Go to the TSL Script, just before inserting of data into "date of flight" insert pointer.
Create->Synchronization->For Obj/Win Bitmap is selected.
(Make sure Flight Reservation is empty) click on "data of flight" text box
Run->Run from Top; results are displayed. Note:(Keep "Timeout value" :1000)

Get Text: From Screen Area: (Note: Checking whether Order no is increasing when ever Order is created)

Open Flight1A; Analysis->graphs(Keep it open)
Create->get text->from screen area
Capture the No of tickets sold; right clcik &close the graph
Now , insert new order, open the graph(Analysis->graphs)
Go to Winrunner window, create->get text->from screen area
Capture the No of tickets sold and right click; close the graph
Save the script file
Add the followinf script; If(text2==text1) tl_step("text comparision",0,"updateed"); else tl_step("text comparision",1,"update property");
Run->Run from top to see the results.

Get Text: For Object/Window:

Open a "Calc" application in two windows (Assuming two are two versions)
Create->get text->for Obj/Window
Click on some button in one window
Stop recording
Repeat 1 to 4 for Capture the text of same object from another "Calc" application.
Add the following TSL(Note:Change "text" to text1 & text2 for each statement) if(text1==text2) report_msg("correct" text1); Else report_msg("incorrect" text2);
Run & see the results

Using GUI-Spy:

Using the GUI Spy, you can view and verify the properties of any GUI object on selected application

Tools->Gui Spy…
Select Spy On ( select Object or Window)
Select Hand icon Button
Point the Object or window & Press Ctrl_L + F3.
You can view and verify the properties.

Using Virtual Object Wizard:

Using the Virtual Object wizard, you can assign a bitmap to a standard object class, define the coordinates of that object, and assign it a logical name

Tools->Virtual Object Wizard.
Click Next Button
Select standard class object for the virtual object Ex: class:Push_button
Click Next button
Click Mark Object button
Drag the cursor to mark the area of the virtual object.
Click Next button
Assign the Logical Name, This name will appear in the test script when you record object.
Select Yes or No check box
Click Finish button
Go to winrunner window & Create->Start Recording.
Do some operations
Stop Recording

Using Gui Map Editor:

Using the GUI Map Editor, you can view and modify the properties of any GUI object on selected application. To modify an object’s logical name in a GUI map file

Tools->GUI Map Editor
Select Learn button
Select the Application A winrunner message box informs “do you want to learn all objects within the window” & select ‘yes’’ button.
Select perticular object and select Modify Button
Change the Logical Name& click ‘OK’ Button
Save the File

To find an object in a GUI map file:

Choose Tools > GUI Map Editor.
Choose View > GUI Files.
Choose File > Open to load the GUI map file.
Click Find. The mouse pointer turns into a pointing hand.
Click the object in the application being tested. The object is highlighted in the GUI map file.

To highlight an object in a Application:

Choose Tools > GUI Map Editor.
Choose View > GUI Files.
Choose File > Open to load the GUI map file.
Select the object in the GUI map file
Click Show. The object is highlighted in the Application.

Data Driver Wizard

Start->Programs->Wirunner->Sample applications->Flight 1A
Open Flight Reservation Application
Go to Winrunner window
Create->Start recording
Select file->new order, insert the fields; Click the Insert Order
Tools->Data Table; Enter different Customer names in one row and Tickets in another row.
Default that two column names are Noname1 and Noname2.
Tools->Data Driver Wizard
Click Next button &select the Data Table
Select Parameterize the test; select Line by Line check box
Click Next Button
Parameterize each specific values with column names of tables;Repeat for all
Final Click finish button.
Run->Run from top;
View the results.

Merge the GUI Files:

Manual Merge

Tools->Merge GUI Map Files A WinRunner message box informs you that all open GUI maps will be closed and all unsaved changes will be discarded & click ‘OK’ button.
Select the Manual Merge. Manual Merge enables you to manually add GUI objects from the source to target files.
To specify the Target GUI map file click the browse button& select GUI map file
To specify the Source GUI map file. Click the add button& select source GUI map file.
Click ‘OK’ button
GUI Map File Manual Merge Tool Opens Select Objects and move Source File to Target File
Close the GUI Map File Manual Merge Tool

Auto Merge

Tools->Merge GUI Map Files A WinRunner message box informs you that all open GUI maps will be closed and all unsaved changes will be discarded & click ‘OK’ button.
Select the Auto Merge in Merge Type. If you chose Auto Merge and the source GUI map files are merged successfully without conflicts,
To specify the Target GUI map file click the browse button& select GUI map file
To specify the Source GUI map file.
Click the add button& select source GUI map file.
Click ‘OK’ button A message confirms the merge.

Manually Retrive the Records form Database

db_connect(query1,DSN=Flight32);
db_execute_query(query1,select * from Orders,rec);
db_get_field_value(query1,#0,#0);
db_get_headers(query1, field_num,headers);
db_get_row(query1,5,row_con);
db_write_records(query1,,c:\\str.txt,TRUE,10);

Web Test Plan Development

2006-12-22T19:50:00.000+05:30

Web Test Plan Development

The objective of a test plan is to provide a roadmap so that the Web site can be evaluated through requirements or design statements. A test plan is a document that describes objectives and the scope of a Web site project. When you prepare a test plan, you should think through the process of the Web site test. The plan should be written so that it can successfully give the reader a complete picture of the Web site project and should be thorough enough to be useful. Following are some of the items that might be included in a test plan. Keep in mind thatthe items may vary depending on the Web site project.

The Web Testing Process

Internet
Web Browser
Web Server

PROJECT

Title of the project:
Date:
Prepared by:

PURPOSE OF DOCUMENT

Objective of testing: Why are you testing the application? Who, what, when, where, why, and how should be some of the questions you ask in this section of the test plan.
Overview of the application: What is the purpose of the application? What are the specifications of the project?

TEST TEAM

Responsible parties: Who is responsible and in charge of the testing?
List of test team: What are the names and titles of the people on the test team?

RISK ASSUMPTIONS

Anticipated risks: What types of risks are involved that could cause the test to fail?
Similar risks from previous releases: Have there been documented risks from previous tests that may be helpful in setting up the current test?

SCOPE OF TESTING

Possible limitations of testing: Are there any factors that may inhibit the test, such as resources and budget?

Impossible testing: What are the considerations involved that could prevent the tests that are planned?
Anticipated output: What are the anticipated outcomes of the test and have they been documented for comparison?
Anticipated input: What are the anticipated outcomes that need to be compared to the test documentation?

TEST ENVIRONMENT: Hardware:

What are the operating systems that will be used?
What is the compatibility of all the hardware being used?

Software:

What data configurations are needed to run the software?
Have all the considerations of the required interfaces to other systems been used?
Are the software and hardware compatible?

TEST DATA

Database setup requirements: Does test data need to be generated or will a specific data from production be captured and used for testing?
Setup requirements: Who will be responsible for setting up the environment and maintaining it throughout the testing process?

TEST TOOLS

Automated:Will automated tools be used?
Manual:Will manual testing be done?

DOCUMENTATION

Test cases: Are there test cases already prepared or will they need to be prepared?
Test scripts: Are there test scripts already prepared or will they need to be prepared?

PROBLEM TRACKING

Tools: What type of tools will be selected?
Processes: Who will be involved in the problem tracking process?

REPORTING REQUIREMENTS

Testing deliverables: What are the deliverables for the test?
Retests: How will the retesting reporting be documented?

PERSONNEL RESOURCES

Training:Will training be provided?
Implementation: How will training be implemented?

ADDITIONAL DOCUMENTATION

Appendix:Will samples be included?
Reference materials:Will there be a glossary, acronyms, and/or data dictionary?

Once you have written your test plan, you should address some of the following issues and questions:

Verify plan. Make sure the plan is workable, the dates are realistic, and that the plan is published. How will the test plan be implemented and what are the deliverables provided to verify the test?
Validate changes. Changes should be recorded by a problem tracking system and assigned to a developer to make revisions, retest, and sign off on changes that have been made.
Acceptance testing. Acceptance testing allows the end users to verify that the system works according to their expectation and the documentation. Certification of the Web site should be recorded and signed off by the end users, testers, and management.

Test reports. Reports should be generated and the data should be checked and validated by the test team and users.

Understanding Software Defects

2006-12-22T16:08:00.000+05:30

Understanding Software Defects

Describe 13 major categories of Software defects:

User interface errors – the system provides something that is different from Interface.
Error handling – the way the errors are recognized and treated may be in error .
Boundary-related errors – the treatment of values at the edges of their ranges may be incorrect .
Calculation errors – arithmetic and logic calculations may be incorrect .
Initial and later states – the function fails the first time it is used but not later, or Vice-versa .
Control flow errors – the choice of what is done next is not appropriate for the current state .
Errors in handling or interpreting data – passing and converting data between systems (and even separate components of the system) may introduce errors.
Race conditions – when two events could be processed, one is always accepted prior to the other and things work fine, however eventually the other event may be processed first and unexpected or incorrect results are produced.
Load conditions – as the system is pushed to maximum limits problems start to occur, e.g. arrays overflow, disks full .
Hardware – interfacing with devices may not operate correctly under certain conditions, e.g. device unavailable .
Source and version control - out-of-date programs may be used where correct revisions are available.
Documentation – the user does not observe operation described in manuals .
Testing errors – the tester makes mistakes during testing and thinks the system is behaving incorrectly.

Testing Life Cycle – Roles and Responsibilities

2006-12-22T15:20:00.000+05:30

Testing Life Cycle – Roles and Responsibilities

Clear communication protocol should be defined with in the testing team to ensure proper understanding of roles and responsibilities.
The roles chart should contain both on-site and off-shore team members.

Testing Life Cycle – Roles and Responsibilities

Test Manager

Single point contact between on site and offshore team
prepare the project plan.
Test management
Test planning
Interact with onsite lead, Client QA manager.
Team Management.
Work Allocation to the team.
Test coverage analysis.
Co-ordination with onsite for issue resolution.
Monitoring the deliverables.
Verify readiness of the product for release through release review.
Obtain customer acceptance on the deliverables
Performing risk analysis when required
Reviews and status reporting.
Authorize intermediate deliverables and patch release to customer.

Test Lead

Resolves technical issues for the product group
Provide direction to the team member.
Perform activities to the respective product group.
Review and approve of test plan.
Review test script/code.
Approve completion of the integration testing.
Conduct system/regression test.
Ensure tests are conducted as per plan.
Reports status to the offshore test manager.

Test Engineer

Development of the test cases and scripts
Test execution
Result capturing and analysis
Defects reporting and status reporting.

Testing Life Cycle – Team Structure

2006-12-22T15:13:00.000+05:30

Testing Life Cycle Team Structure

An effective testing team includes a mixture of members who has Testing expertise/Tools expertise.
Database expertise/Domain/Technology expertise.
Consultants/End users.
The testing team must be properly structured, with defined roles and responsibilities that allow the testers to perform their function with minimal overlap.
There should not be any certainty regarding which team member should perform which duties.
The test manager will be facilitating any resources required for the testing team.

Iteration Model

2006-12-22T14:07:00.001+05:30

Spiral Model

2006-12-22T14:07:00.000+05:30

Prototype Model

2006-12-22T14:02:00.000+05:30

Waterfall Model

2006-12-22T14:00:00.000+05:30

Waterfall Model

The waterfall Model is an engineering model designed to be applied to the development of software.The idea is the following: there are different stages to the development and the outputs of the First Stage "Flow" into the second stage and these outputs "flow" into the third stage and so on.there are Usually five stages in this model of software Development.

Stages of Water Fall Model

Requirement analyis and Planninng:- In This stage the requirements of the "To be developed Software" are established.These are usually the services it will provide,its constraints and Goalsof the Software.Once theae are Established they Have to be defined such a way that are usable in the next Stage.This Stage is often Preludes by a Feasibility or a Feasible study is included in this stage.the Feasibility study includes Questions like;Should we develop the Software,what are the alternatives? It could be called the conception of a software project and might be seen as the very begining of the life cycle.

V-mode of SDLC

2006-12-22T13:46:00.000+05:30

V & V PROCESS MODEL :

V&V Model is Verification & Validation Model.In This Model We work simultaneously Development and Testing.In this Model One V for Verification and one For Validation first 'V' we follow SDLC(software Development Life Cycle) and Second 'V' we follow STLC-(Software Testing Life Cycle).

Testing normally done in a large system in 2 parts. The functional verification and validation against the Requirement specification and Performance evaluation against the indicated requirements.
Testing activity is involved right from the beginning of the project.
Use of V&V process model increases the rate of success in a project development company to deliver the application on time and increases the cost effectiveness.

Testing Related Activities During Requirement Phase

Creation and finalization of testing template.
Creation of test plan and test strategy .
Capturing Acceptance criteria and preparation of acceptance test plan.
Capturing Performance Criteria of the software requirements.

Testing activities in Design Phase

Develop test cases to ensure that product is on par with Requirement Specification document.
Verify Test Cases & Test Scripts by peer reviews.
Preparation of traceability matrix from system requirements.

Testing activities in Unit Testing Phase

Unit test is done for validating the product with respect to client requirements.
Testing can be in multiple rounds.
Defects found during system test should be logged in to defect tracking system for the purpose of resolving and tracking.
Test logs and defects are captured and maintained.
Review of all test documents.

Testing activities in Integration Testing Phase

This testing is done in parallel with integration of various applications or components.
Testing the product with its external and internal interfaces without using drivers and stubs.
Incremental approach while integrating the interfaces.

Performance testing

This is done to validate the performance criteria of the product/ application. This is non-functional testing.

Business Cycle testing

This refers to end to end testing of real life like business scenarios.

Testing activities during Release phase

Acceptance testing is conducted at the customer location.
Resolves all defects reported by the customer during Acceptance testing.
Conduct Root Cause Analysis (RCA) for those defects reported by customer during acceptance testing.

Web Testing Processes In Detail

2006-12-22T13:18:00.000+05:30

Web Testing

Testing a Web site is a relatively new concept in the information technology (IT)field. Many businesses will test one part of a Web site, failing to see the importance of testing all the major components. Many businesses have not been as successful as others have because of this lack of testing; therefore, the need to test different aspects of the Web site has increased. The presence of online businesses on the World Wide Web (WWW) has become almost overwhelming. Because of this, you must test your site if you want to succeed, and to do so you need to identify the testing processes and methodologies that are most applicable to your business. Individuals can purchase just about anything on the Internet such as books, medicine, flowers, and paper supplies. To compete in this market, a Web business must be able to handle the volume, secure purchases, and deliver goods to customers. For this to happen, businesses should take Web testing seriously.

Web Testing Challenges.

http://testingsolution.blogspot.com/2006/12/web-testing-challenges.html

Web Test Plan

http://testingsolution.blogspot.com/2006/12/web-test-plan-development.html

Software Testing Life Cycle Models

2006-12-22T13:00:00.000+05:30

Software Testing Life Cycle Models

The various activities which are undertaken when developing software are commonly Modeled as a software development lifecycle. The software development lifecycle begins with the identification of a requirement for software and ends with the formal verification of the developed software against that requirement. The software development lifecycle does not exist by itself; it is in fact part of an overall Product lifecycle. Within the product lifecycle, software will undergo maintenance to correct errors and to comply with changes to requirements. The simplest overall form is Where the product is just software, but it can become much more complicated, with Multiple software developments each forming part of an overall system to comprise a Product. There are a number of different models for software development lifecycles. One thing Which all models have in common, is that at some point in the lifecycle, software has to be tested. This paper outlines some of the more commonly used software development Lifecycles, with particular emphasis on the testing activities in each model. A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationship between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the following phases of a software project: requirement phase, design phase, implemenentation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure. Life cycle models describe the inter relationship between software development phases .the common life cycle models are;

V-model
http://testingsolution.blogspot.com/2006/12/v-mode-of-sdlc.html
Waterfall Model
http://testingsolution.blogspot.com/2006/12/waterfall-model.html
Prototype Model
http://testingsolution.blogspot.com/2006/12/prototype-model.html
Spiral Model
http://testingsolution.blogspot.com/2006/12/spiral-model.html
Iteration Model
http://testingsolution.blogspot.com/2006/12/iteration-model.html

Testing Life Cycle – Team Structure

http://testingsolution.blogspot.com/2006/12/testing-life-cycle-team-structure.html

Testing Life Cycle – Roles and Responsibilities

http://testingsolution.blogspot.com/2006/12/testing-life-cycle-roles-and.html

Testing Life Cycle – Roles and Responsibilities of Test Manager

http://testingsolution.blogspot.com/2006/12/testing-life-cycle-roles-and.html

Testing Life Cycle – Roles and Responsibilities of Test Lead

http://testingsolution.blogspot.com/2006/12/testing-life-cycle-roles-and.html

Testing Life Cycle – Roles and Responsibilities of Test Engineer

http://testingsolution.blogspot.com/2006/12/testing-life-cycle-roles-and.html

Life cycle model

2006-12-16T16:08:00.000+05:30

Life cycle model A frame work containing the processes, activities, and tasks involved in the development, operation and maintenance of a product spanning the life of the system from the definition of its requirements to the termination of its use.

What is meant by Software? Software is the collection of computer programs, which includes procedures, rules and associated towards documentation of requirements.

Phases in Project Development

ØPreliminary Investigation ØFeasibility Analysis

ØRequirement Analysis ØSRS Preparation ØPlanning ØDesign ØCoding ØTesting ØImplementation & Maintenance

What is meant by Software Engineering?

Software engineering is the systematic approach to the development, operation, maintenance and retirement of software with reliable cost.

Test An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component .

Testing®

The execution of tests with the intent of providing that the system and application under test does or does not perform according to the requirements specifications.

Testing (IEEE) The process of operating a system or component under specified conditions, Observing or recording the results, and making an evaluation of some aspect of the System or component.

Testing is a process designed to :- • Prove that the program is error free • Establish that the software performs its functions correctly • Establish with confidence that the software does its job fully

GOALS OF TESTING 1. Find cases where the program does not do what it is supposed to do.

2. Find cases where the program does things it is not supposed to do.

THE EIGHT BASIC PRINCIPLES OF TESTING

1. Define the expected output or result.

2. Don't test your own programs.

3. Inspect the results of each test completely.

4. Include test cases for invalid or unexpected conditions .

5. Test the program to see if it does what it is not supposed to do as well as what it is supposed to do. 6. Avoid disposable test cases unless the program itself is disposable. 7. Do not plan tests assuming that no errors will be found. 8. The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module. Let's look at each of these pints.

Why Testing is Required?

Technical Reason Business Reasons Professional Reasons

Technical Reason: *Developers not infallible. *Requirement Implications are not always fully seen. *Behavior of system not necessarily predictable from components. *Dynamic testing can only reveal some bugs.

Business Reasons *Don’t need customer/user to find bugs. *Post release debugging is very difficult and expensive.

Professional Reasons *Test case design is challenging and rewarding. *Good testing gives confidence in work. *Systematic testing is effective.

PDCA METHOD Plan (P) Device a plan Do (D) Execute the plan Check (C) Check the results Act (A) Take the necessary action

Attitude of a Tester:

* I perform at least as well as another expert would * I deliver useful results in a usable form * I choose methods that fit the situation * I make appropriate use of available tools and resources * I collaborate effectively with the project team

* I can explain and defend my work * I can advise clients about the risks and limitations of my work * I can advise clients about how my work could be even better * I faithfully and ethically serve my clients * I become more expert over time

The Economics of Testing

* Testing involves a trade-off between COST and RISK. * Is the level of acceptable risk the same for all programs? * When is it not cost effective to continue testing? * Under what circumstances could testing guarantee that a program is correct? Costs of Errors Over the Life Cycle * The sooner an error can be found and corrected, the lower the cost. * Costs can increase exponentially with time between injection and discovery. * An industry survey showed that it is 75 times more expensive to correct errors discovered during ‘installation’’ than during ‘‘analysis’’. * One organization reported an average cost of $91 per defect found during ‘‘inspections’’ versus $25,000 per defect found after product delivery. What is 'Software Quality Assurance'? Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

Verification and Validation Concepts

2006-12-16T15:05:00.000+05:30

Verification Concepts “A Verification concept is the understanding of principles, rationale, rules, participant roles and the psychologies of various techniques used to evaluate systems during development.”

Validation Concepts “Validation typically involves actual testing and takes place after verifications are completed.”

Verification Techniques Audits • An independent assessment of a project • To verify whether or not the project is in compliance with appropriate policies, procedures, standards, contractual specifications • An audit may include operational aspects of the project Reviews and Inspections • To determine whether or not to continue development To identify defects in the product early in the life cycle

Types of Reviews 1. In-Process Reviews 2. Milestone Reviews (also called) Decision-point/Phase-end Reviews (a) Test Readiness Review (b)Test Completion Review 3. Post Implementation Reviews (also called) Post Mortem

Types of Review 1. In-Process •Assess progress towards requirements • During a specific period of the development cycle – like design period • Limited to a segment of the product • Used to find defects in the work product and the work process • Catches defects early – where they are less costly to correct.

2. Decision-point & Phase-end •Review of products and processes near the completion of each phase of development •Decisions for proceeding with development are based on cost, schedule, risk, progress, readiness for next phase •Also referred to as Milestone Review •Contains Requirements, Critical Design, Test Readiness and Phase-end Reviews

Decision-point & Phase-end Software Requirements Review •Requirements documented •Baseline established •Analysis areas identified •Software development plan •Test plan •Configuration management plan derived

Critical Design Review •Baselines the detailed design specification •Test cases are reviewed and approved •Usually, coding will begin at the close of this phase.

Test Readiness Reviews • Performed when the appropriate modules are near completion • Determines whether or not testing should progress based on a review of entrance and exit criteria • Determines the readiness of the application/project for system and acceptance testing

Test Completion Reviews • Determine the state of the software product

3.Post Implementation Reviews •Also known as “Postmortems”

• Review/evaluation of the product that includes planned vs. actual development results and compliance with requirements •Used for process improvement of software development •Can be held up to three to six months after implementation

•Conducted in a formal format

Classes of Reviews 1. Informal Review 2. Semiformal Review 3. Formal Review

Informal • Also called peer-reviews • Generally one-on-one meeting between author of a work product & Peer.

• Initiated as a request for input • No agenda • Results are not formally reported • Occur as needed through out each phase

Semiformal •Facilitated by the author •Presentation is made with comment at the end •Presentation is made with comment made throughout •Issues raised are captured and published in a report distributed to participants •Possible solutions for defects not discussed •Occur one or more times during a phase

Formal •Facilitated by a moderator (not author) •Moderator is assisted by a recorder •Defects are recorded and assigned •Meeting is planned •Materials are distributed beforehand •Participants are prepared- their preparedness dictates the effectiveness of the review •Full participation by all members of the reviewing team is required •A formal report captures issues raised and is distributed to participants and management •Defects found are tracked through the defect tracking system and followed through to resolution •Formal reviews may be held at any time

Review Rules 1.The product is reviewed, not the producer 2.Defects and issues are identified, not corrected 3. All members of the reviewing team are responsible for the results of the review

Review Notes # “Stage Containment”: identifying defects in the stage in which they were created, rather than in later testing stages. # Reviews are generally greater than 65% effective Testing is often less than 30% effective # The earlier defects are found the less expensive they are to correct In addition to learning about a specific product/project, team members are exposed to a variety of approaches to technical issues,Provides training in and enforces the use of standards.

Participant Roles Management of V & V 1. Prepare the plans for execution of the process 2. Initiate the implementation of the plan 3. Monitor the execution of the plan 4. Analyze problems discovered during the execution of the plan 5. Report progress of the processes 6. Ensure products satisfy requirements 7. Assess evaluation results 8. Determine whether a task is complete 9. Check the results for completeness

what is the use of different kind of testing when we use?

2006-12-10T16:04:00.000+05:30

What kinds of testing should be considered in Testing? When We use?

Black Box Testing -Not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
White Box Testing -Based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
Unit Testing -The most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
Incremental Integration Testing -Continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
Integration Testing -Testing of combined parts of an application to determine if they function together correctly. The 'parts' can be 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 -Black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
System Testing -Black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
End-to-End Testing -Similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Sanity Testing or Smoke Testing - Typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'same' enough condition to warrant further testing in its current state.
Regression Testing - Re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance Testing - Final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
Load Testing - 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.
Stress Testing -Term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance Testing - Term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability Testing - Testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/Uninstall Testing -Testing of full, partial, or upgrade install/uninstall processes.
Recovery Testing - Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
Failover Testing - Typically used interchangeably with 'recovery testing'
Security Testing - Testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
Compatability Testing -Testing how well software performs in a particular hardware/software/operatingsystem/network/etc. environment.
Exploratory Testing - Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
Ad-hoc Testing - Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
Context-driven Testing - Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
User Acceptance Testing - Determining if software is satisfactory to an end-user or customer.
Comparison Testing - Comparing software weaknesses and strengths to competing products.
Alpha Testing - Testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
Beta Testing - Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation Testing - A method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

Testing Written Test Question -2

2006-12-10T15:20:00.000+05:30

1 : In software quality assurance work there is no difference between software verification and software validation.
a. True
b. False
The correct answer is b
2 : The best reason for using Independent software test teams is that.
a. software developers do not need to do any testing
b. a test team will test the software more thoroughly
c. testers do not get involved with the project until testing begins
d. arguments between developers and testers are reduced
The correct answer is b
3 : What is the normal order of activities in which traditional software testing is organized?
a. integration testing b. system testing c. unit testing d.validation testing
a. a, d, c, b
b. b, d, a, c
c. c, a, d, b
d. d, b, c, a
The correct answer is c
4 : Class testing of object-oriented software is equivalent to unit testing for traditional software.
a. True
b. False
The correct answer is a
5 : By collecting software metrics and making use of existing software reliability models it is possible to develop meaningful guidelines for determining when software testing is finished.
a. True
b. False
The correct answer is a
6 : Which of the following strategic issues needs to be addressed in a successful software testing process?
a. conduct formal technical reviews prior to testing
b. specify requirements in a quantifiable manner
c. use independent test teams
d. wait till code is written prior to writing the test plan
e. both a and bThe correct answer is e
7 : Which of the following need to be assessed during unit testing?
a. algorithmic performance
b. code stability
c. error handling
d. execution paths
e. both c and d
The correct answer is e
8 : Drivers and stubs are not needed for unit testing because the modules are tested independently of one another.
a. True
b. False
The correct answer is b
9 : Top-down integration testing has as it's major advantage(s) that
a. low level modules never need testing
b. major decision points are tested early
c. no drivers need to be written
d. no stubs need to be written
e. both b and c
The correct answer is e
10 : Bottom-up integration testing has as it's major advantage(s) that
a. major decision points are tested early
b. no drivers need to be written
c. no stubs need to be written
d. regression testing is not required
The correct answer is c
11 : Regression testing should be a normal part of integration testing because as a new module is added to the system new
a. control logic is invoked
b. data flow paths are established
c. drivers require testing
d. all of the above
e. both a and b
The correct answer is e
12 : Smoke testing might best be described as
a. bulletproofing shrink-wrapped software
b. rolling integration testing
c. testing that hides implementation errors
d. unit testing for small programs
The correct answer is b
13 : When testing object-oriented software it is important to test each class operation separately as part of the unit testing process.
a. True
b. False
The correct answer is b
14 : The OO testing integration strategy involves testing
a. groups of classes that collaborate or communicate in some way
b. single operations as they are added to the evolving class implementation
c. operator programs derived from use-case scenarios
d. none of the above
The correct answer is a
15 : The focus of validation testing is to uncover places that a user will be able to observe failure of the software to conform to its requirements.
a. True
b. False
The correct answer is a
16 : Software validation is achieved through a series of tests performed by the user once the software is deployed in his or her work environment.
a. True
b. False
The correct answer is b
17 : Configuration reviews are not needed if regression testing has been rigorously applied during software integration.
a. True
b. False
The correct answer is b
18 : Acceptance tests are normally conducted by the
a. developer
b. end users
c. test team
d. systems engineers
The correct answer is b
19 : Recovery testing is a system test that forces the software to fail in a variety of ways and verifies that software is able to continue execution without interruption.
a. True
b. False
The correct answer is b
20 : Security testing attempts to verify that protection mechanisms built into a system protect it from improper penetration.
a. True
b. FalseThe correct answer is a
21 : Stress testing examines the pressures placed on the user during system use in extreme environments.
a. True
b. False
The correct answer is b
22 : Performance testing is only important for real-time or embedded systems.
a. True
b. False
The correct answer is b
23 : Debugging is not testing, but always occurs as a consequence of testing.
a. True
b. False
The correct answer is a
24 : Which of the following is an approach to debugging?
a. backtracking
b. brute force
c. cause elimination
d. code restructuring
e. a, b, and c
Your answer is d

What is Software Testing?

2006-12-06T13:12:00.000+05:30

What is Software Testing? 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 the terms verification and validation.Verification 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 is the process of checking that what has been specified is what the user actually wanted. •Validation: Are we doing the right job? •Verification: Are we doing the job right? 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. Software testing should not be confused with debugging. Debugging is the process of analyzing and locating bugs when software does not behave as expected. Although the identification of some bugs will be obvious from playing with the software, a methodical approach to software testing is a much more thorough means of identifying bugs. Debugging is therefore an activity which supports testing, but cannot replace testing. However, no amount of testing can be guaranteed to discover all bugs.

Other activities which are often associated with software testing are static analysis and dynamic analysis. Static analysis investigates the source code of software, looking for problems and gathering metrics without actually executing the code. Dynamic analysis looks at the behavior of software while it is executing, to provide information such as execution traces, timing profiles, and test coverage information.

2. Software Specifications and Testing The key component of the above definitions is the word specified. Validation and Verification activities, such as software testing, cannot be meaningful unless there is a Specification for the software. Software could be a single module or unit of code, or an entire system. Depending on the size of the development and the development methods, specification of software can range from a single document to a complex hierarchy of documents. A hierarchy of software specifications will typically contain three or more levels of software specification documents. •The Requirements Specification, which specifies what the software is required to do and may also specify constraints on how this may be achieved. •The Architectural Design Specification, which describes the architecture of a design which implements the requirements. Components within the software and the relationship between them will be described in this document. •Detailed Design Specifications, which describe how each component in the software, down to individual units, is to be implemented. Requirements Specification Architectural Design Specification Detailed Design Specification With such a hierarchy of specifications, it is possible to test software at various stages of the development, for conformance with each specification. The levels of testing which correspond to the hierarchy of software specifications listed above are: •Unit Testing, in which each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. •Software Integration Testing, in which progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a whole. •System Testing, in which the software is integrated to the overall product and tested to Show that all requirements are met. A further level of testing is also concerned with requirements: •Acceptance Testing, upon which acceptance of the completed software is based. This Will often use a subset of the system tests, witnessed by the customers for the software Or system. Once each level of software specification has been written, the next step is to design the tests. An important point here is that the tests should be designed before the software is implemented, because if the software was implemented first it would be too tempting to test the software against what it is observed to do (which is not really testing at all), rather than against what it is specified to do. Within each level of testing, once the tests have been applied, test results are evaluated. If a problem is encountered, then either the tests are revised and applied again, or the software is fixed and the tests applied again. This is repeated until no problems are encountered, at which point development can proceed to the next level of testing.

Testing does not end following the conclusion of acceptance testing. Software has to be maintained to fix problems which show up during use and to accommodate new requirements. Software tests have to be repeated, modified and extended. The effort to revise and repeat tests consequently forms a major part of the overall cost of developing and maintaining software. The term regression testing is used to refer to the repetition of earlier successful tests in order to make sure that changes to the software have not introduced side effects.

3. Test Design Documentation The design of tests is subject to the same basic engineering principles as the design of software. Good design consists of a number of stages which progressively elaborate the design of tests from an initial high level strategy to detailed test procedures. These stages are: test strategy, test planning, test case design, and test procedure design. The design of tests has to be driven by the specification of the software. At the highest level this means that tests will be designed to verify that the software faithfully implements the requirements of the Requirements Specification. At lower levels tests will be designed toverify that items of software implement all design decisions made in the Architectural Design Specification and Detailed Design Specifications. As with any design process, each stage of the test design process should be subject to informal and formal review. The ease with which tests can be designed is highly dependant on the design of the software. It is important to consider testability as a key (but usually undocumented) requirement for any software development.

3.1. Test Strategy The first stage is the formulation of a test strategy. A test strategy is a statement of the Overall approach to testing, identifying what levels of testing are to be applied and the Methods, techniques and tools to be used. A test strategy should ideally be organization Wide, being applicable to all of organizations software developments. Developing a test strategy which efficiently meets the needs of an organization is critical to the success of software development within the organization. The application of a test Strategy to a software development project should be detailed in the projects software . Quality plan. 3.2. Test Plans The next stage of test design, which is the first stage within a software development project, is the development of a test plan. A test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied to the testing of each item, and describes the test environment. A test plan may be project wide, or may in fact be a hierarchy of plans relating to the Various levels of specification and testing: •An Acceptance Test Plan, describing the plan for acceptance testing of the software. This would usually be published as a separate document, but might be published with the System test plan as a single document. •A System Test Plan, describing the plan for system integration and testing. This would also usually be published as a separate document, but might be published with the acceptance test plan. •A Software Integration Test Plan, describing the plan for integration of tested software components. This may form part of the Architectural Design Specification. •Unit Test Plan(s), describing the plans for testing of individual units of software. Thesemay form part of the Detailed Design Specifications. The objective of each test plan is to provide a plan for verification, by testing the software, that the software produced fulfils the requirements or design statements of the appropriate software specification. In the case of acceptance testing and system testing, this means the Requirements Specification. 3.3. Test Case Design Once the test plan for a level of testing has been written, the next stage of test design is to specify a set of test cases or test paths for each item to be tested at that level. A number of test cases will be identified for each item to be tested at each level of testing. Each test case will specify how the implementation of a particular requirement or design decision is to be tested and the criteria for success of the test. The test cases may be documented with the test plan, as a section of software specification, or in a separate document called a test specification or test description. •An Acceptance Test Specification, specifying the test cases for acceptance testing of the software. This would usually be published as a separate document, but might be published with the acceptance test plan. •A System Test Specification, specifying the test cases for system integration and Testing. This would also usually be published as a separate document, but might be Published with the system test plan. •Software Integration Test Specifications, specifying the test cases for each stage of Integration of tested software components. These may form sections of the Architectural Design Specification. •Unit Test Specifications, specifying the test cases for testing of individual units of Software. These may form sections of the Detailed Design Specifications. System testing and acceptance testing involve an enormous number of individual test cases.

In order to keep track of which requirements are tested by which test cases, an index which cross references between requirements and test cases often constructed. This is usually referred to as a Verification Cross Reference Index (VCRI) and is attached to the test specification. Cross reference indexes may also be used with unit testing and software integration testing. It is important to design test cases for both positive testing and negative testing. Positive testing checks that the software does what it should. Negative testing checks that the software doesn't do what it shouldn't. The process of designing test cases, including executing them as thought experiments, will often identify bugs before the software has even been built. It is not uncommon to find more bugs when designing tests than when executing tests.

3.4. Test Procedures The final stage of test design is to implement a set of test cases as a test procedure, Specifying the exact process to be followed to conduct each of the test cases. This is a fairly straight forward process, which can be likened to designing units of code from higher level functional descriptions. For each item to be tested, at each level of testing, a test procedure will specify the process to be followed in conducting the appropriate test cases. A test procedure cannot leave out steps or make assumptions. The level of detail must be such that the test procedure is deterministic and repeatable. Test procedures should always be separate items, because they contain a great deal of detail which is irrelevant to software specifications. If AdaTEST or Cantata are used, test procedures may be coded directly as AdaTEST or Cantata test scripts.

4. Test Results Documentation When tests are executed, the outputs of each test execution should be recorded in a test Results file. These results are then assessed against criteria in the test specification to determine the overall outcome of a test. If AdaTEST or Cantata is used, this file will be Created and the results assessed automatically according to criteria specified in the test Script. Each test execution should also be noted in a test log. The test log will contain records of When each test has been executed, the outcome of each test execution, and may also include key observations made during test execution. Often a test log is not maintained for lower levels of testing (unit test and software integration test). Test reports may be produced at various points during the testing process. A test report Will summaries the results of testing and document any analysis. An acceptance test report often forms a contractual document within which acceptance of software is agreed.

5. Further Results and Conclusion Software can be tested at various stages of the development and with various degrees of Rigors. Like any development activity, testing consumes effort and effort costs money. Developers should plan for between 30% and 70% of a projects effort to be expended on Verification and validation activities, including software testing. From an economics point of view, the level of testing appropriate to a particular Organization and software application will depend on the potential consequences of Undetected bugs. Such consequences can range from a minor inconvenience of having to Find a work-round for a bug to multiple deaths. Often overlooked by software developers (but not by customers), is the long term damage to the credibility of an organization which delivers software to users with bugs in it, and the resulting negative impact on future business. Conversely, a reputation for reliable software will help an organization to obtain future business. Efficiency and quality are best served by testing software as early in the life cycle as Practical, with full regression testing whenever changes are made. The later a bug is found, the higher the cost of fixing it, so it is sound economics to identify and fix bugs as early as possible. Designing tests will help to identify bugs, even before the tests are executed, so designing tests as early as practical in software development is a useful means of reducing the cost of identifying and correcting bugs. In practice the design of each level of software testing will be developed through a number of layers, each adding more detail to the tests. Each level of tests should be designed before the implementation reaches a point which could influence the design of tests in such a way as to be detrimental to the objectivity of the tests. Remember: software should be tested against what it is specified to do, not against what it actually observed to do. The effectiveness of testing effort can be maximized by selection of an appropriate testing strategy, good management of the testing process, and appropriate use of tools such as AdaTEST or Cantata to support the testing process. The net result will be an increase in quality and a decrease in costs, both of which can only be beneficial to a software developers business. The following list provides some rules to follow as an aid to effective and beneficial Software testing. •Always test against a specification. If tests are not developed from a specification, Then it is not testing. Hence, testing is totally reliant upon adequate specification of Software. •Document the testing process: specify tests and record test results. •Test hierarchically against each level of specification. Finding more errors earlier will Ultimately reduce costs. •Plan verification and validation activities, particularly testing. •Complement testing with techniques such as static analysis and dynamic analysis. •Always test positively: that the software does what it should, but also negatively: that it Doesn’t do what it shouldn't. •Have the right attitude to testing - it should be a challenge, not the chore it so often Becomes.

BUG LIFE CYCLE

2006-12-06T12:20:00.000+05:30

BUG: Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT).

Bug Life Cycle: In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:

The different states of a bug can be summarized as follows: 1. New 2. Open 3. Assign 4. Test 5. Verified 6. Deferred 7. Reopened 8. Duplicate 9. Rejected 10. Closed

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved

Guidelines on deciding the Severity of Bug: Indicate the impact each defect has on testing efforts or users and administrators of the application under test. This information is used by developers and management as the basis for assigning priority of work on defects. A sample guideline for assignment of Priority Levels during the product test phase includes: Critical / Show Stopper — An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test. Major / High — A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc. Average / Medium — The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points. Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

What should be done after a bug is found? The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available. The following are items to consider in the tracking process:

Ø Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
Ø Bug identifier (number, ID, etc.)
Ø Current bug status (e.g., 'Released for Retest', 'New', etc.)
Ø The application name or identifier and version
Ø The function, module, feature, object, screen, etc. where the bug occurred
Ø Environment specifics, system, platform, relevant hardware specifics
Ø Test case name/number/identifier
Ø One-line bug description
Ø Full bug description
Ø Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
Ø Names and/or descriptions of file/data/messages/etc. used in test
Ø File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
Ø Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
Ø Was the bug reproducible?
Ø Tester name
Ø Test date
Ø Bug reporting date
Ø Name of developer/group/organization the problem is assigned to
Ø Description of problem cause
Ø Description of fix
Ø Code section/file/module/class/method that was fixed
Ø Date of fix
Ø Application version that contains the fix
Ø Tester responsible for retest
Ø Retest date
Ø Retest results
Ø Regression testing requirements
Ø Tester responsible for regression tests
Ø Regression testing results

Automation Testing- Win Runner

2006-12-05T17:29:00.000+05:30

Testing Automation: Software testing can be very costly. Automation is a good way to cut down time and cost. Software testing tools and techniques usually suffer from a lack of generic applicability and scalability. The reason is straight-forward. In order to automate the process, we have to have some ways to generate oracles from the specification, and generate test cases to test the target software against the oracles to decide their correctness. Today we still don't have a full-scale system that has achieved this goal. In general, significant amount of human intervention is still needed in testing. The degree of automation remains at the automated test script level.There are Many automation Testiing Tool For Functional & Regression Testing,Performance Testing, Bug Tracking and Test Management Tool.

What are the Advantages of Automation in testing?

1. Fast
2. Reliable
3. Repeatable
4. Programmable
5. Comprehensive
6. Reusable

Win Runner: Win Runner is a Functional & Regression Testing Tool of Mercury.

Win Runner:
ØNeed For Automation
ØWinRunner Introduction
ØWinRunner Basic Session / Examples
ØWinRunner Advanced Session / Examples

Few Reasons

Running test manually is boring and frustrating
Eliminates human error
Write once, run as many times as needed
Provides increased testing coverage
Allows testers to focus on verifying new rather than existing functionality
Creates tests that can be maintained and reused throughout the application life cycle

WinRunner is functional testing tool

Specifically a regression test tool
Help in creating reusable and adaptable script
Used for automating testing process
Need to write scripts in TSL for the same
Help in detecting early defects before regression Testing
Specifically a regression test tool
Help in creating reusable and adaptable script
Used for automating testing process
Need to write scripts in TSL for the same
Help in detecting early defects before regression testing

Test Plan Documenting System

Test Plan Design
Test Case Design
Test Script Creation - Manual & Automated

Test Execution Management

Scenario Creation
Test Runs

Analysis of Results

Reports & Graphs

Defect Tracking System WinRunner Testing Process

ØCreate GUI map
ØCreate tests
ØDebug tests
ØRun tests
ØExamine results
ØReport defects

Testing Process of Win Runner in Detail WinRunner testing process involves six main stages .

Create GUI Map File : So that WinRunner can recognize the GUI objects in the application being tested
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.
Debug Test: run tests in Debug mode to make sure they run smoothly
Run Tests: run tests in Verify mode to test your application.
View Results: determines the success or failure of the tests.
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.

WinRunner Testing Modes Context Sensitive

Records the actions on the AUT in terms of GUI objects.
Ignores the physical location of the object on the screen

Analog

Records mouse clicks, keyboard input, and the exact x- and y-coordinates traveled by the mouse

Types of GUI Map files

GUI Map File per Test mode

Separate GUI Map File for each test

Global GUI Map File mode

Single GUI Map File for a group of tests

Different modes for running the tests

1.Verify
2.Debug
3.Update

Checkpoints

ØGUI Checkpoint
ØBitmap Checkpoint
ØDatabase Checkpoint
ØSynchronization point

GUI Checkpoint

ØA GUI checkpoint examines the behavior of an object’s properties
ØDuring execution, the current state of the GUI objects is compared to the expected results

Bitmap Checkpoint

ØCompares captured bitmap images pixel by pixel
ØWhen running a test that includes bitmap checkpoints, make sure that the screen display settings are the same as when the test script was created. If the screen settings are different, WinRunner will report a bitmap mismatch .

Database Checkpoint

ØA query is defined on the database and the database checkpoint checks the values contained in the result set
ØResult set is a set of values retrieved from the results of the query
ØWays to define the query
(a) Microsoft query
(b) ODBC query
(c) Data junction

Synchronization point

ØWhen you run tests, your application may not always respond to input with the same speed
ØInsert a synchronization point into the test script at the exact point where the problem occurs
ØA synchronization point tells WinRunner to pause the test run in order to wait for a specified response in the application

Using Regular Expressions

ØEnables WR to identify objects with varying names or titles
ØCan be used in
An object’s physical descriptions in the GUI map
GUI Checkpoint
Text Checkpoint

Virtual Objects:

ØCan teach WinRunner to recognize any bitmap in a window as a GUI object
ØMake test scripts easier to read and understand

Creating Data-Driven Tests:

ØTo test how the AUT performs with multiple sets of data
ØCan be done using the..
•Data Driver Wizard
Add command manually in script

Advantage of Data-Driven Tests:

ØRun the same test with different data
ØTest the AUT for both, positive and negative results
ØExpandable
ØEasy to maintain

Manual Data-Driven Test

Win Runner Related Some Question Answers
http://testingsolution.blogspot.com/2006/12/win-runner-related-some-questions.html
Win Runner Navigation
http://testingsolution.blogspot.com/2006/12/win-runner-navigation.html

Web Application Testing

2006-12-04T17:40:00.000+05:30

Web Application Testing: Test a Web Based Application , in Web Testing We Consider Many Testing.Web Testing We Test Each and Every Aspect.

http://testingsolution.blogspot.com/2006/12/web-testing-challenges.html

Short release cycle
Constantly Changing Technology
Possibility Of huge number of users
Inability to control user’s running environment
24hour availability of the website

Functionality Testing: It involves making sure that all the features that most affect the user interactions works properly.

These features may include
Forms in the page .
Searches present in the page.
Pop-up windows (client side and server side) .
Any online transactions available.

Usability Testing:

Identify the websites purpose.
Identify the intended users.
Whether the user completes the task successfully.
How much time the user needs to complete the task.
Number of pages accessed to complete the task.
At which place in the application the user can .
possibly make mistakes.
How the user seeks assistance when lost.
Whether the online information provides enough help.
How possibly a user can react for the specific
download time of the page.
Point at which the user gets confused and even fail to complete a task.
Number of clicks between tasks, number of seconds between clicks as well as number of clicks, as well as number of pages browsed.
Whether the user felt successful in using site.
Feedback on navigation and other features of the sites.
Whether the user would recommend this product to friends.
Whether the user understood the terminology.
Ideas for improvement
What the user liked or disliked about the website, and why.

Navigation Testing :

Ø Easy and quick access to the information.
Ø Logical hierarchy of the pages.
Ø Conformation of the page to tell the user about where they are at any point.
Ø Facility to return to previous state or the home page.
Ø Consistent look and lay out of every page.
Ø Moving to and from pages .
Ø Scrolling through the pages .
Ø Clicking on images and thumbnails to make sure they work.
Ø Testing all the links (both internal and external) .
Ø Ensuring no broken links exists.
Ø Proper lay out under different browsers.
Ø Measuring load time of every page.
Ø Compatibility and usage of buttons, key board shortcuts and mouse actions.

Form Testing:

Ø Using tab key the form traverses fields in the proper order, both forward and backward.
Ø Testing boundary values for the data input.
Ø Checking that the form is capable of trapping invalid data correctly. (Specially date and numeric formats)
Ø The form is capable of updating the information correctly.
Ø Tool tip text messages displayed for the form are proper and not misleading.
Ø Objects are aligned in the form properly, and the labels displayed are not misleading.

Page Content Testing :

Ø All the images and the graphics are displayed correctly.
Ø All contents are present as per the requirements.
Ø Page structures are consistent across the browsers.
Ø Critical pages contain same contents across browsers.
Ø All parts of the table or form are present in the right place and in the right order.
Ø Links to the relevant contents inside or out of the page are appropriate.
Ø Web pages are visually appealing.
Ø Checking the vital information’s present in the page are not changing across different builds.

Configuration and Compatibility Testing:

ØIs the user behind firewall?
ØDoes the user connect to the application server through a load balance.
ØDoes the browser accepts cookies?
ØAre high security settings enabled?
ØWhat technologies are the developers of the WebPages using?
ØAre secure blocking tools being used?

Performance Testing:

ØHigh activity volume at launch.
ØTime of day .
ØActivity spikes due to marketing promotions .
ØBottleneck due to hundreds of users on a network.
ØDownload time .
ØUsage patterns .
ØThink time .
ØUser arrival rates .
ØClient platforms .
ØInternet access speed .
ØAbandonment rates .

Load Testing:

Strategy:
•Understand the load requirements
•Number of user hits per day/week/month
•Total concurrent users (worst-case scenario)
•Peak request rates (Number of pages served per second)
•Identify the tools and their limitations.
•Generate enough users and transactions to access capacity.
•Create a base line criterion.
•Check the system behavior in multiple sessions.
•Identify any other application probably running on the client
•system or server.
•Execute the test multiple times.

Security Testing:

ØWhat precautions exist to prevent or limit attacks from users?
ØAre the browser settings set to ensure maximum security protections?
ØHow does the website handle access rights?
ØDoes the application has a virus detection mechanism?
ØDoes the application handle transaction tempering?
ØDoes the e-commerce vendor provide a mechanism to prevent
Øcredit card frauds?
ØHow does the website encrypt data transfer mechanism?
ØHow does the web site authenticate users?
ØDoes viewing the source code disclose any vital information?
ØHow safe is the credit card or user information?
ØDoes the application allow for a file to be digitally signed?

Testing Written Test Questions

2006-12-04T17:09:00.000+05:30

1 : With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.
a. True b. False
The correct answer is b
2 : Which of the following are characteristics of testable software?
a. observability b. simplicity c. stability d. all of the above
The correct answer is d
3 : The testing technique that requires devising test cases to demonstrate that each program function is operational is called
a. black-box testing
b. glass-box testing
c. grey-box testing
d. white-box testing
The correct answer is a
4 : The testing technique that requires devising test cases to exercise the internal logic of a software module is called
a. behavioral testing
b. black-box testing
c. grey-box testing d. white-box testing
The correct answer is d
5 : What types of errors are missed by black-box testing and can be uncovered by white-box testing?
a. behavioral errors
b. logic errors
c. performance errors
d. typographical errors
e. both b and d
The correct answer is e
6 : Program flow graphs are identical to program flowcharts.
a. True b. False
The correct answer is b
7 : The cyclomatic complexity metric provides the designer with information regarding
the number of
a. cycles in the program
b. errors in the program
c. independent logic paths in the program
d. statements in the programThe correct answer is c
8 : The cyclomatic complexity of a program can be computed directly from a PDL
representation of an algorithm without drawing a program flow graph.
a. True b. False
The correct answer is a
9 : Condition testing is a control structure testing technique where the criteria used to
design test cases is that they
a. rely on basis path testing
b. exercise the logical conditions in a program module
c. select test paths based on the locations and uses of variables
d. focus on testing the validity of loop constructs
The correct answer is b
10 : Data flow testing is a control structure testing technique where the criteria used to
design test cases is that they
a. rely on basis path testing
b. exercise the logical conditions in a program module
c. select test paths based on the locations and uses of variables
d. focus on testing the validity of loop constructs
The correct answer is c
11 : Loop testing is a control structure testing technique where the criteria used to design
test cases is that they
a. rely basis path testing
b. exercise the logical conditions in a program module
c. select test paths based on the locations and uses of variables
d. focus on testing the validity of loop constructs
The correct answer is d
12 : Black-box testing attempts to find errors in which of the following categories
a. incorrect or missing functions
b. interface errors
c. performance errors
d. all of the above
e. none of the above
The correct answer is d
13 : Graph-based testing methods can only be used for object-oriented systems
a. True b. False
The correct answer is b
14 : Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.
a. True b. False
The correct answer is a
15 : Boundary value analysis can only be used to do white-box testing.
a. True b. False
The correct answer is b
16 : Comparison testing is typically done to test two competing products as part of customer market analysis prior to product release.
a. True b. False
The correct answer is b
17 : Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.
a. True b. False
The correct answer is a
18 : Test case design "in the small" for OO software is driven by the algorithmic detail of
the individual operations.
a. True b. False
The correct answer is a
19 : Encapsulation of attributes and operations inside objects makes it easy to obtain object state information during testing.
a. True b. False
The correct answer is b
20 : Use-cases can provide useful input into the design of black-box and state-based tests
of OO software.
a. True b. False
The correct answer is a
21 : Fault-based testing is best reserved for
a. conventional software testing
b. operations and classes that are critical or suspect
c. use-case validation
d. white-box testing of operator algorithms
The correct answer is b
22 : Testing OO class operations is made more difficult by
a. encapsulation b. inheritance c. polymorphism d. both b and c
The correct answer is d
23 : Scenario-based testing
a. concentrates on actor and software interaction
b. misses errors in specifications
c. misses errors in subsystem interactions
d. both a and b
The correct answer is a
24 : Deep structure testing is not designed to
a. examine object behaviors
b. exercise communication mechanisms
c. exercise object dependencies
d. exercise structure observable by the user
The correct answer is d
25 : Random order tests are conducted to exercise different class instance life histories.
a. True b. False
The correct answer is a
26 : Which of these techniques is not useful for partition testing at the class level
a. attribute-based partitioning
b. category-based partitioning
c. equivalence class partitioning
d. state-based partitioning
The correct answer is c
27 : Multiple class testing is too complex to be tested using random test cases.
a. True b. False
The correct answer is b
28 : Tests derived from behavioral class models should be based on the a. data flow
diagram
b. object-relation diagram
c. state diagram
d. use-case diagram
The correct answer is c
29 : Client/server architectures cannot be properly tested because network load is highly
variable.
a. True b. False
The correct answer is b
30 : Real-time applications add a new and potentially difficult element to the testing mix
a. performance b. reliability c. security d. time
The correct answer is d

Question Answers

2006-12-03T20:26:00.001+05:30

1.What is Software Testing?
Ans- To validate the software against the requirement.
2. What is the Purpose of Testing?
Ans- To check whether system is meeting requirement.
3. What types of testing do testers perform?
Ans- Black Box
4. What is the Outcome of Testing?
Ans- System which is bug free and meet the system requirements.
5. What kind of testing have you done?
Ans- Black Box
6. What is the need for testing?
Ans- To Make error Free Product and Reduce Development Cost.
7. What are the entry criteria for Functionality and Performance testing?
Ans- Functional: should have stable functionality code Performance- After system testing
8. What is test metrics?
Ans- Contains how many test cases we have executed, which again contain how many pass, fail and can not be executed.
9. Why do you go for White box testing, when Black box testing is available?
Ans- To check code, branches and loops in code
10. What are the entry criteria for Automation testing?
Ans- Should have stable code.
11. When to start and Stop Testing?
Ans-When system meets the requirement and there is no change in functionality.
12. What is Quality?
Ans- Consists of two QA and QC.Customer point of View Fit for use and Meets User Requirement is Quality.
13. What is Baseline document, Can you say any two?
Ans- Document which is standard like test plan format, checklist for system testing .
13. What is Baseline document, Can you say any two?
Ans- Document which is standard like test plan format, checklist for system testing
14. What is verification?
Ans- To review the document.
15. What is validation?
Ans- To validate the system against the requirements.
16. What is quality assurance?
Ans – Bug presentation activity is called QA.
17. What is quality control?
Ans- Bug dictation activity is called QC.
18. What is SDLC and TDLC?
Ans- SDLC- Software Development Life Cycle and Testing is a part of it. TDLC-Test Development Life Cycle.
19. What are the Qualities of a Tester?
Ans- Should have ability of find out hidden bug as early as possible in SDLC.
20. When to start and Stop Testing?
Ans- Start- At the time of requirement gathering, When Meets Requirements.
21. What are the various levels of testing?
ans- Unit,Integration,System and Acceptance testing.
22. What are the types of testing you know and you experienced?
Ans- Black Box, Functional Testing, system testing, gui testing etc
23. After completing testing, what would you deliver to the client?
Ans- Testware
24. What is a Test Bed?
Ans- Test Data is called test bad.
25. What is a Data Guidelines?
Ans- Guidelines which are to be followed for the preparation of test data.
26. Why do you go for Test Bed?
Ans- To validate the system against the required input.
27. What is Severity and Priority and who will decide what?
Ans- Severity- how much severe is bug for application like critical Priority- How much urgency of functionality in which bug occur.
28. Can Automation testing replace manual testing? If it so, how?
Ans- Yes, if there are many modifications in functionality and it is near impossible to update the automated scripts.
29. What is a test condition?
Ans: logical input data against which we validate the system.
30. What is the test data?
Ans- input data against which we validate the system.
31. What is an Inconsistent bug?
Ans-Bug which are not reproducible
32. What is the difference between Re-testing and Regression testing?
Ans- Regression- Check that change in code have not effected the working functionality
Retesting- Again testing the functionality of the application.

Software Testing Books

Test Case

2006-12-03T20:03:00.000+05:30

Test Case : Test case is a document that describes an input, action or event and an expected response to determine if a feature of an application is working correctly and meets the user requirements.A Good test case is the one that has high probability of finding as yet undiscovered error.
The Test case document contains the following fields:
Test case id : This is an id given to every test case and it should be unique.
Test case decription : This field contains the brief description of what we are going to test in that application.
Test input : This contains the input that we are going to give to test the application or system.
Test Action : This field explains the action to be performed to execute the test case.
Expected results : This fielsd contains the description of what tester should see after all test steps has been completed.
Actual results : This field contains a brief description of what the tester saw after the test steps has been completed.
Result:This is often replaced with either pass or fail. If both the expected result and actual result are same then the result is pass else the result is fail.

Test Plan Contents

2006-12-03T19:38:00.000+05:30

Contents of test plan: Introduction: This section contains the purpose and objectives of the test plan. Scope (A)Items to be tested :Refer to the functional requirements that specify the features and functions to be tested. (B)Items not to be Tested:List the features and functions that will not be covered in this test plan. Identify briefly the reasons for leaving them out.

Test Strategy :Testing is the process of analyzing a software item to detect the differencesbetween existing and required conditions and to evaluate the features of thesoftware item. This may appear as a specific document (such as a TestSpecification), or it may be part of the organization's standard test approach. Foreach level of testing, there should be a test plan and an appropriate set ofdeliverables. The test strategy should be clearly defined and the Software TestPlan acts as the high-level test plan.

Environment Requirements:

(a) System Requirements This section should be filled out in detail for new projects. For existing maintenance tasks, a simple cross-reference to the document describing existing system requirements is fine.

(B)Hardware/ software requirements : This section contains the details of system/server required to install the application or perform the testing, specific s/w that needs to be installed on the system to get the application running or to connect to the database, connectivity related issues etc.

Test Schedule: Identify the estimated effort required to execute the test plan. Include a both a range and a confidence level. Identify the resources available to carry out the test plan.Identify time or resource constraints that will lead to a risk of the test project falling behind schedule, below expected scope, or below expected quality.

Resources and Responsibilities: This section will explain the roles and responsibilites of the management team, testing team, Business team, testing support team and external support team.

Deliverables: This section contains various deliverables that are due to the client at various points of time. i.e. daily, weekly, start of project, end of project etc. these could include test plans, test procedures, test matrices, status reports, test scripts etc. templates for all these also be attached.

Suspension / Exit Criteria : This is a particular risk clause to define under what circumstances testing would stop and restart If any defects are found which seriously impact the test progress, the QA manager may choose to Suspend testing.

Criteria that will justify test suspension are:

(I) Hardware/software is not available at the times indicated in the project schedule.

(II) Source code contains one or more critical defects, which seriously prevents or limits testing progress.

(III)Assigned test resources are not available when needed by the test team.

Risks : Define in advance what could go wrong with a plan and the measures that will be taken to deal with these problems.

(A) The event causing the risk.

(B) The likelihood of the event happening.

ToolsApart from manual testing list the tools used for automating the unit testing, functional testing, performance testing and user interface testing.

Documentation:This section contains the embedded documents or links to document which have been/will be used in the course of testing. E.g. Templates used for reports, test cases etc. reference documents can also be attached here.

Approvals: This section contains the mutual agreement between the client and QA team with both leads/ managers signing off their agreement on the test plan.

Testing Process

2006-12-03T19:21:00.000+05:30

The steps in the testing process are as follows.
1. Requirement analysisTesting should begin in the requirements phase of the software life cycle (SDLC). The actual requirement should be understand clearly with the help of Requirement Specification documents, Functional Specification documents, Design Specification documents, Use case Documents etc.
During the requirement analysis the following should be considered.-Are the definitions and descriptions of the required capabilities precise? -Is there clear delineation between the system and its environment?-Can the requirements be realized in practice?-Can the requirements be tested effectively?
2. Test PlanningDuring this phase Test Strategy, Test Plan, Test Bed will be created.A test plan is a systematic approach in testing a system or software. The plan should identify:-Which aspects of the system should be tested?-Criteria for success.-The methods and techniques to be used.-Personnel responsible for the testing.-Different Test phase and Test Methodologies-Manual and Automation Testing-Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc-Evaluation & identification – Test, Defect tracking tools
3. Test Environment SetupDuring this phase the required environment will be setup will be done. The following should also be taken in account.- Network connectivity’s-All the Software/ tools Installation and configuration-Coordination with Vendors and others
4. Test DesignDuring this phase-Test Scenarios will be identified.-Test Cases will be prepared.-Test data and Test scripts prepared.-Test case reviews will be conducted.
5. Test AutomationIn this phase the requirement for the automation will be identified. The tools that are to be used will be identified. Designing framework, scripting, script integration, Review and approval will be undertaken in this phase.
6. Test Execution and Defect Tracking Testers execute the software based on the plans and tests and report any errors found to the development team. In this phase
-Test cases will be executed.-Test Scripts will be tested.-Test Results will be analyzed.-Raised the defects and tracking for its closure.
7. Test Reports Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.
-Test summary reports will be prepared-Test Metrics and process Improvements made-Build release-Receiving acceptance

Software Development Life Cycle

2006-12-03T19:17:00.000+05:30

SDLC: The software development life cycle (SDLC) is the entire process of formal, logical steps taken to develop a software product. Software development is the process of developing software through successive phases in an orderly way. This process includes not only the actual writing of code but also the preparation of requirements and objectives, the design of what is to be coded, and confirmation that what is developed has met objectives.

The software development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Typical phases of software development:

1) Requirement Analysis 2) Software design 3) Development or Coding 4) Testing 5) Maintenance

Requirement Analysis: The new system requirements are defined. The requirements of a desired software product are extracted. Based the business scenario the SRS (Software Requirement Specification) document is prepared in this phase. The purpose of this document is to specify the functional requirements of the software that will be produced by the SOS project group. The specifications are intended to guide the group through the development process.

Design: Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues for the software. Design phase is concerned with making sure the software system will meet the requirements of the product. It should also ensure that the future requirements will also be addressed.. Development (or) Coding: Programs are developed by the developers with the help of the design. The design is reduced to code by the software engineers. Testing: Testing is evaluating the software to check for the user requirements. Here the software is evaluated with intent of finding defects. Maintenance: Once the new system is up and running for awhile, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

Testing Technique

2006-12-03T19:06:00.000+05:30

Testing Techniques

Black Box Testing -Testing of a function without knowing internal structure of the program.
White Box Testing -Testing of a function with knowing internal structure of the program.
Regression Testing -To ensure that the code changes have not had an adverse affect to the other modules or on existing functions.
Functional Testing:Study SRS , Identify Unit Functions For each unit function - Take each input function - Identify Equivalence class - Form Test cases - Form Test cases for boundary values - From Test cases for Error Guessing Form Unit function v/s Test cases, Cross Reference Matrix and Find the coverage.
Unit Testing:
The most 'micro' scale of testing to test particular functions or code modules.
Typically done by the programmer and not by testers .
Unit - smallest testable piece of software.
A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness.
Unit testing done to show that the unit does not satisfy the functional specification and/ or its implemented structure does not match the intended design structure.
Integration Testing: Integration is a systematic approach to build the complete software structure specified in the design from unit-tested modules. There are two ways integration performed. It is called Pre-test and Pro-test.
Pre-test: the testing performed in Module development area is called Pre-test. The Pre-test is required only if the development is done in module development area.
System Testing: *
A system is the big component.
System testing is aimed at revealing bugs that cannot be attributed to a component as such, to inconsistencies between components or planned interactions between components.
Concern: issues, behaviors that can only be exposed by testing the entire integrated system (e.g., performance, security, recovery)
Volume Testing: The purpose of Volume Testing is to find weaknesses in the system with respect to its handling of large amounts of data during short time periods. For example, this kind of testing ensures that the system will process data across physical and logical boundaries such as across servers and across disk partitions on one server.

Stress testing: This refers to testing system functionality while the system is under unusually heavy or peak load; it's similar to the validation testing mentioned previously but is carried out in a "high-stress" environment. This requires that you make some predictions about expected load levels of your Web site.
Usability testing: Usability means that systems are easy and fast to learn, efficient to use, easy to remember, cause no operating errors and offer a high degree of satisfaction for the user. Usability means bringing the usage perspective into focus, the side towards the user.
Security testing: If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access.
Alpha testing: Testing of an application when development is nearing completion minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
Beta testing: Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers.

Why Testing?

2006-12-03T18:56:00.000+05:30

Why Testing?

To unearth and correct defects.
To detect defects early and to reduce cost of defect fixing.
To ensure that product works as user expected it to.
To avoid user detecting problems

What is Testing?

2006-12-03T18:47:00.000+05:30

What is Testing?

An examination of the behavior of a program by executing on sample data sets.
Testing comprises of set of activities to detect defects in a produced material.
To unearth & correct defects.
To detect defects early & to reduce cost of defect fixing.
To avoid user detecting problems.
To ensure that product works as users expected it to.

Why we use Testing? Click on Below Link http://testingsolution.blogspot.com/2006/12/why-testing.html

Testing Defination

2006-12-03T18:31:00.000+05:30

Agile Testing : Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm.
Alpha Testing: Early testing of a software product conducted by selected customers.
Ad Hoc Testing : Ad-hoc testing is the interactive testing process where developers invoke application units explicitly, and individually compare execution results to expected results.
Basis Path Testing: A white box test case design technique that uses the algorithmic flow of the program to design tests.
Beta Testing: Testing of a re-release of a software product conducted by customers.
Binary Portability Testing: Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.
Bottom Up Testing: An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.
Boundary Testing: Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).
Branch Testing: Testing in which all branches in the program source code are tested at least once.
Breadth Testing: A test suite that exercises the full functionality of a product but does not test features in detail
Concurrency Testing: Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single thread code and locking semaphores.
Conversion Testing: Testing of programs or procedures used to convert data from existing systems for use in replacement systems.
Dependency Testing : Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.
Depth Testing : A test that exercises a feature of a product in full detail.
Endurance Testing : Checks for memory leaks or other problems that may occur with prolonged execution.
End-to-End testing : Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
Exhaustive Testing : Testing which covers all combinations of input values and preconditions for an element of the software under test.
Gorilla Testing : Testing one particular module, functionality heavily
Loop Testing : A white box testing technique that exercises program loops.
Path Testing : Testing in which all paths in the program source code are tested at least once.
Scalability Testing : Performance testing focused on ensuring the application under test gracefully handles increases in work load
Structural Testing : Testing based on an analysis of internal workings and structure of a piece of software.
Thread Testing: A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.
Top Down Testing: An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.
Volume Testing: Testing which confirms that any values that may become large over time can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner.
Workflow Testing: Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user.
Books On Computers And Internet

Testing Solution By Manish Bansal

Web Service Testing

Web Services Process Flow

Web Services

SOA Testing Challanges

Multiple Choice Testing Question Answers

What Is WSDL?

Testing Definition In Simple

Test Plan

Differences in Testing

Testing Interview Question.

Do Testers Need Programming Skills ?

SOA- Service Oriented Architecture

Some QTP Related Question Answers

Capability Maturity Model Integration (CMM) Maturity Levels

CMM-Capability Maturity Model

Unit & Integration Testing

White Box and Black Box Testing

Interview Questions

Quality Related Questions

Levels of testing

Web Testing Challenges

Win Runner Related some Questions .

Win Runner Navigation

Web Test Plan Development

Understanding Software Defects

Testing Life Cycle – Roles and Responsibilities

Testing Life Cycle – Team Structure

Iteration Model

Spiral Model

Prototype Model

Waterfall Model

V-mode of SDLC

Web Testing Processes In Detail

Software Testing Life Cycle Models

Life cycle model

Verification and Validation Concepts

what is the use of different kind of testing when we use?

Testing Written Test Question -2

What is Software Testing?

BUG LIFE CYCLE

More Testing Interview Question

Automation Testing- Win Runner

Web Application Testing

Testing Written Test Questions

Question Answers

Test Case

Test Plan Contents

Testing Process

Software Development Life Cycle

Testing Technique

Why Testing?

What is Testing?

Testing Defination