jump to navigation

First Name, Last Name Validation October 22, 2009

Posted by Thiyagarajan Veluchamy in Uncategorized.
Tags:
2 comments

It should be

- first and last character must be alphabet

- accepts single character input

-  it wont allow any special character and white space at start and end

E-mail address validation July 16, 2009

Posted by Thiyagarajan Veluchamy in Manual Testing.
Tags:
1 comment so far

We will discus how to validate email field,
given below,
E-Mail Address = “A@b.c”;                — Valid
E-Mail Address = “A@b.cnet”;         — Invalid
E-Mail Address = “A@b.c_”;             — Invalid
E-Mail Address = “A@bcnn”;            — Invalid
E-Mail Address = “Ab.cnn”;               — Invalid
E-Mail Address = “A@bc”;                  — Invalid
E-Mail Address = “A@bat@.cnn”;   – Invalid
E-Mail Address = “A@bat/.com”;    – Invalid

conditions are,

  1. Must not be too short and too long
  2. Only one @ in email address
  3. Only one period ‘.’ or two periods in email
  4. No more than 3 characters after the final period (reverse find is 0 based not 1 based) com/ org/net/mil/gov/co.in/co.uk and etc
  5. Should not have an underscrode after @
  6. Allowed characters 0-9 A-Z _ . before @

Example E-Mail is thiyagarajannv@yahoo.com

I have devided Email ID in 4 parts in above email id,

  1. In first part we have to check invalid condition input spaces, Left blank, use special character, symbols etc before email in @.
  2. In Second part we have to check invalid condition input other specail character [!#$%^&*()_-:;”‘?/|\) at the place of @. left thisfield as blank. input spaces.etc
  3. In third part we have to check invalid invalid domain.
  4. In fourth part we have to check only valid suffix(.com,.co.in,.edu,.info,.org,.in etc)

very time EmailID should be in well manner.

like thiyagarajannv@yahoo.com and etc.

File Handling Using QTP July 15, 2009

Posted by Thiyagarajan Veluchamy in Automation Testing, QTP.
Tags: ,
1 comment so far

QTP File Handling

Many times we have may need to interact with text files using QTP. Interaction can be (but not limited to) in the form of reading input from a file or writing output to a file.

We can use FSO (FileSystemObject) object to do this.

What is FSO?
FSO stands for File System Object. This is used to support text file creation and manipulation through the TextStream object and is contained in the Scripting type library (Scrrun.dll).
The FSO Object Model has a rich set of properties, methods and events to process folders and files.

How to create a file?
We first create a FSO object using CreateObject.

Secondly we create a text file using CreateTextFile.
For Example: Suppose you want to create a file called “test.txt” located in C:\

Dim fso, file, file_actual_location
file_ actual_location = “C:\file_ actual _location”
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set file = fso.CreateTextFile(file_ actual _location, True)

How to open a file?

Set file= fso.OpenTextFile(“C:\file_ actual_location”, ForWriting, True)
//2nd argument can be ForReading, ForWriting, ForAppending
//3rd argument is “True” if new file has to be created if the specified file doesn’t exist else false, blank signify false.

How to read content from a file?
Use ReadLine() method
For example:

Set file= fso.OpenTextFile(“C:\file_ actual_location”, ForReading, True) //2nd argument should always be “ForReading” in order to read contents from a file
Do while file.AtEndofStream <> True
data = file.ReadLine()
msgbox data
Loop

How to write content to a file?
You can use  Write() or WriteLine() Methods to write text into a file. The difference between the Write() and WriteLine() Method is that the latter automatically inserts a new line character while the former doesn’t insert a new line character.
For example:

Set file= fso.OpenTextFile(“C:\file_ actual_location”, ForWriting, True) //2nd argument should always be “ForWriting” in order to write contents to a file
file.Write(“This is test is”)
file.Write(“file created.”)
//Output will be:
This is test is file created.
while
file.WriteLine(“This is test is “)
file.Write(“file created.”)
//Output will be:
This is test is
file created.

How to delete file?
Use DeleteFile() method to delete a file from a particular location
Foe Example:

file_location = “C:\file_actual_location”
Set fso = CreateObject(“Scripting.FileSystemObject”)
fso.DeleteFile(file_ actual_location)

QTP Advantages and Disadvatages June 26, 2009

Posted by Thiyagarajan Veluchamy in QTP.
Tags:
10 comments

Will be getting the initial focus on development of all new features and supported technologies.

  • Ease of use.
  • Simple interface.
  • Good error handling mechanism
  • Presents the test case as a business workflow to the tester (simpler to understand).
  • Excellent DDT (Data Driven Testing features)
  • Uses a real programming language (Microsoft’s VBScript) with numerous resources available.
  • Quick Test Professional is significantly easier for a non-technical person to adapt to and create working test cases, compared to WinRunner.
  • Data table integration better and easier to use than WinRunner.
  • Test Run Iterations/Data driving a test is easier and better implement with QuickTest.
  • Parametrization easier than WinRunner.
  • Can enhance existing QuickTest VB scripts without the Application Under Test? being available; by using the ActiveScreen.
  • Can create and implement the Microsoft Object Model (Outlook objects, ADO objects, FileSystem objects, supports DOM, WSH, etc.).
  • Better object identification mechanism.
  • Numerous existing functions available for implementation both from within QuickTest Pro and VBScript.
  • QTP supports .NET development environment (currently WinRunner 7.5 does not).
  • XML support (currently WinRunner 7.5 does not).
  • The Test Report is more robust in QuickTest compared to WinRunner.
  • Integrates with TestDirector and WinRunner (can kick off WinRunner scripts from QuickTest).
  • Must know VBScript in order to program at all.
  • Must be able to program in VBScript in order to implement the real advance testing tasks and to handle very dynamic situations.
  • Need training to implement properly.
  • The Object Repository (OR) and testing environment? (paths, folders, function libraries, OR) can be difficult to understand and implement initially.
  • we can’t done merzeing easly, when compare to winrunner
  • we can’t able to check if the Window of Background colour is dynamically changes.

Priority Testing May 20, 2009

Posted by Thiyagarajan Veluchamy in Uncategorized.
2 comments

Generally Priority is Business for the projects.  And this will be set by the team lead or the project lead, based on the severity and the time constraint that the module has the priority will be set.

  1. Must fix the bug as soon as possible. Because bug is blocking further progress in this area.
  2. Should fix the all issues, before release the product or project.
  3. fix the issues within time period.

Available Browsers for Linux, Windows, Mac for Testing April 7, 2009

Posted by Thiyagarajan Veluchamy in Uncategorized.
Tags: , , ,
7 comments

A Web browser is a software application, user to display and interact with text, images, music, videos, games & etc typically located on a Web page at a Web site on the World Wide Web or a local area network. A web browser is importing for web application testing … The great number of browsers in the internet,

Web browsers listing for Windows

Logo Browser Name & Developed by
Internet Explorer logo Internet Explorer
Microsoft Corporation
Download version 7 & 8
Firefox (also called Mozilla Firefox) logo Mozilla Firefox
Mozilla Corporation
Download latest version
Chrome logo Chrome
Google
Download Chrome
Safari logo Safari
Apple Inc.
Download version 4 Beta
Opera logo Opera
Opera Software ASA
Download version 9.64
Netscape Navigator logo Netscape Navigator
AOL
Download version 9
SeaMonkey logo SeaMonkey
Mozilla Foundation
Download version 1.1.15
K-Meleon logo K-Meleon
kmeleonbrowser.org
Download version 1.5.2
Amaya logo Amaya
W3C
Download version 11.1
Maxthon Browser logo Maxthon Browser
Maxthon
Download version 2.5.1
Flock (web browser) logo Flock
Flock, Inc.
Download version 2
Slim Browser logo Slim Browser
FlashPeak
Download version 4.11
KidRocket logo KidRocket
KidRocket.org
Download version 1.5
PhaseOut web browser logo PhaseOut
PhaseOut
Download latest version
Crazy Browser logo Crazy
Crazy Browser
Download version 3
Smart Bro logo Smart Bro
Mind Vision Software
Download latest version
ShenzBrowser logo ShenzBrowser
Shenz International
Download version 1.1
JonDoFox logo JonDoFox
JonDoNYM
Download version 2.1.3
Avant Browser logo Avant Browser
Avant Force
Download version 11.7
xB Browser logo xB Browser
XeroBank
Download version 2.9.1.2
Sleipnir  logo Sleipnir
Fenrir Inc.
Download version 2.8.3
space time logo space time
space time
Download version 1
Browse3D logo Browse3D
Browse3D Corporation
Download version 3.5
3B Room logo 3B Room
3B
Download version 3.11
Bitty Browser logo Bitty Browser
Turnstyle
Download version
Grail logo Grail
CNRI
Download version 0.6
Lynx logo Lynx
Thomas Dickey
Download version 2.8.6
Happy Browser logo Happy Browser
Igoodsoft Software
Download version 1.03

How To Access Blocked Web Sites March 2, 2009

Posted by Thiyagarajan Veluchamy in Uncategorized.
Tags:
3 comments

i given blow more proxy sites:

  1. http://www.hidemyass.com
  2. http://www.anonymizer.com
  3. http://www.wujie.net
  4. http://www.ultrareach.net
  5. http://surfshield.net
  6. http://www.guardster.com/subscription/proxy_free.php
  7. http://anonymouse.ws/anonwww.html
  8. http://www.browser-x.com
  9. http://www.spysurfing.com
  10. http://www.xerohour.org/hideme
  11. http://www.proxyz.be
  12. http://www.sc0rian.com/prox
  13. https://www.proxify.us
  14. http://kproxy.com/index.jsp
  15. http://www.brawl-hall.com/pages/proxy.php
  16. http://www.proxify.net
  17. http://proxy.computersteroids.com/index0.php
  18. http://www.unipeak.com
  19. http://flyproxy.com
  20. http://alienproxy.com
  21. http://proxify.com/
  22. http://www.unfilter.net
  23. http://www.proxymouse.com
  24. http://www.surfonym.com/cgi-bin/nph-proxy
  25. http://www.superproxy.be/browse.pl
  26. http://www.websiteguru.com/mrnewguy
  27. http://www.letsproxy.com
  28. http://www.fsurf.com
  29. http://indianproxy.com
  30. http://www.letmeby.com
  31. http://Boredatschool.net
  32. http://www.ibypass.org
  33. http://www.ipzap.com/
  34. https://proxify.biz
  35. http://kproxy.com/index.jsp
  36. http://www.attackcensorship.com/attack-censorship.html
  37. http://mrnewguy.com
  38. http://www.evilsprouts.co.uk/defilter
  39. http://www.proxify.info
  40. http://www.torify.com
  41. http://www.switchproxy.com
  42. http://www.proxifree.com
  43. http://www.secure-tunnel.com/
  44. http://www.proxify.cn
  45. http://www.arnit.net/utilities/webproxy/new
  46. http://www.proxify.co.uk
  47. http://www.betaproxy.com
  48. http://www.proxify.org
  49. http://www.proxychoice.com
  50. http://www.proxysnail.com
  51. http://www.anonypost.com
  52. http://www.thestrongestlinks.com
  53. http://www.hujiko.com
  54. http://www.anonproxy.info
  55. http://www.peoplesproxy.com
  56. http://www.freeproxy.us
  57. http://www.proxyweb.net
  58. http://www.nopath.com
  59. http://urlencoded.com
  60. http://www.pole.ws
  61. http://www.browseany.com
  62. http://www.spiderproxy.com
  63. http://www.clickcop.com
  64. http://www.sneakysurf.com
  65. http://www.mywebtunnel.com
  66. http://www.thewebtunnel.com
  67. http://www.3proxy.com
  68. http://www.yourfreeproxy.com
  69. http://www.proxy7.com
  70. http://www.fireprox.com
  71. http://www.stupidcensorship.com
  72. http://www.letsproxy.com
  73. http://www.sneak2.com
  74. http://www.cecid.com
  75. http://www.freeproxy.ca
  76. http://www.ibypass.org
  77. http://www.goproxing.com
  78. http://www.projectbypass.com/
  79. http://www.ipsecret.com
  80. http://www.nomorelimits.net
  81. http://www.proxify.de
  82. http://www.bywhat.com
  83. http://www.snoopblocker.com
  84. http://www.anonymizer.ru
  85. http://www.proxyking.net/
  86. http://www.perlproxy.com
  87. http://www.proxylord.com
  88. http://tntproxy.com
  89. http://satanproxy.com
  90. http://zombieinvasion.info
  91. http://demonproxy.com
  92. http://www.myfreeproxy.com
  93. http://www.gezcem.com/nph-proxy.pl.old
  94. http://mpleger.de
  95. http://www.the-cloak.com/login.html

Top 25 common programming bugs February 17, 2009

Posted by Thiyagarajan Veluchamy in Uncategorized.
Tags: , ,
add a comment

Insecure Interaction between Components

  1. Improper Input Validation
  2. Improper Encoding or Escaping of Output
  3. Failure to Preserve SQL Query Structure (‘SQL Injection’)
  4. Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
  5. Failure to Preserve OS Command Structure (‘OS Command Injection’)
  6. Clear text Transmission of Sensitive Information
  7. Cross-Site Request Forgery (CSRF) 8. Race Condition
  8. Error Message Information Leak

Risky Resource Management

  1. Failure to Constrain Operations within the Bounds of a Memory Buffer
  2. External Control of Critical State Data
  3. External Control of File Name or Path
  4. Un trusted Search Path
  5. Failure to Control Generation of Code (‘Code Injection’)
  6. Download of Code Without Integrity Check
  7. Improper Resource Shutdown or Release
  8. Improper Initialization
  9. Incorrect Calculation

Porous Defenses

  1. Improper Access Control (Authorization)
  2. Use of a Broken or Risky Cryptographic Algorithm
  3. Hard-Coded Password
  4. Insecure Permission Assignment for Critical Resource
  5. Use of Insufficiently Random Values
  6. Execution with Unnecessary Privileges
  7. Client-Side Enforcement of Server-Side Security

Testing Challenges January 3, 2009

Posted by Thiyagarajan Veluchamy in Manual Testing.
Tags:
add a comment

It is human (people) nature to respond to any challenges thrown upon them. But what do human mean by a challenge?

Well one of the definition of challenge is ‘a demanding or stimulating situation‘. A challenge could be ‘a call to engage yourself in a contest‘. As a tester we face different challenges in our profession. These situations can be handled in a better way if we have the skills to analyze the problem and off-course by understanding how our fellow testers are tackling a particular problem in their unique context.

As a tester, we have some challenges which are very unique to our profession and some challenges are more generic in nature. A challenge has classified into two broad categories:

Analytical Challenges – These challenges are not unique to our profession and most of the professions require some degree of analytical skills. Analytic can be defined as “Having the ability to analyze” or “Ability to divide into elements and principle“, given the nature of testing it is very important for testers to have good analytical skills. Like any other skill, analytical skill can also be improved by practice. This skill can be improved by practicing different Puzzles, taking challenges or reading different books to improve your aptitude. Best mechanism of improving this skill is to exercise your brain.

Professional Challenges: Every profession has its own challenges. This section explains the different challenges faced in this field and how you can overcome them. These may be the interaction with the developer, attitude of Management towards testing, identification of tools, their usage and training, interaction with the customers, acceptability and entry-exit criteria for the tests and many more.

Web Test Plan Development July 14, 2008

Posted by Thiyagarajan Veluchamy in Web Test Plan Development.
Tags: , ,
add a comment
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 July 8, 2008

Posted by Thiyagarajan Veluchamy in Understanding Software Defects.
Tags:
add a comment

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.

Web Testing Challenges July 7, 2008

Posted by Thiyagarajan Veluchamy in Web Testing Challenges.
Tags:
add a comment

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

Skills of a Tester’s Skull July 1, 2008

Posted by Thiyagarajan Veluchamy in Testing Skill Improvement.
Tags:
add a comment

Understanding Skills

The first and foremost activity of Software Testing is to understand the requirements/ functionalities of the software to be tested. Formal Documents like Software Requirement Specifications, Software Functional Specifications, Use Case Specifications and other Documents like Minutes of Meeting serves as the key references for planning and executing the testing tasks. The testers must have very good understanding skills to read and understand the information written in these documents. Many a times, it is possible to have many interpretations for the information presented in the documents. The testers must be able to identify the duplicate & ambiguous requirements. If the requirements are not clear or ambiguous, the testers must identify the sources of the requirements and get them clarified. The sources of the requirements in most of the project development team should be Business Analysts, Business Users or any other competent authority as identified by the Project Management team. The testers shall analyze and co-relate the information gathered within the perspective of the project.

Listening Skills

Documents are not the only source of reference for the testing activities. The information required for the testing activities may be acquired through offline meetings, seminars, conferences, etc. The minutes of the meetings, conferences, seminars may or may not be recorded in a formal document. The testers must have very good active listening skills in order to collate and co-relate all of that information and refer them for the testing activities. While the requirements or functionalities of the software are discussed over a meeting, many a times, some part of the requirements are missed out. The testers should be able to identify and get them clarified before heading towards the subsequent testing phases.

Test Planning Skills

All software requirements shall be testable. The software shall be designed in such a way that all software requirements shall be testable. The test plan shall be formulated in such a way that paves the way for validating all the software requirements. In the real time scenario, there could be many requirements that are not testable. The tester with his/her test planning skills should be able to find out a workaround to test those non-testable requirements. If there is no way to test them, that shall be communicated clearly to the appropriate authority. There could be many requirements that are very complex to test and the tester should be able to identify the best approach to test them.

Test Design Skills

Software Testing Science preaches many techniques like Equivalence Class Partitioning, Boundary Value Analysis, Orthogonal Array and many more techniques for an effective test design. The testers shall be aware of all those techniques and apply them into their software test designing practice. The tester shall be aware of various formats and templates to author and present the test cases or test procedures in a neat fashion. The tester shall aware of the best practices and the acceptable standards for designing the test cases. The tester shall be aware of the how to write test cases – non-ambiguous, simple, straight to the point.

The test case needs to contain Test Case Description, Test Steps and its corresponding expected results. The tester shall be aware of how to present the content in these three topics effectively in such a way that they can be read without any ambiguity by all the project stakeholders.

Test Execution Skills

Test Execution is nothing but executing the steps that is specified in the test design documents. During the execution, the testers shall capture the actual results and compare against the expected results specified in the test design documents. If there are any deviations between the expected and actual results, the testers shall consider that as a defect. The tester shall analyze the cause of the defect and if it is found and confirmed in the application under test, the same shall be communicated to the developers and it shall get fixed. If the cause of the defect is found with the test case, the same shall be communicated to the test designers and the test cases shall be modified/ amended accordingly. If the testers are not confident about the application functionalities and the test design documents, they may not confidently come to a conclusion about the defect in case of any discrepancies. This will lead to defects being leaked to the next phase and the testers needs to avoid this scenario. The testers shall be confident about the application functionalities and in case of any ambiguity or clarifications; they need to get them sorted out before executing the tests or at least during the test execution.

Defect Reporting Skills

Defect Reports are one of the critical deliverables from a tester. The defect reports are viewed by the development team, business analysts, project managers, technical managers and the quality assurance engineers along with the testers. Hence, the defect reports shall carry enough information about the defect. Steps to reproduce the defect, its expected result and actual result along with other information such as Severity, Priority, Assigned To (developer), Test Environment details are very critical for a defect report without which, the defect report is considered as incomplete. The tester shall be aware of the importance of the defect report and he/she shall create defect report in such a way that it is non-ambiguous. During the course of fixing the defect, the developers may come back to the testing team for more information regarding the defect and the tester shall provide the same without failing.

Test Automation Skills

Test Automation is a wonderful phenomenon by which the testing cost is drastically reduced. The manual test cases upon automation can be executed by running the automated test scripts. This means that the manual effort to run those automated test cases is not necessary and hence the total test effort is reduced drastically. The testers shall be aware of the technique for adopting test automation into the current testing process. Identifying the test automation candidates is very critical for the success of the automation project. Automation candidates shall be identified in such a way that the testing cost towards manual test execution would reduce significantly. This involves lots of thoughts from the financial perspective as well. The testers shall understand the process of do’s & don’ts of automation to make the automation project successful.

Conclusion

The testers shall understand/ learn and be confident about the application functionalities. Test planning, designing, execution and defect reporting are the basic and essential skills that a tester shall possess and develop in his day-to-day career. Professionals who are perfectionist in using these skills are called as “Testing Professionals” or “Testers” or “Testing Engineers”. Hope now, you are a tester…

Good Test Case July 1, 2008

Posted by Thiyagarajan Veluchamy in Test Case.
Tags:
add a comment

What is Test Case? How to write a good test case?

Test Cases are the implementation of a test case design which will help the software tester to detect defects in the application or the system being tested. This should be the primary goal of any test case or set of test cases. When I write a test case, I think of both types of test cases, positive test cases and negative test cases. Positive test cases are those which execute the happy path in the application and make sure that the happy path is working fine. Negative test cases as the name suggests are destructive test cases which are documented with some out-of-box thinking to break the system.
A Test Case should be documented in a manner that is useful for the current test cycle and any future test cycles. At a bare minimum each test case should contain: Sr No, Summary or Title, Description, Steps to reproduce, Expected Results, Actual Results and Status of the test case or remarks.

Test Case Summary or Title

The Summary or title should contain the essence of the test case including the functional area and purpose of the test. Using a common naming convention that groups test cases encourages reuse and help prevents duplicate test cases from occurring.

Test Case Description

The description should clearly state what sequence of events to be executed by the test case. The Test Case description can apply to one or more test cases; it will often take more than one test case to fully test an area of the application.

Test Case Steps to reproduce

Each test case step should clearly state the navigation, test data, and events required to accomplish the step. Using a common descriptive approach encourages reuse and conformity.

Expected Results of Test Case

The expected behavior of the system after any test case step that requires verification / validation – this could include: screen pop-ups, data updates, display changes, or any other discernable event or transaction on the system that is expected to occur when the test case step is executed.

Status or Remarks

The operational status of the test case – Executed or not executed etc.

Tools for Software Test Automation June 20, 2008

Posted by Thiyagarajan Veluchamy in Tools for Software Test Automation.
Tags:
1 comment so far

The following tools are provide automated functional testing and performance testing for environments including Dot Net, Java, CORBA, WWW, WAP, client/server, UNIX, and Windows & Etc …

1 .Segue Software delivers the industry’s premier e-business reliability products and solutions to help you address the risks and complexities that can affect the performance and quality of your e-business system.

  • SilkTest – Automated functional and regression testing
  • SilkPerformer – Automated load and performance testing
  • SilkMonitor – 24×7 monitoring and reporting of Web, application and database servers
  • SilkPilot – Unit testing of CORBA objects
  • SilkObserver – End-to-end transaction management and monitoring for CORBA applications
  • SilkMeter – Access control and usage metering
  • SilkRealizer – Scenario testing and system monitoring
  • SilkRadar – Automated defect tracking

2. Mercury offers a suite of solutions that automate testing and quality assurance for client/server software and systems, e-business applications, and enterprise resource planning applications.

  • QuickTest ProfessionalTM – E-business functional testing
  • LoadRunner® – Enterprise load testing
  • TestDirectorTM – Integrated test management
  • WinRunner® – Test automation for the enterprise

Recover Scenarios in QTP June 16, 2008

Posted by Thiyagarajan Veluchamy in Recover Scenarios in QTP.
Tags:
3 comments

What are Recover Scenarios?

While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To “recover” the test (and continue running) from these unexpected errors you use Recovery Scenarios.

Next question arises,

When to use “on error resume next” or programmatic handling of errors VS Recovery Scenarios ?

If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or “on error resume next”, rather than depending on a recovery scenario. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically.

For Example:

A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.

You cannot handle this error directly in your test or component, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test or component by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test or component may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it.

I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional User’s Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios >

What constitute Recovery Scenarios?

A recovery scenario consists of the following:

  • Trigger Event. The event that interrupts your run session. For example, a window that may pop up on screen, or a QTP run error.
  • Recovery Operations. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows.
  • Post-Recovery Test Run Option. The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue, if at all. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test.

Recovery scenarios are saved in recovery scenario files having the extension .rs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements.

Is there a method to programmatically call them?

By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery object’s method to force QTP to check for triggers after a specific step in the run session.

For a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object

Limitations of DataTable QTP June 12, 2008

Posted by Thiyagarajan Veluchamy in Limitations of DataTable QTP.
Tags:
add a comment

The limitations listed below are specifically for QTP 8.2:

Maximum worksheet size—65,536 rows by 256 columns
Column width—0 to 255 characters
Text length—16,383 characters
Formula length—1024 characters
Number precision—15 digits
Largest positive number—9.99999999999999E307
Largest negative number— -9.99999999999999E307
Smallest positive number—1E-307
Smallest negative number— -1E-307
Maximum number of names per workbook—Limited by available memory
Maximum length of name—255
Maximum length of format string—255
Maximum number of tables (workbooks)—Limited by system resources (windows and memory)

Some Useful Tips with QTP June 9, 2008

Posted by Thiyagarajan Veluchamy in QTP.
Tags: ,
add a comment

We Sharing some of the useful tips on quick test professional. I used while working and found from gds (Project). I urge the readers to share their experiences/tips they have used while working on QTP. You can use the comments section to do the same.

1. How to add a constant number in a datatable?

This is more to do with MS excel then QTP!! but useful to know because at times it becomes frustrating to the novices.
Just append ‘ to the number
Ex: if you wish to enter 1234567 in datatable then write it as ‘1234567

2. How can i check if a parameter exists in DataTable or not?

The best way would be to use the below code:
on error resume next
val=DataTable(“ParamName”,dtGlobalSheet)
if err.number<> 0 then
‘Parameter does not exist
else
‘Parameter exists
end if

3. How can i check if a checkpoint passes or not?
chk_PassFail = Browser(…).Page(…).WebEdit(…).Check (Checkpoint(“Check1″))
if chk_PassFail then
MsgBox “Check Point passed”
else MsgBox “Check Point failed”
end if

4. My test fails due to checkpoint failing, Can i validate a checkpoint without my test failing due to checpoint failure?
Reporter.Filter = rfDisableAll ‘Disables all the reporting stuff
chk_PassFail = Browser(…).Page(…).WebEdit(…).Check (Checkpoint(“Check1″))
Reporter.Filter = rfEnableAll ‘Enable all the reporting stuff
if chk_PassFail then
MsgBox “Check Point passed”
else
MsgBox “Check Point failed”
end if

5. What is the difference between an Action and a function?

Action is a thing specific to QTP while functions are a generic thing which is a feature of VB Scripting. Action can have a object repository associated with it while a function can’t. A function is just lines of code with some/none parameters and a single return value while an action can have more than one output parameters.

6) Where to use function or action?
Well answer depends on the scenario. If you want to use the OR feature then you have to go for Action only. If the functionality is not about any automation script i.e. a function like getting a string between to specific characters, now this is something not specific to QTP and can be done on pure VB Script, so this should be done in a function and not an action. Code specific to QTP can also be put into an function using DP. Decision of using function/action depends on what any one would be comfortable using in a given situation.

7) When to use a Recovery Scenario and when to us on error resume next?
Recovery scenarios are used when you cannot predict at what step the error can occur or when you know that error won’t occur in your QTP script but could occur in the world outside QTP, again the example would be “out of paper”, as this error is caused by printer device driver. “On error resume next” should be used when you know if an error is expected and dont want to raise it, you may want to have different actions depending upon the error that occurred. Use err.number & err.description to get more details about the error.

8) How to use environment variable?
A simple defintion could be… it is a variable which can be used across the reusable actions and is not limited to one reusable action.
There are two types of environment variables:
1. User-defined
2. Built-in
We can retrieve the value of any environment variable. But we can set the value of only user-defined environment variables.

To set the value of a user-defined environment variable:
Environment (VariableName) = NewValue

To retrieve the value of a loaded environment variable:
CurrValue = Environment (VariableName)

Example
The following example creates a new internal user-defined variable named MyVariable with a value of 10, and then retrieves the variable value and stores it in the MyValue variable.

Environment.Value(“MyVariable“)=10
MyValue=Environment.Value(“MyVariable“)

9) What are the files and subfolders of a QuickTest Professional test?
The files and folders hold binary and text data that are required for the test to run successfully.
The following table provides a description, the type, and comments regarding the files that make up a QuickTest Professional test.

File Name

Description

Type

Comments Regarding File

Test.tsp

Test settings

Binary

Do not edit

Default.xls

Data table parameters

Excel similar

Can be edited using Excel

Parameters.mtr

Parameterization information

Binary

Do not edit

Action

Action folder (See other table)

<!–[if !supportEmptyParas]–> <!–[endif]–>

<!–[if !supportEmptyParas]–> <!–[endif]–>

Default.cfg

Load test configuration file

Text

Do not edit

Default.prm

Load test configuration file

Text

Do not edit

Default.usp

Load test configuration file

Text

Do not edit

.usr

Load test configuration file

Text

Do not edit

Thick_usr.dat

Load test configuration file

Text

Do not edit

Thin_usr.dat

Load test configuration file

Text

Do not edit

Files within Action folder:

File Name

Description

Type

Comments Regarding File

Script.mts

Action script

Text

Edit text preceding the @@ sign only

Resource.mtr

Object Repository

Binary

Do not edit

Snapshots

Active screen files

Folder

Do not edit

There are few more files extensions like

.MTB Batch File
.LCK Locked

10) How to rename a checkpoint (QTP 9.0)?
Example:
Window(“Notepad”).WinEditor(“Edit”).Check CheckPoint(“Edit”)
In the above example, the user would like to change the name of the CheckPoint object from “Edit” to something more meaningful.
Note:
This functionality is new to QuickTest Professional 9.0.This is not available for QTP 8.2 and below.
1. Right-click on the Checkpoint step in the Keyword View or on the Checkpoint object in Expert View.
2. Select “Checkpoint Properties” from the pop-up menu.
3. In the Name field, enter the new checkpoint name.
4. Click . The name of the checkpoint object will be updated within the script.
Example:
Window(“Notepad”).WinEditor(“Edit”).Check CheckPoint(“NewCheckPointName”)
Note:
You must use the QuickTest Professional user interface to change the name of the checkpoint. If you manually change the name of the checkpoint in the script, QuickTest Professional will generate an error during replay. The error message will be similar to the following:

“The “” CheckPoint object was not found in the Object Repository. Check the Object Repository to confirm that the object exists or to find the correct name for the object.”

The CheckPoint object is not a visible object within the object repository, so if you manually modify the name, you may need to recreate the checkpoint to resolve the error.

11) Does QuickTest Professional support Internet Explorer 7.0?
QuickTest Professional 9.1
QuickTest Professional 9.1 supports Microsoft Internet Explorer 7.0 Beta 3. Internet Explorer version 7.0 is now certified to work and to be tested with QuickTest Professional version 9.1.
QuickTest Professional 9.0
QuickTest Professional 9.0 supports Internet Explorer 7.0 Beta 2.
QuickTest Professional 8.2 and below
QuickTest Professional 8.2 and below do not include support for Internet Explorer 7.0.

Does QuickTest Professional support Firefox?
QuickTest Professional 9.1 and 9.2
QuickTest Professional 9.1 provides replay support for Mozilla Firefox 1.5 and Mozilla Firefox 2.0 Alpha 3 (Alpha-level support for Bon Echo 2.0a3).
Notes:

QuickTest Professional 9.1 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.

The .Object property for web objects is not supported in FireFox.

QuickTest Professional 9.0
QuickTest Professional 9.0 provides replay support for Mozilla FireFox 1.5.
Notes:

QuickTest Professional 9.0 will not record on FireFox. You can record a test on Microsoft Internet Explorer and run it on any other supported browser, such as FireFox.

The .Object property for web objects is not supported in FireFox.

QuickTest Professional 8.2 and below

QuickTest Professional 8.2 and below do not have support for Firefox.

12. Problem
After Quick Test Professional is started, Windows Media will not start. It returns the error message “wmplayer.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created.”
If you start Window’s Media Player first, it will continue to work normally after starting QuickTest Professional.
Solution:
Include the Windows Media Player’s executable in the NoBBTApps section of the mic.ini file.
1. Close QuickTest Professional.
2. Go to \bin\mic.ini.
3. Include wmplayer.exe in the NoBBTApps section of mic.ini file.

Example:
[NoBBTApps]
wmplayer.exe=rek
4. Save the mic.ini file and restart QuickTest Professional.

13. What is the lservrc file in QTP?
The lservrc file contains the license codes that have been installed
The lservrc file contains the license codes that have been installed. Whenever a new license is created, the license code is automatically added to this file. The lservrc file is a text file, with no extension.

File Location:

1. For a Concurrent (Floating) license installation:
#server installation directory#\#language#”

Example:
C:\Program Files\XYZ Technologies\ABC Server\English\lservrc
2. For a Seat (Stand-alone) license installation:
#AQT/QTP installation directory#\bin”

Example:
C:\Program Files\Mercury Interactive\QuickTest Professional\Bin\lservrc

14. What to do if you are not able to run QTP from quality center?
This is for especially for newbies with QTP.
Check that you have selected Allow other mercury products to run tests and components from Tools–> Options–> Run Tab.

15. Does QuickTest Professional support Macintosh operating systems?
No, QTP is not expected to run on this OS. Only on Windows.

Regression Testing June 2, 2008

Posted by Thiyagarajan Veluchamy in Regression Testing.
Tags:
1 comment so far

Regression Testing

 

As some one has said, changes are the only thing constant in this world. It holds true for software also, existing software are either being changed or removed from the shelves. These changes could be due to any reason. There could be some critical defects which need to be fixed; there could be some enhancements which have to happen in order to remain in the competition. 

Regression testing is done to ensure that enhancement, defect fixes or any other changes made to the software have not broken any existing functionality.

 

Regression testing is very important, because in most places these days iterative development is used. In iterative development, shorter cycle is used with some functionality added in every cycle. In this scenario, it makes sense to have regression testing for every cycle to make sure that new features are not breaking any existing functionality.

