Simple example of a Test case

Many testers one of the daily job is writing a test case. And yes, you have different scenarios and different

domains and different functionality for which you need to write test cases.Here I am trying to give a simple

scenario and how to write a test case for this.

First of all I will write possible test cases for using a ATM machine.

ATM machine accepts the ATM card

Machine Rejects the ATM for some reason such as expired card.

Enter the correct PIN number

Operation failed because you entered the wrong pin for 3 times.

Select the proper language

Select your account category(credit/debit).

operation failed because of wrong account type.

Select amount to be selected.

Withdraw the amount.

A message pop up that you exceeded the daily withdrawl limit.

With draw amount success.

operation failed because there is no money in ATM.

These are all the possible test cases for drawing money from an ATM machine.

IN the next article I will write how to write each test case from the above indetail.

test case example for manual testing test case example for atm test case example

Test ScenarioTest Scenario and software test scenario templates

Test scenarios are used to ensure that all process flows are tested from end to end.  The term “test scenario” is often used interchangeably with the term “test case”. However test scenarios are different from test cases because they usually have several steps whereas test cases are single steps.  When viewed in this sense, test scenarios are test cases, but they usually includes several test cases and the sequence that they should be executed.  In addition to this, each test is usually dependent upon output from the test that preceded it.

Test scenario are created by examining the functional requirements of the software/system, and preparing rational collections of functions that can be split into test procedures.  They should be designed in a manner that represents both typical and atypical conditions that could possibly occur within the application.

Test scenario are based on a hypothetical story that is supposed to help the tester make sense of a complex application.  An ideal test scenario is motivating, credible, complex, and easy to evaluate.  Test procedures and/or test scripts are used to execute test scenarios.   These procedures and/or scripts generally define a chain of steps that are needed to perform one or more test scenarios

Roles and Responsibilities of a Tester

The roles and responsibilities of a tester often vary from organization to organization. In general, a testers main

purpose is to design, develop, and conduct system tests and supports acceptance testing. The roles and

responsibilities of a tester include the core activities associated with the test effort.  This usually involves

identifying the most appropriate implementation approach specific tests, performing test preparations, executing

the tests, logging outcomes, and administering the defect tracking system. More detailed aspects of the roles and

responsibilities of a tester is included in the following:

Analyzing client requirements

Understand the software application being tested

Prepare test strategy

Participating in test plan preparation

Preparing test scenarios

Preparing test cases (used for module, integration, and system testing

Preparing test data (used for test cases)

Preparing test environment

Analyzing test cases (those prepared by others)

Write necessary test scripts

Executing the test cases

Defect tracking

Perform necessary retesting

Providing defect information (for developers)

Preparing report summaries

Preparing lesson learnt documents

Conducting review meetings within the team

Defect Tracking in testing

Defect Tracking

Defect tracking is the process of using inspection, testing, or obtaining customer feedback for the purposes of

finding defects in a product.  This information is used to correct the problems in future versions. Defect tracking is

an important part of software system development because all software products have bugs and it can help to

improve quality and reduce project costs.  Evaluating, prioritizing, and managing these defects can be difficult so

there are database systems that can be used to simplify the defect tracking process.

Defect tracking is sometimes thought of as a pointless cost that delays schedules. However, it is critical part of

software development and quality assurance initiatives.   When properly implemented, defect tracking can reduce

project costs, improve project schedule, increase productivity, boost operational reliability, and improve customer

satisfaction.  In contrast, a poorly managed defect tracking process may have the opposite effect.

While errors can be introduced early in the development process (in specifications and requirements), a majority

of them occur in the design phase.  The costs associated with fixing software defects can be high, especially in

cases where developers are required to revisit software that they haven’t seen for an extended period or modify

software created by someone else.  In addition to this, the increase in cost can be exponential the further the

project is in the development life cycle.

Implementing a Defect Tracking Process

In order for defect tracking to be effective, there must be a systematic process in place. This process should

begin with the logging of defects, followed by an investigation, then finally implementing the structure to solve

them.

Integrate Software Development and Defect Tracking

The earlier a defect is found, the better.  However, in most organizations, testing is done just before

implementation and is often under a time crunch for delivery.   For early defect detection and resolution, tracking

and software development efforts should begin at the same time.  Integrating defect tracking into the phases of

the software development life cycle requires a set of well-defined rules.  During the development life cycle, defect

tracking should focus on the following:

Requirements Phase: In this phase defect tracking focuses on validating that defined requirements meet user

functionality needs and expectations.

Design/Analysis Phase: In this phase efforts are focused on identifying and documenting that software design

meets the requirements.

Programming Phase: During programming, defect tracking should focus on ensuring that programs are fulfilling

the functionality defined by the requirements and design.

Maintenance/Enhancement Phases: While in the maintenance and enhancement phases, user issues should

be tracked continuously and previous releases should be monitored to ensure that they remain stable when

enhancements are added.

User acceptance testing Explained 

User Acceptance Testing or UAT is the last step prior to completion of any application. It is the responsibility of end users using these applications. They test these applications prior to inherit that application to their side. This type of testing is helpful for any end users. It boosts up their confidence as they are sure they will be getting an application with expected results. This kind of testing also help the bugs to be keep away from the application without interfering it.

Prerequisites of user acceptance testing

Application is fully developed prior to user acceptance testing. In User acceptance testing,there are many levels of testing performed. Before you come to start user acceptance testing, all these three level of testing are completed. This is the reason as most of the errors and defects are already been solved until it arrives to UAT stage.

What to test in UAT

For an effective and useful user acceptance testing, you need to create test cases. In requirement definition stage, you will find ample of use cases and you can use them to make your test cases. These test cases help you understand that all major scenarios and situations have been covered within them.

When you start with user acceptance testing, your aim is on what is the real world usage of the application that is being developed. You carry on testing in production environment. Then the test cases are formed using real world scenarios.

How to test in UAT

If you want to know how to use User acceptance testing, then you should have some knowledge on black box testing. User acceptance testing is something like black box testing, where the goal is on function and use of application. This testing does not take care of any technical knowledge. When you get application for User acceptance testing, it is assumed that they have passed all other testing like unit till system testing.

It is best when user acceptance testing is carried out in environment that is the actual world. It is here that end users could get good benefit with an effective application that is being developed.

1)      Planning in User Acceptance test: This is the essential phase that outlines the testing strategy. Main focus area, that is entry point as well as exit points are described here. This could be the most effective step if proper planning is done.