Whenever there are any changes in the system, regression testing is performed. Regression testing can be performed for the complete product or it can be selective. Normally, full regression cycle is executed during the end of testing cycle and partial regression cycle is executed between the test cycles. During the regression cycle it becomes very important to select the proper test cases to get the maximum benefits. Test cases for regression testing should be selected based on the knowledge of 

  • What defect fixes, enhancement or changes have gone into the system?
  • What is the impact of these changes on the other aspect of system?

Focus of the regression testing is always on the impact of the changes in the system. In most of the organizations, priority of the regression defect is always very high. It is normally included in the exit criteria of the product that it should have zero regression defects. 

Regression testing should always happen after the sanity or smoke testing. Sanity/Smoke can be defined as the type of testing which make sure that software is in testable state. Normally, sanity test suite will contain very basic and core test cases. These test cases decide the quality of the build and any failure in the sanity test suite should result in the rejection of build by the test team.

Regression testing is a continuous process and it happens after every release. Test cases are added to the regression suite after every release and repetitively executed for every release. 

Because test cases of regression suite are executed for every release, they are perfect candidate for the automation. Test automation is discussed separately in the Test Automation section of this website.

Performance Testing Strategies May 26, 2008

Posted by Thiyagarajan Veluchamy in Performance Testing Strategies.
Tags:
add a comment

Performance Testing Strategies

The basic purpose of this document is to give a high level introduction to Software Load and Performance testing methodologies and strategies. This document is intended to facilitate Software test Managers, Project Managers, Software Engineers, Test Leads, Test engineers, and QA leads — anyone who is responsible for planning and/or implementation of a successful and cost effective performance testing program.
 

Scope

the scope of all the conceptualization mentioned in this document is only in the Test Execution in Automation Context.

In this context the attributes of Load & Performance testing covered are as follows,

Load / Performance Test Planning

Load / Performance Tool Evaluation / Selection

Load Test Process / Methodology and Test Strategy

Load / Performance Test Start/Stop Criteria

Test Environmental Setup and Pre-Requisites

Test Scenarios Definition including Load Scenario, Data Volume, Virtual Users Ramp Rates and Scripting Guidelines etc.

Pass / Fail / Exit Criteria

Analysis and Report Generation
 
 
2       Load / Performance Test Planning 

To make any operation/mission successive planning plays the most vital role and according to the 80-20 theory, 80% of the time should be spent in planning and 20% in real time plan execution/implementation. In the similar fashion, Software performance test planning is very crucial as well.
Any Software Performance Test Plan should have the minimal contents such as,
Performance Test Strategy and Scope Definitions.

-Test Process and Methodologies to follow in different test phases.

-Test Tool Details (Tool Evaluation, Selection, Configuration, Addins, Third Party Utilities Integration, Os Configurations etc)

-Test Cases Details including Scripting, Library Development and Script Maintenance Mechanisms to be used in Every Performance Test Phases.

-Resource Allocations and Responsibilities for Test Participants.

-Test Life Cycle Tasks Management and Communication Media.

-Risk Management Definitions.

-Test Start /Stop Criteria along with Pass/Fail Criteria Definitions.

-Test Environment Setup Requirements. (Hardware Setup, Software Setup, Os Configurations, Third Party Utilities Setup etc.)

-Multi-Platform Performance Test Strategies.

-Application Deployment Setup Requirements for Load Test.

-Virtual Users, Load (Iterations Vs Users), Volume Load Definitions for Different Load/Performance Test Phases.

-Results Analysis Algorithms and Reporting Format Definitions.

3       Load / Performance Tool Evaluation & Selection
Tool Evaluation are yet another important task in Performance Test Automation wherein there are several things to be considered. In cases wherein the tool evaluation and selection is completely done by the Client then readers may skip this Topic and proceed to next. 

While selecting any tool for Load or/and Performance testing the following things should be analyzed such as, 

-Test Budget Vs Available Load/Performance tools in the market mapping to the Budget.

-Protocols, Development & Deployment Technologies, Platforms, Middle-Ware tools / Servers, Third-Party Integrations of the Application Under test Vs Support for these factors in the available tools with prioritization of the availability in the tool for the Scope of expected test.

-Complexity of the Tool Usage Vs Availability of the tool experts along with the timeline requirements for the tool scripting / load scenario creation / tool configuration with respect to Man-hours and Other Resource Requirements.

-Tools Limitations and Work-Around factor mapping with the current scope of testing.

-Tool’s Integration / Portability Factors with Other Tools used to Monitoring, Analyzing and Test Management.

-On Evaluation and Selection of Base tool, third party monitors / tools to be used in Integration with Main Load Testing Tool should be defined.

(Third Party Monitors / Tools like ‘Optimize IT’, ‘Web logic’, ‘Oracle Tools’, ‘Spotlight On Oracle’, ‘Fog-Light’ and Test Management Tools like Mercury-Test Director, Segue-Silk Plan Pro, Compuare-QA Center etc.)
  

4       Test Process / Methodology and Test Strategy 

Test Process, Methodology and Strategy for any Load / Performance testing will definitely vary for every project based on the Client Requirements / Company Process Implementations but still here we are going to put some light on the common generic performance test process, methodologies and strategies followed in the industry.

By using a methodology a project can make sure that resources are applied to the problem effectively and that the people involved approach the work in a structured way. In Performance testing Process there are couple of classifications as mentioned below,
Benchmark Testing

This task tests the newly coded performance features to assert that they do actually improve the performance of the application. There is always a danger that a new performance feature decreases the performance of the application instead of increasing it. Tests should be constructed so that they executed a standard benchmark style test with the feature switched on and with the feature switched off.

      The first time this particular task is performed the task becomes developing the benchmark tests. When this task is performed in later iterations it becomes re-running the benchmark tests with the new version of the code in order to track whether or not the code is improving.

 
Analysis Testing

      Benchmark tests are good for a basic understanding of what is happening and are very useful for tracking improvements over time but they are not so good at isolating the reasons of the next major performance problem. Analysis Testing refers to designing tests that attempt to isolate the next major performance problem. These kinds of tests may do something completely different to the benchmark tests in order to explore what is happening in the target application. The tests are designed to explore theories as to where the next performance problem may be.

      This is also where supplementary tools are used most often. Additional tools such as method-level profilers and operating system performance monitors can be useful in working out where a problem might be occurring.

Long Running Tests

It is important to include some tests that run for long periods of time. There are a number of problems that may occur only after the target application has been running for more than a day or even after a week. Memory leaks in particular may take many hours before they become measurable. The length of these tests should be related to how often you plan to run the target application before restarting. If you plan to restart the target application every day then the test length should simulate one day’s worth of work but if you plan to restart the target application only once a week then the test length should simulate a week’s worth of work.

      This type of testing involves long periods of time and this causes problems such as,

1.      Since the tests take so long you are not typically able to perform as many of them.

2.      These tests take so long that they tie up resources for long periods of time.

                  One thing that you can do to be compact the work performed over one day into a short period time by making use of how normally a server machine is not run at one hundred percent of CPU for the whole day. By creating a sustained workload for a shorter period of time you can usually simulate on days worth of work in a shorter period. For problems like memory leaks it doesn’t normally matter how long the test takes what is important is how much work the test does. A quick half-hour test may not exercise the application for long enough but a sustained high-workload test that simulates one days worth of work in six hours should hopefully identify any problems.

      For example a typical interactive application that services internal users might look like the following chart with peaks at around 11am in the morning and 2pm in the afternoon.

By making the CPU do more work in less time you can compact the overall length of the test into a shorter period and so perform long running tests more easily.

Due to the hassle and restrictions involved in this kind of testing it should be done after the application is behaving reasonably well with shorter testing periods. But also it shouldn’t be left too late either since it takes so long to run these tests it is a good idea to get started with them before the end of the time allocated to performance testing.

Distributed Testing 

Another issue that often comes up is where the clients are located to do their testing. If the clients are located near where the server is running then the test may not adequately simulate the eventual production configuration. If the eventual production configuration is to have the client processes distributed nation-wide over a company’s private network then some testing should be done to simulate this otherwise if there is a problem with the network then testing with the client processes near to the server may not uncover this.

      There are generally practical problems with doing this kind of testing. There may be many different sites from where the clients may be executed and managing the load testing clients out on all of these sites can be a hassle. Due to these sorts of problems not all of the performance testing has to be done in a distributed way but some of it should be. Also like the long running tests this sort of testing should be done after the application is behaving reasonably well in a non-distributed way. This way the methodologies can be implemented based on the scope of testing requirements at a particular phase of performance testing.

      If we talk about the Test Process in general practice, once the Benchmark attributes like Load Scenario with load (Iterations / Scenario / Script), Virtual users with ramp-up rates, Business Transactions Definitions, Finalization of Tools for testing, Hardware Environment, SW-Environment like OS configuration, DB, Data Dependencies, Tool configurations, Application under test deployment details are finalized and documented the initial base benchmark test can be conducted in a normal circumstances to make sure that the application is in a stable state to go through the heavy load test. If any issues found during this test, then release cycles may be repeated till application reaches enough stability to start heavy Load / Performance test.

      The next task at the end of Baseline Performance test can be to start the Load Test. Load testing is an important task accomplished through Stress and Data Volume testing. This methodology of testing is used to establish an initial sound structure upon which the product is developed. A load test is meant to exercise the design of the application and reveal weaknesses in the targeted product before “General Availability”. By revealing problems during the development we do not only prepare for a successful deployment, but also a long prosperous product life cycle.

      Load testing comprises of Individual Module testing run on Iterative basis. Load tests are conducted against the Application under Test using a varying number of virtual users whose results are used for developers/architects to validate/tune the code / design /configurations for optimizing the product performance. The metrics established from the load test will be compared against the baseline to identify performance discrepancies.

      The cycles of such load tests and tuning can be repeated till the product stability reaches enough to go to production OR stability as defined by the client.

      Along with load testing, Stress testing is implemented as a sub-set of load testing. The stress is nothing but applying the load in the ramp-up of virtual users in the groups at the pre-defined rates. (I.e. Group1 – Users will ramp at rate of 5 users/scenario – 5, 10, 15, 20). There are cases when Client expects to benchmark the bottlenecks for specific application functionalities commonly used/accessed by all users the most and that too at a time. For such cases, we can put rendezvous points at appropriate transaction actions wherein all the users will ramp up at the pre-defined rate but when it comes the time to execute the action of rendezvous action, users will wait till all Virtual Users reach till that point and perform that action at a time. So in such a scenario bottlenecks can be easily located. Basically Stress tests are intended to be modular in design so each functional script can be run independently.

      In the performance testing process, there are cases in which some part of application is data volume dependant like Search Screens wherein the Queries / Stored Procedures Performance based on amount of data volume existing in the database, then for such cases before starting the test, the dump of some huge amount of data should be inserted in the database through some SQL Scripts or Automation Scripts etc. so that the results of such screens can help in database tuning / optimization.

      At the end of all such tests, the results from the load testing tool, monitoring tools give a bright idea about the tuning requirements in the system like CPU, Memory, OS, HW, SW, Code, Application Configuration, Middle-tier servers etc. and such Load Test and Results Analysis Vs tuning cycles can be repeated till the application reaches stability as expected by the client.

 
5       Load / Performance Test Start/Stop Criteria 

In case of any performance testing there should be a defined / documented Start and End Criteria to avoid the adhoc process resulting in weird outputs. This start / end criteria should be well defined in the Performance Test Plan along with all the risk management factors.

The start of any Performance or load testing should be done for any application or any module of the application only when the Design, Database Structure and Application Development platform is finalized and there will be no major changes at any layers of the application, which affect directly or indirectly to the Performance Factor.  It really again depends on the scope of testing such that the test is going to be conducted for a specific Module or the whole System.

Once the Load or Performance Test is conducted, results are collected and analyzed the cycles of tuning will carry on but yes definitely the end criteria should be well defined to Stop this Performance Testing and Tuning Cycles based on various factors like product GA release timelines (Project Deadlines) and Client Requirements in terms of System Stability, Scalability and reliability under load and Performance Tolerance Criterions.

In some projects the end criteria is defined based on the Client Performance Measures Requirements defined for each section of the application so if product reaches to that expected level then that might be considered as the end criteria for Performance Testing.

6       Test Environmental Setup and Pre-Requisites 

In the performance testing, by the term test environment here, it’s composed of hardware environment (Machine, Memory, Virtual Memory, Number of CPU’s etc), Software environment like Os, Os configuration, Files System Settings, Free Space for logs, Application Configuration along with Middle Tier Server and associated Configurations, Database, Network etc.

Among all of the above environmental variables defined few or all might be used for setup based on the Deployment Setup Client / Customer expects to have in production.

This setup also involves the Automation Tools installation, configurations, Agent Installations and setup in Load Clients, Third Party Monitors on Clients / Servers etc.

      There may or may not be any pre-requisites if all of the above variables setup is all set before starting the test but some pre-requisites like Reference Data, Test Input Data in the database Insertion etc.

Also System Settings at Os Level, Tier-Level, and Server Level etc. should be listed in a document as Checklists and should be verified before starting any Performance Test.

7       Test Scenarios 

Test Scenarios Definition includes various tasks like Business Scenarios Definitions, Writing Automation Scripts for Test Cases Corresponding to defined Business / Functional Scenarios, expected Data Volume for Test mapping to Virtual Users Ramp Rates and Scripting Guidelines etc.

       In the test scenario development, the scripts written can be made data driven to facilitate Iterative testing in Load Test Scenarios. Once these details are well defined in Test Automation Plan, then Virtual User Test Scripts can be written to simulate User Client Actions / Client – Server Request-Response Hits etc. On completion of baseline scripting, based on data-drive requirements the test scripts can be parameterized to make them compatible to execute the same functionality / User Actions for different set of Test Data on Iterative basis.

In some typical cases in few scenarios wherein the performance of some sections of the application is based on the volume of the data residing in the database then Data Volume Based Performance Test is a must. In such cases, the data insertion SQL Scripts can be written and executed before the execution of Load Test and Data-Volume based Test Scripts should be mapped to this data.

Also along with these factors definitely the number of Virtual Users, amount of load (i.e. Preset Number of Iterations/script) should be predefined from the Customer Production load Volume in peak and non-peak hours. Also in the Stress test which is a part of load test itself, the Virtual Users need to be set in Ramp Up by the pre-defined rates like 5,10,15,20,25 Users etc. Along with the Stress Ramping Rate setting of the Virtual Users in the load scenario, there are cases wherein if the requirement is to perform a particular Action/Operation by all the virtual users at a time for finding out the bottle neck points, Test Scripts should have rendezvous points for such actions so that whenever all the virtual users are performing different operations for different test cases, they will wait till all Virtual Users get to the rendezvous points and execute that action at a time and at the end of that action then again the Ramp-up of  Virtual Users is re-started.

 
8       Analysis and Report Generation 

Once the results are ready, analysis is the most important job in the whole performance test if the requirements of load or performance test are not defined.

In the analysis, the main criteria for analysis should be to find out the bottle neck points wherein we should be able to track out the transactions / users / hits creating the highest level of performance reduction. The main factors to be consideration are,         

Request / Response Timings to-fro from Client to Server
-Transaction Timings Vs Users
-Transaction Timings Vs Load
-Transaction Timings Vs CPU Utilization
-Server Memory Utilization
-Database Server Performance using DB Server Monitors
-Web / Application Server Performance
-Paging Rate Ratios
-Open Cursor Factors in Database
-Load Balancer Factors
-Network Delays
-Bean Performance Factors using Monitors like Optimize IT for Java Based Applications
-Other Monitors like Application Server (e.g. Web-logic) Monitors etc.

 

Thus now after consolidating all the results for the above points, the statistical analysis should be done and the Performance Test Report should be created such that the Development, Design-Architecture, Database / IT, PMG group can get a clear idea about the Application Performance and all the factors affecting it.

After Analysis then based on the scope the corresponding tuning like Os tuning, Database Tuning, Memory Up-gradations, CPU counts in Multi-CPU machine, Code-Tuning, Application Server Cache tuning or any other tuning as per the scope can be done and same tests executed earlier should be repeated in the tuned environment to make out the differences in the results before and after tuning. These tuning cycles can be repeated until the pre-defined required Performance is achieved. In the next version of this document we will be placing the examples for each type of Performance Analysis with the corresponding graph with all the algorithms used for analysis.

 
9       Pass / Fail  / Exit Criteria 

At the end of the Load / Performance Test execution, we can find the number of failed users, failed transactions or failed scripts but the Pass / Fail Criteria for a particular test should be well defined before execution of the test as basically this criteria entirely depends on the scope of testing and the environment. For e.g. in some cases few transaction steps failed which has some workarounds or the reasons for failing the transactions or virtual users are due to unusual attributes behavior which is not related to the application then the results, or few times the tests / scripts / virtual users / transactions failure might happen due to Load Tool Configuration or Load Tool Defects also so its very important to analyze and make a precise differentiation of the Defect occurred in the test and then finalize whether the test was pass or fail.

Also based on the failed Items due to any of the performance test parameters the Failed Item Details should be included in the Applications Limitations List. By doing so, the limitations list can give a clear picture about the Applications Scalability / Load or Performance Limitations with respect to corresponding Load Parameters which in turn will give inputs for the tuning / enhancements for the Application.

Based on the Test Results tuning cycles will be driven and test phases will as well be repeated but the exit criteria should be pre-defined to avoid hazardous tuning life cycle.

Test Case May 19, 2008

Posted by Thiyagarajan Veluchamy in Test Case.
Tags:
1 comment so far

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.

Testing Life Cycle – Roles and Responsibilities May 12, 2008

Posted by Thiyagarajan Veluchamy in Roles and Responsibilities.
Tags:
1 comment so far

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.

Web Test Plan Development May 5, 2008

Posted by Thiyagarajan Veluchamy in Web Test Plan Development.
Tags: , ,
1 comment so far
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.

Win Runner Navigation April 28, 2008

Posted by Thiyagarajan Veluchamy in Win Runner Navigation.
Tags: , , ,
1 comment so far

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);

Software Testing Interview Questions Part 5 April 27, 2008

Posted by Thiyagarajan Veluchamy in Software Testing Interview Questions.
Tags: , ,
add a comment

46. High severity, low priority bug?

A: — A page is rarely accessed, or some activity is performed rarely but that thing outputs some important Data incorrectly, or corrupts the data, this will be a bug of H severity L priority

47. If project wants to release in 3 months what type of Risk analysis u do in Test plan?

A:– Use risk analysis to determine where testing should be focused. Since it’s rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgment skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include:

• Which functionality is most important to the project’s intended purpose?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which aspects of the application can be tested early in the development cycle?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• Which aspects of similar/related previous projects caused problems?
• Which aspects of similar/related previous projects had large maintenance expenses?
• Which parts of the requirements and design are unclear or poorly thought out?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?
• Which tests will have the best high-risk-coverage to time-required ratio

48. Test cases for IE 6.0 ?

A:– Test cases for IE 6.0 i.e Internet Explorer 6.0:—
1)First I go for the Installation side, means that –
+ is it working with all versions of Windows ,Netscape or other softwares in other words we can say that IE must check with all hardware and software parts.
2) Secondly go for the Text Part means that all the Text part appears in frequent and smooth manner.
3) Thirdly go for the Images Part means that all the Images appears in frequent and smooth manner.
4) URL must run in a better way.
5) Suppose Some other language used on it then URL take the Other Characters, Other than Normal Characters.
6)Is it working with Cookies frequently or not.
7) Is it Concerning with different script like JScript and VBScript.
8) HTML Code work on that or not.
9) Troubleshooting works or not.
10) All the Tool bars are work with it or not.
11) If Page has Some Links, than how much is the Max and Min Limit for that.
12) Test for Installing Internet Explorer 6 with Norton Protected Recycle Bin enabled .
13) Is it working with the Uninstallation Process.
14) Last but not the least test for the Security System for the IE 6.0

49. Where you involve in testing life cycle ,what type of test you perform ?

A:– Generally test engineers involved from entire test life cycle i.e, test plan, test case preparation, execution, reporting. Generally system testing, regression testing, adhoc testing
etc.

50. what is Testing environment in your company ,means hwo testing process start ?

A:– testing process is going as follows
quality assurance unit
quality assurance manager
testlead
test engineer

51. who prepares the use cases?

A:– In Any company except the small company Business analyst prepares the use cases
But in small company Business analyst prepares along with team lead

52. What methodologies have you used to develop test cases?

A:– generally test engineers uses 4 types of methodologies
1. Boundary value analysis
2.Equivalence partition
3.Error guessing
4.cause effect graphing

53. Why we call it as a regression test nor retest?

A:– If we test whether defect is closed or not i.e Retesting But here we are checking the impact also regression means repeated times

54. Is automated testing better than manual testing. If so, why?

A:– Automated testing and manual testing have advantages as well as disadvantages
Advantages: It increase the efficiency of testing process speed in process
reliable
Flexible
disadvantage’s
Tools should have compatibility with our development or deployment tools needs lot of time initially If the requirements are changing continuously Automation is not suitable
Manual: If the requirements are changing continuously Manual is suitable Once the build is stable with manual testing then only we go 4 automation
Disadvantages:
It needs lot of time
We can not do some type of testing manually
E.g Performances

55. what is the exact difference between a product and a project.give an example ?

A:– Project Developed for particular client requirements are defined by client Product developed for market Requirements are defined by company itself by conducting market survey
Example
Project: the shirt which we are interested stitching with tailor as per our specifications is project
Product: Example is “Ready made Shirt” where the particular company will imagine particular measurements they made the product
Mainframes is a product
Product has many mo of versions
but project has fewer versions i.e depends upon change request and enhancements

56. Define Brain Stromming and Cause Effect Graphing? With Eg?

A:– BS:
A learning technique involving open group discussion intended to expand the range of available ideas
OR
A meeting to generate creative ideas. At PEPSI Advertising, daily, weekly and bi-monthly brainstorming sessions are held by various work groups within the firm. Our monthly I-
Power brainstorming meeting is attended by the entire agency staff.
OR
Brainstorming is a highly structured process to help generate ideas. It is based on the principle that you cannot generate and evaluate ideas at the same time. To use brainstorming, you must first gain agreement from the group to try brainstorming for a fixed interval (eg six minutes).

CEG :
A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.

57. Actually by using severity u should know which one u need to solve so what is the need of priority?

A:– I guess severity reflects the seriousness of the bug where as priority refers to which bug should rectify first. of course if the severity is high the same case is with priority in normal.

severity decided by the tester where as priority decided by developers. which one need to solve first knows through priority not with severity. how serious of the bug knows through
severity.

severity is nothing impact of that bug on the application. Priority is nothing but importance to resolve the bug yeah of course by looking severity we can judge but sometimes high severity bug doesn’t have high priority At the same time High priority bug don’t have high severity
So we need both severity and priority

58. What do u do if the bug that u found is not accepted by the developer and he is saying its not reproducible. Note:The developer is in the on site location ?

A:– once again we will check that condition with all reasons. then we will attach screen shots with strong reasons. then we will explain to the project manager and also explain to the client when they contact us

Sometimes bug is not reproducible it is because of different environment suppose development team using other environment and you are using different environment at this situation there is chance of bug not reproducing. At this situation please check the environment in the base line documents that is functional documents if the environment which we r using is correct we will raise it as defect We will take screen shots and sends them with test procedure also

59. what is the difference between three tier and two tier application?

A:– Client server is a 2-tier application. In this, front end or client is connected to
‘Data base server’ through ‘Data Source Name’,front end is the monitoring level.

Web based architecture is a 3-tier application. In this, browser is connected to web server through TCP/IP and web server is connected to Data base server,browser is the monitoring level. In general, Black box testers are concentrating on monitoring level of any type of application.

All the client server applications are 2 tier architectures.
Here in these architecture, all the “Business Logic” is stored in clients and “Data” is stored in Servers. So if user request anything, business logic will b performed at client, and the data is retrieved from Server(DB Server). Here the problem is, if any business logic changes, then we
need to change the logic at each any every client. The best ex: is take a super market, i have branches in the city. At each branch i have clients, so business logic is stored in clients, but the actual data is store in servers.If assume i want to give some discount on some items, so i
need to change the business logic. For this i need to goto each branch and need to change the business logic at each client. This the disadvantage of Client/Server architecture.

So 3-tier architecture came into picture:

Here Business Logic is stored in one Server, and all the clients are dumb terminals. If user requests anything the request first sent to server, the server will bring the data from DB Sever and send it to clients. This is the flow for 3-tier architecture.

Assume for the above. Ex. if i want to give some discount, all my business logic is there in Server. So i need to change at one place, not at each client. This is the main advantage of 3-tier architecture.

Levels of testing April 27, 2008

Posted by Thiyagarajan Veluchamy in Levels of testing.
Tags:
2 comments
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 .

Automation Testing- Win Runner April 24, 2008

Posted by Thiyagarajan Veluchamy in WinRunner Introduction.
Tags: ,
5 comments

Automation Testing- Win Runner

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?
  • Fast
  • Reliable
  • Repeatable
  • Programmable
  • Comprehensive
  • 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

  • Verify
  • Debug
  • 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

Bug Life Cycle April 22, 2008

Posted by Thiyagarajan Veluchamy in Bug life cycle.
Tags: , , ,
add a comment

The main purpose behind any Software Development process is to provide the client (Final/End User of the software product) with a complete solution (software product), which will help him in managing his business/work in cost effective and efficient way. A software product developed is considered successful if it satisfies all the requirements stated by the end user.

 Any software development process is incomplete if the most important phase of Testing of the developed product is excluded. Software testing is a process carried out in order to find out and fix previously undetected bugs/errors in the software product. It helps in improving the quality of the software product and make it secure for client to use.

What is a bug/error?
A bug or error in software product is any exception that can hinder the functionality of either the whole software or part of it.

How do I find out a BUG/ERROR?
Basically, test cases/scripts are run in order to find out any unexpected behavior of the software product under test. If any such unexpected behavior or exception occurs, it is called as a bug.

What is a Test Case?
A test case is a noted/documented set of steps/activities that are carried out or executed on the software in order to confirm its functionality/behavior to certain set of inputs.

What do I do if I find a bug/error?
In normal terms, if a bug or error is detected in a system, it needs to be communicated to the developer in order to get it fixed.

Right from the first time any bug is detected till the point when the bug is fixed and closed, it is assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending Reject, Reject, Deferred, and Closed.

(Please note that there are various ways to communicate the bug to the developer and track the bug status)

Statuses associated with a bug:
New:
When a bug is found/revealed for the first time, the software tester communicates it to his/her team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the bug.

Assigned:
After the bug is reported as ‘New’, it comes to the Development Team. The development team verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix it and a status of ‘Assigned’ is assigned to it.

Open:
Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’ to indicate that he/she is working on it to find a solution.

Fixed:
Once the developer makes necessary changes in the code and verifies the code, he/she marks the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing team.

Pending Retest:
After the bug is fixed, it is passed back to the testing team to get retested and the status of ‘Pending Retest’ is assigned to it.

Retest:
The testing team leader changes the status of the bug, which is previously marked with ‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.

Closed:
After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the tester closes it and marks it with ‘Closed’ status.

Reopen:
If after retesting the software for the bug opened, if the system behaves in the same way or same bug arises once again, then the tester reopens the bug and again sends it back to the developer marking its status as ‘Reopen’.

Pending Reject:
If the developers think that a particular behavior of the system, which the tester reports as a bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as ‘Pending Reject’.

Rejected:
If the Testing Leader finds that the system is working according to the specifications or the bug is invalid as per the explanation from the development, he/she rejects the bug and marks its status as ‘Rejected’.

Postponed:
Sometimes, testing of a particular bug has to be postponed for an indefinite period. This situation may occur because of many reasons, such as unavailability of Test data, unavailability of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.

Deferred:
In some cases a particular bug stands no importance and is needed to be/can be avoided, that time it is marked with ‘Deferred’ status.

Very Basics Of Testing April 22, 2008

Posted by Thiyagarajan Veluchamy in Very Basics Of Testing.
Tags: ,
add a comment

TESTING

Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. Testing is the exposure of the system to trial input to see whether it produces correct output.

Testing Phases:

Software testing phases include the following:

Test activities are determined and test data selected.

The test is conducted and test results are compared with the expected results.

There are various types of Testing:

Unit Testing:

Unit testing is essentially for the verification of the code produced during the coding phase and the goal is test the internal logic of the module/program. In the Generic code project, the unit testing is done during coding phase of data entry forms whether the functions are working properly or not. In this phase all the drivers are tested they are rightly connected or not.

Integration Testing:

All the tested modules are combined into sub systems, which are then tested. The goal is to see if the modules are properly integrated, and the emphasis being on the testing interfaces between the modules. In the generic code integration testing is done mainly on table creation module and insertion module.

System Testing:

It is mainly used if the software meets its requirements. The reference document for this process is the requirement document. Acceptance Testing:

It is performed with realistic data of the client to demonstrate that the software is working satisfactorily. In the Generic code project testing is done to check whether the Creation of tables and respected data entry was working successfully or not.

Testing Methods:

Testing is a process of executing a program to find out errors. If testing is conducted successfully, it will uncover all the errors in the software. Any testing can be done basing on two ways:

White Box Testing:

It is a test case design method that uses the control structures of the procedural design to derive test cases. using this testing a software Engineer can derive the following test cases:

Exercise all the logical decisions on either true or false sides. Execute all loops at their boundaries and within their operational boundaries. Exercise the internal data structures to assure their validity.

Black Box Testing:

It is a test case design method used on the functional requirements of the software. It will help a software engineer to derive sets of input conditions that will exercise all the functional requirements of the program. Black Box testing attempts to find errors in the following categories:

Incorrect or missing functions

Interface errors

Errors in data structures

Performance errors

Initialization and termination errors

By black box testing we derive a set of test cases that satisfy the following criteria:

Test cases that reduce by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing.

Test cases that tell us something about the presence or absence of classes of errors rather than errors associated only with a specific test at hand.

TEST APPROACH :
Testing can be done in two ways:

Bottom up approach

Top down approach

Bottom up approach:

Testing can be performed starting from smallest and lowest level modules and proceeding one at a time. For each module in bottom up testing a short program executes the module and provides the needed data so that the module is asked to perform the way it will when embedded with in the larger system. When bottom level modules are tested attention turns to those on the next level that use the lower level ones they are tested individually and then linked with the previously examined lower level modules.

Top down approach:

This type of testing starts from upper level modules. Since the detailed activities usually performed in the lower level routines are not provided stubs are written. A stub is a module shell called by upper level module and that when reached properly will return a message to the calling module indicating that proper interaction occurred. No attempt is made to verify the correctness of the lower level module.

Phone Interview Tips April 14, 2008

Posted by Thiyagarajan Veluchamy in Phone Interview Tips.
Tags:
add a comment

Now a days, employers use telephone interviews as a way of identifying and recruiting candidates for employment. Phone interviews are often used to screen candidates in order to narrow the pool of applicants who will be invited for in-person interviews.

While you are actively job searching, it is important to be prepared for a phone interview on a moments notice. You never know when a recruiter call and ask if you have a few minutes to talk.

When there is a call for you from company then you need to clear your head and shift your focus from family to your career. When you pick up the phone, ask the recruiter to repeat his or her name. Verify the spelling and write it down. Use the recruiter’s name in your response. You are now ready to make a good impression during your first five minutes.

There are three basic types of telephone interviews:

You initiate a call to the Hiring Manager and he or she is interested in your background. The call from that point forward is an interview.
A company calls you based upon a previous contact. You will likely be unprepared for the call, but it is still an interview.
You have a pre-set time with a company representative to speak further on the phone.
Here are some phone interview tips to help you:

1.Be Prepared For preparing the phone interview, there are several things you can do. To prepare for the phone interview you can consider the following points:

You can keep all of your employer research materials within easy reach of the phone.
You can tape your resume to a wall near the phone. It will help a lot during the call and will be a constant reminder for your job search.
Have a notepad handy to take notes.
If the phone interview will occur at a set time, Following are some additional points you have to consider:

Turn off call waiting on your phone.
Place a “Do Not Disturb” note on your door.
Warm up your voice while waiting for the call.
Have a glass of water handy, so that you will not have a chance to take a break during the call.
Turn off your stereo, TV, and any other potential distraction.

2.Do not be afraid to pick up the phone The first step in the hiring process is the telephone interview. It may happen that when you pick up the phone, the call may be from any company. Then that time ask the recruiter to repeat his or her name. Verify the spelling and write it down. Use the recruiter’s name in your response.
If there is really any problem for you to talk, then ask for a telephone number and a convenient time to call back. You are now ready to make a good impression during your first five minutes.

The phone interview tips will help you master the phone interview and get you to the next step – the face to face interview. So do not afraid to pick the phone.

3.Be a good listener During telephonic interview, you must keep in mind that you must be a good listener.
Avoid interrupting and let the recruiter complete his thought or question before you respond. Ask for clarification. Use open-ended questions. The more information you can gather, the better you can respond. We must know the fact that good listener is the best quality.

4.During phone interview Here are the some points for successful phone interviewing. Follow these simple rules and you should achieve success in this important phase of job-hunting.
Here are some do’s for phone Interviews:

  1. Smile always helps you in every situation. Smiling will project a positive image to the listener and will change the tone of your voice.
  2. Do keep a glass of water handy, in case you need to wet your mouth.
  3. Do know what job you are interviewing for.
  4. Speak slowly and enunciate clearly.
  5. Take your time, it is perfectly acceptable to take a moment to collect your thoughts.
  6. Remember your goal is to set up a face to face interview. After you thank the interviewer ask if it would be possible to meet in person.
  7. Do give accurate and detailed contact information in your cover letter so your interviewers can easily connect with you.
  8. Household members must understand the importance of phone messages in your job search.
  9. Use the person’s title (Mr. or Ms. and their last name.) Only use a first name if they ask you to.
  10. When being interviewed by phone, do make sure you are in a place where you can read notes, take notes, and concentrate.
  11. If you cannot devote enough time to a phone interview, do suggest a specific alternate time to the recruiter.
  12. Give short answers.
  13. Do ensure that you can hear and are being clearly heard.
  14. Do create a strong finish to your phone interview with thoughtful questions.

Following are some Don’ts for phone Interviews:

  1. Do not smoke, chew gum, eat, or drink.
  2. Do not interrupt the interviewer.
  3. Do not cough. If you cannot avoid these behaviors, say, “excuse me.”
  4. Do not feel you have to fill in the silences. If you have completed a response, but the interviewer has not asked his or her next question, do not start anything new; ask a question of your own related to your last response.

5.The Open and Available Technique You have a major advantage in a phone interview which does not exist in a face-to-face interview. You cannot be seen. Use this to your advantage.
Have all of your materials on yourself and the employer open and available on your desk as you are speaking on the phone. This includes not only your resume, but also a “cheat sheet” of compelling story subjects, which you would like to introduce. It can also include a “cheat sheet” about the employer, including specific critical points describing the employer and their products.

As anyone may be interviewer is speaking with you on the other end of the phone, he/she has no idea that you are actually being prompted from a document as you are speaking. All that person can hear is a well-informed, well-prepared interviewee. Keep in mind that this preparation is not “cheating” at all. It is preparation, pure and simple.

So have your materials open and available when you are preparing for a phone interview. They are there to support you and enhance your value to the employer, who will greatly respect your ability to answer questions with focus and meaningful content.

6.Focus on what you offer and can do The phone interview is surprise for us, so we must prepared for the telephonic interview. The recruiter’s mission is to screen candidates and recommend those who will best meet the employer’s needs.
When describing your background, avoid the negative points. You will only get one chance to make a positive first impression. Stay focused by reviewing and use the key points you wrote down about your strengths.

7. Sound positive, self-confident and focused The recruiter has called you indicates that your resume or a member of your network has given him or her a favorable impression of you. You need to confirm this impression. Put a smile on your face and into your voice.
You need to demonstrate your enthusiasm and interest through your voice and telephone manner. Check your voice by taping your voice. Listen it very carefully and make the necessary changes.

8. Write out your responses and practice reading them aloud This will help you to remember the response. By knowing what to say, you will seem more confident and all qualities that recruiters seek in candidates. Most candidates usually are asked about their salary expectations during screening interviews. Recruiters and employers usually have a salary range in mind, and while often unwilling to share it at this stage, they expect you to answer.
Your objective at this point is to win acceptance and be recommended for further consideration. Accordingly, you may want to avoid providing a direct answer to this question. These issues could include non-cash benefits and compensation, scope of responsibilities, work environment, job location, career advancement and others.

9.Ask about the next step At the end of the interview, tell the recruiter you are interested. Ask about the next step in the interview process as well as the hiring timetable. If you do not receive a positive response and you are sincerely interested, ask the recruiter if he or she has any areas of concern.
If there is a misunderstanding about you or the recruiter does not seem certain that you are suitable, try to clarify the problem, then ask again about the next step and timetable.

10.After the Interview After the phone interview. Following are some points which we have to consider after the phone interview:

Take notes about how you answered and what you were asked.
Remember to say “thank you.” at the end of conversation.

Software Testing FAQ Part2 April 7, 2008

Posted by Thiyagarajan Veluchamy in Software Testing FAQ Part2.
Tags:
add a comment
  1. What is Test Bed?
    An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.
  2. What is Software Requirements Specification?
    A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software.
  3. 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.
  4. 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.
  5. What is Scalability Testing?
    Performance testing focused on ensuring the application under test gracefully handles increases in work load.
  6. What is Release Candidate?
    A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).
  7. What is Ramp Testing?
    Continuously raising an input signal until the system breaks down.
  8. What is Race Condition?
    A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.
  9. What is Quality System?
    The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.
  10. What is Quality Policy?
    The overall intentions and direction of an organization as regards quality as formally expressed by top management.
  11. What is Quality Management?
    That aspect of the overall management function that determines and implements the quality policy.
  12. What is Quality Control?
    The operational techniques and the activities used to fulfill and verify requirements of quality.
  13. What is Quality Circle?
    A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.
  14. What is Quality Audit?
    A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.
  15. What is Quality Assurance?
    All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.
  16. 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.
  17. What is Metric?
    A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.
  18. What is Localization Testing?
    This term refers to making software specifically designed for a specific locality.
  19. What is Independent Test Group (ITG)?
    A group of people whose primary responsibility is software testing.
  20. What is Gorilla Testing?
    Testing one particular module, functionality heavily.
  21. What is Gray Box Testing?
    A combination of Black Box and White Box testing methodologies, testing a piece of software against its specification but using some knowledge of its internal workings.
  22. What is Functional Specification?
    A document that describes in detail the characteristics of the product with regard to its intended features.
  23. What is Functional Decomposition?
    A technique used during planning, analysis and design; creates a functional hierarchy for the software.
  24. What is Exhaustive Testing?
    Testing which covers all combinations of input values and preconditions for an element of the software under test.
  25. What is Equivalence Partitioning?
    A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.
  26. What is Equivalence Class?
  27. What is Endurance Testing?
    Checks for memory leaks or other problems that may occur with prolonged execution.
  28. What is Emulator?
    A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.
  29. What is Depth Testing?
    A test that exercises a feature of a product in full detail.
  30. What is Dependency Testing?
    Examines an application’s requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.
  31. What is Defect?
    Non conformance to requirements or functional / program specification
  32. What is Debugging?
    The process of finding and removing the causes of software failures.
  33. 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.
  34. What is Data Flow Diagram?
    A modeling notation that represents a functional decomposition of a system.
  35. What is Cyclomatic Complexity?
    A measure of the logical complexity of an algorithm, used in white-box testing.
  36. What is Conversion Testing?
    Testing of programs or procedures used to convert data from existing systems for use in replacement systems.
  37. 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.
  38. 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.
  39. 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.
  40. What is Component?
    A minimal software item for which a separate specification is available.
  41. What is Code Coverage?
    An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.
  42. What is Code Complete?
    Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.
  43. What is Cause Effect Graph?
    A graphical representation of inputs and the associated outputs effects which can be used to design test cases.
  44. What is Capture/Replay Tool?
    A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.
  45. What is Breadth Testing?
    A test suite that exercises the full functionality of a product but does not test features in detail.
  46. What is Branch Testing?
    Testing in which all branches in the program source code are tested at least once.
  47. What is Boundary Value Analysis?
    BVA is similar to Equivalence Partitioning but focuses on “corner cases” or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.
  48. What is Boundary Testing?
    Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).
  49. What is Binary Portability Testing?
    Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.
  50. What is Baseline?
    The point at which some deliverable produced during the software engineering process is put under formal change control.
  51. What is Basis Set?
    The set of tests derived using basis path testing.
  52. What is Basis Path Testing?
    A white box test case design technique that uses the algorithmic flow of the program to design tests.
  53. What is Basic Block?
    A sequence of one or more consecutive, executable statements containing no branches.
  54. What is Backus-Naur Form?
    A metalanguage used to formally describe the syntax of a language.
  55. What is Automated Testing?
    Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.
    The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.
  56. What is Automated Software Quality (ASQ)?
    The use of software tools, such as automated testing tools, to improve software quality.
  57. What is Application Programming Interface (API)?
    A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.
  58. What is Application Binary Interface (ABI)?
    A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.
  59. What is Agile Testing?
    Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm.
  60. What is Ad Hoc Testing?
    A testing phase where the tester tries to ‘break’ the system by randomly trying the system’s functionality. Can include negative testing as well.
  61.  How do you debug an ASP.NET Web application?
    Attach the aspnet_wp.exe process to the DbgClr debugger.
  62. Why are there five tracing levels in System.Diagnostics.TraceSwitcher?
    The tracing dumps can be quite verbose.
    � For applications that are constantly running you run the risk of overloading the machine and the hard drive.
    � Five levels range from None to Verbose, allowing you to fine-tune the tracing activities.
  63. What’s the difference between the Debug class and Trace class?
    Documentation looks the same. Use Debug class for debug builds, use Trace class for both debug and release builds.
  64. Difference between Smoke Testing and Sanity Testing?
    Smoke Testing is non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details.Sanity Testing is a cursory testing,it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.
  65. What is the difference between QC and QA?
    Quality assurance is the process where the documents for the product to be tested is verified with actual requirements of the customers. It includes inspection, auditing , code review , meeting etc. Quality control is the process where the product is actually executed and the expected behavior is verified by comparing with the actual behavior of the software under test. All the testing types like black box testing, white box testing comes under quality control. Quality assurance is done before quality control.
  66. What is a scenario?
    A scenario defines the events that occur during each testing session. For example, a scenario defines and controls the number of users to emulate, the actions to be performed, and the machines on which the virtual users run their emulations.
  67. What is Difference betweem Manual and Automation Testing?
    This answer is quite simple, Manual is when user needs to do many things based on the test case specified, say like click some tab and check if the tab is working fine or click on a particular URL and check if the web site specified opens. The above stuff can also be done automatically, i.e. through some automated tools like Winrunner , Silk Test etc the things can be automated , so user just has to trigger the tool and the tool will take care of executing , only thing needed is we need to know how to make the testcases automated through that tool which is not very difficult.
  68. What is L10 Testing?
    L10 Testing is Localization Testing, it verifies whether your products are ready for local markets or not.
  69. What is I18N Testing?
    I18N Testing is “Internationalization testing”
    Determine whether your developed product’s support for international character encoding methods is sufficient and whether your product development methodologies take into account international coding standards.
  70. What is SEI? CMM? CMMI? ISO? IEEE? ANSI?
  71. SEI = ‘Software Engineering Institute’ at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.
    CMM = ‘Capability Maturity Model’, now called the CMMI (’Capability Maturity Model Integration’), developed by the SEI. It’s a model of 5 levels of process ‘maturity’ that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMMI ratings by undergoing assessments by qualified auditors.
    Level 1 – characterized by chaos, periodic panics, and heroic efforts required by individuals to successfully complete projects.� Few if any processes in place; successes may not be repeatable.
    Level 2 – software project tracking, requirements management, realistic planning, and configuration management processes are in place; successful practices can be repeated.
    Level 3 – standard software development and maintenance processes are integrated throughout an organization; a Software Engineering Process Group is is in place to oversee software processes, and training programs are used to ensure understanding and compliance.
    Level 4 – metrics are used to track productivity, processes, and products.� Project performance is predictable, and quality is consistently high.
    Level 5 – the focus is on continouous process improvement. The impact of new processes and technologies can be predicted and effectively implemented when required.

    ISO = ‘International Organisation for Standardization’ – The ISO 9001:2000 standard (which replaces the previous standard of 1994) concerns quality systems that are assessed by outside auditors, and it applies to many kinds of production and manufacturing organizations, not just software. It covers documentation, design, development, production, testing, installation, servicing, and other processes. The full set of standards consists of: (a)Q9001-2000 – Quality Management Systems: Requirements; (b)Q9000-2000 – Quality Management Systems: Fundamentals and Vocabulary; (c)Q9004-2000 – Quality Management Systems: Guidelines for Performance Improvements.

    To be ISO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete reassessment is required. Note that ISO certification does not necessarily indicate quality products – it indicates only that documented processes are followed.

    IEEE = ‘Institute of Electrical and Electronics Engineers’ – among other things, creates standards such as ‘IEEE Standard for Software Test Documentation’ (IEEE/ANSI Standard 829), ‘IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008), ‘IEEE Standard for Software Quality Assurance Plans’ (IEEE/ANSI Standard 730) etc

    ANSI = ‘American National Standards Institute’, the primary industrial standards body in the U.S.; publishes some software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).

    Other software development/IT management process assessment methods besides CMMI and ISO 9000 include SPICE, Trillium, TickIT, Bootstrap, ITIL, MOF, and CobiT.

  72. What makes a good Software Test engineer?
    A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgement skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.
  73. What is documentation change management?
    Documentation change management is part of configuration management (CM). CM covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes
  74. What is the role of documentation in QA?
    Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.
  75. How do you perform integration testing?
    First, unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team.
    Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
  76. What is clear box testing?
    Clear box testing is the same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.
  77. What is closed box testing?
    Closed box testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, nor the “inner workings” of the software.
  78. What is open box testing?
    Open box testing is same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.
  79. 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’.
  80. What is Security Testing?
    Security TestingApplication vulnerabilities leave your system open to attacks, Downtime, Data theft, Data corruption and application Defacement. Security within an application or web service is crucial to avoid such vulnerabilities and new threats.While automated tools can help to eliminate many generic security issues, the detection of application vulnerabilities requires independent evaluation of your specific application’s features and functions by experts. An external security vulnerability review by Third Eye Testing will give you the best possible confidence that your application is as secure as possible.
  81. 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. For example, a web server may be stress tested using scripts, bots, and various denial of service tools to observe the performance of a web site during peak loads. Stress testing a subset of load testing. Also see testing, software testing, performance testing.
  82. What is Acceptance Testing?
    Acceptance TestingUser acceptance testing (UAT) is one of the final stages of a software project and will often occur before the customer accepts a new system.Users of the system will perform these tests which, ideally, developers have derived from the User Requirements Specification, to which the system should conform.Test designers will draw up a formal test plan and devise a range of severity levels. The focus in this type of testing is less on simple problems (spelling mistakes, cosmetic problems) and show stoppers (major problems like the software crashing, software will not run etc.). Developers should have worked out these issues during unit testing and integration testing. Rather, the focus is on a final verification of the required business function and flow of the system. The test scripts will emulate real-world usage of the system. The idea is that if the software works as intended and without issues during a simulation of normal use, it will work just the same in production.Results of these tests will allow both the customers and the developers to be confident that the system will work as intended.
  83. What is Compatibility Testing?
    Compatibility TestingOne of the challenges of software development is ensuring that the application works properly on the different platforms and operating systems on the market and also with the applications and devices in its environment.Compatibility testing service aims at locating application problems by running them in real environments, thus ensuring you that your application is compatible with various hardware, operating system and browser versions.
  84. What is Fuzz Testing?
    Fuzz testing is a software testing technique. The basic idea is to attach the inputs of a program to a source of random data. If the program fails (for example, by crashing, or by failing in-built code assertions), then there are defects to correct.The great advantage of fuzz testing is that the test design is extremely simple, and free of preconceptions about system behavior.
  85. What is Walkthrough?
    A review of requirements, designs or code characterized by the author of the object under review guiding the progression of the review.
  86. What is 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.
  87. What is Oracle?
    A mechanism to produce the predicted outcomes to compare with the actual outcomes of the software under test.
  88. What is Mutation Analysis?
    A method to determine test case suite thoroughness by measuring the extent to which a test case suite can discriminate the program from slight variants (mutants) of the program.
  89. Do you know about LCSAJ?
    LCSAJ: A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements, the end of the linear sequence, and the target line to which control flow is transferred at the end of the linear sequence.
  90. What is Inspection?
    A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).
  91. What is Executable Statement?
    A statement which, when compiled, is translated into object code, which will be executed procedurally when the program is running and may perform an action on program data.
  92. Do you know about Cause- Effect graph?
    A graphical representation of inputs or stimuli (causes) with their associated outputs (effects), which can be used to design test cases.
  93. What is Capture/Playback Tool?
    A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time.
  94. What is 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.
  95. What is Big Bang Testing?
    Integration testing where no incremental testing takes place prior to all the system’s components being combined to form the system.
  96. What is Productivity Metrics?
    PRODUCTIVITY METRICSOUTPUT / INPUT OR
    VALUE OF MATERIAL / COST OF PRODUCTIONEg: Non Commented Software Source (NCSS) Per Engineer Per Month
    NCSS per Person Month
    NCSS per Function Point
    NCSS can also be replaced by KLOC (Kilo Lines of Code)
  97. What is Effort Variance?
    Effort variance = (Actual effort – Planned Effort)/Planned effort * 100
  98. How do we calculate Schedule Variance?
    Schedule variance = (Actual time taken – Planned time) / Planned time * 100
  99. How do you create a test plan/design?
    Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking…
    •Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.
    •Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.
    •It is the test team who, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.
    •Test scenarios are executed through the use of test procedures or scripts.
    •Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.
    •Test procedures or scripts include the specific data that will be used for testing the process or transaction.
    •Test procedures or scripts may cover multiple test scenarios.
    •Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.
    •Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.
    • Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.
    •A pre-test meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.
    Inputs for this process:
    •Approved Test Strategy Document.
    •Test tools, or automated test tools, if applicable.
    • Previously developed scripts, if applicable.
    • Test documentation problems uncovered as a result of testing.
    • A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data.
    Outputs for this process:
    • Approved documents of test scenarios, test cases, test conditions and test data.
    •Reports of software design issues, given to software developers for correction.
  100. How do you create a test strategy?
    The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.Inputs for this process:
    •A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
    •A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
    •Testing methodology. This is based on known standards.
    •Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
    •Requirements that the system can not provide, e.g. system limitations.
    Outputs for this process:
    •An approved and signed off test strategy document, test plan, including test cases.
    •Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.
  101. What is the general testing process?
    The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests.
  102. What is software testing methodology?
     is a three step process of…
    Creating a test strategy;
    Creating a test plan/design; and
    Executing tests.
    This methodology can be used and molded to your organization’s needs.
  103. What is a test schedule?
    The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.
  104. What is a Test Configuration Manager?
    Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager.
  105. What is a Technical Analyst?
    Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst.
  106. What is a Database Administrator?
    Database Administrators, Test Build Managers, and System Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator
  107. What is a System Administrator?
    Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator.
  108. What is a Test Build Manager?
    Test Build Managers deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager.
  109. What is a Test Engineer?
    A Test Engineer is an engineer who specializes in testing. Test engineers create test cases, procedures, scripts and generate data. They execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing. They also…
    •Speed up the work of your development staff;
    •Reduce your risk of legal liability;
    •Give you the evidence that your software is correct and operates properly;
    •Improve problem tracking and reporting;
    •Maximize the value of your software;
    •Maximize the value of the devices that use it;
    •Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;
    •Help the work of your development staff, so the development team can devote its time to build up your product;
    •Promote continual improvement;
    •Provide documentation required by FDA, FAA, other regulatory agencies and your customers;
    •Save money by discovering defects ‘early’ in the design process, before failures occur in production, or in the field;
    •Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company.
  110. What is a Test/QA Team Lead?
    The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team
  111. What testing roles are standard on most testing projects?
    Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager.
  112. What is alpha testing?
    Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by end-users or others, not programmers, software engineers, or test engineers
  113. What is acceptance testing?
    Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.
  114. What is comparison testing?
    Comparison testing is testing that compares software weaknesses and strengths to those of competitors’ products.
  115. What is beta testing?
    Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.
  116. What is compatibility testing?
    Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.
  117. What is recovery/error testing?
    Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
  118. What is security/penetration testing?
    Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.
  119. What is installation testing?
    Installation testing is the testing of a full, partial, or upgrade install/uninstall process. The installation test is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the application’s System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. Following installation testing, a sanity test is performed when necessary.
  120. What is load testing?
    Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.
  121. What is performance testing?
    Performance testing verifies loads, volumes and response times, as defined by requirements. Although performance testing is a part of system testing, it can be regarded as a distinct level of testing.
  122. What is sanity testing?
    Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.
  123. What is end-to-end testing?
    End-to-end testing is similar to system testing, the *macro* end of the test scale; it is the testing a complete application in a situation that mimics real life use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.
  124. What is regression testing?
    The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify that changes introduced during the release have not “undone” any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.
  125. What is system testing?
    System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an application’s accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a “simulated real life” test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input.
    Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by SWQA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels.
  126. What is integration testing?
    Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.
  127. What is usability testing?
    Usability testing is testing for ‘user-friendliness’. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Test engineers are needed, because programmers and developers are usually not appropriate as usability testers
  128. What is functional testing?
    Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers should perform functional testing.
  129. What is parallel/audit testing?
    Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.
  130. What is incremental integration testing?
    Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application’s functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.
  131. What is unit testing?
    Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.
  132. What is white box testing?
    White box testing is based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths and conditions.
  133. What is black box testing?
    Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality.
  134. What is a good code?
    A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards.
  135. What is an inspection?
    An inspection is a formal meeting, more formalized than a walk-through and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection.
  136. What is validation?
    Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed
  137. What is verification?
    Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings.
  138. How is testing affected by object-oriented designs?
    Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements.
    While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application’s objects. If the application was well-designed this can simplify test design.
  139. How can it be known when to stop testing?
    This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:
    • Deadlines (release deadlines, testing deadlines, etc.)
    • Test cases completed with certain percentage passed
    • Test budget depleted
    • Coverage of code/functionality/requirements reaches a specified point
    • Bug rate falls below a certain level
    • Beta or alpha testing period ends
  140. What is ‘configuration management’?
    Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes
  141. What’s a ‘test case’?
    • A 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.
    • A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
    • Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it’s useful to prepare test cases early in the development cycle if possible.
  142. What’s the role of documentation in QA?
    • Critical. (Note that documentation can be electronic, not necessarily paper.)
    • QA practices should be documented such that they are repeatable.
    • Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented.
  143. What makes a good software QA engineer?
    • The same qualities a good tester has are useful for a QA engineer.
    • Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization.
    • Communication skills and the ability to understand various sides of issues are important.
    • In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed.
    • An ability to find problems as well as to see ‘what’s missing’ is important for inspections and reviews.
    • There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information.
    • Change management for documentation should be used if possible.
  144. What makes a good test engineer?
    • A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail.
    • Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful.
    • Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming.
    • Judgement skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.
  145. How do you view the contents of the GUI map?
    GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.
  146. What is the different between GUI map and GUI map files?
    The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing 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.
    GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.
  147. If the object does not have a name then what will be the logical name?
    If the object does not have a name then the logical name could be the attached text.
  148. What are the reasons that WinRunner fails to identify an object on the GUI?
    WinRunner fails to identify an object in a GUI due to various reasons.� The object is not a standard windows object. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.
  149. What is the use of Test Director software?
    TestDirector is Mercury Interactive software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create a database of manual and automated tests, build test cycles, run tests, and report and track defects. You can also create reports and graphs to help review the progress of planning tests, running tests, and tracking defects before a software release.
  150. Explain WinRunner testing process?
    WinRunner testing process involves six main stages
    1. Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested
    2. 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.
    3. Debug Test: run tests in Debug mode to make sure they run smoothly
    4. Run Tests: run tests in Verify mode to test your application.
    5. View Results: determines the success or failure of the tests.
    6. 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.

Software testing interview guidelines April 7, 2008

Posted by Thiyagarajan Veluchamy in Software testing interview guidelines.
Tags:
add a comment

Software Testing interview Questions
Software testing job is a high-tech and hi-profile job. The testers are recruited in order to evaluate the quality of specific computer software. Typically, quality refers to many standards including accuracy, comprehensiveness, security, capability, trustworthiness, effectiveness, portability, maintainability, compatibility and usability. A software testing team may comprise of different professional like tester, developer, business analyst, customer, information service management, test manager, senior organization management, and quality team.

Questions on Test Automation

In this section, the interviewer may ask you questions regarding automation such as your familiarity with specific automation tools, your idea of implementation of automation tools in software testing job, problems encountered while using automation tools, whether test automation has the ability to improve test effectiveness, whether it has the ability to substitute manual testing, selection of tools during testing, evaluation of tools, etc.

Questions on Load Testing

This section primarily focuses on your in-depth knowledge concerning software testing job. The questions may include the knowledge regarding the criterion to be used for the selection of web transaction for load testing, purpose of creating virtual user, purpose of recommendation for adding verification checks in all scenarios, context of parameterize text verification check, and necessity of parameterize fields in virtual user script, etc.

General questions

This is indeed a vast area to be concerned. While assessing the ability of an applicant, the interviewer may inquire about his past experience, potential clients, projects encountered, major challenges, etc. The questions may shed light on various arena including STLC, Bug life cycle, requirement of documentations for testing, major defect in Bugzilla defect tracking tools, knowledge regarding artistic, clean, positive and negative testing, knowledge regarding standard keys, non standard keys and customized keys, requirement of synchronization in quick testing, explanation of step generator in QTP, the reason for using object spy in QTP, difference between test effort and test procedure, etc. The interviewer may also put some critical thinking questions in front of the candidate such as if a project is released without testing, the candidate needs to explain the possible situation, etc.

Software Requirements Management April 3, 2008

Posted by Thiyagarajan Veluchamy in Software Requirements Management.
Tags: ,
add a comment

Software Requirements Management

Between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. In plain English, this means that about half of the problems encountered could have been avoided by making it clear, from the very beginning, what the customer expected from the respective project. This is to say that the programming was fine and the developers did their job well – only they did a different job from what they were supposed to.

The definition of a successful program is that it is 100% compliant with its initial requirements. But it those requirements contain mistakes, are unclear or poorly defined, then there is very little one can do to correct the problem later in the process. So, a bit of advance planning simply doubles the success changes of any software project.

The persons in charge with writing the requirements should be the project managers and the team in charge with software engineering, all the stakeholders, the clients and the end-users. Writing good requirements takes time and practice, and, even with all the new tools designed to help you, it will not happen overnight. You need a good, clear, organized mind, good programming knowledge (because you’ll need to know exactly what your team of developers can do, and you need to make sure that you speak the same language with them) and, to a certain extent, good people skills. You will need to get in touch with the clients during this period, and to find out exactly what they want and how they want it. Some of them are not capable of explaining what they need, others don’t have the time to meet you and look over the drafts, other thinks they know better and they give you all the wrong ideas and others will simply be very happy to approve your specifications without having a second look at them. You need to persuade all of them about the importance of this step, hold long, boring meeting, and then “translate” their needs for the programmers and developers. If customers or end-users are not available, despite your best efforts, you can use “surrogates” to simulate the actual users.

Make sure you remain in close contact with the client for the entire duration of the process. Their needs may change, or they may find out about something they forgot to tell you in the beginning – so inform them that you will always be available to meet with them and look at all the options again.

Also, the quality testing department needs to be informed about the requirements from the very beginning, because they will design their tests accordingly, and also they may have some details about what can go wrong in some cases.

One of the biggest issues is the time you have available for writing the requirements. Sometimes, when the deadline is very tight, the developers may start working before you completed the requirements, and this can cause a lot of problems later on.

The process of requirement management ends when the final product is shipped, and the customer is fully satisfied by it. However, the fewer modifications your requirements will suffer, the better for everybody. You should be able to trace your requirements all the time, and we’ll have a look, later on, at the tools that enable you to do this.

In some cases, when a client comes up with an additional issue, it may be too late to change a requirement or ad a new one – the workload and the costs are simply too big to make it worth it. This remains subject to negotiation between you and the client – but your task is to know exactly what would be the effect of implementing new requirements, and to translate it into the language of the client (meaning that the client may not be receptive when he sees how many code lines need to be changed, but he may understand when you tell him how much this will cost).

Tracing requirements also involves additional tests, performed from time to time, to insure that the process runs smoothly and errors are identified and corrected early on. When faced with a big project, you may have different sets of requirements, some that apply to the entire project, and some for parts of it. When a certain design is implemented for a certain requirements, make a note about the effects and the alternatives – it may be useful for future projects (or even for the same project, if the client is not satisfied with the result).

So far, we’ve seen what software requirements are. In the following sections, we’ll show some tips and tools about what good software requirements are. If this section is your responsibility, the wisest thing you can do is to get the IEEE Software Engineering Standards Collection. At 400 dollars, it may be somewhat expensive, but it will give you a lot of useful details about terminology, processes, the quality assurance and the user documentation needed. Also, the standards are conveniently given for each separate unit of the process – the specific part about software requirements specification is IEEE STD 830-1998, which describes the content of good requirements specifications and provides some useful samples. The guide is designed for in-house software, but it can be used for commercial software as well, with minor changes. Another useful reference is the “Standards Guidelines and Examples of System and Software Requirements Engineering” by M. Dorfman and R. Thayer, a compilation covering all the major standards (IEEE, ANSI, NASA and US Military). These are all flexible instruments, and should be used as such. 

Software Testing FAQ Part1 April 2, 2008

Posted by Thiyagarajan Veluchamy in Software Testing FAQ Part1.
Tags: , ,
add a comment

Q: What is software quality assurance?

Software Quality Assurance (SWQA) it is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they are the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organization’s size and business structure. Rob Davis can provide QA and/or SWQA. This document details some aspects of how he can provide software testing/QA service.

Q: What is quality assurance?

Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews. Rob Davis’ QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developers’ test engineers and testers.

Q: Processes and procedures – why follow them?

Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customer’s business processes and procedures, he will follow them. He will also recommend improvements and/or additions.

Q: Standards and templates – what is supposed to be in a document?

All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. It also helps in learning where information is located, making it easier for a user to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.

Q: What are the different levels of testing?

Rob Davis has expertise in testing at all testing levels listed in the these FAQs. At each test level, he documents the results. Each level of testing is either considered black or white box testing.

Q: What is black box testing?

Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing is based on requirements and functionality.

Q: What is white box testing?

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

Q: What is unit testing?

Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

Q: What is parallel/audit testing?

Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.

Q: What is functional testing?

Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers should perform functional testing.

Q: What is usability testing?

Usability testing is testing for ‘user-friendliness’. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Test engineers are needed, because programmers and developers are usually not appropriate as usability testers.

Q: What is incremental integration testing?

Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application’s functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.

Q: What is integration testing?

Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team. Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Q: What is system testing?

System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an application’s accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a “simulated real life” test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input. Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by SWQA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels.

Q: What is end-to-end testing?

End-to-end testing is similar to system testing, the *macro* end of the test scale; it is the testing a complete application in a situation that mimics real life use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.

Q: What is regression testing?

The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify that changes introduced during the release have not “undone” any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.

Q: What is sanity testing?

Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

Q: What is performance testing?

Performance testing verifies loads, volumes and response times, as defined by requirements. Although performance testing is a part of system testing, it can be regarded as a distinct level of testing.

Q: What is load testing?

Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.

Q: What is installation testing?

Installation testing is the testing of a full, partial, or upgrade install/uninstall process. The installation test is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the application’s System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. Following installation testing, a sanity test is performed when necessary.

Q: What is security/penetration testing?

Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

Q: What is recovery/error testing?

Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Q: What is compatibility testing?

Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.

Q: What is comparison testing?

Comparison testing is testing that compares software weaknesses and strengths to those of competitors’ products.

Q: What is acceptance testing?

Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.

Q: What is alpha testing?

Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q: What is beta testing?

Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q: What testing roles are standard on most testing projects?

Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager.

Q: What is a Test/QA Team Lead?

The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team.

Q: What is a Test Engineer?

A Test Engineer is an engineer who specializes in testing. Test engineers create test cases, procedures, scripts and generate data. They execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing. They also… Speed up the work of your development staff; Reduce your risk of legal liability; Give you the evidence that your software is correct and operates properly; Improve problem tracking and reporting; Maximize the value of your software; Maximize the value of the devices that use it; Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down; Help the work of your development staff, so the development team can devote its time to build up your product; Promote continual improvement; Provide documentation required by FDA, FAA, other regulatory agencies and your customers; Save money by discovering defects ‘early’ in the design process, before failures occur in production, or in the field; Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company.

Q: What is a Test Build Manager?

Test Build Managers deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager.

Q: What is a System Administrator?

Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator.

Q: What is a Database Administrator?

Database Administrators, Test Build Managers, and System Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator.

Q: What is a Technical Analyst?

Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst.

Q: What is a Test Configuration Manager?

Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager.

Q: What is a test schedule?

The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.

Q: What is software testing methodology?

One software testing methodology is a three step process of… 1.      Creating a test strategy; 2.      Creating a test plan/design; and 3.      Executing tests. This methodology can be used and molded to your organization’s needs. Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his customers’ applications.

Q: What is the general testing process?

The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests.

Q: How do you create a test strategy?

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment. Inputs for this process: A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data. A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules. Testing methodology. This is based on known standards. Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents. Requirements that the system can not provide, e.g. system limitations. Outputs for this process:  An approved and signed off test strategy document, test plan, including test cases. Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

Q: How do you create a test plan/design?

 Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking… Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application. Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases. It is the test team who, with assistance of developers and clients, develops test cases and scenarios for integration and system testing. Test scenarios are executed through the use of test procedures or scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. Test procedures or scripts include the specific data that will be used for testing the process or transaction. Test procedures or scripts may cover multiple test scenarios. Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope. Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment. Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing. A pre-test meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release. Inputs for this process: Approved Test Strategy Document. Test tools, or automated test tools, if applicable. Previously developed scripts, if applicable. Test documentation problems uncovered as a result of testing. A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data Outputs for this process:  Approved documents of test scenarios, test cases, test conditions and test data. Reports of software design issues, given to software developers for correction.

Q: How do you execute tests?

 Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities. The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing. A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool. Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA (SWQA) Manager and/or Test Team Lead. After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager’s formal acceptance. The test team reviews test document problems identified during testing, and update documents where appropriate. Inputs for this process:  Approved test documents, e.g. Test Plan, Test Cases, Test Procedures. Test tools, including automated test tools, if applicable. Developed scripts. Changes to the design, i.e. Change Request Documents. Test data. Availability of the test team and project team. General and Detailed Design Documents, i.e. Requirements Document, Software Design Document. A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager. Test Readiness Document. Document Updates. Outputs for this process:  Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables. Changes to the code, also known as test fixes. Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems. Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues. Formal record of test incidents, usually part of problem tracking. Base-lined package, also known as tested source and object code, ready for migration to the next level.  

Software Testing FAQ March 26, 2008

Posted by Thiyagarajan Veluchamy in FAQ.
Tags: ,
add a comment

What are 5 common problems in the software development process?

  • poor requirements – if requirements are unclear, incomplete, too general, and not testable, there will be problems.
  • unrealistic schedule – if too much work is crammed in too little time, problems are inevitable.
  • inadequate testing – no one will know whether or not the program is any good until the customer complains or systems crash.
  • featuritis – requests to pile on new features after development is underway; extremely common.
  • miscommunication – if developers don’t know what’s needed or customer’s have erroneous expectations, problems can be expected.