1)      Design made for UA test cases: Test cases are the sources that help the testing team in testing the complete application effectively. There are use cases that are being created in requirement definition stage of software testing. These use cases serves as a source of test case designing. Later on business analyst and other experts of team revise these test cases thoroughly.

2)      Selection of team executing UAT test cases: This is a major step as proper execution team would help in easy and effective running and testing of application. This team represents the actual world users who would be benefitted from the application. Hence, the team has the actual end users who would be making use of the application that is being developed.

3)      Execution of test cases: The test engineers carries out all the test cases.

4)      Documentation of defects found in UAT: If any kind of defects or bugs is found in application, then the team in comments from lists those.

5)      Bug fixing and resolving issues: The issues or bugs that are found in UAT are cleared out with team of project, business analyst and all other team experts. According all suggestions and mutual consents, these errors and bugs are resolved.

6)      Signing off: Once there is an error free completion of user acceptance testing, the application is being indicated as being accepted by end users. This is one of the important steps for commercial purpose. Once users indicate that they have accepted the application, it is known whether that application meets the software requirements. The step makes the developers sure that this application can be delivered to vendors easily.

Fig: complete software development and UAT cycle performed in offshore and onsite

Key deliverable in user acceptance testing

When you look at traditional software life cycle, you find that bug and error free completion of application is a major step. Some of the major deliverables of user acceptance testingphase are described here:

1)      Test plan: Here, step where test strategy is being developed.

2)      User Applications Test cases: These test cases are responsible for effectively testing the application at end user.

3)      Test Log: This is a place where all test results are executed and actual results are described.

4)      User signing off: Products are delivered to full satisfaction is distinguished by this testing field.

In user acceptance testing a group of end users are testing the application with the real world scenario.

Why to carry on User Acceptance testing

The user acceptance testing is carried to protect any organization from harm and danger. There could be many risk involved in installing any software on your computer. To go in details there are main reasons for performing UAT are due to many risks that may be involved with your organization. These risks are:

1) Legal risk: System might break any rule leading your organization to legal bounding.

2) Time risk: Business deadlines may not be met by the system. This must be discussed in testing phase rather than in live phase.

3) Resource risk: Lots of resources may be expended in working around the system and all these may add cost but no value. It is better to carry on testing to avoid any resource risk.

4) Reputation risk: This is the main risk due to which User acceptance testing should be done. This is done to avoid any risk involved with the end users and customers who would be using the software application developed by your organization. With UAT, all these risks could be avoided.

user-acceptance-testing-need

Fig: detailed flow of User acceptance test in market

User Acceptance testing is very important as it helps in proper conduction of tests and freeing your software application from every bugs and errors. This testing helps your organization to be away from any harm and danger that may be incurred to your organization.

Software Testing Bug Life Cycle

To gratify the customer or client’s demand; one must perform complete software testing activities on the

application before the deployment as its stated that “No Software Exists Without a BUG”; while performing

those actions if any ambiguity found then the tester should report the bug and notify the developer.

Elimination of bug from the software needs to follow the proper steps formerly known as BUG LIFE CYCLE; the

structure of it varies from organization to organization but the basic flow will remain the same. Every organization

use different tools or software to report the bug.

software_testing_BugCycle

1.1 Cataloguing new bug:

Following are the important things that should be kept in mind while reporting the bug

1. Bug description should have the STR (Steps to reproduce) which should be specific and clear so that