What are 5 common solutions to software development problems?

  • solid requirements – clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. In ‘agile’-type environments, continuous close coordination with customers/end-users is necessary to ensure that changing/emerging requirements are understood.
  • realistic schedules – allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.
  • adequate testing – start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. ‘Early’ testing could include static code analysis/testing, test-first development, unit testing by developers, built-in testing and diagnostic capabilities, automated post-build testing, etc.
  • stick to initial requirements where feasible – be prepared to defend against excessive changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, work closely with customers/end-users to manage expectations. In ‘agile’-type environments, initial requirements may be expected to change significantly, requiring that true agile processes be in place.
  • communication – require walkthroughs and inspections when appropriate; make extensive use of group communication tools – groupware, wiki’s, bug-tracking tools and change management tools, intranet capabilities, etc.; ensure that information/documentation is available and up-to-date – preferably electronic, not paper; promote teamwork and cooperation; use protoypes and/or continuous communication with end-users if possible to clarify expectations.

What are some recent major computer system failures caused by software bugs?

  • News reports in December of 2007 indicated that significant software problems were continuing to occur in a new ERP payroll system for a large urban school system. It was believed that more than one third of employees had received incorrect paychecks at various times since the new system went live in January of that year, resulting in overpayments of $53 million, as well as underpayments. An employees’ union brought a lawsuit against the school system, the cost of the ERP system was expected to rise by 40%, and the non-payroll part of the ERP system was delayed. Inadequate testing reportedly contributed to the problems.
  • In November of 2007 a regional government reportedly brought a multi-million dollar lawsuit against a software services vendor, claiming that the vendor ‘minimized quality’ in delivering software for a large criminal justice information system and the system did not meet requirements. The vendor also sued its subcontractor on the project.
  • In June of 2007 news reports claimed that software flaws in a popular online stock-picking contest could be used to gain an unfair advantage in pursuit of the game’s large cash prizes. Outside investigators were called in and in July the contest winner was announced. Reportedly the winner had previously been in 6th place, indicating that the top 5 contestants may have been disqualified.
  • A software problem contributed to a rail car fire in a major underground metro system in April of 2007 according to newspaper accounts. The software reportedly failed to perform as expected in detecting and preventing excess power usage in equipment on a new passenger rail car, resulting in overheating and fire in the rail car, and evacuation and shutdown of part of the system.
  • Tens of thousands of medical devices were recalled in March of 2007 to correct a software bug. According to news reports, the software would not reliably indicate when available power to the device was too low.
  • A September 2006 news report indicated problems with software utilized in a state government’s primary election, resulting in periodic unexpected rebooting of voter checkin machines, which were separate from the electronic voting machines, and resulted in confusion and delays at voting sites. The problem was reportedly due to insufficient testing.
  • In August of 2006 a U.S. government student loan service erroneously made public the personal data of as many as 21,000 borrowers on it’s web site, due to a software error. The bug was fixed and the government department subsequently offered to arrange for free credit monitoring services for those affected.
  • A software error reportedly resulted in overbilling of up to several thousand dollars to each of 11,000 customers of a major telecommunications company in June of 2006. It was reported that the software bug was fixed within days, but that correcting the billing errors would take much longer.
  • News reports in May of 2006 described a multi-million dollar lawsuit settlement paid by a healthcare software vendor to one of its customers. It was reported that the customer claimed there were problems with the software they had contracted for, including poor integration of software modules, and problems that resulted in missing or incorrect data used by medical personnel.
  • In early 2006 problems in a government’s financial monitoring software resulted in incorrect election candidate financial reports being made available to the public. The government’s election finance reporting web site had to be shut down until the software was repaired.
  • Trading on a major Asian stock exchange was brought to a halt in November of 2005, reportedly due to an error in a system software upgrade. The problem was rectified and trading resumed later the same day.
  • A May 2005 newspaper article reported that a major hybrid car manufacturer had to install a software fix on 20,000 vehicles due to problems with invalid engine warning lights and occasional stalling. In the article, an automotive software specialist indicated that the automobile industry spends $2 billion to $3 billion per year fixing software problems.
  • Media reports in January of 2005 detailed severe problems with a $170 million high-profile U.S. government IT systems project. Software testing was one of the five major problem areas according to a report of the commission reviewing the project. In March of 2005 it was decided to scrap the entire project.
  • In July 2004 newspapers reported that a new government welfare management system in Canada costing several hundred million dollars was unable to handle a simple benefits rate increase after being put into live operation. Reportedly the original contract allowed for only 6 weeks of acceptance testing and the system was never tested for its ability to handle a rate increase.
  • Millions of bank accounts were impacted by errors due to installation of inadequately tested software code in the transaction processing system of a major North American bank, according to mid-2004 news reports. Articles about the incident stated that it took two weeks to fix all the resulting errors, that additional problems resulted when the incident drew a large number of e-mail phishing attacks against the bank’s customers, and that the total cost of the incident could exceed $100 million.
  • A bug in site management software utilized by companies with a significant percentage of worldwide web traffic was reported in May of 2004. The bug resulted in performance problems for many of the sites simultaneously and required disabling of the software until the bug was fixed.
  • According to news reports in April of 2004, a software bug was determined to be a major contributor to the 2003 Northeast blackout, the worst power system failure in North American history. The failure involved loss of electrical power to 50 million customers, forced shutdown of 100 power plants, and economic losses estimated at $6 billion. The bug was reportedly in one utility company’s vendor-supplied power monitoring and management system, which was unable to correctly handle and report on an unusual confluence of initially localized events. The error was found and corrected after examining millions of lines of code.
  • In early 2004, news reports revealed the intentional use of a software bug as a counter-espionage tool. According to the report, in the early 1980’s one nation surreptitiously allowed a hostile nation’s espionage service to steal a version of sophisticated industrial software that had intentionally-added flaws. This eventually resulted in major industrial disruption in the country that used the stolen flawed software.
  • A major U.S. retailer was reportedly hit with a large government fine in October of 2003 due to web site errors that enabled customers to view one anothers’ online orders.
  • News stories in the fall of 2003 stated that a manufacturing company recalled all their transportation products in order to fix a software problem causing instability in certain circumstances. The company found and reported the bug itself and initiated the recall procedure in which a software upgrade fixed the problems.
  • In August of 2003 a U.S. court ruled that a lawsuit against a large online brokerage company could proceed; the lawsuit reportedly involved claims that the company was not fixing system problems that sometimes resulted in failed stock trades, based on the experiences of 4 plaintiffs during an 8-month period. A previous lower court’s ruling that “…six miscues out of more than 400 trades does not indicate negligence.” was invalidated.
  • In April of 2003 it was announced that a large student loan company in the U.S. made a software error in calculating the monthly payments on 800,000 loans. Although borrowers were to be notified of an increase in their required payments, the company will still reportedly lose $8 million in interest. The error was uncovered when borrowers began reporting inconsistencies in their bills.
  • News reports in February of 2003 revealed that the U.S. Treasury Department mailed 50,000 Social Security checks without any beneficiary names. A spokesperson indicated that the missing names were due to an error in a software change. Replacement checks were subsequently mailed out with the problem corrected, and recipients were then able to cash their Social Security checks.
  • In March of 2002 it was reported that software bugs in Britain’s national tax system resulted in more than 100,000 erroneous tax overcharges. The problem was partly attributed to the difficulty of testing the integration of multiple systems.
  • A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-shelf software that had long been used in systems for tracking certain U.S. nuclear materials. The same software had been recently donated to another country to be used in tracking their own nuclear materials, and it was not until scientists in that country discovered the problem, and shared the information, that U.S. officials became aware of the problems.
  • According to newspaper stories in mid-2001, a major systems development contractor was fired and sued over problems with a large retirement plan management system. According to the reports, the client claimed that system deliveries were late, the software had excessive defects, and it caused other systems to crash.
  • In January of 2001 newspapers reported that a major European railroad was hit by the aftereffects of the Y2K bug. The company found that many of their newer trains would not run due to their inability to recognize the date ‘31/12/2000′; the trains were started by altering the control system’s date settings.
  • News reports in September of 2000 told of a software vendor settling a lawsuit with a large mortgage lender; the vendor had reportedly delivered an online mortgage processing system that did not meet specifications, was delivered late, and didn’t work.
  • In early 2000, major problems were reported with a new computer system in a large suburban U.S. public school district with 100,000+ students; problems included 10,000 erroneous report cards and students left stranded by failed class registration systems; the district’s CIO was fired. The school district decided to reinstate it’s original 25-year old system for at least a year until the bugs were worked out of the new system by the software vendors.
  • A review board concluded that the NASA Mars Polar Lander failed in December 1999 due to software problems that caused improper functioning of retro rockets utilized by the Lander as it entered the Martian atmosphere.
  • In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a simple data conversion error. It was determined that spacecraft software used certain data in English units that should have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar Lander mission, which failed for unknown reasons in December 1999. Several investigating panels were convened to determine the process failures that allowed the error to go undetected.
  • Bugs in software supporting a large commercial high-speed data network affected 70,000 business customers over a period of 8 days in August of 1999. Among those affected was the electronic trading system of the largest U.S. futures exchange, which was shut down for most of a week as a result of the outages.
  • In April of 1999 a software bug caused the failure of a $1.2 billion U.S. military satellite launch, the costliest unmanned accident in the history of Cape Canaveral launches. The failure was the latest in a string of launch failures, triggering a complete military and industry review of U.S. space launch programs, including software integration and testing processes. Congressional oversight hearings were requested.
  • A small town in Illinois in the U.S. received an unusually large monthly electric bill of $7 million in March of 1999. This was about 700 times larger than its normal bill. It turned out to be due to bugs in new software that had been purchased by the local power company to deal with Y2K software issues.
  • In early 1999 a major computer game company recalled all copies of a popular new product due to software problems. The company made a public apology for releasing a product before it was ready.
  • The computer system of a major online U.S. stock trading service failed during trading hours several times over a period of days in February of 1999 according to nationwide news reports. The problem was reportedly due to bugs in a software upgrade intended to speed online trade confirmations.
  • In April of 1998 a major U.S. data communications network failed for 24 hours, crippling a large part of some U.S. credit card transaction authorization systems as well as other large U.S. bank, retail, and government data systems. The cause was eventually traced to a software bug.
  • January 1998 news reports told of software problems at a major U.S. telecommunications company that resulted in no charges for long distance calls for a month for 400,000 customers. The problem went undetected until customers called up with questions about their bills.
  • In November of 1997 the stock of a major health industry company dropped 60% due to reports of failures in computer billing systems, problems with a large database conversion, and inadequate software testing. It was reported that more than $100,000,000 in receivables had to be written off and that multi-million dollar fines were levied on the company by government agencies.
  • A retail store chain filed suit in August of 1997 against a transaction processing system vendor (not a credit card company) due to the software’s inability to handle credit cards with year 2000 expiration dates.
  • In August of 1997 one of the leading consumer credit reporting companies reportedly shut down their new public web site after less than two days of operation due to software problems. The new site allowed web site visitors instant access, for a small fee, to their personal credit reports. However, a number of initial users ended up viewing each others’ reports instead of their own, resulting in irate customers and nationwide publicity. The problem was attributed to “…unexpectedly high demand from consumers and faulty software that routed the files to the wrong computers.”
  • In November of 1996, newspapers reported that software bugs caused the 411 telephone information system of one of the U.S. RBOC’s to fail for most of a day. Most of the 2000 operators had to search through phone books instead of using their 13,000,000-listing database. The bugs were introduced by new software modifications and the problem software had been installed on both the production and backup systems. A spokesman for the software vendor reportedly stated that ‘It had nothing to do with the integrity of the software. It was human error.’
  • On June 4 1996 the first flight of the European Space Agency’s new Ariane 5 rocket failed shortly after launching, resulting in an estimated uninsured loss of a half billion dollars. It was reportedly due to the lack of exception handling of a floating-point error in a conversion from a 64-bit integer to a 16-bit signed integer.
  • Software bugs caused the bank accounts of 823 customers of a major U.S. bank to be credited with $924,844,208.32 each in May of 1996, according to newspaper reports. The American Bankers Association claimed it was the largest such error in banking history. A bank spokesman said the programming errors were corrected and all funds were recovered.
  • On January 1 1984 all computers produced by one of the leading minicomputer makers of the time reportedly failed worldwide. The cause was claimed to be a leap year bug in a date handling function utilized in deletion of temporary operating system files. Technicians throughout the world worked for several days to clear up the problem. It was also reported that the same bug affected many of the same computers four years later.
  • Software bugs in a Soviet early-warning monitoring system nearly brought on nuclear war in 1983, according to news reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet satellites picking up sunlight reflections off cloud-tops, but failed to do so. Disaster was averted when a Soviet commander, based on what he said was a ‘…funny feeling in my gut’, decided the apparent missile attack was a false alarm. The filtering software code was rewritten.

What kinds of testing should be considered?

  • 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 ’sane’ 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/operating system/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.

Will automated testing tools make testing easier?

  • Possibly. For small projects, the time needed to learn and implement them may not be worth it unless personnel are already familiar with the tools. For larger projects, or on-going long-term projects they can be valuable.
  • A common type of automated tool is the ‘record/playback’ type. For example, a tester could click through all combinations of menu choices, dialog box choices, buttons, etc. in an application GUI and have them ‘recorded’ and the results logged by a tool. The ‘recording’ is typically in the form of text based on a scripting language that is interpretable by the testing tool. Often the recorded script is manually modified and enhanced. If new buttons are added, or some underlying code in the application is changed, etc. the application might then be retested by just ‘playing back’ the ‘recorded’ actions, and comparing the logging results to check effects of the changes. The problem with such tools is that if there are continual changes to the system being tested, the ‘recordings’ may have to be changed so much that it becomes very time-consuming to continuously update the scripts. Additionally, interpretation and analysis of results (screens, data, logs, etc.) can be a difficult task. Note that there are record/playback tools for text-based interfaces also, and for all types of platforms.
  • Another common type of approach for automation of functional testing is ‘data-driven’ or ‘keyword-driven’ automated testing, in which the test drivers are separated from the data and/or actions utilized in testing (an ‘action’ would be something like ‘enter a value in a text box’). Test drivers can be in the form of automated test tools or custom-written testing software. The data and actions can be more easily maintained – such as via a spreadsheet – since they are separate from the test drivers. The test drivers ‘read’ the data/action information to perform specified tests. This approach can enable more efficient control, development, documentation, and maintenance of automated tests/test cases.
  • Other automated tools can include:

code analyzers – monitor code complexity, adherence to standards, etc.

coverage analyzers – these tools check which parts of the code have been exercised by a test, and may be oriented to code statement coverage, condition coverage, path coverage, etc.

memory analyzers – such as bounds-checkers and leak detectors.

load/performance test tools – for testing client/server and web applications under various load levels.

web test tools – to check that links are valid, HTML code usage is correct, client-side and
server-side programs work, a web site’s interactions are secure.
                                         
other tools – for test case management, documentation management, bug reporting, and configuration management, file and database comparisons, screen captures, security testing, macro recorders, etc.

Test automation is, of course, possible without COTS tools. Many successful automation efforts utilize custom automation software that is targeted for specific projects, specific software applications, or a specific organization’s software development environment. In test-driven agile software development environments, automated tests are often built into the software during (or preceding) coding of the application.

What steps are needed to develop and run software tests?
The following are some of the steps to consider:

  • Obtain requirements, functional design, and internal design specifications and other necessary documents
  • Obtain budget and schedule requirements
  • Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
  • Determine project context, relative to the existing quality culture of the organization and business, and how it might impact testing scope, aproaches, and methods.
  • Identify application’s higher-risk aspects, set priorities, and determine scope and limitations of tests
  • Determine test approaches and methods – unit, integration, functional, system, load, usability tests, etc.
  • Determine test environment requirements (hardware, software, communications, etc.)
  • Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
  • Determine test input data requirements
  • Identify tasks, those responsible for tasks, and labor requirements
  • Set schedule estimates, timelines, milestones
  • Determine input equivalence classes, boundary value analyses, error classes
  • Prepare test plan document and have needed reviews/approvals
  • Write test cases
  • Have needed reviews/inspections/approvals of test cases
  • Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
  • Obtain and install software releases
  • Perform tests
  • Evaluate and report results
  • Track problems/bugs and fixes
  • Retest as needed
  • Maintain and update test plans, test cases, test environment, and testware through life cycle

What is ‘good code’ in project?
‘Good code’ is code that works, is reasonably bug free, and is readable and maintainable. Some organizations have coding ’standards’ that all developers are supposed to adhere to, but everyone has different ideas about what’s best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. ‘Peer reviews’, ‘buddy checks’ pair programming, code analysis tools, etc. can be used to check for problems and enforce standards.
For C and C++ coding, here are some typical ideas to consider in setting rules/standards; these may or may not apply to a particular situation:

  • minimize or eliminate use of global variables.
  • use descriptive function and method names – use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions.
  • use descriptive variable names – use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions.
  • function and method sizes should be minimized; less than 100 lines of code is good, less than 50 lines is preferable.
  • function descriptions should be clearly spelled out in comments preceding a function’s code.
  • organize code for readability.
  • use whitespace generously – vertically and horizontally
  • each line of code should contain 70 characters max.
  • one code statement per line.
  • coding style should be consistent throught a program (eg, use of brackets, indentations, naming conventions, etc.)
  • in adding comments, err on the side of too many rather than too few comments; a common rule of thumb is that there should be at least as many lines of comments (including header blocks) as lines of code.
  • no matter how small, an application should include documentaion of the overall program function and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation.
  • make extensive use of error handling procedures and status and error logging.
  • for C++, to minimize complexity and increase maintainability, avoid too many levels of inheritance in class heirarchies (relative to the size and complexity of the application). Minimize use of multiple inheritance, and minimize use of operator overloading (note that the Java programming language eliminates multiple inheritance and operator overloading.)
  • for C++, keep class methods small, less than 50 lines of code per method is preferable.
  • for C++, make liberal use of exception handlers

 What is a ‘walkthrough’?
A ‘walkthrough’ is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.

 What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed. The term ‘IV & V’ refers to Independent Verification and Validation.

 What makes a good Software Test engineer?
A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgement skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

Visa Interview Questions March 21, 2008

Posted by Thiyagarajan Veluchamy in Visa Interview Questions.
Tags:
1 comment so far

Here we is a set of U.S. visa interview questions that you may be asked as a part of the H-1B visa application process.

  • What is the purpose of your trip to the United States?
  • Why do you want to work in the US?
  • Where are you working currently?
  • What is the company you are going to work in USA?
  • What is your role in US Company?
  • What is your current salary?
  • What is the salary you will get in United States?
  • Have you been to any other country before? If yes, how long was your stay there?
  • Where will you be staying in the U.S.?
  • How long do you plan to stay in the U.S.?
  • Will you be back to your home country?
  • When you will be back to your home country?

Points to Remember:

  • Applicants should practice for the interview with friends.
  • Applicant must arrive at the exact time mentioned in the appointment letter.
  • Applicant must answer all questions clearly during the interview.
  • Applicant must be honest with consular officials at all times.
  • Applicants must ensure that they have all the forms and personal documents that they need to submit at the time of interview.

Some more questions

  1. What is the purpose of your trip to the United States?
  2. Do you have any family in the United States?
  3. Why are you changing your Job?
  4. Why do you want to work in the US?
  5. Have you applied for visa for any other country?
  6. Do you know what is the living cost in the U.S. specific to the place where you are going?
  7. When are you planning to travel?
  8. How will you survive for the first month?
  9. Have you been to any other country before?
    If yes, how long was your stay there?
  10. Will you come back to India?
  11. When will you return to india?
  12. Why would you want to return to India?
  13. Is it your first H1B or visa revalidation?
  14. After the conclusion of your visa, what will you do?

Questions About Your Education/Experience

  1. Are you a student?
  2. Which university is your degree from?
  3. What was your thesis about?
  4. What is the diff between PL SQL n SQL?
  5. What are the software’s you know?
    Do you have work experience with them?
  6. What courses did you complete here [Home Country]?
  7. Show me your certificates.
  8. Can I see your educational certificates and experience letters.
  9. Tell me in detail about all the jobs and work experiences and profile.
  10. What’s your highest educational qualification?

Questions About Your Current Company

  1. How long have you been working?
  2. Where are you working currently?
  3. What is your current salary?
  4. What is your current role in the current company?
  5. Is it an Indian company you currently work for?

Questions About Sponsoring Company

  1. What is the company you are going to work for in USA?
  2. Where are you going to work in US?
  3. Why are you joining [New Company]?
  4. How do you know this is a real company?
  5. When did you receive your offer letter?
  6. What will you be working on there? Is it an internal project?
  7. I need a client letter describing your work project.
  8. Tell me what do you know about [New Company]?
  9. When was the US company founded?
  10. Tell me about the project and the company (client) you will be working for?
  11. How did you find out about this company?
  12. How did you contact the [New Company]?
  13. What is the current project you will be working on?
  14. What are your responsibilities and for which client are you going to be working for? Please explain in detail.
  15. Do you have any proof from your new employer regarding your responsibilities?
  16. Do you have any company photographs?
  17. How long has the company been in the current location?
  18. How many rounds of interviews has the USA company conducted?
    What are they?
  19. What is the name of your interviewer?
  20. Can you give me the dates of your interview?
  21. Who are the clients for your U.S. company?
  22. What are the technologies you are working on?
  23. Who is the President/CEO of the U.S. company?
  24. What kind of projects is the U.S. company working on?
  25. What is the annual turn over of the company?
  26. How many employees does the U.S. Company have?
  27. What’s your designation in [Previous Company] and what’s your designation in the [New Company]?
  28. Will you be working from [New Company] office or client’s place?
  29. Can I see the Employee petition to USCIS and the Tax Returns of the Company?
  30. What is the salary you will get in USA?
  31. How many rounds of interviews did the U.S. company conduct?
    What are they? 4 rounds (2 technical, 1 HR, 1 manager interview)
  32. Can I see your client end letter and itinerary of services.

A few more here

  1. How you came to know about this company?
  2. Where are you working currently?
  3. What is the company you are going to work in USA?
  4. What is your current salary?
  5. What is the salary you will get in USA?
  6. How many rounds of interviews the USA company conducted? What are they?
  7. Who had taken interview for you?
  8. Can you give me the dates of your interview?
  9. Who are the clients for your USA company?
  10. What are the technologies you are working on?
  11. Who is the President/CEO of US company?
  12. What kind of projects US company is working on?
  13. What is the annual turn over of the company?
  14. How many employees in US Company?
  15. Why are you changing your Job?
  16. Why you want to work in US?
  17. Have you applied for any other Country?
  18. Do you know what is the leaving cost in US specific to the place where you are going?
  19. When did you received your offer letter?
  20. What is the current project you are going to work?
  21. What is your current role?
  22. What is your role in US company?
  23. Where are you going to work in US?
  24. What is your designation in US company?
  25. When did US company founded?
  26. What is your current pay?
  27. What is your pay in US company?
  28. When are you planned to travel?
  29. How will you survive for the first month?
  30. Have you been to any other country before?
  31. Will you come back to India?
  32. When you will be back to india?
  33. Why you want to return back?

Quick Test Professional Q & A March 21, 2008

Posted by Thiyagarajan Veluchamy in Quick Test Professional Q & A.
Tags:
8 comments

1. What is Quick test pro?

It’s a Mercury interactive’s keyword driven testing tool

2. By using QTP what kind of applications we can test?

By using QTP we can test standard windows applications, Web objects, ActiveX controls, and Visual basic applications.

3. What is called as test?

Test is a collection of steps organized into one or more actions, which are used to verify that your application performs as expected

4. What is the meaning of business component?

It’s a collection of steps representing a single task in your application. Business components are combined into specific scenario to build business process tests in Mercury Quality center with Business process testing

5. How the test will be created in QTP?

As we navigate through our application, QTP records each step we perform and generates a test or component that graphically displays theses steps in a table-based keyword view.

6. What are all the main tasks which will be accomplished by the QTP after creating a test?

After we have finished recording, we can instruct QTP to check the properties of specific objects in our application by means of enhancement features available in QTP. When we perform a run session, QTP performs each step in our test or component. After the run session ends, we can view a report detailing which steps were performed, and which one succeeded or failed.

7. What is Actions?

A test is composed of actions. The steps we add to a test are included with in the test’s actions. By each test begin with a single action. We can divide our test into multiple actions to organize our test.

8. What are all the main stages will involve in QTP while testing?

  • Creating tests or business components
  • Running tests or business components
  • Analyzing results

9. How the creation of test will be accomplished in QTP?

We can create the test or component by either recording a session on our application or web site or building an object repository and adding steps manually to the keyword view using keyword-driven functionality. We can then modify our test with programming statements.

10. What is the purpose of documentation in key word view?

The documentation column of the key word view used to displays a description of each step in easy to understand sentences.

11. Keyword view in QTP is also termed as

Icon based view

12. What is the use of data table in QTP?

Parameterizing the test

13. What is the use of working with actions?

To design a modular and efficient tests

14. What is the file extension of the code file and object repository file in QTP?

The extension for code file is .vbs and the extension for object repository is .tsr

15. What are the properties we can use for identifying a browser and page when using descriptive programming?

The name property is used to identify the browser and the title property is used to identify the page

16. What are the different scripting languages we can use when working with QTP?

VB script

17. Give the example where we can use a COM interface in our QTP project?

COM interface appears in the scenario of front end and back end.

18. Explain the keyword create object with example

Create object is used to create and return a reference to an automation object.

For example:

Dim ExcelSheetSet

ExcelSheet=createobject(“Excel.Sheet”)

19. How to open excel sheet using QTP script?

You can open excel in QTP by using the following command

System.Util.Run”Path of the file”

20. Is it necessary to learn VB script to work with QTP?

Its not mandate that one should mastered in VB script to work with QTP. It is mostly user friendly and for good results we need to have basic VB or concepts which will suffice

21. If Win Runner and QTP both are functional testing tools from the same company. Why a separate tool QTP came in to picture?

QTP has some additional functionality which is not present in Win Runner. For example, you can test (Functionality and Regression testing) an application developed in .Net technology with QTP, which is not possible to test in Win Runner

22. Explain in brief about the QTP automation object model

The test object model is a large set of object types or classes that QTP uses to represent the objects in our application. Each test object has a list of properties that can uniquely identify objects of that class

23. What is a Run-Time data table?

The test results tree also includes the table-shaped icon that displays the run-time data table-a table that shows the values used to run a test containing data table parameters or the data table output values retrieved from a application under test

24. What are all the components of QTP test script?

QTP test script is a combination of VB script statements and statements that use QuickTest test objects, methods and properties

25. What is test object?

It’s an object that QTP uses to represent an object in our application. Each test object has one or more methods and properties that we can use to perform operations and retrieve values for that object. Each object also has a number of identification properties that can describe the object.

26. What are all the rules and guidelines want to be followed while working in expert view?

Case-sensitivity

VB script is not case sensitive and does not differentiate between upper case and lower case spelling of words.

Text strings

When we enter value as a string, that time we must add quotation marks before and after the string

Variables

We can use variables to store strings, integers, arrays and objects. Using variables helps to make our script more readable and flexible.

Parentheses

To achieve the desired result and to avoid the errors, it is important that we use parentheses() correctly in our statements.

Comments

We can add comments to our statements using apostrophe (‘), either at a beginning of the separate line or at the end of a statement

Spaces

We can add extra blank spaces to our script to improve clarity. These spaces are ignored by the VB script

Additional Interview Questions March 20, 2008

Posted by Thiyagarajan Veluchamy in Additional Interview Questions.
Tags: , , ,
3 comments

Q1. What is verification?

 A: Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, and walkthroughs and inspection meetings. You CAN learn to do verification, with little or no outside help. Get CAN get free information. Click on a link!

Q2. What is validation?

 A: Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.

Q3. What is a walkthrough?

A: A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. It’s the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individual’s or team’s competency.

Q4. What is an inspection?

 A: An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting should be documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection.

Q5. What is quality?

 A: Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things. Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization’s management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free.

Q6. What is good code?

 A: A good code is code that works, is free of bugs and is readable and maintainable. Organizations usually have coding standards all developers should adhere to, but every programmer and software engineer has different ideas about what is best and what are too many or too few rules. We need to keep in mind that excessive use of rules can stifle both productivity and creativity. Peer reviews and code analysis tools can be used to check for problems and enforce standards.

Q7. What is good design?

 A: Design could mean too many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented.

Q8. What is software life cycle?

A: Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.

Q9. Why are there so many software bugs?

 A: Generally speaking, there are bugs in software because of unclear requirements, software complexity, programming errors, changes in requirements, errors made in bug tracking, time pressure, poorly documented code and/or bugs in tools used in software development.

There are unclear software requirements because there is miscommunication as to what the software should or shouldn’t do.

Software complexity. All of the followings contribute to the exponential growth in software and system complexity: Windows interfaces, client-server and distributed applications, data communications, enormous relational databases and the sheer size of applications.

Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.

As to changing requirements, in some fast-changing business environments, continuously modified requirements are a fact of life. Sometimes customers do not understand the effects of changes, or understand them but request them anyway. And the changes require redesign of the software, rescheduling of resources and some of the work already completed have to be redone or discarded and hardware requirements can be effected, too.

Bug tracking can result in errors because the complexity of keeping track of changes can result in errors, too.

Time pressures can cause problems, because scheduling of software projects is not easy and it often requires a lot of guesswork and when deadlines loom and the crunch comes, mistakes will be made.

Code documentation is tough to maintain and it is also tough to modify code that is poorly documented. The result is bugs. Sometimes there is no incentive for programmers and software engineers to document their code and write clearly documented, understandable code. Sometimes developers get kudos for quickly turning out code or programmers and software engineers feel they cannot have job security if everyone can understand the code they write, or they believe if the code was hard to write, it should be hard to read.

Software development tools, including visual tools, class libraries, compilers, scripting tools, can introduce their own bugs. Other times the tools are poorly documented, which can create additional bugs.

Q10. How do you introduce a new software QA process?

A: It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable.  

Q11. Give me five common problems that occur during software development.

A: Poorly written requirements, unrealistic schedules, inadequate testing, and adding new features after development is underway and poor communication.  Requirements are poorly written when requirements are unclear, incomplete, too general, or not testable; therefore there will be problems.

The schedule is unrealistic if too much work is crammed in too little time.

Software testing is inadequate if none knows whether or not the software is any good until customers complain or the system crashes.

It’s extremely common that new features are added after development is underway.

Miscommunication either means the developers don’t know what is needed, or customers have unrealistic expectations and therefore problems are guaranteed.

Q12. Do automated testing tools make testing easier?

A: Yes and no. For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then re-tested by just playing back the recorded actions and compared to the logged results in order to check effects of the change. One problem with such tools is that if there are continual changes to the product being tested, the recordings have to be changed so often that it becomes a very time-consuming task to continuously update the scripts. Another problem with such tools is the interpretation of the results (screens, data, logs, etc.) that can be a time-consuming task. You CAN learn to use automated testing tools, with little or no outside help. Get CAN get free information. Click on a link!

Q13. Give me five solutions to problems that occur during software development.

A: Solid requirements, realistic schedules, adequate testing, firm requirements and good communication.

Ensure the requirements are solid, clear, complete, detailed, cohesive, attainable and testable. All players should agree to requirements. Use prototypes to help nail down requirements.

Have schedules that are realistic. Allow adequate time for planning, design, testing, bug fixing, re-testing, changes and documentation. Personnel should be able to complete the project without burning out.

Do testing that is adequate. Start testing early on, re-test after fixes or changes, and plan for sufficient time for both testing and bug fixing.

Avoid new features. Stick to initial requirements as much as possible. Be prepared to defend design against changes and additions, once development has begun and be prepared to explain consequences. If changes are necessary, ensure they’re adequately reflected in related schedule changes. Use prototypes early on so customers’ expectations are clarified and customers can see what to expect; this will minimize changes later on.

Communicate. Require walkthroughs and inspections when appropriate; make extensive use of e-mail, networked bug-tracking tools, and tools of change management. Ensure documentation is available and up-to-date. Use documentation that is electronic, not paper. Promote teamwork and cooperation.

Q14. What makes a good test engineer?

A: Rob Davis is a good test engineer because he

Has a “test to break” attitude,

Takes the point of view of the customer,

Has a strong desire for quality,

Has an attention to detail, He’s also

Tactful and diplomatic and

Has well a communication skill, both oral and written. And he

Has previous software development experience, too.

Good test engineers have a “test to break” attitude. We, good test engineers, take the point of view of the customer; have a strong desire for quality and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers and an ability to communicate with both technical and non-technical people. Previous software development experience is also helpful as it provides a deeper understanding of the software development process gives the test engineer an appreciation for the developers’ point of view and reduces the learning curve in automated test tool programming.

Q15. What makes a good QA engineer?

A: The same qualities a good test engineer has are useful for a QA engineer. Additionally, Rob Davis understands the entire software development process and how it fits into the business approach and the goals of the organization. Rob Davis’ communication skills and the ability to understand various sides of issues are important. Good QA engineers understand the entire software development process and how it fits into the business approach and the goals of the organization. Communication skills and the ability to understand various sides of issues are important.

Q16. What makes a good resume?

A: On the subject of resumes, there seems to be an unending discussion of whether you should or shouldn’t have a one-page resume. The followings are some of the comments I have personally heard: “Well, Joe Blow (car salesman) said I should have a one-page resume.” “Well, I read a book and it said you should have a one page resume.” “I can’t really go into what I really did because if I did, it’d take more than one page on my resume.” “Gosh, I wish I could put my job at IBM on my resume but if I did it’d make my resume more than one page, and I was told to never make the resume more than one page long.” “I’m confused, should my resume be more than one page? I feel like it should, but I don’t want to break the rules.” Or, here’s another comment, “People just don’t read resumes that are longer than one page.” I have heard some more, but we can start with these. So what’s the answer? There is no scientific answer about whether a one-page resume is right or wrong. It all depends on who you are and how much experience you have. The first thing to look at here is the purpose of a resume. The purpose of a resume is to get you an interview. If the resume is getting you interviews, then it is considered to be a good resume. If the resume isn’t getting you interviews, then you should change it. The biggest mistake you can make on your resume is to make it hard to read. Why? Because, for one, scanners don’t like odd resumes. Small fonts can make your resume harder to read. Some candidates use a 7-point font so they can get the resume onto one page. Big mistake. Two, resume readers do not like eye strain either. If the resume is mechanically challenging, they just throw it aside for one that is easier on the eyes. Three, there are lots of resumes out there these days, and that is also part of the problem. Four, in light of the current scanning scenario, more than one page is not a deterrent because many will scan your resume into their database. Once the resume is in there and searchable, you have accomplished one of the goals of resume distribution. Five, resume readers don’t like to guess and most won’t call you to clarify what is on your resume. Generally speaking, your resume should tell your story. If you’re a college graduate looking for your first job, a one-page resume is just fine. If you have a longer story, the resume needs to be longer. Please put your experience on the resume so resume readers can tell when and for whom you did what. Short resumes — for people long on experience — are not appropriate. The real audience for these short resumes is people with short attention spans and low IQ. I assure you that when your resume gets into the right hands, it will be read thoroughly.  

Q17. What makes a good QA/Test Manager?

A: QA/Test Managers are familiar with the software development process; able to maintain enthusiasm of their team and promote a positive atmosphere; able to promote teamwork to increase productivity; able to promote cooperation between Software and Test/QA Engineers, have the people skills needed to promote improvements in QA processes, have the ability to withstand pressures and say *no* to other managers when quality is insufficient or QA processes are not being adhered to; able to communicate with technical and non-technical people; as well as able to run meetings and keep them focused.

Q18. What is the role of documentation in QA?

A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.

Q19. What about requirements?

A: Requirement specifications are important and one of the most reliable methods of insuring problems in a complex software project is to have poorly documented requirement specifications. Requirements are the details describing an application’s externally perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable and testable. A non-testable requirement would be, for example, “user-friendly”, which is too subjective. A testable requirement would be something such as, “the product shall allow the user to enter their previously-assigned password to access the application”. Care should be taken to involve all of a project’s significant customers in the requirements process. Customers could be in-house or external and could include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, future software maintenance engineers, salespeople and anyone who could later derail the project. If his/her expectations aren’t met, they should be included as a customer, if possible. In some organizations, requirements may end up in high-level project plans, functional specification documents, design documents, or other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by test engineers in order to properly plan and execute tests. Without such documentation there will be no clear-cut way to determine if a software application is performing correctly. You CAN learn to capture requirements, with little or no outside help. Get CAN get free information. Click on a link!

Q20. What is a test plan?

A: A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.

Q21. What is a test case?

A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a…

Test case identifier;

Test case name;

Objective;

Test conditions/setup;

Input data requirements/steps, and

Expected results.

Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

Q22. What should be done after a bug is found?

A: When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn’t create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Q23. What is configuration management?

A: Configuration management (CM) covers the tools and processes used to control, coordinate and track code, requirements, documentation, problems, change requests, designs, tools, compilers, libraries, patches, changes made to them and who makes the changes. Rob Davis has had experience with a full range of CM tools and concepts. Rob Davis can easily adapt to your software tool and process needs.

Q24. What if the software is so buggy it can’t be tested at all?

A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.

Q25. How do you know when to stop testing?

A: This can be difficult to determine. Many modern software applications are so complex and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are…

Deadlines, e.g. release deadlines, testing deadlines;

Test cases completed with certain percentage passed;

Test budget has been depleted;

Coverage of code, functionality, or requirements reaches a specified point;

Bug rate falls below a certain level; or

Beta or alpha testing period ends.

Q26. What if there isn’t enough time for thorough testing?

A: Since it’s rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:

·         Which functionality is most important to the project’s intended purpose?

·         Which functionality is most visible to the user?

·         Which functionality has the largest safety impact?

·         Which functionality has the largest financial impact on users?

·         Which aspects of the application are most important to the customer?

·         Which aspects of the application can be tested early in the development cycle?

·         Which parts of the code are most complex and thus most subject to errors?

·         Which parts of the application were developed in rush or panic mode?

·         Which aspects of similar/related previous projects caused problems?

·         Which aspects of similar/related previous projects had large maintenance expenses?

·         Which parts of the requirements and design are unclear or poorly thought out?

·         What do the developers think are the highest-risk aspects of the application?

·         What kinds of problems would cause the worst publicity?

·         What kinds of problems would cause the most customer service complaints?

·         What kinds of tests could easily cover multiple functionalities?

·         Which tests will have the best high-risk-coverage to time-required ratio?

Q27. What if the project isn’t big enough to justify extensive testing?

A: Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the considerations listed under “What if there isn’t enough time for thorough testing?” do apply. The test engineer then should do “ad hoc” testing, or write up a limited test plan based on the risk analysis.

Q28. What can be done if requirements are changing continuously?

A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application’s initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to…

·         Ensure the code is well commented and well documented; this makes changes easier for the developers.

·         Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.

·         In the project’s initial schedule, allow for some extra time to commensurate with probable changes.

·         Move new requirements to a ‘Phase 2′ version of an application and use the original requirements for the ‘Phase 1′ version.

·         Negotiate to allow only easily implemented new requirements into the project; move more difficult, new requirements into future versions of the application.

·         Ensure customers and management understands scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers decide if the changes are warranted; after all, that’s their job.

·         Balance the effort put into setting up automated testing with the expected effort required to redo them to deal with changes.

·         Design some flexibility into automated test scripts;

·         Focus initial automated testing on application aspects that are most likely to remain unchanged;

·         Devote appropriate effort to risk analysis of changes, in order to minimize regression-testing needs;

·         Design some flexibility into test cases; this is not easily done; the best bet is to minimize the detail in the test cases, or set up only higher-level generic-type test plans;

·         Focus less on detailed test plans and test cases and more on ad-hoc testing with an understanding of the added risk this entails.

Q29. What if the application has functionality that wasn’t in the requirements?

A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer.

If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only affects areas, such as minor improvements in the user interface, it may not be a significant risk.

Q30. How can software QA processes be implemented without stifling productivity?

A: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout will decrease and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings and promote training as part of the QA process. However, no one, especially talented technical types, like bureaucracy and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug fixing and calming of irate customers.

 

Q34. What is software quality assurance?

A: Software Quality Assurance, when Rob Davis does it, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with. Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results. Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they’re the combined responsibility of one group or individual. Also common are project teams, which include a mix of test engineers, testers and developers who work closely together, with overall QA processes monitored by project managers. It depends on what best fits your organization’s size and business structure. Rob Davis can provide QA and/or Software QA. This document details some aspects of how he can provide software testing/QA service.

Q35. What is quality assurance?

A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews.

Rob Davis’ QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developers’ test engineers and testers.

Q36. Process and procedures – why follow them?

A: Detailed and well-written processes and procedures ensure the correct steps are being executed to facilitate a successful completion of a task. They also ensure a process is repeatable. Once Rob Davis has learned and reviewed customer’s business processes and procedures, he will follow them. He will also recommend improvements and/or additions.

Q37. Standards and templates – what is supposed to be in a document?

A: All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. It also helps in learning where information is located, making it easier for a user to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document. Once Rob Davis has learned and reviewed your standards and templates, he will use them. He will also recommend improvements and/or additions.

Q38. What are the different levels of testing?

A: Rob Davis has expertise in testing at all testing levels listed below. At each test level, he documents the results. Each level of testing is either considered black or white box testing.

Q39. What is black box testing?

A: Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing are based on requirements and functionality.

Q40. What is white box testing?

A: White box testing is based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths and conditions.

Q41. What is unit testing?

A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

Q42. What is parallel/audit testing?

A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.

Q43. What is functional testing?

A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers *should* perform functional testing.

Q44. What is usability testing?

A: Usability testing is testing for ‘user-friendliness’. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Programmers and developers are usually not appropriate as usability testers.

Q45. What is incremental integration testing?

A: Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application’s functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers, software engineers, or test engineers.

Q46. What is integration testing?

A: Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements. Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team.

Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Q47. What is system testing?

A: System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment. The purpose of system testing is to validate an application’s accuracy and completeness in performing the functions as designed. System testing simulates real life scenarios that occur in a “simulated real life” test environment and test all functions of the system that are required in real life. System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input.

Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels. You CAN learn system testing, with little or no outside help. Get CAN get free information. Click on a link!

Q48. What is end-to-end testing?

A: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.

Q49. What is regression testing?

A: The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify changes introduced during the release have not “undone” any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.

Q50. What is sanity testing?

A: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

Q51. What is performance testing?

A: Although performance testing is described as a part of system testing, it can be regarded as a distinct level of testing. Performance testing verifies loads, volumes and response times, as defined by requirements.

Q52. What is load testing?

A: Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.

Q53. What is installation testing?

A: Installation testing is testing full, partial, upgrade, or install/uninstall processes. The installation test for a release is conducted with the objective of demonstrating production readiness. This test includes the inventory of configuration items, performed by the application’s System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. When necessary, a sanity test is performed, following installation testing.

Q54. What is security/penetration testing?

A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.

Q55. What is recovery/error testing?

A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Q56. What is compatibility testing?

A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network environment.

Q57. What is comparison testing?

A: Comparison testing is testing that compares software weaknesses and strengths to those of competitors’ products.

Q58. What is acceptance testing?

A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production. The acceptance test is the responsibility of the client/customer or project manager; however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.

Q59. What is alpha testing?

A: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by a group that is independent of the design team, but still within the company, e.g. in-house software test engineers, or software QA engineers.

Q60. What is beta testing?

A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q61. What testing roles are standard on most testing projects?

A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager. You CAN get a job in testing. Click on a link!

Q62. What is a Test/QA Team Lead?

A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team.

Q63. What is a Test Engineer?

A: Test Engineers are engineers who specialize in testing. We, test engineers, create test cases, procedures, scripts and generate data. We execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing. We also…

·         Speed up the work of the development staff;

·         Reduce your organization’s risk of legal liability;

·         Give you the evidence that your software is correct and operates properly;

·         Improve problem tracking and reporting;

·         Maximize the value of your software;

·         Maximize the value of the devices that use it;

·         Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;

·         Help the work of your development staff, so the development team can devote its time to build up your product;

·         Promote continual improvement;

·         Provide documentation required by FDA, FAA, other regulatory agencies and your customers;

·         Save money by discovering defects ‘early’ in the design process, before failures occur in production, or in the field;

·         Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company.

Q64. What is a Test Build Manager?

A: Test Build Managers deliver current software versions to the test environment, install the application’s software and apply software patches, to the both application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager.

Q65. What is a System Administrator?

A: Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator.

Q66. What is a Database Administrator?

A: Test Build Managers, System Administrators and Database Administrators deliver current software versions to the test environment, install the application’s software and apply software patches, to the both application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator.

Q67. What is a Technical Analyst?

A: Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst.

Q68. What is a Test Configuration Manager?

A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager.

Q69. What is a test schedule?

A: The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.

Q70. What is software testing methodology?

A: One software testing methodology is the use a three step process of…

1.      Creating a test strategy;

2.      Creating a test plan/design; and

3.      Executing tests.

This methodology can be used and molded to your organization’s needs. Rob Davis believes that using this methodology is important in the development and in ongoing maintenance of his customers’ applications.

Q71. What is the general testing process?

A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests.

Q72. How do you create a test strategy?

A: The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, and the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Inputs for this process:

·         A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.

·         A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.

·         Testing methodology. This is based on known standards.

·         Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.

·         Requirements that the system can not provide, e.g. system limitations.

Outputs for this process:

·         An approved and signed off test strategy document, test plan, including test cases.

·         Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

Q73. How do you create a test plan/design?

A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking…

Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.

Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.

It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.

Test scenarios are executed through the use of test procedures or scripts.

Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.

Test procedures or scripts include the specific data that will be used for testing the process or transaction.

Test procedures or scripts may cover multiple test scenarios.

Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.

Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.

Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.

A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.

Inputs for this process:

Approved Test Strategy Document.

Test tools, or automated test tools, if applicable.

Previously developed scripts, if applicable.

Test documentation problems uncovered as a result of testing.

A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code and software complexity data.

Outputs for this process:

Approved documents of test scenarios, test cases, test conditions and test data.

Reports of software design issues, given to software developers for correction.

Q74. How do you execute tests?

A: Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities.

The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing.

A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool.

Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead.

After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager’s formal acceptance.

The test team reviews test document problems identified during testing, and update documents where appropriate.

Inputs for this process:

Approved test documents, e.g. Test Plan, Test Cases, Test Procedures.

Test tools, including automated test tools, if applicable.

Developed scripts.

Changes to the design, i.e. Change Request Documents.

Test data.

Availability of the test team and project team.

General and Detailed Design Documents, i.e. Requirements Document, Software Design Document.

A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager.

Test Readiness Document.

Document Updates.

Outputs for this process:

Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables.

Changes to the code, also known as test fixes.

Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems.

Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues.

Formal record of test incidents, usually part of problem tracking.

Base-lined package, also known as tested source and object code, ready for migration to the next level.

Q75. What testing approaches can you tell me about?

A: Each of the followings represents a different testing approach:

Black box testing,

White box testing,

Unit testing,

Incremental testing,

Integration testing,

Functional testing,

System testing,

End-to-end testing,

Sanity testing,

Regression testing,

Acceptance testing,

Load testing,

Performance testing,

Usability testing,

Install/uninstall testing,

Recovery testing,

Security testing,

Compatibility testing,

Exploratory testing, ad-hoc testing,

User acceptance testing,

Comparison testing,

Alpha testing,

Beta testing, and

Mutation testing.

Q76. What is stress testing?

A: Stress testing is testing that investigates the behavior of software (and hardware) under extraordinary operating conditions. For example, when a web server is stress tested, testing aims to find out how many users can be on-line, at the same time, without crashing the server. Stress testing tests the stability of a given system or entity. It tests something beyond its normal operational capacity, in order to observe any negative results. For example, a web server is stress tested, using scripts, bots, and various denials of service tools.

Q77. What is load testing?

A: Load testing simulates the expected usage of a software program, by simulating multiple users that access the program’s services concurrently. Load testing is most useful and most relevant for multi-user systems, client/server models, including web servers. For example, the load placed on the system is increased above normal usage patterns, in order to test the system’s response at peak loads. You CAN learn load testing, with little or no outside help. Get CAN get free information. Click on a link!

Q79. What is the difference between performance testing and load testing?

A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing. You CAN learn testing, with little or no outside help. Get CAN get free information. Click on a link!

Q80. What is the difference between reliability testing and load testing?

A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.

Q81. What is the difference between volume testing and load testing?

A: Load testing is a blanket term that is used in many different ways across the professional software testing community. The term, load testing, is often used synonymously with stress testing, performance testing, reliability testing, and volume testing. Load testing generally stops short of stress testing. During stress testing, the load is so great that errors are the expected results, though there is gray area in between stress testing and load testing.

Q82. What is incremental testing?

A: Incremental testing is partial testing of an incomplete product. The goal of incremental testing is to provide an early feedback to software developers.

Q83. What is software testing?

A: Software testing is a process that identifies the correctness, completeness, and quality of software. Actually, testing cannot establish the correctness of software. It can find defects, but cannot prove there are no defects. You CAN learn software testing, with little or no outside help. Get CAN get free information. Click on a link!

Q84. What is automated testing?

A: Automated testing is a formally specified and controlled method of formal testing approach.

Q85. What is alpha testing?

A: Alpha testing is final testing before the software is released to the general public. First, (and this is called the first phase of alpha testing), the software is tested by in-house developers. They use either debugger software, or hardware-assisted debuggers. The goal is to catch bugs quickly. Then, (and this is called second stage of alpha testing), the software is handed over to us, the software QA staff, for additional testing in an environment that is similar to the intended use.

Q86. What is beta testing?

A: Following alpha testing, “beta versions” of the software are released to a group of people, and limited public tests are performed, so that further testing can ensure the product has few bugs. Other times, beta versions are made available to the general public, in order to receive as much feedback as possible. The goal is to benefit the maximum number of future users.

Q87. What is the difference between alpha and beta testing?

A: Alpha testing is performed by in-house developers and software QA personnel. Beta testing is performed by the public, a few select prospective customers, or the general public.

Q88. What is clear box testing?

A: Clear box testing is the same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic. You CAN learn clear box testing, with little or no outside help. Get CAN get free information. Click on a link!

Q89. What is boundary value analysis?

A: Boundary value analysis is a technique for test data selection. A test engineer chooses values that lie along data extremes. Boundary values include maximum, minimum, just inside boundaries, just outside boundaries, typical values, and error values. The expectation is that, if a systems works correctly for these extreme or special values, then it will work correctly for all values in between. An effective way to test code is to exercise it at its natural boundaries.

Q90. What is ad hoc testing?

A: Ad hoc testing is a testing approach; it is the least formal testing approach.

Q91. What is gamma testing?

A: Gamma testing is testing of software that has all the required features, but it did not go through all the in-house quality checks. Cynics tend to refer to software releases as “gamma testing”.

Q92. What is glass box testing?

A: Glass box testing is the same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.

Q93. What is open box testing?

A: Open box testing is same as white box testing. It is a testing approach that examines the application’s program structure, and derives test cases from the application’s program logic.

Q94. What is black box testing?

A: Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, or the “inner workings” of the software. You CAN learn to do black box testing, with little or no outside help. Get CAN get free information. Click on a link!

Q95. What is functional testing?

A: Functional testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, or the “inner workings” of the software.

Q96. What is closed box testing?

A: Closed box testing is same as black box testing. Black box testing a type of testing that considers only externally visible behavior. Black box testing considers neither the code itself, or the “inner workings” of the software.

Q97. What is bottom-up testing?

A: Bottom-up testing is a technique for integration testing. A test engineer creates and uses test drivers for components that have not yet been developed, because, with bottom-up testing, low-level components are tested first. The objective of bottom-up testing is to call low-level components first, for testing purposes.

Q98. What is software quality?

A: The quality of the software does vary widely from system to system. Some common quality attributes are stability, usability, reliability, portability, and maintainability. See quality standard ISO 9126 for more information on this subject.

Q99. How do test case templates look like?

A: Software test cases are in a document that describes inputs, actions, or events, and their expected results, in order to determine if all features of an application are working correctly. Test case templates contain all particulars of every test case. Often these templates are in the form of a table. One example of this table is a 6-column table, where column 1 is the “Test Case ID Number”, column 2 is the “Test Case Name”, column 3 is the “Test Objective”, column 4 is the “Test Conditions/Setup”, column 5 is the “Input Data Requirements/Steps”, and column 6 is the “Expected Results”. All documents should be written to a certain standard and template. Standards and templates maintain document uniformity. They also help in learning where information is located, making it easier for users to find what they want. Lastly, with standards and templates, information will not be accidentally omitted from a document. You CAN learn to create test case templates, with little or no outside help. Get CAN get free information. Click on a link!

Q100. What is a software fault?

A: Software faults are hidden programming errors. Software faults are errors in the correctness of the semantics of computer programs.

Q101. What is software failure?

A: Software failure occurs when the software does not do what the user expects to see.

Q102. What is the difference between a software fault and a software failure?

A: Software failure occurs when the software does not do what the user expects to see. A software fault, on the other hand, is a hidden programming error. A software fault becomes a software failure only when the exact computation conditions are met, and the faulty portion of the code is executed on the CPU. This can occur during normal usage. Or, when the software is ported to a different hardware platform. Or, when the software is ported to a different complier. Or, when the software gets extended.

WinRunner Testing Process

 

WinRunner Interview Questions And Answers March 20, 2008

Posted by Thiyagarajan Veluchamy in WinRunner Interview Questions And Answers new.
Tags: ,
2 comments

1) Explain WinRunner testing process?

a) WinRunner testing process involves six main stages

i.Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested

ii.Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.

iii.Debug Test: run tests in Debug mode to make sure they run smoothly

iv.Run Tests: run tests in Verify mode to test your application.

v.View Results: determines the success or failure of the tests.

vi.Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window.

2) What is contained in the GUI map?

a) 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.

b) There are 2 types of GUI Map files.

i.Global GUI Map file: a single GUI Map file for the entire application

ii.GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.

3) How does WinRunner recognize objects on the application?

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

4) Have you created test scripts and what is contained in the test scripts?

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

5) How does WinRunner evaluates test results?

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


6) Have you performed debugging of the scripts?

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

7) How do you run your test scripts?

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

8) How do you analyze results and report the defects?

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

9) What are the different modes of recording?

a) There are two type of recording in WinRunner.

i.Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects.

ii.Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.

10) What is the purpose of loading WinRunner Add-Ins?

a) Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator and while executing the script only those functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize the function.

 

11.How to modify the logical name or physical description of the object?

Using GUI editor

12.How Winrunner handles varying window labels?

Using regular expressions

13.How do you write messages to the report?

report_msg

14. How you used WinRunner in your project?

Yes, I have been WinRunner for creating automates scripts for GUI, functional and regression testing of the AUT.

15. Explain WinRunner testing process?

WinRunner testing process involves six main stages

i.Create GUI Map File so that WinRunner can recognize the GUI objects in the application being tested

ii.Create test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where you want to check the response of the application being tested.

iiiDebug Test: run tests in Debug mode to make sure they run smoothly

iv.Run Tests: run tests in Verify mode to test your application.

v.View Results: determines the success or failure of the tests.

vi.Report Defects: If a test run fails due to a defect in the application being tested, you can report information about the defect directly from the Test Results window.

16. What in contained in the GUI map?

a) 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.

b) There are 2 types of GUI Map files.

i.Global GUI Map file: a single GUI Map file for the entire application

ii.GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.

17. How does WinRunner recognize objects on the application?

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

18. Have you created test scripts and what is contained in the test scripts?

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

19. How does WinRunner evaluates test results?

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

20. Have you performed debugging of the scripts?

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

31. How do you view the contents of the GUI map?

a) GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.

32. When you create GUI map do you record all the objects of specific objects?

a) If we are learning a window then WinRunner automatically learns all the objects in the window else we will we identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.

33. What is the purpose of set_window command?

a) Set_Window command sets the focus to the specified window. We use this command to set the focus to the required window before executing tests on a particular window.

Syntax: set_window(, time);

The logical name is the logical name of the window and time is the time the execution has to wait till it gets the given window into focus.

34. How do you load GUI map?

a) We can load a GUI Map by using the GUI_load command.

Syntax: GUI_load();

35. What is the disadvantage of loading the GUI maps through start up scripts?

a) If we are using a single GUI Map file for the entire AUT then the memory used by the GUI Map may be much high.

b) If there is any change in the object being learned then WinRunner will not be able to recognize the object, as it is not in the GUI Map file loaded in the memory. So we will have to learn the object again and update the GUI File and reload it.

36. How do you unload the GUI map?

a) We can use GUI_close to unload a specific GUI Map file or else we call use GUI_close_all command to unload all the GUI Map files loaded in the memory.

Syntax: GUI_close(); or GUI_close_all;

37. What actually happens when you load GUI map?

a) When we load a GUI Map file, the information about the windows and the objects with their logical names and physical description are loaded into memory. So when the WinRunner executes a script on a particular window, it can identify the objects using this information loaded in the memory.

38. What is the purpose of the temp GUI map file?

a) While recording a script, WinRunner learns objects and windows by itself. This is actually stored into the temporary GUI Map file. We can specify whether we have to load this temporary GUI Map file should be loaded each time in the General Options.

39. What is the extension of gui map file?

a) The extension for a GUI Map file is “.gui”.

40. How do you find an object in an GUI map.

a) The GUI Map Editor is been provided with a Find and Show Buttons.

i To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks the selected object.

ii.To find a particular object in a GUI Map file click the Find button, which gives the option to select the object. When the object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.

41. What different actions are performed by find and show button?

a) To find a particular object in the GUI Map file in the application, select the object and click the Show window. This blinks the selected object.

b) To find a particular object in a GUI Map file click the Find button, which gives the option to select the object. When the object is selected, if the object has been learned to the GUI Map file it will be focused in the GUI Map file.

42. How do you identify which files are loaded in the GUI map?

a) The GUI Map Editor has a drop down “GUI File” displaying all the GUI Map files loaded into the memory.

43. How do you modify the logical name or the physical description of the objects in GUI map?

a) You can modify the logical name or the physical description of an object in a GUI map file using the GUI Map Editor.


44. When do you feel you need to modify the logical name?

a) Changing the logical name of an object is useful when the assigned logical name is not sufficiently descriptive or is too long.

45. When it is appropriate to change physical description?

a) Changing the physical description is necessary when the property value of an object changes.

46. How WinRunner handles varying window labels?

a) We can handle varying window labels using regular expressions. WinRunner uses two “hidden” properties in order to use regular expression in an object’s physical description. These properties are regexp_label and regexp_MSW_class.

i.The regexp_label property is used for windows only. It operates “behind the scenes” to insert a regular expression into a window’s label description.

ii.The regexp_MSW_class property inserts a regular expression into an object’s MSW_class. It is obligatory for all types of windows and for the object class object.

[

47. What is the purpose of regexp_label property and regexp_MSW_class property?

a) The regexp_label property is used for windows only. It operates “behind the scenes” to insert a regular expression into a window’s label description.

b) The regexp_MSW_class property inserts a regular expression into an object’s MSW_class. It is obligatory for all types of windows and for the object class object.

48. How do you suppress a regular expression?

a) We can suppress the regular expression of a window by replacing the regexp_label property with label property.

49. How do you copy and move objects between different GUI map files?

a) We can copy and move objects between different GUI Map files using the GUI Map Editor. The steps to be followed are:

i Choose Tools > GUI Map Editor to open the GUI Map Editor.

ii.Choose View > GUI Files.

iii.Click Expand in the GUI Map Editor. The dialog box expands to display two GUI map files simultaneously.

iv. View a different GUI map file on each side of the dialog box by clicking the file names in the GUI File lists.

v.In one file, select the objects you want to copy or move. Use the Shift key and/or Control key to select multiple objects. To select all objects in a GUI map file, choose Edit > Select All.

vi.Click Copy or Move.

vii.To restore the GUI Map Editor to its original size, click Collapse.

50. How do you select multiple objects during merging the files?

a) Use the Shift key and/or Control key to select multiple objects. To select all objects in a GUI map file, choose Edit > Select All.

51. How do you clear a GUI map files?

a) We can clear a GUI Map file using the “Clear All” option in the GUI Map Editor.

52. How do you filter the objects in the GUI map?

a) GUI Map Editor has a Filter option. This provides for filtering with 3 different types of options.

i. Logical name displays only objects with the specified logical name.

ii. Physical description displays only objects matching the specified physical description. Use any substring belonging to the physical description.

iii. Class displays only objects of the specified class, such as all the push buttons.

53.How do you configure gui map?

a) When WinRunner learns the description of a GUI object, it does not learn all its properties. Instead, it learns the minimum number of properties to provide a unique identification of the object.

b) Many applications also contain custom GUI objects. A custom object is any object not belonging to one of the standard classes used by WinRunner. These objects are therefore assigned to the generic “object” class. When WinRunner records an operation on a custom object, it generates obj_mouse_ statements in the test script.

c) If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure the properties WinRunner uses to identify a custom object during Context Sensitive testing. The mapping and the configuration you set are valid only for the current WinRunner session. To make the mapping and the configuration permanent, you must add configuration statements to your startup test script.

54.W hat is the purpose of GUI map configuration?

a) GUI Map configuration is used to map a custom object to a standard object.

55. How do you make the configuration and mappings permanent?

a) The mapping and the configuration you set are valid only for the current WinRunner session. To make the mapping and the configuration permanent, you must add configuration statements to your startup test script.

56. What is the purpose of GUI spy?

a) Using the GUI Spy, you can view the properties of any GUI object on your desktop. You use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box. You can choose to view all the properties of an object, or only the selected set of properties that WinRunner learns.

57. What is the purpose of obligatory and optional properties of the objects?

a) For each class, WinRunner learns a set of default properties. Each default property is classified “obligatory” or “optional”.

i. An obligatory property is always learned (if it exists).

ii.An optional property is used only if the obligatory properties do not provide unique identification of an object. These optional properties are stored in a list. WinRunner selects the minimum number of properties from this list that are necessary to identify the object. It begins with the first property in the list, and continues, if necessary, to add properties to the description until it obtains unique identification for the object.

58. When the optional properties are learned?

a) An optional property is used only if the obligatory properties do not provide unique identification of an object.

59. What is the purpose of location indicator and index indicator in GUI map configuration?

a) In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:

i. A location selector uses the spatial position of objects.

1. The location selector uses the spatial order of objects within the window, from the top left to the bottom right corners, to differentiate among objects with the same description.

ii. An index selector uses a unique number to identify the object in a window.

1. The index selector uses numbers assigned at the time of creation of objects to identify the object in a window. Use this selector if the location of objects with the same description may change within a window.

60. How do you handle custom objects?

a) A custom object is any GUI object not belonging to one of the standard classes used by WinRunner. WinRunner learns such objects under the generic “object” class. WinRunner records operations on custom objects using obj_mouse_ statements.

b) If a custom object is similar to a standard object, you can map it to one of the standard classes. You can also configure the properties WinRunner uses to identify a custom object during Context Sensitive testing.

61. What is the name of custom class in WinRunner and what methods it applies on the custom objects?

a) WinRunner learns custom class objects under the generic “object” class. WinRunner records operations on custom objects using obj_ statements.

62. In a situation when obligatory and optional both the properties cannot uniquely identify an object what method WinRunner applies?

a) In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:

i. A location selector uses the spatial position of objects.

ii. An index selector uses a unique number to identify the object in a window.

63 What is the purpose of different record methods 1) Record 2) Pass up 3) As Object 4) Ignore.

a) Record instructs WinRunner to record all operations performed on a GUI object. This is the default record method for all classes. (The only exception is the static class (static text), for which the default is Pass Up.)

b) Pass Up instructs WinRunner to record an operation performed on this class as an operation performed on the element containing the object. Usually this element is a window, and the operation is recorded as win_mouse_click.

c) As Object instructs WinRunner to record all operations performed on a GUI object as though its class were “object” class.

d) Ignore instructs WinRunner to disregard all operations performed on the class.

64. How do you find out which is the start up file in WinRunner?

a) The test script name in the Startup Test box in the Environment tab in the General Options dialog box is the start up file in WinRunner.

65. What are the virtual objects and how do you learn them?

a) Applications may contain bitmaps that look and behave like GUI objects. WinRunner records operations on these bitmaps using win_mouse_click statements. By defining a bitmap as a virtual object, you can instruct WinRunner to treat it like a GUI object such as a push button, when you record and run tests.

b) 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.

To define a virtual object using the Virtual Object wizard:

i. Choose Tools > Virtual Object Wizard. The Virtual Object wizard opens. Click Next.

ii. In the Class list, select a class for the new virtual object. If rows that are displayed in the window. For a table class, select the number of visible rows and columns. Click Next.

iii. Click Mark Object. Use the crosshairs pointer to select the area of the virtual object. You can use the arrow keys to make precise adjustments to the area you define with the crosshairs. Press Enter or click the right mouse button to display the virtual object’s coordinates in the wizard. If the object marked is visible on the screen, you can click the Highlight button to view it. Click Next.

iv.Assign a logical name to the virtual object. This is the name that appears in the test script when you record on the virtual object. If the object contains text that WinRunner can read, the wizard suggests using this text for the logical name. Otherwise, WinRunner suggests virtual_object, virtual_push_button, virtual_list, etc.

v. You can accept the wizard’s suggestion or type in a different name. WinRunner checks that there are no other objects in the GUI map with the same name before confirming your choice. Click Next.

66.H ow you created you test scripts 1) by recording or 2) programming?

a) Programming. I have done complete programming only, absolutely no recording.

67. What are the two modes of recording?

a) There are 2 modes of recording in WinRunner

i.Context Sensitive recording records the operations you perform on your application by identifying Graphical User Interface (GUI) objects.

ii.Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.

68. What is a checkpoint and what are different types of checkpoints?

a) Checkpoints allow you to compare the current behavior of the application being tested to its behavior in an earlier version.

You can add four types of checkpoints to your test scripts:

i. GUI checkpoints verify information about GUI objects. For example, you can check that a button is enabled or see which item is selected in a list.

ii. Bitmap checkpoints take a “snapshot” of a window or area of your application and compare this to an image captured in an earlier version.

iii. Text checkpoints read text in GUI objects and in bitmaps and enable you to verify their contents.

iv. Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query you create on your database.

 

 

 

 

 

71. What is parameterizing?

a) In order for WinRunner to use data to drive the test, you must link the data to the test script which it drives. This is called parameterizing your test. The data is stored in a data table.

72. How do you maintain the document information of the test scripts?

a) Before creating a test, you can document information about the test in the General and Description tabs of the Test Properties dialog box. You can enter the name of the test author, the type of functionality tested, a detailed description of the test, and a reference to the relevant functional specifications document.

73. What do you verify with the GUI checkpoint for single property and what command it generates, explain syntax?

a) You can check a single property of a GUI object. For example, you can check whether a button is enabled or disabled or whether an item in a list is selected. To create a GUI checkpoint for a property value, use the Check Property dialog box to add one of the following functions to the test script:

i. button_check_info

ii. scroll_check_info

iii. edit_check_info

iv. static_check_info

v. list_check_info

vi. win_check_info

vii. obj_check_info

Syntax: button_check_info (button, property, property_value );

edit_check_info ( edit, property, property_value );

74. What do you verify with the GUI checkpoint for object/window and what command it generates, explain syntax?