developer can easily understand. For ease in making understanding to the developer, tester can upload

screen shot and mark the bug by the red color font so that it is clearly be visible immediately.

2. Expected Result should be clearly visible

3. Bug Priority should be correctly set (See description on 1.3)

4. Bug Severity should be correctly set(See description on 1.4)

5. Build No should be set accordingly (See description on 1.5)

6. Bug should be assigned to the concerned person who is in charge of solving the bug(See description on

1.6)

1.2 Bug Life Cycle and Description:

1. New: Default status of the bug should be as NEW.

2. Checked In: As soon as the developer understood and resolved the bug; he will changed the NEW

status as CHECKED IN before releasing the build.

3. In Progress : Developer may change the status to IN PROGRESS if bug needs to be resolved in many

days

4. Fixed It Later: Usually Low Priority bugs marked as FIXED IT LATER by the developer

5. Not a Bug: If lead/verifier/ developer consider the bug as Not a Bug then he may mark and change the

status also providing healthy comments against it.

6. Re-Opened: If bug still exists or QA not satisfied with the solution in the new build then tester should

open the bug again by selecting the status as RE-OPENED.

7. Closed: If bug is successfully resolved and verified by the tester then it status should be marked as

CLOSED.

8. Suggestion: Tester should has the enough knowledge about the quality principles and if he found any

lack in the requirement or testing phase than he can report the SUGGESTION to make the application

more efficient

Note: Status options can be changed according to the tools for the different organizations

1.3 Bug Priority:

Setting bug priorities is essential because magnitude of a bug impact on the company’s business

1. P1- Critical:  All critical level bugs should be reported under this category; these include business logic,

performance issues or if site is dead etc.

2. P2 – Major: Major level bugs should be reported under this category; these includes too much delay in

loading the page etc

3. P3 –Moderate:  Moderate or average level of bugs that are bearable should be reported under this

category; these include verification of TO and FROM date as TO date cannot be less than FROM date;

Buttons not performing the functionality etc.

4. P4 –Low: Cosmetic or Low level of bugs should be reported under this category; Problems with layout

or the bugs that wont effect the performance should be included here.

1.4 Bug Severity:

Setting bug severity is essential because magnitude of a bug impact on the software.

1. Blocker – When testing procedure is halted due to some issue

2. Application Crash – When performing QA Activities and suddenly any page got crashed due to large

input, entering invalid data in the field, or due to connectivity or integration issues

3. Major- when bug severity is Major

4. Minor - When bug severity is Minor

5. Trivial - When bug severity is very low; mostly incase of GUI (Graphic User Interface) issues

6. Enhancement –  When any bug is reported just to enrich the application

1.5 Build No:

It is the unique identifier which shows that how many versions of the software has been release for the testing;

when any major change is implemented then the developer will change the value to 2.0 prior it was 1.9 say, but if

any minor change is implemented then build No should be as 1.10.

1.6 Assigned To:

Tester should select the name of the person who is the current owner of the bug

SQL Testing Questions and AnswersBelow are some of the important sql testing interview questions.

1. Explain how a “where” clause differs from a “having” clause?

The “where” is used as a command for restricting data from a database but a “having” clause is used as a command for filtering. For example, a “where” clause may be used to retrieve results and a “have” clause may be used to filter the results of the retrieved data.

2. How can you speed up table reads for a database?

In order to tune the database one should do the following:

a) Check for proper index use

b) Check for correct location of database objects across multiple files, table spaces, etc.

c) Create a particular area with a special data type (such as a table space) to place some of the data

3. Explain database replication.

Database replication is the practice of moving or copying data from one database to another. There are three types of replication supported by SQL Server: merge, snapshot, and transactional.

4. Name a few trade-offs for using indexes?

Allows faster selection, but updates are slower because both the table and the index must be updated.

Indexes require additional storage space.

5. What is the size limit for a row?

A row can be a maximum of 8060 bytes.

6. Explain how a “join” command is used.

A “join” command is used to logically connect two or more tables.  This can be done either with or without a common field.

7. What are user-defined data types and give an example of how they can be used?

User-defined data types provides the database with a descriptive name and format and allows the base SQL Server data types to be extended.  As an example, let’s say a database has a column named bin_num that is varchar(8) and is used in several tables. A user-defined data type called bin_num_type of varchar(8) can be created and used in all of the tables.

8. What is the difference between “normalization” and “Denormalization”?

When data is normalizing redundant information is removed from the table and it is organized to make future changes simpler. For denormalization, redundant data is allowed to remain in the table.  Denormalization can be beneficial because reducing the number of joins used for data processing can make data manipulation and retrieval simpler and therefore and improvement in performance.

9. Describe the purpose of a constraint.

Constraints provide a means to check tables for referential integrity. SQL Server has four types of constraints and a default:

DEFAULT – indicates a column default value in the event that one is not provided by an insert operation

NOT NULL – does not allow null values in the specified column

PRIMARY/UNIQUE – requires values in a specific column to be unique