a) You can create a GUI checkpoint to check a single object in the application being tested. You can either check the object with its default properties or you can specify which properties to check.

b) Creating a GUI Checkpoint using the Default Checks

i. You can create a GUI checkpoint that performs a default check on the property recommended by WinRunner. For example, if you create a GUI checkpoint that checks a push button, the default check verifies that the push button is enabled.

ii. To create a GUI checkpoint using default checks:

1. Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.

2. Click an object.

3. WinRunner captures the current value of the property of the GUI object being checked and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui statement

Syntax: win_check_gui ( window, checklist, expected_results_file, time );

c) Creating a GUI Checkpoint by Specifying which Properties to Check

d) You can specify which properties to check for an object. For example, if you create a checkpoint that checks a push button, you can choose to verify that it is in focus, instead of enabled.

e) To create a GUI checkpoint by specifying which properties to check:

i. Choose Create > GUI Checkpoint > For Object/Window, or click the GUI Checkpoint for Object/Window button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode as well. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens on the screen.

ii. Double-click the object or window. The Check GUI dialog box opens.

iii. Click an object name in the Objects pane. The Properties pane lists all the properties for the selected object.

iv. Select the properties you want to check.

1. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it.

2. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis (three dots) appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects.

3. To change the viewing options for the properties of an object, use the Show Properties buttons.

4. Click OK to close the Check GUI dialog box. WinRunner captures the GUI information and stores it in the test’s expected results folder. The WinRunner window is restored and a GUI checkpoint is inserted in the test script as an obj_check_gui or a win_check_gui statement.

Syntax: win_check_gui ( window, checklist, expected_results_file, time );

obj_check_gui ( object, checklist, expected results file, time );

75. What do you verify with the GUI checkpoint for multiple objects and what command it generates, explain syntax?

a) To create a GUI checkpoint for two or more objects:

i. Choose Create > GUI Checkpoint > For Multiple Objects or click the GUI Checkpoint for Multiple Objects button on the User toolbar. If you are recording in Analog mode, press the CHECK GUI FOR MULTIPLE OBJECTS softkey in order to avoid extraneous mouse movements. The Create GUI Checkpoint dialog box opens.

ii. Click the Add button. The mouse pointer becomes a pointing hand and a help window opens.

iii. To add an object, click it once. If you click a window title bar or menu bar, a help window prompts you to check all the objects in the window.

iv. The pointing hand remains active. You can continue to choose objects by repeating step 3 above for each object you want to check.

v. Click the right mouse button to stop the selection process and to restore the mouse pointer to its original shape. The Create GUI Checkpoint dialog box reopens.

vi. The Objects pane contains the name of the window and objects included in the GUI checkpoint. To specify which objects to check, click an object name in the Objects pane. The Properties pane lists all the properties of the object. The default properties are selected.

1. To edit the expected value of a property, first select it. Next, either click the Edit Expected Value button, or double-click the value in the Expected Value column to edit it.

2. To add a check in which you specify arguments, first select the property for which you want to specify arguments. Next, either click the Specify Arguments button, or double-click in the Arguments column. Note that if an ellipsis appears in the Arguments column, then you must specify arguments for a check on this property. (You do not need to specify arguments if a default argument is specified.) When checking standard objects, you only specify arguments for certain properties of edit and static text objects. You also specify arguments for checks on certain properties of nonstandard objects.

3. To change the viewing options for the properties of an object, use the Show Properties buttons.

vii. To save the checklist and close the Create GUI Checkpoint dialog box, click OK. WinRunner captures the current property values of the selected GUI objects and stores it in the expected results folder. A win_check_gui statement is inserted in the test script.

Syntax: win_check_gui ( window, checklist, expected_results_file, time );

obj_check_gui ( object, checklist, expected results file, time );

76. What information is contained in the checklist file and in which file expected results are stored?

a) The checklist file contains information about the objects and the properties of the object we are verifying.

b) The gui*.chk file contains the expected results which is stored in the exp folder

77. What do you verify with the bitmap check point for object/window and what command it generates, explain syntax?

a) You can check an object, a window, or an area of a screen in your application as a bitmap. While creating a test, you indicate what you want to check. WinRunner captures the specified bitmap, stores it in the expected results folder (exp) of the test, and inserts a checkpoint in the test script. When you run the test, WinRunner compares the bitmap currently displayed in the application being tested with the expected bitmap stored earlier. In the event of a mismatch, WinRunner captures the current actual bitmap and generates a difference bitmap. By comparing the three bitmaps (expected, actual, and difference), you can identify the nature of the discrepancy.

b) When working in Context Sensitive mode, you can capture a bitmap of a window, object, or of a specified area of a screen. WinRunner inserts a checkpoint in the test script in the form of either a win_check_bitmap or obj_check_bitmap statement.

c) Note that when you record a test in Analog mode, you should press the CHECK BITMAP OF WINDOW softkey or the CHECK BITMAP OF SCREEN AREA softkey to create a bitmap checkpoint. This prevents WinRunner from recording extraneous mouse movements. If you are programming a test, you can also use the Analog function check_window to check a bitmap.

d) To capture a window or object as a bitmap:

i. Choose Create > Bitmap Checkpoint > For Object/Window or click the Bitmap Checkpoint for Object/Window button on the User toolbar. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF OBJECT/WINDOW softkey. The WinRunner window is minimized, the mouse pointer becomes a pointing hand, and a help window opens.

ii. Point to the object or window and click it. WinRunner captures the bitmap and generates a win_check_bitmap or obj_check_bitmap statement in the script. The TSL statement generated for a window bitmap has the following syntax:

win_check_bitmap ( object, bitmap, time );

iii. For an object bitmap, the syntax is:

obj_check_bitmap ( object, bitmap, time );

iv. For example, when you click the title bar of the main window of the Flight Reservation application, the resulting statement might be:

win_check_bitmap ("Flight Reservation", "Img2", 1);

v. However, if you click the Date of Flight box in the same window, the statement might be:

obj_check_bitmap ("Date of Flight:", "Img1", 1);

Syntax: obj_check_bitmap ( object, bitmap, time [, x, y, width, height] );

78. What do you verify with the bitmap checkpoint for screen area and what command it generates, explain syntax?

a) You can define any rectangular area of the screen and capture it as a bitmap for comparison. The area can be any size: it can be part of a single window, or it can intersect several windows. The rectangle is identified by the coordinates of its upper left and lower right corners, relative to the upper left corner of the window in which the area is located. If the area intersects several windows or is part of a window with no title (for example, a popup window), its coordinates are relative to the entire screen (the root window).

b) To capture an area of the screen as a bitmap:

i. Choose Create > Bitmap Checkpoint > For Screen Area or click the Bitmap Checkpoint for Screen Area button. Alternatively, if you are recording in Analog mode, press the CHECK BITMAP OF SCREEN AREA softkey. The WinRunner window is minimized, the mouse pointer becomes a crosshairs pointer, and a help window opens.

ii. Mark the area to be captured: press the left mouse button and drag the mouse pointer until a rectangle encloses the area; then release the mouse button.

iii. Press the right mouse button to complete the operation. WinRunner captures the area and generates a win_check_bitmap statement in your script.

iv. The win_check_bitmap statement for an area of the screen has the following syntax:

win_check_bitmap ( window, bitmap, time, x, y, width, height );

79. What do you verify with the database checkpoint default and what command it generates, explain syntax?

a) By adding runtime database record checkpoints you can compare the information in your application during a test run with the corresponding record in your database. By adding standard database checkpoints to your test scripts, you can check the contents of databases in different versions of your application.

b) When you create database checkpoints, you define a query on your database, and your database checkpoint checks the values contained in the result set. The result set is set of values retrieved from the results of the query.

c) You can create runtime database record checkpoints in order to compare the values displayed in your application during the test run with the corresponding values in the database. If the comparison does not meet the success criteria you

d) specify for the checkpoint, the checkpoint fails. You can define a successful runtime database record checkpoint as one where one or more matching records were found, exactly one matching record was found, or where no matching records are found.

e) You can create standard database checkpoints to compare the current values of the properties of the result set during the test run to the expected values captured during recording or otherwise set before the test run. If the expected results and the current results do not match, the database checkpoint fails. Standard database checkpoints are useful when the expected results can be established before the test run.

Syntax: db_check(, );

f) You can add a runtime database record checkpoint to your test in order to compare information that appears in your application during a test run with the current value(s) in the corresponding record(s) in your database. You add runtime database record checkpoints by running the Runtime Record Checkpoint wizard. When you are finished, the wizard inserts the appropriate db_record_check statement into your script.

Syntax:

db_record_check(ChecklistFileName,SuccessConditions,RecordNumber );

ChecklistFileName A file created by WinRunner and saved in the test’s checklist folder. The file contains information about the data to be captured during the test run and its corresponding field in the database. The file is created based on the information entered in the Runtime Record Verification wizard.

Contains one of the following values:

1. DVR_ONE_OR_MORE_MATCH – The checkpoint passes if one or more matching database records are found.

2. DVR_ONE_MATCH – The checkpoint passes if exactly one matching database record is found.

3. DVR_NO_MATCH – The checkpoint passes if no matching database records are found.

RecordNumber An out parameter returning the number of records in the database.

80. How do you handle dynamically changing area of the window in the bitmap checkpoints?

a) The difference between bitmaps option in the Run Tab of the general options defines the minimum number of pixels that constitute a bitmap mismatch

81. What do you verify with the database check point custom and what command it generates, explain syntax?

a) When you create a custom check on a database, you create a standard database checkpoint in which you can specify which properties to check on a result set.

b) You can create a custom check on a database in order to:

i. check the contents of part or the entire result set

ii. edit the expected results of the contents of the result set

iii. count the rows in the result set

iv. count the columns in the result set

c) You can create a custom check on a database using ODBC, Microsoft Query or Data Junction.

82. What do you verify with the sync point for object/window property and what command it generates, explain syntax?

a) Synchronization compensates for inconsistencies in the performance of your application during a test run. By inserting a synchronization point in your test script, you can instruct WinRunner to suspend the test run and wait for a cue before continuing the test.

b) You can a synchronization point that instructs WinRunner to wait for a specified object or window to appear. For example, you can tell WinRunner to wait for a window to open before performing an operation within that window, or you may want WinRunner to wait for an object to appear in order to perform an operation on that object.

c) You use the obj_exists function to create an object synchronization point, and you use the win_exists function to create a window synchronization point. These functions have the following syntax:

Syntax:

obj_exists ( object [, time ] );

win_exists ( window [, time ] );

83. What do you verify with the sync point for object/window bitmap and what command it generates, explain syntax?

a) You can create a bitmap synchronization point that waits for the bitmap of an object or a window to appear in the application being tested.

b) During a test run, WinRunner suspends test execution until the specified bitmap is redrawn, and then compares the current bitmap with the expected one captured earlier. If the bitmaps match, then WinRunner continues the test.

Syntax:

obj_wait_bitmap ( object, image, time );

win_wait_bitmap ( window, image, time );

84. What do you verify with the sync point for screen area and what command it generates, explain syntax?

a) For screen area verification we actually capture the screen area into a bitmap and verify the application screen area with the bitmap file during execution

Syntax: obj_wait_bitmap(object, image, time, x, y, width, height);

85. How do you edit checklist file and when do you need to edit the checklist file?

a) WinRunner has an edit checklist file option under the create menu. Select the “Edit GUI Checklist” to modify GUI checklist file and “Edit Database Checklist” to edit database checklist file. This brings up a dialog box that gives you option to select the checklist file to modify. There is also an option to select the scope of the checklist file, whether it is Test specific or a shared one. Select the checklist file, click OK which opens up the window to edit the properties of the objects.

86. How do you edit the expected value of an object?

a) We can modify the expected value of the object by executing the script in the Update mode. We can also manually edit the gui*.chk file which contains the expected values which come under the exp folder to change the values.

87. How do you modify the expected results of a GUI checkpoint?

a) We can modify the expected results of a GUI checkpoint be running the script containing the checkpoint in the update mode.

88. How do you handle ActiveX and Visual basic objects?

a) WinRunner provides with add-ins for ActiveX and Visual basic objects. When loading WinRunner, select those add-ins and these add-ins provide with a set of functions to work on ActiveX and VB objects.

89. How do you create ODBC query?

a) We can create ODBC query using the database checkpoint wizard. It provides with option to create an SQL file that uses an ODBC DSN to connect to the database. The SQL File will contain the connection string and the SQL statement.

90. How do you record a data driven test?

a) We can create a data-driven testing using data from a flat file, data table or a database.

i. Using Flat File: we actually store the data to be used in a required format in the file. We access the file using the File manipulation commands, reads data from the file and assign the variables with data.

ii. Data Table: It is an excel file. We can store test data in these files and manipulate them. We use the ‘ddt_*’ functions to manipulate data in the data table.

iii.Database: we store test data in the database and access these data using ‘db_*’ functions.

91. How do you convert a database file to a text file?

a) You can use Data Junction to create a conversion file which converts a database to a target text file.

92. How do you parameterize database check points?

a) When you create a standard database checkpoint using ODBC (Microsoft Query), you can add parameters to an SQL statement to parameterize the checkpoint. This is useful if you want to create a database checkpoint with a query in which the SQL statement defining your query changes.

93. How do you create parameterize SQL commands?

a) A parameterized query is a query in which at least one of the fields of the WHERE clause is parameterized, i.e., the value of the field is specified by a question mark symbol ( ? ). For example, the following SQL statement is based on a query on the database in the sample Flight Reservation application:


i. SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week FROM Flights Flights WHERE (Flights.Departure=?) AND (Flights.Day_Of_Week=?)

SELECT defines the columns to include in the query.

FROM specifies the path of the database.

WHERE (optional) specifies the conditions, or filters to use in the query.

Departure is the parameter that represents the departure point of a flight.

Day_Of_Week is the parameter that represents the day of the week of a flight.

b) When creating a database checkpoint, you insert a db_check statement into your test script. When you parameterize the SQL statement in your checkpoint, the db_check function has a fourth, optional, argument: the parameter_array argument. A statement similar to the following is inserted into your test script:

db_check(“list1.cdl”, “dbvf1″, NO_LIMIT, dbvf1_params);

The parameter_array argument will contain the values to substitute for the parameters in the parameterized checkpoint.

94. Explain the following commands:

a) db_connect

to connect to a database

db_connect(, );

b) db_execute_query

to execute a query

db_execute_query ( session_name, SQL, record_number );

record_number is the out value.

c) db_get_field_value

returns the value of a single field in the specified row_index and column in the session_name database session.

db_get_field_value ( session_name, row_index, column );

d) db_get_headers

returns the number of column headers in a query and the content of the column headers, concatenated and delimited by tabs.

db_get_headers ( session_name, header_count, header_content );

e) db_get_row

returns the content of the row, concatenated and delimited by tabs.

db_get_row ( session_name, row_index, row_content );

f) db_write_records

writes the record set into a text file delimited by tabs.

db_write_records ( session_name, output_file [ , headers [ , record_limit ] ] );

g) db_get_last_error

returns the last error message of the last ODBC or Data Junction operation in the session_name database session.

db_get_last_error ( session_name, error );

h) db_disconnect

disconnects from the database and ends the database session.

db_disconnect ( session_name );

i) db_dj_convert

runs the djs_file Data Junction export file. When you run this file, the Data Junction Engine converts data from one spoke (source) to another (target). The optional parameters enable you to override the settings in the Data Junction export file.

db_dj_convert ( djs_file [ , output_file [ , headers [ , record_limit ] ] ] );

95. What check points you will use to read and check text on the GUI and explain its syntax?

a) You can use text checkpoints in your test scripts to read and check text in GUI objects and in areas of the screen. While creating a test you point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. You may then add simple programming elements to your test scripts to verify the contents of the text.

b) You can use a text checkpoint to:

i.Read text from a GUI object or window in your application, using obj_get_text and win_get_text

ii.Search for text in an object or window, using win_find_text and obj_find_text

iii. Move the mouse pointer to text in an object or window, using obj_move_locator_text and win_move_locator_text

iv. Click on text in an object or window, using obj_click_on_text and win_click_on_text

96. Explain Get Text checkpoint from object/window with syntax?

a) We use obj_get_text (, ) function to get the text from an object

b) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.

97. Explain Get Text checkpoint from screen area with syntax?

a) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.

98. Explain Get Text checkpoint from selection (web only) with syntax?

a) Returns a text string from an object.

web_obj_get_text (object, table_row, table_column, out_text [, text_before, text_after, index]);

i. object The logical name of the object.

ii. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the # character.

iii. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the # character.

iv. out_text The output variable that stores the text string.

v. text_before Defines the start of the search area for a particular text string.

vi. text_after Defines the end of the search area for a particular text string.

vii. index The occurrence number to locate. (The default parameter number is numbered 1).

99. Explain Get Text checkpoint web text checkpoint with syntax?

a) We use web_obj_text_exists function for web text checkpoints.

web_obj_text_exists ( object, table_row, table_column, text_to_find [, text_before, text_after] );

a. object The logical name of the object to search.

b. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the character #.

c. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the character #.

d. text_to_find The string that is searched for.

e. text_before Defines the start of the search area for a particular text string.

f. text_after Defines the end of the search area for a particular text string.

100. Which TSL functions you will use for

a) Searching text on the window

i. find_text ( string, out_coord_array, search_area [, string_def ] );

string The string that is searched for. The string must be complete, contain no spaces, and it must be preceded and followed by a space outside the quotation marks. To specify a literal, case-sensitive string, enclose the string in quotation marks. Alternatively, you can specify the name of a string variable. In this case, the string variable can include a regular expression.

out_coord_array The name of the array that stores the screen coordinates of the text (see explanation below).

search_area The area to search, specified as coordinates x1,y1,x2,y2. These define any two diagonal corners of a rectangle. The interpreter searches for the text in the area defined by the rectangle.

string_def Defines the type of search to perform. If no value is specified, (0 or FALSE, the default), the search is for a single complete word only. When 1, or TRUE, is specified, the search is not restricted to a single, complete word.

b) getting the location of the text string

i. win_find_text ( window, string, result_array [, search_area [, string_def ] ] );

window The logical name of the window to search.

string The text to locate. To specify a literal, case sensitive string, enclose the string in quotation marks. Alternatively, you can specify the name of a string variable. The value of the string variable can include a regular expression. The regular expression should not include an exclamation mark (!), however, which is treated as a literal character. For more information regarding Regular Expressions, refer to the “Using Regular Expressions” chapter in your User’s Guide.

result_array The name of the output variable that stores the location of the string as a four-element array.

search_area The region of the object to search, relative to the window. This area is defined as a pair of coordinates, with x1,y1,x2,y2 specifying any two diagonally opposite corners of the rectangular search region. If this parameter is not defined, then the entire window is considered the search area.

string_def Defines how the text search is performed. If no string_def is specified, (0 or FALSE, the default parameter), the interpreter searches for a complete word only. If 1, or TRUE, is specified, the search is not restricted to a single, complete word.

c) Moving the pointer to that text string

i. win_move_locator_text (window, string [ ,search_area [ ,string_def ] ] );

window The logical name of the window.

string The text to locate. To specify a literal, case sensitive string, enclose the string in quotation marks. Alternatively, you can specify the name of a string variable. The value of the string variable can include a regular expression (the regular expression need not begin with an exclamation mark).

search_area The region of the object to search, relative to the window. This area is defined as a pair of coordinates, with x1, y1, x2, y2 specifying any two diagonally opposite corners of the rectangular search region. If this parameter is not defined, then the entire window specified is considered the search area.

string_def Defines how the text search is performed. If no string_def is specified, (0 or FALSE, the default parameter), the interpreter searches for a complete word only. If 1, or TRUE, is specified, the search is not restricted to a single, complete word.

d) Comparing the text

i. compare_text (str1, str2 [, chars1, chars2]);

str1, str2 The two strings to be compared.

chars1 One or more characters in the first string.

chars2 One or more characters in the second string. These characters are substituted for those in chars1.

101. What are the steps of creating a data driven test?

a) The steps involved in data driven testing are:

i. Creating a test

ii. Converting to a data-driven test and preparing a database

iii. Running the test

iv. Analyzing the test results.

102. Record a data driven test script using data driver wizard?

a) You can use the DataDriver Wizard to convert your entire script or a part of your script into a data-driven test. For example, your test script may include recorded operations, checkpoints, and other statements that do not need to be repeated for multiple sets of data. You need to parameterize only the portion of your test script that you want to run in a loop with multiple sets of data.

To create a data-driven test:

i. If you want to turn only part of your test script into a data-driven test, first select those lines in the test script.

ii. Choose Tools > DataDriver Wizard.

iii. If you want to turn only part of the test into a data-driven test, click Cancel. Select those lines in the test script and reopen the DataDriver Wizard. If you want to turn the entire test into a data-driven test, click Next.

iv. The Use a new or existing Excel table box displays the name of the Excel file that WinRunner creates, which stores the data for the data-driven test. Accept the default data table for this test, enter a different name for the data table, or use

v. The browse button to locate the path of an existing data table. By default, the data table is stored in the test folder.

vi. In the Assign a name to the variable box, enter a variable name with which to refer to the data table, or accept the default name, “table.”

vii. At the beginning of a data-driven test, the Excel data table you selected is assigned as the value of the table variable. Throughout the script, only the table variable name is used. This makes it easy for you to assign a different data table

viii. To the script at a later time without making changes throughout the script.

ix. Choose from among the following options:

1. Add statements to create a data-driven test: Automatically adds statements to run your test in a loop: sets a variable name by which to refer to the data table; adds braces ({and}), a for statement, and a ddt_get_row_count statement to your test script selection to run it in a loop while it reads from the data table; adds ddt_open and ddt_close statements

2. To your test script to open and close the data table, which are necessary in order to iterate rows in the table. Note that you can also add these statements to your test script manually.

3. If you do not choose this option, you will receive a warning that your data-driven test must contain a loop and statements to open and close your datatable.

4. Import data from a database: Imports data from a database. This option adds ddt_update_from_db, and ddt_save statements to your test script after the ddt_open statement.

5. Note that in order to import data from a database, either Microsoft Query or Data Junction must be installed on your machine. You can install Microsoft Query from the custom installation of Microsoft Office. Note that Data Junction is not automatically included in your WinRunner package. To purchase Data Junction, contact your Mercury Interactive representative. For detailed information on working with Data Junction, refer to the documentation in the Data Junction package.

6. Parameterize the test: Replaces fixed values in selected checkpoints and in recorded statements with parameters, using the ddt_val function, and in the data table, adds columns with variable values for the parameters. Line by line: Opens a wizard screen for each line of the selected test script, which enables you to decide whether to parameterize a particular line, and if so, whether to add a new column to the data table or use an existing column when parameterizing data.

7. Automatically: Replaces all data with ddt_val statements and adds new columns to the data table. The first argument of the function is the name of the column in the data table. The replaced data is inserted into the table.

x. The Test script line to parameterize box displays the line of the test script to parameterize. The highlighted value can be replaced by a parameter. The Argument to be replaced box displays the argument (value) that you can replace with a parameter. You can use the arrows to select a different argument to replace.

Choose whether and how to replace the selected data:

1. Do not replace this data: Does not parameterize this data.

2. An existing column: If parameters already exist in the data table for this test, select an existing parameter from the list.

3. A new column: Creates a new column for this parameter in the data table for this test. Adds the selected data to this column of the data table. The default name for the new parameter is the logical name of the object in the selected. TSL statement above. Accept this name or assign a new name.

xi. The final screen of the wizard opens.

1. If you want the data table to open after you close the wizard, select Show data table now.

2. To perform the tasks specified in previous screens and close the wizard, click Finish.

3. To close the wizard without making any changes to the test script, click Cancel.


103. What are the three modes of running the scripts?

a) WinRunner provides three modes in which to run tests—Verify, Debug, and Update. You use each mode during a different phase of the testing process.

i. Verify

1. Use the Verify mode to check your application.

ii. Debug

1. Use the Debug mode to help you identify bugs in a test script.

iii. Update

1. Use the Update mode to update the expected results of a test or to create a new expected results folder.

104. Explain the following TSL functions:

a) Ddt_open

Creates or opens a datatable file so that WinRunner can access it.

Syntax: ddt_open ( data_table_name, mode );

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

mode The mode for opening the data table: DDT_MODE_READ (read-only) or DDT_MODE_READWRITE (read or write).

b) Ddt_save

Saves the information into a data file.

Syntax: dt_save (data_table_name);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table.

c) Ddt_close

Closes a data table file

Syntax: ddt_close ( data_table_name );

data_table_name The name of the data table. The data table is a Microsoft Excel file or a tabbed text file. The first row in the file contains the names of the parameters.

d) Ddt_export

Exports the information of one data table file into a different data table file.

Syntax: ddt_export (data_table_namename1, data_table_namename2);

data_table_namename1 The source data table filename.

data_table_namename2 The destination data table filename.

e) Ddt_show

Shows or hides the table editor of a specified data table.

Syntax: ddt_show (data_table_name [, show_flag]);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table.

show_flag The value indicating whether the editor should be shown (default=1) or hidden (0).

f) Ddt_get_row_count

Retrieves the no. of rows in a data tables

Syntax: ddt_get_row_count (data_table_name, out_rows_count);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.

out_rows_count The output variable that stores the total number of rows in the data table.

g) ddt_next_row

Changes the active row in a database to the next row

Syntax: ddt_next_row (data_table_name);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.

h) ddt_set_row

Sets the active row in a data table.

Syntax: ddt_set_row (data_table_name, row);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

row The new active row in the data table.

i) ddt_set_val

Sets a value in the current row of the data table

Syntax: ddt_set_val (data_table_name, parameter, value);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

parameter The name of the column into which the value will be inserted.

value The value to be written into the table.

j) ddt_set_val_by_row

Sets a value in a specified row of the data table.

Syntax: ddt_set_val_by_row (data_table_name, row, parameter, value);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

row The row number in the table. It can be any existing row or the current row number plus 1, which will add a new row to the data table.

parameter The name of the column into which the value will be inserted.

value The value to be written into the table.

k) ddt_get_current_row

Retrieves the active row of a data table.

Syntax: ddt_get_current_row ( data_table_name, out_row );

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

out_row The output variable that stores the active row in the data table.

l) ddt_is_parameter

Returns whether a parameter in a datatable is valid

Syntax: ddt_is_parameter (data_table_name, parameter);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.

parameter The parameter name to check in the data table.

m) ddt_get_parameters

Returns a list of all parameters in a data table.

Syntax: ddt_get_parameters ( table, params_list, params_num );

table The pathname of the data table.

params_list This out parameter returns the list of all parameters in the data table, separated by tabs.

params_num This out parameter returns the number of parameters in params_list.

n) ddt_val

Returns the value of a parameter in the active roe in a data table.

Syntax: ddt_val (data_table_name, parameter);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters.

parameter The name of the parameter in the data table.

o) ddt_val_by_row

Returns the value of a parameter in the specified row in a data table.

Syntax: ddt_val_by_row ( data_table_name, row_number, parameter );

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

row_number The number of the row in the data table.

parameter The name of the parameter in the data table.

p) ddt_report_row

Reports the active row in a data table to the test results

Syntax: ddt_report_row (data_table_name);

data_table_name The name of the data table. The name may be the table variable name, the Microsoft Excel file or a tabbed text file name, or the full path and file name of the table. The first row in the file contains the names of the parameters. This row is labeled row 0.

q) ddt_update_from_db

imports data from a database into a data table. It is inserted into your test script when you select the Import data from a database option in the DataDriver Wizard. When you run your test, this function updates the data table with data from the database.

105. How do you handle unexpected events and errors?

a) WinRunner uses exception handling to detect an unexpected event when it occurs and act to recover the test run.

Define Exception Handling

Define Exception

Define Handler Function

WinRunner enables you to handle the following types of exceptions:

Pop-up exceptions: Instruct WinRunner to detect and handle the appearance of a specific window.

TSL exceptions: Instruct WinRunner to detect and handle TSL functions that return a specific error code.

Object exceptions: Instruct WinRunner to detect and handle a change in a property for a specific GUI object.

Web exceptions: When the WebTest add-in is loaded, you can instruct WinRunner to handle unexpected events and errors that occur in your Web site during a test run.

106. How do you handle pop-up exceptions?

a) A pop-up exception Handler handles the pop-up messages that come up during the execution of the script in the AUT. TO handle this type of exception we make WinRunner learn the window and also specify a handler to the exception. It could be

i. Default actions: WinRunner clicks the OK or Cancel button in the pop-up window, or presses Enter on the keyboard. To select a default handler, click the appropriate button in the dialog box.

ii. User-defined handler: If you prefer, specify the name of your own handler. Click User Defined Function Name and type in a name in the User Defined Function Name box.

107. How do you handle TSL exceptions?

a) A TSL exception enables you to detect and respond to a specific error code returned during test execution.

b) Suppose you are running a batch test on an unstable version of your application. If your application crashes, you want WinRunner to recover test execution. A TSL exception can instruct WinRunner to recover test execution by exiting the current test, restarting the application, and continuing with the next test in the batch.

c) The handler function is responsible for recovering test execution. When WinRunner detects a specific error code, it calls the handler function. You implement this function to respond to the unexpected error in the way that meets your specific testing needs.

d) Once you have defined the exception, WinRunner activates handling and adds the exception to the list of default TSL exceptions in the Exceptions dialog box. Default TSL exceptions are defined by the XR_EXCP_TSL configuration parameter in the wrun.ini configuration file.

108. How do you handle object exceptions?

a) During testing, unexpected changes can occur to GUI objects in the application you are testing. These changes are often subtle but they can disrupt the test run and distort results.

b) You could use exception handling to detect a change in property of the GUI object during the test run, and to recover test execution by calling a handler function and continue with the test execution

109. How do you comment your script?

a) We comment a script or line of script by inserting a ‘#’ at the beginning of the line.

110. What is a compile module?

a) A compiled module is a script containing a library of user-defined functions that you want to call frequently from other tests. When you load a compiled module, its functions are automatically compiled and remain in memory. You can call them directly from within any test.

b) Compiled modules can improve the organization and performance of your tests. Since you debug compiled modules before using them, your tests will require less error-checking. In addition, calling a function that is already compiled is significantly faster than interpreting a function in a test script.

111. What is the difference between script and compile module?

a) Test script contains the executable file in WinRunner while Compiled Module is used to store reusable functions. Complied modules are not executable.

b) WinRunner performs a pre-compilation automatically when it saves a module assigned a property value of “Compiled Module”.

c) By default, modules containing TSL code have a property value of “main”. Main modules are called for execution from within other modules. Main modules are dynamically compiled into machine code only when WinRunner recognizes a “call” statement. Example of a call for the “app_init” script:

call cso_init();

call( “C:\\MyAppFolder\\” & “app_init” );

d) Compiled modules are loaded into memory to be referenced from TSL code in any module. Example of a load statement:

reload (“C:\\MyAppFolder\\” & “flt_lib”);

or

load (“C:\\MyAppFolder\\” & “flt_lib”);

112. Write and explain various loop command?

a) A for loop instructs WinRunner to execute one or more statements a specified number of times.

It has the following syntax:

for ( [ expression1 ]; [ expression2 ]; [ expression3 ] )statement

i. First, expression1 is executed. Next, expression2 is evaluated. If expression2 is true, statement is executed and expression3 is executed. The cycle is repeated as long as expression2 remains true. If expression2 is false, the for statement terminates and execution passes to the first statement immediately following.

ii. For example, the for loop below selects the file UI_TEST from the File Name list

iii. in the Open window. It selects this file five times and then stops.

set_window (“Open”)

for (i=0; i<5;>

list_select_item(“File_Name:_1″,”UI_TEST”); #Item Number2

b) A while loop executes a block of statements for as long as a specified condition is true.

It has the following syntax:

while ( expression )

statement ;

i. While expression is true, the statement is executed. The loop ends when the expression is false. For example, the while statement below performs the same function as the for loop above.

set_window (“Open”);

i=0;

while (i<5){

i++;

list_select_item (“File Name:_1″, “UI_TEST”); # Item Number 2

}

c) A do/while loop executes a block of statements for as long as a specified condition is true. Unlike the for loop and while loop, a do/while loop tests the conditions at the end of the loop, not at the beginning.

A do/while loop has the following syntax:

do

statement

while (expression);

i. The statement is executed and then the expression is evaluated. If the expression is true, then the cycle is repeated. If the expression is false, the cycle is not repeated.

ii. For example, the do/while statement below opens and closes the Order dialog box of Flight Reservation five times.

set_window (“Flight Reservation”);

i=0;

do

{

menu_select_item (“File;Open Order…”);

set_window (“Open Order”);

button_press (“Cancel”);

i++;

}

while (i<5);

113. Write and explain decision making command?

a) You can incorporate decision-making into your test scripts using if/else or switch statements.

i. An if/else statement executes a statement if a condition is true; otherwise, it executes another statement.

It has the following syntax:

if ( expression )

statement1;

[ else

statement2; ]


expression is evaluated. If expression is true, statement1 is executed. If expression1 is false, statement2 is executed.

b) A switch statement enables WinRunner to make a decision based on an expression that can have more than two values.

It has the following syntax:

switch (expression )

{

case case_1: statements

case case_2: statements

case case_n: statements

default: statement(s)

}

The switch statement consecutively evaluates each case expression until one is found that equals the initial expression. If no case is equal to the expression, then the default statements are executed. The default statements are optional.

114. Write and explain switch command?

a) A switch statement enables WinRunner to make a decision based on an expression that can have more than two values.

It has the following syntax:

switch (expression )

{

case case_1: statements

case case_2: statements

case case_n: statements

default: statement(s)

}

b) The switch statement consecutively evaluates each case expression until one is found that equals the initial expression. If no case is equal to the expression, then the default statements are executed. The default statements are optional.

115. How do you write messages to the report?

a) To write message to a report we use the report_msg statement

Syntax: report_msg (message);

116. What is a command to invoke application?

a) Invoke_application is the function used to invoke an application.

Syntax: invoke_application(file, command_option, working_dir, SHOW);

117. What is the purpose of tl_step command?

a) Used to determine whether sections of a test pass or fail.

Syntax: tl_step(step_name, status, description);

118. Which TSL function you will use to compare two files?

a) We can compare 2 files in WinRunner using the file_compare function.

Syntax: file_compare (file1, file2 [, save file]);

119. What is the use of function generator?

a) The Function Generator provides a quick, error-free way to program scripts. You can:

i. Add Context Sensitive functions that perform operations on a GUI object or get information from the application being tested.

ii. Add Standard and Analog functions that perform non-Context Sensitive tasks such as synchronizing test execution or sending user-defined messages to a report.

iii. Add Customization functions that enable you to modify WinRunner to suit your testing environment.

120. What is the use of putting call and call_close statements in the test script?

a) You can use two types of call statements to invoke one test from another:

i. A call statement invokes a test from within another test.

ii. A call_close statement invokes a test from within a script and closes the test when the test is completed.

iii. The call statement has the following syntax:

1. call test_name ( [ parameter1, parameter2, ...parametern ] );

iv. The call_close statement has the following syntax:

1. call_close test_name ( [ parameter1, parameter2, ... parametern ] );

v. The test_name is the name of the test to invoke. The parameters are the parameters defined for the called test.

vi. The parameters are optional. However, when one test calls another, the call statement should designate a value for each parameter defined for the called test. If no parameters are defined for the called test, the call statement must contain an empty set of parentheses.

121. What is the use of treturn and texit statements in the test script?

a) The treturn and texit statements are used to stop execution of called tests.

i. The treturn statement stops the current test and returns control to the calling test.

ii. The texit statement stops test execution entirely, unless tests are being called from a batch test. In this case, control is returned to the main batch test.

b) Both functions provide a return value for the called test. If treturn or texit is not used, or if no value is specified, then the return value of the call statement is 0.

treturn

c) The treturn statement terminates execution of the called test and returns control to the calling test.

The syntax is:

treturn [( expression )];

d) The optional expression is the value returned to the call statement used to invoke the test.

texit

e) When tests are run interactively, the texit statement discontinues test execution. However, when tests are called from a batch test, texit ends execution of the current test only; control is then returned to the calling batch test.

The syntax is:

texit [( expression )];

122. Where do you set up the search path for a called test.

a) The search path determines the directories that WinRunner will search for a called test.

b) To set the search path, choose Settings > General Options. The General Options dialog box opens. Click the Folders tab and choose a search path in the Search Path for Called Tests box. WinRunner searches the directories in the order in which they are listed in the box. Note that the search paths you define remain active in future testing sessions.

123. How you create user-defined functions and explain the syntax?

a) A user-defined function has the following structure:

[class] function name ([mode] parameter…)

{

declarations;

statements;

}

b) The class of a function can be either static or public. A static function is available only to the test or module within which the function was defined.

c) Parameters need not be explicitly declared. They can be of mode in, out, or inout. For all non-array parameters, the default mode is in. For array parameters, the default is inout. The significance of each of these parameter types is as follows:

in: A parameter that is assigned a value from outside the function.

out: A parameter that is assigned a value from inside the function.

inout: A parameter that can be assigned a value from outside or inside the function.

124. What does static and public class of a function means?

a) The class of a function can be either static or public.

b) A static function is available only to the test or module within which the function was defined.

c) Once you execute a public function, it is available to all tests, for as long as the test containing the function remains open. This is convenient when you want the function to be accessible from called tests. However, if you want to create a function that will be available to many tests, you should place it in a compiled module. The functions in a compiled module are available for the duration of the testing session.

d) If no class is explicitly declared, the function is assigned the default class, public.

125. What does in, out and input parameters means?

a) in: A parameter that is assigned a value from outside the function.

b) out: A parameter that is assigned a value from inside the function.

c) inout: A parameter that can be assigned a value from outside or inside the function.

126. What is the purpose of return statement?

a) This statement passes control back to the calling function or test. It also returns the value of the evaluated expression to the calling function or test. If no expression is assigned to the return statement, an empty string is returned.

Syntax: return [( expression )];


127. What does auto, static, public and extern variables means?

a) auto: An auto variable can be declared only within a function and is local to that function. It exists only for as long as the function is running. A new copy of the variable is created each time the function is called.

b) static: A static variable is local to the function, test, or compiled module in which it is declared. The variable retains its value until the test is terminated by an Abort command. This variable is initialized each time the definition of the function is executed.

c) public: A public variable can be declared only within a test or module, and is available for all functions, tests, and compiled modules.

d) extern: An extern declaration indicates a reference to a public variable declared outside of the current test or module.

128. How do you declare constants?

a) The const specifier indicates that the declared value cannot be modified. The class of a constant may be either public or static. If no class is explicitly declared, the constant is assigned the default class public. Once a constant is defined, it remains in existence until you exit WinRunner.

b) The syntax of this declaration is:

[class] const name [= expression];

129. How do you declare arrays?

a) The following syntax is used to define the class and the initial expression of an array. Array size need not be defined in TSL.

b) class array_name [ ] [=init_expression]

c) The array class may be any of the classes used for variable declarations (auto, static, public, extern).

130. How do you load and unload a compile module?

a) In order to access the functions in a compiled module you need to load the module. You can load it from within any test script using the load command; all tests will then be able to access the function until you quit WinRunner or unload the compiled module.

b) You can load a module either as a system module or as a user module. A system module is generally a closed module that is “invisible” to the tester. It is not displayed when it is loaded, cannot be stepped into, and is not stopped by a pause command. A system module is not unloaded when you execute an unload statement with no parameters (global unload).

load (module_name [,1|0] [,1|0] );

The module_name is the name of an existing compiled module.


Two additional, optional parameters indicate the type of module. The first parameter indicates whether the function module is a system module or a user module: 1 indicates a system module; 0 indicates a user module.

(Default = 0)

The second optional parameter indicates whether a user module will remain open in the WinRunner window or will close automatically after it is loaded: 1 indicates that the module will close automatically; 0 indicates that the module will remain open.

(Default = 0)

c) The unload function removes a loaded module or selected functions from memory.

d) It has the following syntax:

unload ( [ module_name | test_name [ , "function_name" ] ] );

141. How do you update your expected results?

142. How do you run your script with multiple sets of expected results?

143. How do you view and evaluate test results for various check points?

144. How do you view the results of file comparison?

145. What is the purpose of Wdiff utility?

146. What are batch tests and how do you create and run batch tests ?

147. How do you store and view batch test results?

148. How do you execute your tests from windows run command?

149. Explain different command line options?

150. What TSL function you will use to pause your script?

151. What is the purpose of setting a break point?

152. What is a watch list?

153. During debugging how do you monitor the value of the variables?

154.What are the reasons that WinRunner fails to identify an object on the GUI?

a) WinRunner fails to identify an object in a GUI due to various reasons.

i. The object is not a standard windows object.

ii. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window.

155.What do you mean by the logical name of the object.

a) An object’s logical name is determined by its class. In most cases, the logical name is the label that appears on an object.

156.If the object does not have a name then what will be the logical name?

If the object does not have a name then the logical name could be the attached text.

157.What is the different between GUI map and GUI map files?

a) The GUI map is actually the sum of one or more GUI map files. There are two modes for organizing GUI map files.

i. Global GUI Map file: a single GUI Map file for the entire application

ii. GUI Map File per Test: WinRunner automatically creates a GUI Map file for each test created.

b) GUI Map file is a file which contains the windows and the objects learned by the WinRunner with its logical name and their physical description.

158.How do you view the contents of the GUI map?

a) GUI Map editor displays the content of a GUI Map. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description.

160.What is startup script in WinRunner?

It is writing a script and when WinRunner starts it automatically runs the script. If you write script like invoking some application as soon as the script is run the application will be invoked for the purpose of testing

161.What is the purpose of loading WinRunner add-ins?

Add-ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the add-in selected will be listed in the function generator,and while executing the script only those functions in the loaded add-in will be executed,else WinRunner will give an error message saying it does not recognize the function

162.What is the purpose of GUI spy?

Using the GUI spy you can view the properties of any GUI object and your desktop. You use the spy pointer to point to an object,and the GUI spy displays the properties and their values in the GUI spy dialog box. You can choose to view all properties of an object, or only the selected set of properties that WinRunner learns.

163.When you create GUI map do you record all the objects of specific objects?

a) If we are learning a window then WinRunner automatically learns all the objects in the window else we will we identifying those object, which are to be learned in a window, since we will be working with only those objects while creating scripts.

164.What is the purpose of set_window command?

b) Set_Window command sets the focus to the specified window. We use this command to set the focus to the required window before executing tests on a particular window.


Syntax: set_window(, time);

The logical name is the logical name of the window and time is the time the execution has to wait till it gets the given window into focus.

165.How do you load GUI map?

c) We can load a GUI Map by using the GUI_load command.

Syntax: GUI_load();

166..What is the disadvantage of loading the GUI maps through start up scripts?

d) If we are using a single GUI Map file for the entire AUT then the memory used by the GUI Map may be much high.

e) If there is any change in the object being learned then WinRunner will not be able to recognize the object, as it is not in the GUI Map file loaded in the memory. So we will have to learn the object again and update the GUI File and reload it.

167.How do you unload the GUI map?

f) We can use GUI_close to unload a specific GUI Map file or else we call use GUI_close_all command to unload all the GUI Map files loaded in the memory.

Syntax: GUI_close(); or GUI_close_all;

 

Test Director Interview Questions March 19, 2008

Posted by Thiyagarajan Veluchamy in Test Director Interview Questions.
Tags:
11 comments
  1. How many types of tabs in Test Director?
    There are 4 tabs available in Test Director.
    1. Requirement
    2. Test plan
    3.Test lab.
    4.Defect
     We can change the name of Tabs, as we like. Test Director enables us to rename the Tab. In TD there only 4 tabs are available.
  2. What is meant by test lab in test director?
    Test lab is a part of test director where we can execute our test on different cycles creating test tree for each one of them. We need to add test to these test trees from the tests, which are placed under test plan in the project.
  3. What is Test Director
    Its a Mercury interactive’s Test management tool. It includes all the features we need to organize and manage the testing process.
  4. What are all the main features of Test Director?
    It enables us to create a database of tests,execute tests, report and track defects detected in the software.
  5. How the assessment of the application will be taken place in Test Director?
    As we test, Test Director allows us to continuously assess the status of our application by generating sophisticated reports and graphs. By integrating all tasks involved in software testing Test Director helps us to ensure that our software is ready for deployment.
  6. What the planning tests will do in Test Director?
    It is used to develop a test plan and create tests. This includes defining goals and strategy,designing tests,automating tests where beneficial and analyzing the plan.
  7. What the running tests will do in Test Director?
    It execute the test created in the planning test phase, and analyze the test results.
  8. What the tracking defects will do in Test Director?
    It is used to monitor the software quality. It includes reporting defects,determining repair priorities,assigning tasks,and tracking repair progress.
  9. What are all the three main views available in What the running tests will do in Test Director?

    ? Plan tests

    ? Run tests

    ? Track defects

    Each view includes all the tools we need to complete each phase of the testing process

  10. What is test plan tree?

    A test plan tree enables you to organize and display your test hierarchically,according to your testing requirements

  11. What are all the contents of test plan tree?

    Test plan tree can include several type of tests

    ? Manual test scripts

    ? Win Runner test scripts

    ? Batch of Win Runner test scripts

    ? Visual API test scripts

    ? Load Runner scenario scripts and Vuser scripts

  12. What is test step?

    A test step includes the action to perform in our application,input to enter,and its expected output

  13. TestDirector is a Test management tool

  14. What are all the components of TestDirector5.0?

    Plan tests,Run tests,Track defects

  15. Who is having full privileges in TestDirector project?

    TD Admin

  16. What is test set?

    A test set is a subset of tests in our database designed to achieve a specified testing objective

  17. How the analyzing of test results will be accomplished in TestDirector?

    Analyzing results will be accomplished by viewing run data and by generating TestDirector reports and graphs

  18. What is Test set builder?

    The test set builder enables us to create,edit,and delete test sets. Our test sets can include both manual and automated tests. We can include the same test in different test sets.

  19. How the running of Manual test will be accomplished in TestDirector?

    When running a manual test,we perform the actions detailed in the test steps and compare them to the expected results. The mini step window allows us to conveniently perform manual tests and record results with TestDirector minimized

  20. How the running of Automated test will be accomplished in TestDirector?

    We can execute automated tests on our own computer or on multiple remote hosts. The test execution window enables us to control test execution and manage hosts. We can execute a single test, or launch an entire batch of tests.

  21. How to execute test plan in testdirector?

    Write testcases in test plan(Description and expected results)

    To execute them go to TEST LAB . Give coverage from test plan to test lab by selecting “select tests”.

    Then click on RUN of RUN TEST SET to execute the test cases.

  22. What is the use of Test Director software?

    TestDirector is Mercury Interactive’s software test management tool. It helps quality assurance personnel plan and organize the testing process. With TestDirector you can create database of manual and automated tests, build test cycles, run tests, and report and track defects.

  23. How you integrated your automated scripts from TestDirector?

    When you work with WinRunner , you can choose to save your tests directly to your TestDirector database or while creating a test case in the TestDirector we can specify whether the script in automated or manual.

    20.Who all are having the rights to detect and report the defects?

  24. Who all are having the rights to detect and report the defects?

    ? Software developers

    ? Testers

    ? End users

  25. What are the main things want to be considered while reporting the bug?

    ? Description about the bug

    ? Software version

    ? Additional informations necessary to reproduce and repair the defect

  26. Describe about mailing defect data

    Connecting TestDirector to your e-mail system lets you routinely inform development and quality assurance personnel about defect repair activity.

  27. What is report designer?

    Its a powerful and flexible tool that allows you to design your own unique reports

  28. What is the use of graphs in TestDirector?

    TestDirector graphs help us visualize the progress of test planning,test execution,and defect tracking for our application,so that we can detect bottlenecks in the testing process.

  29. What is difference between master test plan and test plan?
    Master plan is a document showing the planning for whole of the project i.e. all the phases of the project whereas the test plan is the document required for only testing people.
  30. How to generate the graphs in Test Director?
    The generation of graphs in the Test Director that to Test Lab module is:
    1. Analysis
    2. graph.
    3. Graph Wizard.
    4. select the graph type as summary and click the next button.
    5. Select the show current tests and click the next button.
    6. Select the define a new filter and click the filter button.
    7. Select the tests set and click on the ok button
    8. select the plan: subject and click on the Ok button.
    9. select the plan:status.
    10. select the test set as X axis.
    11. Click the finish button.
  31. How can we export multiple test cases from TD in a single go?
    If we want to export it to any office tools
    1. Select the multiple steps/cases you need.
    2. Right click > save as and proceed.
  32. How to upload test cases from excel into test director?
    First we have to activate excel in test director with the help of adding page. After activation we can view the option as ‘export to test director’ in excel under tools tab.
    If you select the export to test director pop up dialog box opens the following process should be followed i.e.,
    Enter
    1. URL of Test Director
    2. Domain name and project name
    3. user name and password
    4. Select anyone of these 3 options: Requirements or test cases or defects
    5. Select a map option. a)select a map b)select a new map name c)create a temporary map.
    6. Map the test director to corresponding excel. Map the field whatever you mention in excel.These are the required steps to export the excel into TD.
  33. Does anyone know of any integration between Test director and Rational Robot?
    Any idea on the technical feasibility of such integration and level of effort would also be interesting?
    Test Director is software management tool. It is a Mercury Interactive Product.
    Rational Robot is a Rational product. It comes included with ‘test manager’ module for software management.
    Integrating the test director and Rational Robot is not feasible.
  34. Explain the project tree in test director?
    Project Tree in test director : Planning tests –Create test– execute tests–tracking defects.
  35.  What is coverage status, what does it do?
    Coverage status is percentage of testing covered at a given time. If you have 100 test cases in a project and you have finished 40 of test cases out of total test cases then your coverage status of project is 40%. Coverage Status is used to keep track of project accomplishment to meet the final deadline of the deliverables.
  36.  Difference between data validation and data integrity.
    Data Validation: We check whether the input data/output data is valid in terms of its length, data type etc..
    Data Integrity: We check out database contains only accurate data. We implement data integrity with the help of integrity constraints. So in data integrity we check whether the integrity constraints or implemented correctly or not
  37.  What are the uses of filters in test director?
    Limits the data displayed according to the criteria you specified.
    For Ex: You could create a filter that displays only those tests associated with the specified tester and subject.
    Each filter contains multiple filter conditions. These are expressions that are applied to a test plan tree or to the field in a grid. When the filter is applied, only those records that meet the filter conditions are displayed.
    You create and edit filters with the filter dialog box.This opens when you select the filter command. Once you have created a filter, we can save it for future use.
  38. How do we generate test cases through test director?
    Test lab we do the design step. Design grid we create parent child tree.
    Ex: Database operation (test name)
    1. Delete an order
    Description: Click delete button to delete the order.
    Expected results: Order is deleted.
    Pass/Fail:
    Update an order
    create an order.
  39. What are the datatypes a available in PL/SQL ?
  40. Difference between WEBINSPECT-QAINSPECT and WINRUNNER/TEST DIRECTOR?
  41. How will you generate the defect ID in test director? Is it generated automatically or not?
  42. Difference between TD 8.0 (Test director) and QC 8.0 (Quality Center).
  43. How do you ensure that there are no duplication of bugs in Test Director?
  44. Difference between WinRunner and Test Director?
  45. How will you integrated your automated scripts from TestDirector?
  46. What is the use of Test Director software?
  47. What is the Extra tab in QC ? (TCS)
  48. What is Test Builder?(TCS)
  49. I am using Quality Center 9.2. While raising a defect i can see that there is only option to send a mail to assigned and it is also sent to me. Is there any way i can send the mail to multiple users ? I know i can save the defect and than later sent it to multiple users, but is there any way where i can send it at the time of raising the defect itself. Any configuration that can be done by an adminstrator?
  50. what is connection between test plan tab and test lab tab? how can u access your test cases in test lab tab?
  51. How do you create Test script from Quality centre Using QTP
  52. What is the difference between Quality centre and Test Director
  53. what is the last version in TD to support for qtp?
  54. What r the madatory fields in TD?
  55. TD is web based or client/server?
  56. What is the latest version in TD?
  57. What r the views in testdirector?
  58. How to map testcases with requirements in test lab?
  59. how can we see all fields in test director
  60. How do you prepare Bug Reports ? What all do you include in Bug Report ?
  61. How can we connect defectreport from testlab&testplan tabs?
  62. Hi, I would like to upload from excel sheet test case to Quality center test plan section .Please tell me how to upload data(written test case in excel) to Quality center.
  63. what is RTM in test director?
  64. what iz d difference between TD an QC??
  65. Can any one tell how to install the TD in our system?
  66. how many ways are there to copy test cases in test director
  67. how to import excel/word data into the test plan module of quality center 9.0
  68. what would be purpose of Dashboard on Quality center? please provide me the advantage of dashboard? thanks in advance….
  69. what was the advantage of Quality center? functions performed using Quality center? thanks in advance
  70. can test cases we wroitten directly on td. wat else we can do in td
  71. What do you mean by Requirment Coverage?
  72. how will you do execution workflow, creat and modify test sets

A – Z Testing March 19, 2008

Posted by Thiyagarajan Veluchamy in a to z testing.
Tags: , ,
add a comment

To know with the basic definitions of software testing and quality assurance this is the best glossary compiled by Erik van Veenendaal. Also for each definition there is a reference of IEEE or ISO mentioned in brackets.

 

A

acceptance criteria: The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE 610]

acceptance testing: Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system. [After IEEE 610]

accessibility testing: Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard]

accuracy: The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing.

actual result: The behavior produced/observed when a component or system is tested.

 

ad hoc testing: Testing carried out informally; no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and randomness guides the test execution activity.

adaptability: The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See also portability testing.

 

agile testing: Testing practice for a project using agile methodologies, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm.

alpha testing: Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organization. Alpha testing is often employed as a form of internal acceptance testing.

analyzability: The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified. [ISO 9126] See also maintainability testing.

anomaly: Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc. or from someone’s perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation. [IEEE 1044] See also defect, deviation, error, fault, failure, incident, problem.

attractiveness: The capability of the software product to be attractive to the user. [ISO 9126]

audit: An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify:

(1) the form or content of the products to be produced

(2) the process by which the products shall be produced

(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]

audit trail: A path by which the original input to a process (e.g. data) can be traced back through the process, taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap]

automated testware: Testware used in automated testing, such as tool scripts.

availability: The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage. [IEEE 610]

 

B

back-to-back testing: Testing in which two or more variants of a component or system are executed with the same inputs, the outputs compared, and analyzed in cases of discrepancies. [IEEE 610]

baseline: A specification or software product that has been formally reviewed or agreed upon, that thereafter serves as the basis for further development, and that can be changed only through a formal change control process. [After IEEE 610]

basic block: A sequence of one or more consecutive executable statements containing no branches.

basis test set: A set of test cases derived from the internal structure or specification to ensure that 100% of a specified coverage criterion is achieved.

behavior: The response of a component or system to a set of input values and preconditions.

benchmark test: (1) A standard against which measurements or comparisons can be made. (2) A test that is be used to compare components or systems to each other or to a standard as in (1). [After IEEE 610]

bespoke software: Software developed specifically for a set of users or customers. The opposite is off-the-shelf software.

best practice: A superior method or innovative practice that contributes to the improved performance of an organization under given context, usually recognized as ‘best’ by other peer organizations.

beta testing: Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing in order to acquired feedback from the market.

big-bang testing: A type of integration testing in which software elements, hardware elements, or both are combined all at once into a component or an overall system, rather than in stages. [After IEEE 610] See also integration testing.

black box testing: Testing, either functional or non-functional, without reference to the internal structure of the component or system.

black box test design techniques: Documented procedure to derive and select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.

blocked test case: A test case that cannot be executed because the preconditions for its execution are not fulfilled.

bottom-up testing: An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested. See also integration testing.

boundary value: An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum or maximum value of a range.

boundary value analysis: A black box test design technique in which test cases are designed based on boundary values.

boundary value coverage: The percentage of boundary values that have been exercised by a test suite.

branch: A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths are available, e.g. case, jump, go to, ifthen- else.

branch coverage: The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.

branch testing: A white box test design technique in which test cases are designed to execute branches.

business process-based testing: An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes.

 

C

Capability Maturity Model (CMM): A five level staged framework that describes the key elements of an effective software process. The Capability Maturity Model covers practices for planning, engineering and managing software development and maintenance. [CMM]

Capability Maturity Model Integration (CMMI): A framework that describes the key elements of an effective product development and maintenance process. The Capability Maturity Model Integration covers practices for planning, engineering and managing product development and maintenance. CMMI is the designated successor of the CMM. [CMMI]

capture/playback tool: A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.

CASE: Acronym for Computer Aided Software Engineering.

CAST: Acronym for Computer Aided Software Testing. See also test automation.

cause-effect graph: A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects), which can be used to design test cases.

cause-effect graphing: A black box test design technique in which test cases are designed from cause-effect graphs. [BS 7925/2]

 

certification: The process of confirming that a component, system or person complies with its specified requirements, e.g. by passing an exam.

changeability: The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability.

classification tree method: A black box test design technique in which test cases, described by means of a classification tree, are designed to execute combinations of representatives of input and/or output domains. [Grochtmann]

code coverage: An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g. statement coverage, decision coverage or condition coverage.

co-existence: The capability of the software product to co-exist with other independent software in a common environment sharing common resources. [ISO 9126] See portability testing.

complexity: The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify. See also cyclomatic complexity.

compliance: The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions. [ISO 9126]

compliance testing: The process of testing to determine the compliance of component or system.

component: A minimal software item that can be tested in isolation.

component integration testing: Testing performed to expose defects in the interfaces and interaction between integrated components.

component specification: A description of a component’s function in terms of its output values for specified input values under specified conditions, and required non-functional behavior (e.g. resource-utilization).

component testing: The testing of individual software components. [After IEEE 610]

compound condition: Two or more single conditions joined by means of a logical operator (AND, OR or XOR), e.g. ‘A>B AND C>1000’.

concurrency testing: Testing to determine how the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or system. [After IEEE 610]

condition: A logical expression that can be evaluated as True or False, e.g. A>B. See also test condition.

condition coverage: The percentage of condition outcomes that have been exercised by a test suite. 100% condition coverage requires each single condition in every decision statement to be tested as True and False.

condition determination coverage: The percentage of all single condition outcomes that independently affect a decision outcome that have been exercised by a test case suite. 100% condition determination coverage implies 100% decision condition coverage.

condition determination testing: A white box test design technique in which test cases are designed to execute single condition outcomes that independently affect a decision outcome.

condition testing: A white box test design technique in which test cases are designed to execute condition outcomes.

condition outcome: The evaluation of a condition to True or False.

configuration: The composition of a component or system as defined by the number, nature, and interconnections of its constituent parts.

configuration auditing: The function to check on the contents of libraries of configuration items, e.g. for standards compliance. [IEEE 610]

configuration control: An element of configuration management, consisting of the evaluation, co-ordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE 610]

configuration identification: An element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation. [IEEE 610]

configuration item: An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process. [IEEE 610]

configuration management: A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE 610]

consistency: The degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a component or system. [IEEE 610]

control flow: An abstract representation of all possible sequences of events (paths) in the execution through a component or system.

conversion testing: Testing of software used to convert data from existing systems for use in replacement systems.

COTS: Acronym for Commercial Off-The-Shelf software.

coverage: The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.

coverage analysis: Measurement of achieved coverage to a specified coverage item during test execution referring to predetermined criteria to determine whether additional testing is required and if so, which test cases are needed.

coverage item: An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements.

coverage tool: A tool that provides objective measures of what structural elements, e.g. statements, branches have been exercised by the test suite.

cyclomatic complexity: The number of independent paths through a program. Cyclomatic complexity is defined as: L – N + 2P, where – L = the number of edges/links in a graph – N = the number of nodes in a graph – P = the number of disconnected parts of the graph (e.g. a calling graph and a subroutine). [After McCabe]

D

data definition: An executable statement where a variable is assigned a value.

data driven testing: A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution tools such as capture/playback tools. [Fewster and Graham] See also keyword driven testing.

data flow: An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of: creation, usage, or destruction. [Beizer]

data flow analysis: A form of static analysis based on the definition and usage of variables.

data flow coverage: The percentage of definition-use pairs that have been exercised by a test case suite.

data flow test: A white box test design technique in which test cases are designed to execute definition and use pairs of variables.

debugging: The process of finding, analyzing and removing the causes of failures in software.

debugging tool: A tool used by programmers to reproduce failures, investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step by step, to halt a program at any program statement and to set and examine program variables.

decision: A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.

decision condition coverage: The percentage of all condition outcomes and decision outcomes that have been exercised by a test suite. 100% decision condition coverage implies both 100% condition coverage and 100% decision coverage.

decision condition testing: A white box test design technique in which test cases are designed to execute condition outcomes and decision outcomes.

decision coverage: The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage.

decision table: A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.

decision table testing: A black box test design techniques in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table. [Veenendaal]

decision testing: A white box test design technique in which test cases are designed to execute decision outcomes.

decision outcome: The result of a decision (which therefore determines the branches to be taken).

defect: A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

defect density: The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g. lines-ofcode, number of classes or function points).

Defect Detection Percentage (DDP): the number of defects found by a test phase, divided by the number found by that test phase and any other means afterwards.

defect report: A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. [After IEEE 829]

defect management: The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact. [After IEEE 1044]

defect masking: An occurrence in which one defect prevents the detection of another. [After IEEE 610]

definition-use pair: The association of the definition of a variable with the use of that variable. Variable uses include computational (e.g. multiplication) or to direct the execution of a path (“predicate” use).

deliverable: Any (work) product that must be delivered to someone other that the (work) product’s author.

design-based testing: An approach to testing in which test cases are designed based on the architecture and/or detailed design of a component or system (e.g. tests of interfaces between components or systems).

desk checking: Testing of software or specification by manual simulation of its execution.

development testing: Formal or informal testing conducted during the implementation of a component or system, usually in the development environment by developers. [After IEEE 610]

documentation testing: Testing the quality of the documentation, e.g. user guide or installation guide.

domain: The set from which valid input and/or output values can be selected.

driver: A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [After TMap]

dynamic analysis: The process of evaluating behavior, e.g. memory performance, CPU usage, of a system or component during execution. [After IEEE 610]

dynamic comparison: Comparison of actual and expected results, performed while the software is being executed, for example by a test execution tool.

dynamic testing: Testing that involves the execution of the software of a component or system.

 E

efficiency: The capability of the software product to provide appropriate performance, relative to the amount of resources used under stated conditions. [ISO 9126]

efficiency testing: The process of testing to determine the efficiency of a software product.

elementary comparison testing: A black box test design techniques in which test cases are designed to execute combinations of inputs using the concept of condition determination coverage. [TMap]

emulator: A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator.

entry criteria: the set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria. [Gilb and Graham]

entry point: The first executable statement within a component.

equivalence partition: A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification.

equivalence partition coverage: The percentage of equivalence partitions that have been exercised by a test suite.

equivalence partitioning: A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.

error: A human action that produces an incorrect result. [After IEEE 610]

error guessing: A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them.

error seeding: The process of intentionally adding known defects to those already in the component or system for the purpose of monitoring the rate of detection and removal, and estimating the number of remaining defects. [IEEE 610]

error tolerance: The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].

exception handling: Behavior of a component or system in response to erroneous input, from either a human user or from another component or system, or to an internal failure.

executable statement: A statement which, when compiled, is translated into object code, and which will be executed procedurally when the program is running and may perform an action on data.

exercised: A program element is said to be exercised by a test case when the input value causes the execution of that element, such as a statement, decision, or other structural element.

exhaustive testing: A test approach in which the test suite comprises all combinations of input values and preconditions.

exit criteria: The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used by testing to report against and to plan when to stop testing. [After Gilb and Graham]

exit point: The last executable statement within a component.

expected result: The behavior predicted by the specification, or another source, of the component or system under specified conditions.

exploratory testing: Testing where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. [Bach]

F

fail: A test is deemed to fail if its actual result does not match its expected result.

failure: Actual deviation of the component or system from its expected delivery, service or result. [After Fenton]

failure mode: The physical or functional manifestation of a failure. For example, a system in failure mode may be characterized by slow operation, incorrect outputs, or complete termination of execution.

Failure Mode and Effect Analysis (FMEA): A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence.

failure rate: The ratio of the number of failures of a given category to a given unit of measure, e.g. failures per unit of time, failures per number of transactions, failures per number of computer runs. [IEEE 610]

fault tolerance: The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface. [ISO 9126] See also reliability.

fault tree analysis: A method used to analyze the causes of faults (defects).

feasible path: A path for which a set of input values and preconditions exists which causes it to be executed.

feature: An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints). [After IEEE 1008]

finite state machine: A computational model consisting of a finite number of states and transitions between those states, possibly with accompanying actions. [IEEE 610]

formal review: A review characterized by documented procedures and requirements, e.g. inspection.

frozen test basis: A test basis document that can only be amended by a formal change control process. See also baseline.

Function Point Analysis (FPA): Method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources, and project control.

functional integration: An integration approach that combines the components or systems for the purpose of getting a basic functionality working early. See also integration testing.

functional requirement: A requirement that specifies a function that a component or system must perform. [IEEE 610]

functional test design technique: Documented procedure to derive and select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure. See also black box test design technique.

functional testing: Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing.

functionality: The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions. [ISO 9126]

functionality testing: The process of testing to determine the functionality of a software product.

G

glass box testing: See white box testing.

H

heuristic evaluation: A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called “heuristics”).

high level test case: A test case without concrete (implementation level) values for input data and expected results.

horizontal traceability: The tracing of requirements for a test level through the layers of test documentation (e.g. test plan, test design specification, test case specification and test procedure specification).

 

I

impact analysis: The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.

incremental development model: A development life cycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overal project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this life cycle model, each subproject follows a ‘mini V-model’ with its own design, coding and testing phases.

incremental testing: Testing where components or systems are integrated and tested one or some at a time, until all the components or systems are integrated and tested.

incident: Any event occurring during testing that requires investigation. [After IEEE 1008]

incident management: The process of recognizing, investigating, taking action and disposing of incidents. It involves recording incidents, classifying them and identifying the impact. [After IEEE 1044]

incident management tool: A tool that facilitates the recording and status tracking of incidents found during testing. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of incidents and provide reporting facilities.

incident report: A document reporting on any event that occurs during the testing which requires investigation. [After IEEE 829]

independence: Separation of responsibilities, which encourages the accomplishment of objective testing. [After DO-178b]

infeasible path: A path that cannot be exercised by any set of possible input values.

informal review: A review not based on a formal (documented) procedure.

input: A variable (whether stored within a component or outside) that is read by a component.

input domain: The set from which valid input values can be selected.. See also domain.

input value: An instance of an input. See also input.

inspection: A type of review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure. [After IEEE 610, IEEE 1028]

installability: The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability.

installability testing: The process of testing the installability of a software product. See also portability testing.

installation guide: Supplied instructions on any suitable media, which guides the installer through the installation process. This may be a manual guide, step-by-step procedure, installation wizard, or any other similar process description.

installation wizard: Supplied software on any suitable media, which leads the installer through the installation process. It normally runs the installation process, provides feedback on installation results, and prompts for options.

instrumentation: The insertion of additional code into the program in order to collect information about program behavior during execution.

instrumenter: A software tool used to carry out instrumentation.

intake test: A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase.

integration: The process of combining components or systems into larger assemblies.

integration testing: Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing, system integration testing.

interface testing: An integration test type that is concerned with testing the interfaces between components or systems.