FOREIGN KEY – checks that each value in a particular column exists in a column in a different table.

CHECK – verifies that all stored values in particular column exist in a list that is specified.

10. What is the difference between a primary and a unique key?

While the primary and unique keys enforce uniqueness in their columns, a clustered index is created in the column of the primary key, and a non-clustered index is created in the column of the unique key. Also, NULL values are not allowed with a primary key but up to one is allowed with a unique key.

Some more SQl Testing Interview Questions11.         What is a “trigger”?

Triggers are procedures that are created for a database to enforce rules of integrity. They are executed whenever an operation to modify data such as insert or delete is performed.

12. What type of information is stored in a column that is specified with a bit data type?

The bit data type is used for Boolean data, which is either true or false, 1 or 0. SQL Server versions prior to version 6.5 only allowed the storage of 1’s or 0’s, no NULL values.   However, version 7.0 and beyond allows the storage of NULL values.

13. Explain RAID.

RAID is an acronym for Redundant Array of Inexpensive Disk.  RAIDs provide fault tolerance for database servers and has six (numbered 0-5) levels of different fault tolerance performance.

 

14. When does blocking occur?

Blocking occurs when an application connection holds a lock and a conflicting lock type if required for a second connection. In this case, the second connection is considered blocked by the first connection.

15. Explain isolation levels.

Isolation levels include the following: read uncommitted, read committed (default), repeatable read, and serializable.  Isolation levels determine the extent of data isolation between simultaneous transactions.

16. What is a deadlock?

A deadlock is a condition where two processes have established a lock on an article of data and each tries to obtain a lock on the other process’ piece. In this case, unless one process is terminated, both processes will wait indefinitely for the data to be released. If SQL Server detectsa deadlock, it will kill one of the processes.

17. What is a live lock?

A live lock occurs when a request for an exclusive lock is denied over and over due to interference from shared locks that overlap. This can also occur when a read transaction dominates a page or a table and forces indefinite waiting for a write transaction.  If the SQL Server detects four denials of this type, it automatically refuses subsequent shared locks.

18. Give a few SQL server options to move data and/or databases between servers and other databases.

Some options are the following:

Replication DTS BCP BACKUP/RESTORE command Attaching/detaching databases Log shipping SELECT…INTO

INSERT…SELECT Generating data with INSERT scripts

19. Explain cursors and their disadvantages.

Cursors are used for row-by-row processing of results.  There are four types of coursers: dynamic, static, keyset-driven, and forward only.  One of the disadvantages of using curser is that whenever a row from a cursor is fetched, it results in a network round-trip.  Cursors also require more temporary storage and other resources.  In addition to this, some types of cursors impose restrictions on the use of SELECT statements.

20. What is the difference between TRUNCATE TABLE and DELETE TABLE?

The DELETE TABLE command is a little slow because it is recorded in the transaction log.  Like DELETE TABLE, the TRUNCATE TABLE command also deletes all the rows in a table, but it is a bit faster because this is not logged.  Instead, the TRUNCATE TALE command logs the de-allocation of the table data pages.

21. What is a transaction and what are its properties?

A transaction is considered to be a unit of work with steps in which all or none must be performed. The properties of a transaction can be defined using the acronym ACID, which stands for Atomicity, Consistency, Isolation, and Durability.

QTP Interview Questions and Answers1. Explain the purpose of QTP.

Quick Test Professional or QTP is a record-playback test automation tool for graphical interfaces. QTP aids in testing web objects as well as ActiveX controls and can be used with any Java, Java applets, windows client, .NET framework, and Visual Basic web applications.

2. How can the recovery scenario manager be used to handle exceptions in QTP?

If unexpected errors and events occur during a test run, QTP provides a wizard through the Recovery Scenario Manger that can recover them.   A recovery scenario can be activated during 4 specific trigger events.  They include the following:

Appearance of a pop up window during test execution The value or state change of an object’s properties A failed test step A failed test run in the application

3.    When creating functions, what should be done to allow optional arguments?

Since optional arguments are not supported a more indirect method must be employed. If an argument is not required, a blank string should be passed with a default value.

4.    When running a script, is it possible to turn off the results?

The window that displays the results can be suppressed but results will still appear in the log.  To do this, you must make sure that “View Results When Run Session Ends” is deselected in the Run tab of the options under the Tools menu.

5. What is the Test Fusion Report?

The Test Fusion Report contains the details of the test run.  This includes a high-level overview, the data used, application screenshots of discrepancies, a tree view of the failure points, and detailed explanations of each checkpoint.

6. What testing environments are supported by QTP?

All enterprise environments are supported for functional testing including .NET, J2EE, Java, Windows, Oracle, Siebel, SAP, Visual Basic, PeopleSoft, ActiveX, mainframe terminal emulators, and Web services.

7.    How does one go about changing an object’s run-time value?

During a test run the SetToProperty function can be used to change the property values that identify an object. This is only possible for properties that are included in the test object description.