interoperability: The capability of the software product to interact with one or more specified components or systems. [After ISO 9126] See also functionality.

interoperability testing: The process of testing to determine the interoperability of a software product. See also functionality testing.

invalid testing: Testing using input values that should be rejected by the component or system. See also error tolerance.

isolation testing: Testing of individual components in isolation from surrounding components, with surrounding components being simulated by stubs and drivers, if needed.

 K

keyword driven testing: A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control script for the test. See also data driven testing.

 L

LCSAJ: A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements, the end of the linear sequence, and the target line to which control flow is transferred at the end of the linear sequence.

LCSAJ coverage: The percentage of LCSAJs of a component that have been exercised by a test suite. 100% LCSAJ coverage implies 100% decision coverage.

LCSAJ testing: A white box test design technique in which test cases are designed to execute LCSAJs.

learnability: The capability of the software product to enable the user to learn its application. [ISO 9126] See also usability.

load test: A test type concerned with measuring the behavior of a component or system with increasing load, e.g. number of parallel users and/or numbers of transactions to determine what load can be handled by the component or system.

low level test case: A test case with concrete (implementation level) values for input data and expected results.

 

M

maintenance: Modification of a software product after delivery to correct defects, to improve performance or other attributes, or to adapt the product to a modified environment. [IEEE 1219]

maintenance testing: Testing the changes to an operational system or the impact of a changed environment to an operational system.

maintainability: The ease with which a software product can be modified to correct defects, modified to meet new requirements, modified to make future maintenance easier, or adapted to a changed environment. [ISO 9126]

maintainability testing: The process of testing to determine the maintainability of a software product.

management review: A systematic evaluation of software acquisition, supply, development, operation, or maintenance process, performed by or on behalf of management that monitors progress, determines the status of plans and schedules, confirms requirements and heir system allocation, or evaluates the effectiveness of management approaches to achieve fitness for purpose. [After IEEE 610, IEEE 1028]

maturity: (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and work practices. See also Capability Maturity Model, Test Maturity Model. (2) The capability of the software product to avoid failure as a result of defects in the software. [ISO 9126] See also reliability.

measure: The number or category assigned to an attribute of an entity by making a measurement [ISO 14598].

measurement: The process of assigning a number or category to an entity to describe an attribute of that entity. [ISO 14598]

measurement scale: A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]

memory leak: A defect in a program’s dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it, eventually causing the program to fail due to lack of memory.

metric: A measurement scale and the method used for measurement. [ISO 14598]

milestone: A point in time in a project at which defined (intermediate) deliverables and results should be ready.

moderator: The leader and main person responsible for an inspection or other review process.

monitor: A software tool or hardware device that run concurrently with the component or system under test and supervises, records and/or analyses the behavior of the component or system. [After IEEE 610]

multiple condition coverage: The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% condition determination coverage.

multiple condition testing: A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement).

mutation analysis: A method to determine test suite thoroughness by measuring the extent to which a test suite can discriminate the program from slight variants (mutants) of the program.

N

N-switch coverage: The percentage of sequences of N+1 transitions that have been exercised by a test suite. [Chow]

N-switch testing: A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions. [Chow] See also state transition testing.

negative testing: Tests aimed at showing that a component or system does not work. Negative testing is related to the testers’ attitude rather than a specific test approach or test design technique. [After Beizer].

non-conformity: Non fulfillment of a specified requirement. [ISO 9000]

non-functional requirement: A requirement that does not relate to functionality, but to attributes of such as reliability, efficiency, usability, maintainability and portability.

non-functional testing: Testing the attributes of a component or system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability.

non-functional test design techniques: Methods used to design or select tests for nonfunctional testing.

 O

off-the-shelf software: A software product that is developed for the general market, i.e. for a large number of customers, and that is delivered to many customers in identical format.

operability: The capability of the software product to enable the user to operate and control it. [ISO 9126] See also usability.

operational environment: Hardware and software products installed at users’ or customers’ sites where the component or system under test will be used. The software may include operating systems, database management systems, and other applications.

operational profile testing: Statistical testing using a model of system operations (short duration tasks) and their probability of typical use. [Musa]

operational testing: Testing conducted to evaluate a component or system in its operational environment. [IEEE 610]

output: A variable (whether stored within a component or outside) that is written by a component.

output domain: The set from which valid output values can be selected. See also domain.

output value: An instance of an output. See also output.

 P

pair programming: A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews are performed.

pair testing: Two testers work together to find defects. Typically, they share one computer and trade control of it while testing.

 

Pass: A test is deemed to pass if its actual result matches its expected result.

pass/fail criteria: Decision rules used to determine whether a test item (function) or feature has passed or failed a test. [IEEE 829]

path: A sequence of events, e.g. executable statements, of a component or system from an entry point to an exit point.

path coverage: The percentage of paths that have been exercised by a test suite. 100% path coverage implies 100% LCSAJ coverage.

path sensitizing: Choosing a set of input values to force the execution of a given path.

path testing: A white box test design technique in which test cases are designed to execute paths.

performance: The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate. [After IEEE 610] See efficiency.

performance indicator: A high level metric of effectiveness and/or efficiency used to guide and control progressive development, e.g. Defect Detection Percentage (DDP) for testing. [CMMI]

performance testing: The process of testing to determine the performance of a software product. See efficiency testing.

performance testing tool: A tool to support performance testing and that usually has two main facilities: load generation and test transaction measurement. Load generation can simulate either multiple users or high volumes of input data. During execution, response time measurements are taken from selected transactions and these are logged. Performance testing tools normally provide reports based on test logs and graphs of load against response times.

phase test plan: A test plan that typically addresses one test level.

portability: The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]

portability testing: The process of testing to determine the portability of a software product.

postcondition: Environmental and state conditions that must be fulfilled after the execution of a test or test procedure.

post-execution comparison: Comparison of actual and expected results, performed after the software has finished running.

precondition: Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.

 Priority: The level of (business) importance assigned to an item, e.g. defect.

process cycle test: A black box test design technique in which test cases are designed toexecute business procedures and processes. [TMap]

 process: A set of interrelated activities, which transform inputs into outputs. [ISO 12207]

project: A project is a unique set of coordinated and controlled activities with start and finish dates undertaken an objective conforming to specific requirements, including the constraints of time, cost and resources. [ISO 9000]

 project test plan: A test plan that typically addresses multiple test levels.

pseudo-random: A series which appears to be random but is in fact generated according to some prearranged sequence.

 Q

quality: The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations. [After IEEE 610]

quality assurance: Part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISO 9000]

quality attribute: A feature or characteristic that affects an item’s quality. [IEEE 610]

quality management: Coordinated activities to direct and control an organization with regard to quality. Direction and control with regard to quality generally includes the establishment of the quality policy and quality objectives, quality planning, quality control, quality assurance and quality improvement. [ISO 9000]

R

random testing: A black box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performance.

recoverability: The capability of the software product to re-establish a specified level of performance and recover the data directly affected in case of failure. [ISO 9126] See also reliability.

recoverability testing: The process of testing to determine the recoverability of a software product. See also reliability testing.

regression testing: Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.

release note: A document identifying test items, their configuration, current status and other delivery information delivered by development to testing, and possibly other stakeholders, at the start of a test execution phase. [After IEEE 829]

reliability: The ability of the software product to perform its required functions under stated conditions for a specified period of time, or for a specified number of operations. [ISO 9126]

reliability testing: The process of testing to determine the reliability of a software product.

replaceability: The capability of the software product to be used in place of another specified software product for the same purpose in the same environment. [ISO 9126] See also portability.

requirement: A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. [After IEEE 610]

requirements-based testing: An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.

requirements management tool: A tool that supports the recording of requirements, requirements attributes (e.g. priority, knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to pre-defined requirements rules.

requirements phase: The period of time in the software life cycle during which the equirements for a software product are defined and documented. [IEEE 610]

resource utilization: The capability of the software product to use appropriate amounts and types of resources, for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files, when the software performs its function under stated conditions. [After ISO 9126] See also efficiency.

resource utilization testing: The process of testing to determine the resource-utilization of a software product.

result: The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports, and communication messages sent out. See also actual result, expected result.

resumption criteria: The testing activities that must be repeated when testing is re-started after a suspension. [After IEEE 829]

re-testing: Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.

review: An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough. [After IEEE 1028]

reviewer: The person involved in the review who shall identify and describe anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process.

risk: A factor that could result in future negative consequences; usually expressed as impact and likelihood.

risk analysis: The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).

risk-based testing: Testing oriented towards exploring and providing information about product risks. [After Gerrard]

risk control: The process through which decisions are reached and protective measures are implemented for reducing risks to, or maintaining risks within, specified levels.

risk identification: The process of identifying risks using techniques such as brainstorming, checklists and failure history.

risk management: Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk.

robustness: The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also errortolerance, fault-tolerance.

root cause: An underlying factor that caused a non-conformance and possibly should be permanently eliminated through process improvement.

 

S

safety: The capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use. [ISO 9126]

safety testing: The process of testing to determine the safety of a software product.

scalability: The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]

scalability testing: Testing to determine the scalability of the software product.

scribe: The person who has to record each defect mentioned and any suggestions for improvement during a review meeting, on a logging form. The scribe has to make ensure that the logging form is readable and understandable.

scripting language: A programming language in which executable test scripts are written, used by a test execution tool (e.g. a capture/replay tool).

security: Attributes of software products that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data. [ISO 9126]

security testing: Testing to determine the security of the software product.

severity: The degree of impact that a defect has on the development or operation of a component or system. [After IEEE 610]

simulation: The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]

simulator: A device, computer program or system used during testing, which behaves or operates like a given system when provided with a set of controlled inputs. [After IEEE 610, DO178b] See also emulator.

smoke test: A subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. A daily build and smoke test is among industry best practices. See also intake test.

software quality: The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126]

specification: A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have been satisfied. [After IEEE 610]

specification-based test design technique: See black box test design technique.

specified input: An input for which the specification predicts a result.

stability: The capability of the software product to avoid unexpected effects from modifications in the software. [ISO 9126] See also maintainability.

 

state diagram: A diagram that depicts the states that a component or system can assume, and shows the events or circumstances that cause and/or result from a change from one state to another. [IEEE 610]

state table: A grid showing the resulting transitions for each state combined with each possible event, showing both valid and invalid transitions.

state transition: A transition between two states of a component or system.

state transition testing: A black box test design technique in which test cases are designed to execute valid and invalid state transitions. See also N-switch testing.

statement: An entity in a programming language, which is typically the smallest indivisible unit of execution.

statement coverage: The percentage of executable statements that have been exercised by a test suite.

statement testing: A white box test design technique in which test cases are designed toexecute statements.

static analysis: Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software artifacts.

static analyzer: A tool that carries out static analysis.

static code analysis: Analysis of program source code carried out without execution of that software.

static code analyzer: A tool that carries out static code analysis. The tool checks source code, for certain properties such as conformance to coding standards, quality metrics or data flow anomalies.

static testing: Testing of a component or system at specification or implementation level without execution of that software, e.g. reviews or static code analysis.

statistical testing: A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing.

status accounting: An element of configuration management, consisting of the recording andreporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of the approved changes. [IEEE 610]

 

Stress testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements. [IEEE 610]

structural coverage: Coverage measures based on the internal structure of the component.

structural test design technique: See white box test design technique.

stub: A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]

subpath: A sequence of executable statements within a component.

suspension criteria: The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [After IEEE 829]

suitability: The capability of the software product to provide an appropriate set of functions for specified tasks and user objectives. [ISO 9126] See also functionality.

Software Usability Measurement Inventory (SUMI): A questionnaire based usability test technique to evaluate the usability, e.g. user-satisfaction, of a component or system. [Veenendaal]

syntax testing: A black box test design technique in which test cases are designed based upon the definition of the input domain and/or output domain.

system: A collection of components organized to accomplish a specific function or set of functions. [IEEE 610]

system integration testing: Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet).

system testing: The process of testing an integrated system to verify that it meets specified requirements. [Hetzel]

 

T

technical review: A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. A technical review is also known as a peer review. [Gilb and Graham, IEEE 1028]

test approach: The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project’s goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed.

test automation: The use of software to perform or support test activities, e.g. test management, test design, test execution and results checking.

test basis: All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozen test basis. [After TMap]

test case: A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. [After IEEE 610]

test case specification: A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item. [After IEEE 829]

test charter: A statement of test objectives, and possibly test ideas. Test charters are amongst other used in exploratory testing. See also exploratory testing.

test comparator: A test tool to perform automated test comparison.

test comparison: The process of identifying differences between the actual results produced by the component or system under test and the expected results for a test. Test comparison can be performed during test execution (dynamic comparison) or after test execution.

test condition: An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, quality attribute, or structural element.

test data: Data that exists (for example, in a database) before a test is executed, and thataffects or is affected by the component or system under test.

test data preparation tool: A type of test tool that enables data to be selected from existing databases or created, generated, manipulated and edited for use in testing.

 

test design specification: A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases. [After IEEE 829]

test design tool: A tool that support the test design activity by generating test inputs from a specification that may be held in a CASE tool repository, e.g. requirements management tool, or from specified test conditions held in the tool itself.

test design technique: A method used to derive or select test cases.

test environment: An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test. [After IEEE 610]

test evaluation report: A document produced at the end of the test process summarizing all testing activities and results. It also contains an evaluation of the test process and lessons learned.

test execution: The process of running a test by the component or system under test, producing actual result(s).

test execution automation: The use of software, e.g. capture/playback tools, to control the execution of tests, the comparison of actual results to expected results, the setting up of test preconditions, and other test control and reporting functions.

test execution phase: The period of time in a software development life cycle during which the components of a software product are executed, and the software product is evaluated to determine whether or not requirements have been satisfied. [IEEE 610]

test execution schedule: A scheme for the execution of test procedures. The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed.

test execution technique: The method used to perform the actual test execution, either manually or automated.

test execution tool: A type of test tool that is able to execute other software using an automated test script, e.g. capture/playback. [Fewster and Graham]

test harness: A test environment comprised of stubs and drivers needed to conduct a test.

test infrastructure: The organizational artifacts needed to perform testing, consisting of test environments, test tools, office environment and procedures.

test item: The individual element to be tested. There usually is one test object and many test items. See also test object.

test level: A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test. [After TMap]

test log: A chronological record of relevant details about the execution of tests. [IEEE 829]

test logging: The process of recording information about tests executed into a test log.

test manager: The person responsible for testing and evaluating a test object. The individual, who directs, controls, administers plans and regulates the evaluation of a test object.

test management: The planning, estimating, monitoring and control of test activities, typically carried out by a test manager.

Test Maturity Model (TMM): A five level staged framework for test process improvement, related to the Capability Maturity Model (CMM) that describes the key elements of an effective test process.

Test Process Improvement (TPI): A continuous framework for test process improvement that describes the key elements of an effective test process, especially targeted at system testing and acceptance testing.

test object: The component or system to be tested. See also test item.

test objective: A reason or purpose for designing and executing a test.

test oracle: A source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark), a user manual, or an individual’s specialized knowledge, but should not be the code. [After Adrion]

test performance indicator: A metric, in general high level, indicating to what extent a certain target value or criterion is met. Often related to test process improvement objectives, e.g. Defect Detection Percentage (DDP).

test phase: A distinct set of test activities collected into a manageable phase of a project, e.g. the execution activities of a test level. [After Gerrard]

test plan: A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and test measurement techniques to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process [After IEEE 829]

test planning: The activity of establishing or updating a test plan.

test policy: A high level document describing the principles, approach and major objectives of the organization regarding testing.

test point analysis (TPA): A formula based test estimation method based on function point analysis. [TMap]

test procedure: See test procedure specification.

test procedure specification: A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829]

test process: The fundamental test process comprises planning, specification, execution, recording and checking for completion. [BS 7925/2]

test repeatability: An attribute of a test indicating whether the same results are produced each time the test is executed.

test run: Execution of a test on a specific version of the test object.

test script: Commonly used to refer to a test procedure specification, especially an automated one.

test specification: A document that consists of a test design specification, test case specification and/or test procedure specification.

test strategy: A high-level document defining the test levels to be performed and the testing within those levels for a programme (one or more projects).

test suite: A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.

test summary report: A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria. [After IEEE 829]

test target: A set of exit criteria.

test tool: A software product that supports one or more test activities, such as planning and control, specification, building initial files and data, test execution and test analysis. [TMap] See also CAST.

test type: A group of test activities aimed at testing a component or system regarding one or more interrelated quality attributes. A test type is focused on a specific test objective, i.e. reliability test, usability test, regression test etc., and may take place on one or more test levels or test phases. [After TMap]

testability: The capability of the software product to enable modified software to be tested. [ISO 9126] See also maintainability.

testability review: A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process. [After TMap]

testable requirements: The degree to which a requirement is stated in terms that permit establishment of test designs (and subsequently test cases) and execution of tests to determine whether the requirements have been met. [After IEEE 610]

tester: A technically skilled professional who is involved in the testing of a component or system.

testing: The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

testware: Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing. [After Fewster and Graham]

thread testing: A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy.

traceability: The ability to identify related items in documentation and software, such as requirements with associated tests. See also horizontal traceability, vertical traceability.

top-down testing: An incremental 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.

 

U

understandability: The capability of the software product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use. [ISO 9126] See also usability.

unreachable code: Code that cannot be reached and therefore is impossible to execute.

usability: The capability of the software to be understood, learned, used and attractive to the user when used under specified conditions. [ISO 9126]

usability testing: Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions. [After ISO 9126]

use case testing: A black box test design technique in which test cases are designed to execute user scenarios.

user test: A test whereby real-life users are involved to evaluate the usability of a component or system.

 

V

V-model: A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.

validation: Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. [ISO 9000]

variable: An element of storage in a computer that is accessible by a software program by referring to it by a name.

verification: Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled. [ISO 9000]

vertical traceability: The tracing of requirements through the layers of development documentation to components.

volume testing: Testing where the system is subjected to large volumes of data. See also resource-utilization testing.

 

W

walkthrough: A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. [Freedman and Weinberg, IEEE 1028]

white box test design technique: Documented procedure to derive and select test cases based on an analysis of the internal structure of a component or system.

white box testing: Testing based on an analysis of the internal structure of the component or system.

Wide Band Delphi: An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.

Testing Life Cycle March 18, 2008

Posted by Thiyagarajan Veluchamy in Testing Life Cycle.
Tags: , ,
3 comments

Life Cycle of Testing Process This article explains about Different steps in Life Cycle of Testing Process. In Each phase of the development process will have a specific input and a specific output. Once the project is confirmed to start, the phases of the development of project can be divided into the following phases:

  • Software requirements phase.
  • Software Design
  • Implementation
  • Testing
  • Maintenance

In the whole development process, testing consumes highest amount of time. But most of the developers oversee that and testing phase is generally neglected. As a consequence, erroneous software is released. The testing team should be involved right from the requirements stage itself.

The various phases involved in testing, with regard to the software development life cycle are:

  1.  Requirements stage
  2. Test Plan
  3.  Test Design.
  4. Design Reviews
  5. Code Reviews
  6. Test Cases preparation.
  7. Test Execution
  8. Test Reports.
  9. Bugs Reporting
  10. Reworking on patches.
  11. Release to production.

Requirements Stage

Normally in many companies, developers itself take part in the requirements stage. Especially for product-based companies, a tester should also be involved in this stage. Since a tester thinks from the user side whereas a developer can’t. A separate panel should be formed for each module comprising a developer, a tester and a user. Panel meetings should be scheduled in order to gather everyone’s view. All the requirements should be documented properly for further use and this document is called “Software Requirements Specifications”.

Test Plan

Without a good plan, no work is a success. A successful work always contains a good plan. The testing process of software should also require good plan. Test plan document is the most important document that brings in a process – oriented approach. A test plan document should be prepared after the requirements of the project are confirmed. The test plan document must consist of the following information:

• Total number of features to be tested.
• Testing approaches to be followed.
• The testing methodologies
• Number of man-hours required.
• Resources required for the whole testing process.
• The testing tools that are to be used.
• The test cases, etc

Test Design

Test Design is done based on the requirements of the project. Test has to be designed based on whether manual or automated testing is done. For automation testing, the different paths for testing are to be identified first. An end to end checklist has to be prepared covering all the features of the project.The test design is represented pictographically. The test design involves various stages. These stages can be summarized as follows:• The different modules of the software are identified first.
• Next, the paths connecting all the modules are identified.

Then the design is drawn. The test design is the most critical one, which decides the test case preparation. So the test design assesses the quality of testing process.

Test Cases Preparation

Test cases should be prepared based on the following scenarios:

• Positive scenarios
• Negative scenarios
• Boundary conditions and
• Real World scenarios

Design Reviews

The software design is done in systematical manner or using the UML language. The tester can do the reviews over the design and can suggest the ideas and the modifications needed.

Code Reviews

Code reviews are similar to unit testing. Once the code is ready for release, the tester should be ready to do unit testing for the code. He must be ready with his own unit test cases. Though a developer does the unit testing, a tester must also do it. The developers may oversee some of the minute mistakes in the code, which a tester may find out.

Test Execution and Bugs Reporting

Once the unit testing is completed and the code is released to QA, the functional testing is done. A top-level testing is done at the beginning of the testing to find out the top-level failures. If any top-level failures occur, the bugs should be reported to the developer immediately to get the required workaround.The test reports should be documented properly and the bugs have to be reported to the developer after the testing is completed.

Release to Production

Once the bugs are fixed, another release is given to the QA with the modified changes. Regression testing is executed. Once the QA assures the software, the software is released to production. Before releasing to production, another round of top-level testing is done. The testing process is an iterative process. Once the bugs are fixed, the testing has to be done repeatedly. Thus the testing process is an unending process.

Types of software Testing March 14, 2008

Posted by Thiyagarajan Veluchamy in Types of software Testing.
Tags: , ,
comments closed

Software Testing Types:

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

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

 

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

Incremental integration testing – Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers.

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

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

System testing – Entire system is tested as per the requirements. 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, 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 - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

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

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

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

Stress testing – System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.

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

Usability testing – User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

Recovery testing – Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Security testing – Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Compatibility testing – Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.

Comparison testing – Comparison of product strengths and weaknesses with previous versions or other similar products.

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

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

Web Testing, Example Test cases March 14, 2008

Posted by Thiyagarajan Veluchamy in Web Testing.
Tags: , ,
20 comments

WEB TESTING
While testing a web application you need to consider following Cases:

• Functionality Testing
• Performance Testing
• Usability Testing
• Server Side Interface
• Client Side Compatibility
• Security

Functionality:
In testing the functionality of the web sites the following should be tested:
• Links
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links

 

• Forms
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields

• Database
* Testing will be done on the database integrity.

• Cookies
* Testing will be done on the client system side, on the temporary Internet files.

Performance :
Performance testing can be applied to understand the web site’s scalability, or to benchmark the performance in the environment of third party products such as servers and middleware for potential purchase.

• Connection Speed:
Tested over various networks like Dial Up, ISDN etc
• Load:
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
• Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..

Usability:
Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction.
• Ease of learning
• Navigation
• Subjective user satisfaction
• General appearance

Server Side Interface:
In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.

Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.

Security:
The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection

Web Testing: Complete guide on testing web applications March 14, 2008

Posted by Thiyagarajan Veluchamy in Web Testing.
Tags: , ,
6 comments

In my previous post I have outlined points to be considered while testing web applications. Here we will see some more details on web application testing with web testing test cases. Let me tell you one thing that I always like to share practical knowledge, which can be useful to users in their career life. This is a quite long article so sit back and get relaxed to get most out of it.

Let’s have first web testing checklist.
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing

1) Functionality Testing:

Test for – all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing.

Check all the links:

  • Test the outgoing links from all the pages from specific domain under test.
  • Test all internal links.
  • Test links jumping on the same pages.
  • Test links used to send the email to admin or other users from web pages.
  • Test to check if there are any orphan pages.
  • Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages:
Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?

  • First check all the validations on each field.
  • Check for the default values of fields.
  • Wrong inputs to the fields in the forms.
  • Options to create forms if any, form delete, view or modify the forms.

Let’s take example of the search engine project currently I am working on, In this project we have advertiser and affiliate signup steps. Each sign up step is different but dependent on other steps. So sign up flow should get executed correctly. There are different field validations like email Ids, User financial info validations. All these validations should get checked in manual or automated web testing.

Cookies testing:
Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the sessions ends) check for login sessions and user stats after session end. Check effect on application security by deleting the cookies. (I will soon write separate article on cookie testing)

Validate your HTML/CSS:
If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to different search engines.

Database testing:
Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below.

2) Usability Testing:

Test for navigation:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.

Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing

Other user information for user help:
Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap.
“Search in the site” option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.

3) Interface Testing:
The main interfaces are:
Web server and application server interface
Application server and Database server interface.

Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between?

4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:

  • Browser compatibility
  • Operating system compatibility
  • Mobile browsing
  • Printing options

Browser compatibility:
In my web-testing career I have experienced this as most influencing part on web site testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.

OS compatibility:
Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API’s may not be available in all Operating Systems.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.

Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.

Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option.

5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web Stress Testing

Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.

In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,

6) Security Testing:

Following are some test cases for web security testing:

  • Test by pasting internal url directly into browser address bar without login. Internal pages should not open.
  • If you are logged in using username and password and browsing internal pages then try changing url options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the url site ID parameter to different site ID which is not related to logged in user. Access should denied for this user to view others stats.
  • Try some invalid inputs in input fields like login username, password, input text boxes. Check the system reaction on all invalid inputs.
  • Web directories or files should not be accessible directly unless given download option.
  • Test the CAPTCHA for automates scripts logins.
  • Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.
  • All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

I think I have addressed all major web testing methods. I have worked for around 2 years out of my testing career on web testing. There are some experts who have spent their whole career life on web testing. If I missed out addressing some important web testing aspect then let me know in comments below. I will keep on updating the article for latest testing information.

How can a Web site be tested? March 14, 2008

Posted by Thiyagarajan Veluchamy in Web Testing.
Tags: , , ,
add a comment

Points to be considered while testing a Web site:

Web sites are essentially client/server applications -
with web servers and ‘browser’ clients.

Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.).

 

Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort.

Other considerations might include:

What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?

Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?

What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?

Will down time for server and content maintenance/upgrades be allowed? how much?

What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?

How reliable are the site’s Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?

What processes will be required to manage updates to the web site’s content, and

what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?

Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?

Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??

How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet ‘traffic congestion’ problems to be accounted for in testing?

How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?

How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page.

The page layouts and design elements should be consistent throughout a site, so that it’s clear to the user that they’re still within a site.

Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.

All pages should have links external to the page; there should be no dead-end pages.
The page owner, revision date, and a link to a contact person or organization should be included on each page.

I am working on the search engine website. Testing a search engine site is a little bit different than a regular website. In my next posts I will explain how to test WWW in detail.

Software Automation Testing, Should Automate project Testing? March 14, 2008

Posted by Thiyagarajan Veluchamy in Automation Testing.
Tags: ,
add a comment

Should we go for Automtion testing of project?
This is really a difficult question as I understand.

If you are doing manual testing of your project and decide to go for Automation I think you will have to ask yourself some basic questions like:

Which is the best testing tool?
To which level should I automate project Testing?
Is it possible to Automate my complete application?

By asking these questions you can go to near the Automation testing decision. i.e To be or not to be?

Let’s have answers for these basic questions:

Which is the best testing tool?
A basic question asked often. Different people will give you different answers for this question.

It is important to evaluate the tool based on your project environment, your budget,skills level of individuals Some tools work better in specific
environments, while in another environment they can create compatibility issue.
Demonstrate the tool using your application under test.

You can go for some open source tools available in the market, but with
the study of indivisual tool and then finalising which is better suit for you.

Second question is:
To which level should I automate project Testing?
Or can I 100 percent Automate project?
- Automation testing can provide several benefits if implemented successfully.
Expectation to Automation comes alog with, but you may not have the results
as quick as you expect.
Test Engineer must evaluate the great potential and should be able to put these benifites into your application.

Keep in mind that 100 percent Automation of any project is difficult to achieve given the time and budget constraints.

So try to Automate as possible as you can, atleast 80 percent, which will greatly benefit to your organisation.

Feel free to ask me query on Software testing Automation. I will try my best to answer it!

How to find a bug in application? Tips and Tricks March 14, 2008

Posted by Thiyagarajan Veluchamy in Testing Skill Improvement.
Tags: , , ,
comments closed

very good and important point. Right? If you are a software tester or a QA engineer then you must be thinking every minute to find a bug in an application. And you should be!I think finding a blocker bug like any system crash is often rewarding! No I don’t think like that. You should try to find out the bugs that are most difficult to find and those always misleads users.

 

Finding such a subtle bugs is most challenging work and it gives you satisfaction of your work. Also it should be rewarded by seniors. I will share my experience of one such subtle bug that was not only difficult to catch but was difficult to reproduce also.
I was testing one module from my search engine project. I do most of the activities of this project manually as it is a bit complex to automate. That module consist of traffic and revenue stats of different affiliates and advertisers. So testing such a reports is always a difficult task. When I tested this report it was showing the data accurately processed for some time but when tried to test again after some time it was showing misleading results. It was strange and confusing to see the results.

There was a cron (cron is a automated script that runs after specified time or condition) to process the log files and update the database. Such multiple crons are running on log files and DB to synchronize the total data. There were two crons running on one table with some time intervals. There was a column in table that was getting overwritten by other cron making some data inconsistency. It took us long time to figure out the problem due to the vast DB processes and different crons.

My point is try to find out the hidden bugs in the system that might occur for special conditions and causes strong impact on the system. You can find such a bugs with some tips and tricks.

So what are those tips:

1) Understand the whole application or module in depth before starting the testing.

2) Prepare good test cases before start to testing. I mean give stress on the functional test cases which includes major risk of the application.

3) Create a sufficient test data before tests, this data set include the test case conditions and also the database records if you are going to test DB related application.

4) Perform repeated tests with different test environment.

5) Try to find out the result pattern and then compare your results with those patterns.

6) When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some monkey testing.

7) Use your previous test data pattern to analyse the current set of tests.

 Try some standard test cases for which you found the bugs in some different application. Like if you are testing input text box try inserting some html tags as the inputs and see the output on display page.

9) Last and the best trick is try very hard to find the bug  As if you are testing only to break the application!

I will include more tips in some coming posts.

Meantime you can comment out more tips here.

How to write software Testing Weekly Status Report March 14, 2008

Posted by Thiyagarajan Veluchamy in Bug Defect tracking.
Tags: , ,
comments closed

Writing effective status report is as important as the actual work you did! How to write a effective status report of your weekly work at 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.

So how to write weekly status report?

Follow the below template:
Prepared By:
Project:
Date of preparation:
Status:
A) Issues:
Issues holding the QA team from delivering on schedule:
Project:
Issue description:
Possible solution:
Issue resolution date:

You can mark these issues in red colour. These are the issues that requires managements help in resolving them.

Issues that management should be aware:

These are the issues that not hold the QA team from delivering on time but management should be aware of them. Mark these issues in Yellow colour. You can use above same template to report them.

Project accomplishments:
Mark them in Green colour. Use below template.
Project:
Accomplishment:
Accomplishment date:

B) Next week Priorities:
Actionable items next week list them in two categories:

1) Pending deliverables: Mark them in blue colour: These are previous weeks deliverables which should get released as soon as possible in this week.
Project:
Work update:
Scheduled date:
Reason for extending:

2) New tasks:
List all next weeks new task here. You can use black colour for this.
Project:
Scheduled Task:
Date of release:

C) Defect status:

Active defects:
List all active defects here with Reporter, Module, Severity, priority, assigned to.

Closed Defects:
List all closed defects with Reporter, Module, Severity, priority, assigned to.

Test cases:
List total number of test cases wrote, test cases passed, test cases failed, test cases to be executed.

This template should give you the overall idea of the status report. Don’t ignore the status report. Even if your managers are not forcing you to write these reports they are most important for your work assessment in future.

Try to follow report writing routine. Use this template or at least try to report it in your own words about the overall work of which you can keep some track.

Do you have any better idea for this routine work? Comment it out!

How to write effective Test cases, procedures and definitions March 14, 2008

Posted by Thiyagarajan Veluchamy in Software Testing Templates.
Tags: ,
7 comments

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written.

Here I will share some tips on how to write test cases, test case procedures and some basic test case definitions.

What is a test case?
“A test case has components that describes an input, action or event and an expected response, to determine if a feature of an application is working correctly.” Definition by Glossary

There are levels in which each test case will fall in order to avoid duplication efforts.
Level 1: In this level you will write the basic test cases from the available specification and user documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
Level 3: This is the stage in which you will group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases maximum of 10.
Level 4: Automation of the project. This will minimize human interaction with system and thus QA can focus on current updated functionalities to test rather than remaining busy with regression testing.

So you can observe a systematic growth from no testable item to a Automation suit.

Why we write test cases?
The basic objective of writing test cases is to validate the testing coverage of the application. If you are working in any CMMi company then you will strictly follow test cases standards. So writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.

How to write test cases?
Here is a simple test case format

Fields in test cases:

Test case id:
Unit to test:
What to be verified?
Assumptions:
Test data:
Variables and their values
Steps to be executed:
Expected result:
Actual result:
Pass/Fail:
Comments:

So here is a basic format of test case statement:

Verify
Using
[tool name, tag name, dialog, etc]
With [conditions]
To [what is returned, shown, demonstrated]

Verify: Used as the first word of the test case statement.
Using: To identify what is being tested. You can use ‘entering’ or ‘selecting’ here instead of using depending on the situation.

For any application basically you will cover all the types of test cases including functional, negative and boundary value test cases.

Keep in mind while writing test cases that all your test cases should be simple and easy to understand. Don’t write explanations like essays. Be to the point.

Try writing the simple test cases as mentioned in above test case format. Generally I use Excel sheets to write the basic test cases. Use any tool like ‘Test Director’ when you are going to automate those test cases.

Feel free to comment below any query regarding test case writing or execution.