8. What task does checkpoints perform?

Checkpoints are used to verify that the information that is expected is displayed while the test is running. There are eight types of checkpoints available:

Page – checks application characteristics Text – verifies that text strings are show in the proper locations in the application Object – checks the values of application objects Image – checks the values of application images Table – verifies information in an application table Accessibility – checks the web page for compliance with Section 508 XML – verifies that the contents of XML data files or documents that are part of the

application Database – verifies the contents of databases accessed by your web site

Some more QTP Interview Questions9.    Are object repositories required to for test case script?

An object repository is not required but you must know the window handlers.

10.         Name two ways that checkpoints can be added to an application?

One way is to add them while the application is recording.  The other is to use the Active screen (while it is active) to add them after recording is finished.

11. How you add a run-time parameter to a datasheet?

This can be achieved by using LocalSheet property. For example, the following is an example of how to return the local sheet of the run-time data table so that a parameter can be added: YourParam=DataTable.LocalSheet.AddParameter(“Date”, “6:30″)

12.         What does QTP use to identify application objects?

Objects are identified by class and by logical name.

13.         What does parameterize mean?

When a tester wants to verify how an application performs a certain operation, they will often run it several times using different sets of data. Instead of running the test several separate times, they can create a parameterized test that runs the operation several times using a different set of data each time.

14.         Describe the QTP test object model?

The test object model is a set of object classes and types that are used to represent application objects. Each object class contains a list of properties that identify objects of that class as well as a set of methods that can be recorded for it.

15. What are the object repositories modes?

There is two object repository modes: per-action mode and shared mode.   The per-action mode is best to use when creating simple record and run tests when there is only one or very few tests that correspond to the interface, objects, or application, when test object properties will not be modified frequently, and when creating single-action tests.  The shared mode is best used when there are several tests that correspond to the interface, objects, or application, when test object properties are expected to be modified frequently, and with multi-action tests.

16.         Describe the Object Spy.

Object Spy is a feature that can be used to view the properties of any of the application objects. When the pointer is used to select and object, the hierarchy tree, values, and properties of the object are displayed in the Properties tab of the Object Spy dialog box.

17.         How is batch testing performed in QTP?

Batch testing is performed by running the entire test set. All automated test scripts are executed one at a time by keeping the other scripts in waiting mode.

18.         Provide an example of how to use a COM interface in QTP?

A COM interface appears in the front and back end of a scenario.   If Oracle is being as the back end and Visual Basic as the front end, COM will create a more compatible interface.

Above listed are some of the important QTP interview questions for a tester job.

Quality Center Interview Questions 

Quality center is a Defect tracking tool, where you can view existing defects, create a new defect that you found from your manual testing,  you can edit, close defects. remember that Test director was the previous version to Quality center. Now-a-days every where HP quality center or IBM Clear quest is used for defect management.

Quality Center Interview Questions can be normally focused by the interview panel along with manual testing interview questions. Though the interview mostly targeted to Quality center skills, then need a guy with common testing skills as well. Because with  out manual testing knowledge, there is not use if quality center as this tool is only used for defect tracking.

1.  What is the relationship between Quality Center and TestDirector?

TestDirector is the tool that was later renamed to Quality Center. The last version of TestDirector was version 8.2.

2.  What is the purpose of Quality Center?

TestDirector is a web-enabled tool used for the management of tests.  It supports cross-team communication and helps to improve the efficiency and effectiveness of collaboration in the process of testing global applications. It is capable of generating reports and graphs that can be used for test analysis, planning, and the tracking of defects.

3. What is the purpose of linking test cases to requirements?

Test cases are linked to requirement so verify test coverage.  This ensures that all requirements are being verified by at least one test case.

4. What types of requirement options can be added to test cases?

There are two types of requirements:

Parent Requirement – High level functions Child requirements. – Low level (sub-requirements of parents)

5. What are the main advantages of Quality Center?

It is capable of performing manual and automated testing It takes all parts of the testing process into account, from test planning through defect

tracking It ensures test coverage by linking requirements to the test cases It allows for test plans and requirements to be imported from Microsoft Excel

6. What do you have to use to upload test cases from Microsoft Excel?

This can be done using the MS Excel add-in.  This option can be installed from the Quality Center Add-In menu. Once this is completed, there will be a new menu option in MS Excel for exporting to Quality Center.

7. How are filters be used?

Filters are used to sort the test results. A tester can easily find all pass or fail results using a filter.

8. What is the Test Lab?

The Quality Centre Test Lab where tests are executed.  Tests from the test plan can be added to test trees that run in various test cycles.

9. How can the defect management cycle be tailored in Quality Center?

Once all of the defect attributes that will be tracked (i.e. version, details, etc.) are determined, use the “Modify Options” feature of Quality Center to customize.

10. Does Quality Center allow defect to be mapped directly to requirements?

No, defects are mapped indirectly to requirements through test cases.

Few more Quality center Interview Questions. 

11. Can test data be stored in TestDirector?

Test data can be stored by attaching it to the matching test cases.  It can also be saved into a separate folder in test plan.

12. Will test data be lost if you choose to upgrade from TestDirector to QC?

If the instructions are followed, test data will not be lost when migrating from TestDirector to Quality Center.

13. How are test cases grouped?

The tested decides how to group test cases.  The tester has the option of creating several folders in the test plan to represent the test modules.  They also have the option of creating sub-modules from there.

14. How does Quality Center compare to Bugzilla?

Quality Center has much more functionality than Bugzilla.  Bugzilla is a defect logging and tracking tool while Quality Center is a test management tool. In addition to being able to track defects, Quality Center is capable of managing requirements and test cases for both manual and automated tests and much more.

15. What reports are available in Quality Center?

Some of the test reports that are available include those for requirements, test cases, defect tracking and more. They can be generated from any module and can also be customized using filters to include summaries, coverage, progress, and more. Customized report setting can be saved and reloaded for future testing.

16. Can one defect be mapped to more than one test script?

A defect can be mapped to several different test scripts using the option called ‘associate defect.”

17. Do scripts have to be recorded in QTP or WinRunner before importing them into Quality Center?

No, scripts can be recorded directly to Quality Center by first specifying the URL, user ID, password, project, etc and connecting to Quality Center. The recording tool has to be opened when doing this. The script can be saved to Quality Center rather than the local machine.

18. How can you be sure that bugs are not duplicated?

The “Find Similar Defect” feature searches for defect duplication.

19. What information is in the test grid?

The test grid contains all tests that are related to a project as well as a toolbar with controls that are frequently used when creating and modifying the tests.  Filters used in the grid and test history are also displayed.

20. What views are available in TestDirector?

There are three views available in TD:

Plan Test –for preparation of test cases

Run Test – for test execution

Track Defects – for logging bugs

21. What are the Quality Center tabs?

There are four tabs: requirements, test plan, Test Lab, and defects.

22. How can Quality Center be used in real-time projects?

For real-time project, when the test cases are completed, they should be imported into Quality Center and loaded into a test plan.  When test execution begins, test cases are moved to Test Lab.  Test Lab executes the cases and assigns pass/fail/incomplete statuses.  Graphs can be generated and defects attached.

23. What is the difference between ‘Not run’ and ‘Not covered’ statuses?

The “Not Run” status indicates that the test cases associated with the requirements exist but have not been executed.   The “Not Covered” status indicates that the test cases associated with the requirements do not exist yet.

24. What is the difference between QA Inspect and Web Inspect?

The QA Inspect feature searched the full web application for vulnerabilities in security, prioritizes them, and provided detailed information and solution suggestions.  Web Inspect, on the other hand, is often used as a security assessment for vulnerabilities in security for critical data.  Web inspect is use the most by security experts and compliance auditors.

Above are the important and very commonly askedQuality Center Interview Questions, along with some below imp notes:Normally the flow of quality center is like this: First you will encounter few errors/suggestions in your testing of the application. Now you will raise a defect for this error you found in quality center and assign that defect to a developer. The developer will then resolve the issue in his programming/coding and then will re assign to a tester. Now the tester will re test the application (Also called regression testing) and then if he is not seeing that error any more, then he will close the defect.

For creating a defect, you need to enter the title of the defect, summary of the defect, screen shots if available etc

Sample bug reports for web and product applications

On request from may readers I am updating sample bug report on separate page. Here

are couple of sample bug reports and treat them as samples only. You can always

make the changes in bug report format as per your requirements. It’s not mandatory to

use same fields in same sequence as specified below. You can find out your own working

template.

Read below articles on more guide on writing good bug report:

  How to write a good bug report

  Bug Life Cycle

Bug report sample 1: Web Project bug report

Summary: In CTR (Click through ratio) ‘Total’ row calculation is wrong

Product: Example product

Version: 1.0

Platform: PC

URL: (Provide url of page where bug occurs)

OS/Version: Windows 2000

Status: NEW

Severity: Major

Priority: P1

Component: Publisher stats

Assigned To: developer@example.com

Reported By: tester@example.com

CC: manager@example.com

Bug Description:

Reproduce steps:

1) Go to page: (Provide URL of page where bug occurs)

2) Click on ‘Publisher stats’ link to view publisher’s revenue detail stats date wise.

3) On page (Provide URL of page where bug occurs) check CTR value in ‘Total’ row of CTR

stats table.

Actual result: Calculation of ‘Total’ row in CTR table is wrong. Also Individual row CTR for

each publisher is not truncated to 2 digits after decimal point. It’s showing CTR like

0.042556767.

Expected result: Total CTR= (Total clicks/Total searches)*100

[Attach bug screenshot if any]

Please fix the bug.

************************************

Sample bug report 2: Application product Bug report sample

Application testing scenario:

Lets assume in your application you want to create a new user with his/her information,

for that you need to logon into the application and navigate to USERS menu > New User,

then enter all the details in the User form like, First Name, Last Name, Age, Address,

Phone etc. Once you enter all these need to click on SAVE button in order to save the

user and you can see a success message saying, “New User has been created

successfully”.

Now you entered into your application by logging in and navigate to USERS menu > New

user, entered all the information and clicked on SAVE button and now the application

crashed and you can see one error page on the screen, now you would like to report this

BUG.

Now here is how we can report bug for above scenario:

Bug Name: Application crash on clicking the SAVE button while creating a new user.

Bug ID: The BUG Tracking tool will automatically create it once you save this.

Area Path: USERS menu > New Users

Build Number:/Version Number 5.0.1

Severity: HIGH (High/Medium/Low)

Priority: HIGH (High/Medium/Low)

Assigned to: Developer-X

Created By: Your Name

Created On: Date

Reason: Defect

Status: New/Open/Active – Depends on the Tool you are using

Environment: Windows 2003/SQL Server 2005

Description:

Application crash on clicking the SAVE button while creating a new user, hence unable to

create a new user in the application.

Steps To Reproduce:

1) Logon into the application

2) Navigate to the Users Menu > New User

3) Filled all the fields

4) Clicked on ‘Save’ button

5) Seen an error page “ORA1090 Exception: Insert values Error…”

6) See the attached logs for more information

7) And also see the attached screenshot of the error page.

Expected: On clicking SAVE button should be prompted to a success message “New User

has been created successfully”.

How to write a good bug report? Tips and Tricks

September 18th, 2007 — Bug Defect tracking, How to be a good tester,Software Testing

Templates

Why good Bug report?

If your bug report is effective, chances are higher that it will get fixed. So fixing a bug

depends on how effectively you report it. Reporting a bug is nothing but a skill and I will

tell you how to achieve this skill.

“The point of writing problem report(bug report) is to get bugs fixed” – By Cem

Kaner. If tester is not reporting bug correctly, programmer will most likely reject this bug

stating as irreproducible. This can hurt testers moral and some time ego also. (I suggest

do not keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce

it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc etc..)

What are the qualities of a good software bug report?

Anyone can write a bug report. But not everyone can write a effective bug report. You

should be able to distinguish between average bug report and a good bug report. How to

distinguish a good or bad bug report? It’s simple, apply following characteristics and

techniques to report a bug.

1) Having clearly specified bug number:

Always assign a unique number to each bug report. This will help to identify the bug

record. If you are using any automated bug-reporting tool then this unique number will

be generated automatically each time you report the bug. Note the number and brief

description of each bug you reported.

2) Reproducible:

If your bug is not reproducible it will never get fixed. You should clearly mention the

steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step

described bug problem is easy to reproduce and fix.

3) Be Specific:

Do not write a essay about the problem. Be Specific and to the point. Try to summarize

the problem in minimum words yet in effective way. Do not combine multiple problems

even they seem to be similar. Write different reports for each problem.

How to Report a Bug?

Use following simple Bug report template:

This is a simple bug report format. It may vary on the bug report tool you are using. If

you are writing bug report manually then some fields need to specifically mention like

Bug number which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub modules of the product.

Platform: Mention the hardware platform where you found this bug. The various

platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Operating system: Mention all operating systems where you found the bug. Operating

systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions

also if applicable like Windows NT, Windows 2000, Windows XP etc.

Priority:

When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with

highest priority” and P5 as ” Fix when time permits”.

Severity:

This describes the impact of the bug.

Types of Severity:

Blocker: No further testing work can be done.

Critical: Application crash, Loss of data.

Major: Major loss of function.

Minor: minor loss of function.

Trivial: Some UI enhancements.

Enhancement: Request for new feature or some enhancement in existing one.

Status:

When you are logging the bug in any bug tracking system then by default the bug status

is ‘New’.

Later on bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.

Click here to read more about detail bug life cycle.

Assign To: 

If you know which developer is responsible for that particular module in which bug

occurred, then you can specify email address of that developer. Else keep it blank this

will assign bug to module owner or Manger will assign bug to developer. Possibly add the

manager email address in CC list.

URL:

The page url on which bug occurred.

Summary:

A brief summary of the bug mostly in 60 or below words. Make sure your summary is

reflecting what the problem is and where it is.

Description:

A detailed description of bug. Use following fields for description field:

Reproduce steps: Clearly mention the steps to reproduce the bug.

Expected result: How application should behave on above mentioned steps.

Actual result: What is the actual result on running above steps i.e. the bug

behavior.

These are the important steps in bug report. You can also add the “Report type” as one

more field which will describe the bug type.

The report types are typically:

1) Coding error

2) Design error

3) New suggestion

4) Documentation issue

5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately:If you found any bug while testing, do not wait to

write detail bug report later. Instead write the bug report immediately. This will ensure a

good and reproducible bug report. If you decide to write the bug report later on then

chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report:Your bug should be

reproducible. Make sure your steps are robust enough to reproduce the bug without any

ambiguity. If your bug is not reproducible every time you can still file a bug mentioning

the periodic nature of the bug.

3) Test the same bug occurrence on other similar module:

Sometimes developer use same code for different similar modules. So chances are high

that bug in one module can occur in other similar modules as well. Even you can try to

find more severe version of the bug you found.

4) Write a good bug summary:

Bug summary will help developers to quickly analyze the bug nature. Poor quality report

will unnecessarily increase the development and testing time. Communicate well through

your bug report summary. Keep in mind bug summary is used as a reference to search

the bug in bug inventory.

5) Read bug report before hitting Submit button:

Read all sentences, wording, steps used in bug report. See if any sentence is creating

ambiguity that can lead to misinterpretation. Misleading words or sentences should be

avoided in order to have a clear bug report.

6) Do not use Abusive language:

It’s nice that you did a good work and found a bug but do not use this credit for criticizing

developer or to attack any individual.

Conclusion:

No doubt that your bug report should be a high quality document. Focus on writing good

bug reports, spend some time on this task because this is main communication point

between tester, developer and manager. Mangers should make aware to their team that

writing a good bug report is primary responsibility of any tester. Your efforts towards

writing good bug report will not only save company resources but also create a good

relationship between you and developers.

For better productivity write a better bug report.

200 Comments

Bug life cycle

September 5th, 2007 — Bug Defect tracking, Software Testing Templates,Testing Life

cycle

What is Bug/Defect?

Simple Wikipedia definition of Bug is: “A computer bug is an error, flaw, mistake,

failure, or fault in a computer program that prevents it from working correctly or

produces an incorrect result. Bugs arise from mistakes and errors, made by people, in

either a program’s source code or its design.”

Other definitions can be:

An unwanted and unintended property of a program or piece of hardware, especially one

that causes it to malfunction.

or

A fault in a program, which causes the program to perform in an unintended or

unanticipated manner.

Lastly the general definition of bug is: “failure to conform to specifications”.

If you want to detect and resolve the defect in early development stage, defect tracking

and software development phases should start simultaneously.

We will discuss more on Writing effective bug report in another article. Let’s concentrate

here on bug/defect life cycle.

Life cycle of Bug:

1) Log new defect

When tester logs any new bug the mandatory fields are:

Build version, Submit On, Product, Module, Severity, Synopsis and Description to

Reproduce

In above list you can add some optional fields if you are using manual Bug submission

template:

These Optional Fields are: Customer name, Browser, Operating system, File Attachments

or screenshots.

The following fields remain either specified or blank:

If you have authority to add bug Status, Priority and ‘Assigned to’ fields them you can

specify these fields. Otherwise Test manager will set status, Bug priority and assign the

bug to respective module owner.

Look at the following Bug life cycle:

[Click on the image to view full size] Ref: Bugzilla bug life cycle

The figure is quite complicated but when you consider the significant steps in bug life

cycle you will get quick idea of bug life.

On successful logging the bug is reviewed by Development or Test manager. Test

manager can set the bug status as Open, can Assign the bug to developer or bug may be

deferred until next release.

When bug gets assigned to developer and can start working on it. Developer can set bug

status as won’t fix, Couldn’t reproduce, Need more information or ‘Fixed’.

If the bug status set by developer is either ‘Need more info’ or Fixed then QA responds

with specific action. If bug is fixed then QA verifies the bug and can set the bug status as

verified closed or Reopen.

Bug status description:

These are various stages of bug life cycle. The status caption may vary depending on the

bug tracking system you are using.

1) New: When QA files new bug.

2) Deferred: If the bug is not related to current build or can not be fixed in this release

or bug is not important to fix immediately then the project manager can set the bug

status as deferred.

3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to

developer.

4) Resolved/Fixed: When developer makes necessary code changes and verifies the

changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing

team.

5) Could not reproduce: If developer is not able to reproduce the bug by the steps

given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to

check if bug is reproduced and can assign to developer with detailed reproducing steps.

6) Need more information: If developer is not clear about the bug reproduce steps

provided by QA to reproduce the bug, then he/she can mark it as “Need more

information’. In this case QA needs to add detailed reproducing steps and assign bug

back to dev for fix.

7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix

then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved

then QA can mark bug as ‘Closed’.

9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected

or invalid if the system is working according to specifications and bug is just due to some

misinterpretation.

159 Comments

How to write software Testing Weekly Status Report

July 3rd, 2007 — Bug Defect tracking, Software Testing Templates, Testing Tips and

resources

Writing effective status report is as important as the actual work you did! How to write

a effective status report of your weekly workat the end of each week?

Here I am going to give some tips. Weekly report is important to track the important

project issues, accomplishments of the projects, pending work and milestone

analysis. Even using these reports you can track the team performance to some extent.

From this report prepare future actionables items according to the priorities and

make the list of next weeks actionable.