Writing of Test Cases ?

Basics of Writing Test Cases:

#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.

For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.

#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.

#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.

#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.

#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.

#6. The MS word template looks something like this:

#7. The Excel template could look like the following:

#8. From the above two templates it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.

So, as long as there is a field for each of the type of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.

 Below is a list and please check out the links provided for more information on these methods.

• Boundary value analysis
• Equivalence partitioning
• Error guessing - This is a very simple method and relies on a tester’s intuition. An example is: Say there is a date field on a page. The requirements are going to specify that a valid date is to be accepted by this field. Now, a tester can try “Feb 30” as a date- because as far as the numbers are concerned, it is a valid input, but February is a month that never has 30 days in it- so an invalid input.
• State transition diagrams
• Decision tables

Using the above techniques and following the general test case creation process, we create a set of test cases that would effective test the application on hand.

Telling programmers to test own code?

Would you trust a programmer to test your application?  It’s like asking a Fox to guard the chicken-house, right?

Well, sometimes you don’t have a choice, or you do but that choice is to release the application untested.

As part of an Agile testing consulting engagement I am doing at a friend’s company, yesterday I started providing short training sessions for programmers who need to learn how to test better.  It’s not that this company doesn’t have testers, they have good testers!  But as many other agile teams they have much more testing tasks than available testers, and they want programmers to take part in at least some of their testing tasks.

Programmers are not good at testing or they might be but they don't want to do it properly because its their baby.

A couple of months ago I wrote a post explaining why I think programmers are poor testers, and I still think that in a sense it is like asking a dog to fly. On the other hand I also believe that with some good intentions, hard work, and perseverance you can teach a dog to skip far enough and that way to jump over large obstacles.

In the same way, you will not be able to magically transform programmers into a good testers overnight, but you can start by working with them on their weaknesses and then teaching them some simple and effective testing techniques.  With good intentions, a little practice, some hand-holding, and constant feedback you will be able to get some good testing help in your project.

Step 1 – understand the limitation and weaknesses of a programmer

I started my session yesterday by going over the points I listed in my earlier blog that make programmers “less-than-perfect-testers”:

- Parental feeling towards their own code.
– Placing the focus mainly on positive scenarios, instead of actively looking for the bugs.
– Tendency to look at a “complex problem” as a collection of “smaller, simpler, and isolated cases”.
– Less End-to-End or User-Perspective oriented.
– Less experience and knowledge of the common bugs and application pitfalls.

It made a big difference during the session to not only list the weaknesses but talk about why each of them is naturally present in programmers due to the nature of their work, their knowledge and training.

Step 2 – how to plan tests
I’ve seen that many (most?) programmers have the perception that testing requires little or no planning.

Maybe we testers are guilty of this misconception since we don’t get them involved in our test planning process as much as we should, but the truth of the matter is that when we ask them to test they they automatically grab a mouse and start pressing on the buttons without much consideration or thought.

Test Planning is a cardinal aspect of good tested, so I gave them a couple of ideas and principles planing:

1.  DON’T TEST YOUR OWN CODE!
When as a team they are asked to test, they should make sure to divide the tasks so that each of them is testing the code developed by other programmers as much as possible.

2.  Work with your testing team to create test sets.
This specific team is using PractiTest (the hosted QA and Test Management platform my company is developing), but it can be any other tool or format (even word and excel!).  They should sit with their testers and define what test cases need to be run, reusing the testing scripts already available in their repositories.

3.  Expand your scenarios by making “Testing Lists”
- Features that were created or modified (directly or indirectly)
– User profiles and scenarios to be verified.
– Different environments / configurations / datasets to be tested

The use of these lists is two-fold.
They help you get a better idea of what you want to test while you are running your manual test scripts, and they also serve as a verification list to consult towards the end of the tests when you are looking for additional ideas ow when you want to make sure you are not missing anything of importance.

4.  Testing Heuristics – SFDEPOT
The use of (good) heuristics greatly improve the quality of your testing.
I provided the programmers with the heuristic I learned fist and still helps me up to this day.  I read about SFDEPO(T) from James Bach some years ago – you can check one of the sources for it from Jame’s Site.

SFDEPOT stands for:
Structure (what the product is)
Function (what the produce does)
Data (what it processes)
Platform (what it depends upon)
Operations (how will it be used)
Time (when will it be used)
There are other heuristics and Mnemonics you can take from the Internet…

Step 3 – what to do when running tests
We talked a lot about tips to help perform good testing sessions.
1. Have a notebook handy.
In it you can take notes such as testing ideas you will want to test later, bugs you ran into and want to report later in order to “not to cut your testing thoughts”, etc.

2.  Work with extreme data.
Big files vs. Small files
Equivalent input classes [ -10 ; 0 ; 1 ; 10,000,000 ; 0.5 ; not-a-number ]
Dates: Yesterday, now, 10 years from now
etc

3.  Think about negative scenarios.
– How would Mr. Bean use your software?
– How would a hacker try to exploit the system? or you can say a mouse name Jerry enter your house and you are a Tom.
– What would happen if…? (blackout, run out of space, exceptions, etc)
– What if your  2 year old would hijack the keyboard in the middle of an operation?
– etc

4.  Focus & Defocus:
I used this technique to explain to them that during their testing process they need to make a conscious effort to always look at the bigger picture (application, system, process) and not only focus on the specific function they were testing.

5.  Fight Intentional Blindness:
I used the following film of the kids passing the balls to explain the concept of Inattentional Blindness and it worked great!
We were 8 people in the room, and only I had seen the video before.  Out of the 7 participants one is currently a tester, another one is a former tester turned programmer, the rest are “regular programmers”.
The cool thing is that only the 2 testers saw the Gorilla the first time…  talk about making a point!

Step 4 – what to do when (you think) you are done testing ?
We talked about how even when you think you are done testing you should always make sure there is nothing else that should be tested, and what techniques they can use in order to find these additional places:

1.  Walking the dog
Taking a break from your tests, doing another tasks for 30 – 60 minutes, and then returning to review the tests you did and what you found.  This break usually helps to refresh the mind and to come up with more ideas.

2.  Doing a walk-through session to review the tests you did.
Most of the time you will be able to get more ideas as you explain to your peers about tests you just did.
The funny part is that many of these ideas will come from yourself and the things you think about when you are explaining your tests to others out loud.

3.  Ask for ideas from other developers or testers.
Simple as it sounds, come to others in your team and ask them to pitch you ideas of stuff they think you could test.  90% of the stuff you will already have tested, but the other 10% might prove useful too!

In the end is a questions of mindset and motivation
One of the things I like most of agile teams (and many non-agile but yes smart development teams) is that they define Quality to be the responsibility of the whole team and not only of the testing guys running the tests tasks at the end of the process.



My final piece of advice to the group was that everything starts from them, and their understanding that testing is not a trivial task and definitely not a sequence of doing a bad job or for finishing their tasks ahead of time.  What’s more, I am sure that once these guys start testing better and gaining a testing perspective of their application they will also start developing better software too.

Why can’t developers be good testers?

I’ve been trying to explain to a couple of Agile Teams why developers are usually not good testers; so after working hard to remember all the reasons I could think of (based on my experience so far) I decided to put together a short list and post it.

Don’t get me wrong I think developers should take part in the testing tasks, specially on Agile Teams, but I am also aware of their limitations and the cognitive blind-spots that tend to harm their testing; and as it has been said before, the first step to improve your weaknesses is to understand you have them.

Why developers (usually) suck at testing?

1. “Parental feelings” towards their code
Developers are emotionally linked to the stuff they write.  It may sound silly but it is hard to be objective towards the stuff you create.
For example, I know my kids are not perfect and still I am sure I would have a hard time if someone would come to me and starts criticizing them in any way (after all they are perfect, right? :) ) .

2. Focus on the “Positive Paths”
Development work is based on taking positive scenarios and enabling them on the product.  Most of their efforts are concentrated on how to make things work right, effectively, efficiently, etc.  The mental switch required to move them from a positive/building mind-set to a negative/what-can-go-wrong mind-set is not trivial and very hard to achieve in a short time.

3. Work based on the principle of simplifying of complex scenarios
One of the basic things a tester does as part of his work is to look for complex scenarios (e.g. do multiple actions simultaneously, or make an operation over and over again, etc) in order to break the system and find the bugs.  So we basically take a simple thing and look for ways in which we can complicate it.

On the other hand our developer counterparts are trained into taking a complex process or project and breaking it down into the smallest possible components that will allow them to create a solution (I still remember my shock in college the first time I understood that all a computer could do was work with AND, OR, NOT, NAND, NOR, XOR and XNOR operations on Zeros & Ones).

4. Inability to catch small things in big pictures
I can’t really explain the reason behind this one, but I have seen it many times in my testing lifetime.
One of the side-effects from becoming a good tester is to develop a sense to (almost unconsciously) detect what “doesn’t fit” in the picture.  The best way to describe it is by the feeling one gets when something “doesn’t fit” in the picture but we just can’t put our hand on it; then by applying some systematic processes we are able to find the specific problem.

I had a developer once tell me that good testers can “smell bugs”, and maybe he was not very far from the truth.

5. Lack of end-to-end & real-user perspective
Do the nature of their tasks most developers concentrate on a single component or feature in their product, while they still maintain a vague idea of how their users work with their end-to-end system.
Testers need to have a much broader perspective of our products, we are required to understand and test them as a whole while using techniques that allow us to simulate the way users will eventually work in the real world.

6. Less experience with common bugs & application pitfalls

Again something that comes with time and experience is our knowledge of the common bugs and application pitfalls.  Obviously as a developer accumulates KLOCs on his keyboard he will also get to meet many bugs and pitfalls, but as a tester we are going to gain this experience faster and in a more deeper sense.

An experienced tester sees a form and automatically starts thinking about the common bugs and failures he may find in it and starts testing for them.

My bottom line
It’s not they don’t want to do it, developers simply are not able to test in the same way we tester do.  This doesn’t mean they cannot help in testing, and in some specific areas they will be able to do it even better than we do, but before they start it may help if they are able to map their testing-blind-spots in a way that will allow them to compensate for them.

Developer testing adds a lot of value to the general testing process…  I am even thinking as I write this about a future post on the subject of the added value gained from pairing developers and testers.

Don’t write a single test, Until you know how to do it !!

We've all heard about the “Infinite Monkey Theorem” whereby a monkey hitting keys on a keyboard (typewriter) at random will eventually come up even with the complete works of Shakespeare.

But the problem is that it would take it an infinite number of years, and maybe more importantly the work would be buried under so much junk and gibberish that it would be impossible to find it.

What’s the status of your test cases?

Now take a look at your test repository.  What do you see?
Is there anything in common with the work of the monkey above?

I am not implying your team is made up of chimps typing at random – even though if it is, please take a picture of them and send it back to me, I promise to publish it!!!

But something I see a lot in the context of my work with PractiTest’s customers is that people tend to concentrate on the quantity of their test cases, and fail to put enough efforts on the quality of their resources.

The result is repository with a lot more test cases than it should actually have, many of them covering the same feature too many times, others describing functionality that was modified a number of releases back, and some that have not been run in a number of years because they are not really important anymore.

I don’t think this comes from incompetence, but I do believe that a big factor for this is the fact that it is easier to create a new test than to find an existing case (or cases) and modifying it accordingly.

Another cause is the fact that it is a lot easier to measure the number of tests than the measure the quality of your testing coverage (and the quality of the individual tests cases themselves).

Process and rules of thumb for writing test cases

A good way of stopping problems of this type is to have some process and rules of thumb in place to help testers write better cases.

Some examples for rules of thumb you can define with the team can be the following:
Setting upper and lower limits for the number of steps per test case.
Setting maximum number of test cases per feature or functional area.
Working with modular test cases that you can use as building blocks for your complex test scenarios.
Have separate test cases for positive and negative scenarios.
Use attachments and spreadsheets to decouple testing data from testing processes.
Regarding process, this is a little harder but it is also a lot more effective in the long run.  Some examples might be:

Before starting to write test cases have a small team create the test list and their scope, only then fill out the steps.
Break your test repository into areas, assign each area to a tester in your team and make him/her responsible for all aspects of its maintenance.
Have peer test creating or review sessions.
Visit and validate “old” test cases & tests that have not run in the last 6 months.
Review tests that do not find any issues in the last year.
Create visibility and accountability into your test management system

A big factor that will help or hamper the way you maintain your test cases is how you manage and organize them.  You can obviously do this in your file system repository or using something like Dropbox to share these resources with your team.

But  after your tests grow in size or your team expands above a certain level it makes more sense to find a professional test management system that will help you to organize your test cases and generate good visibility and control over them.

I don’t want to make this a marketing post, but I do recommend you take a look at PractiTest and the way we provide excellent visibility into your test cases with the use of our exclusive Hierarchical Filtering system.

Other than creating visibility, make sure there is accountability for each area of your testing repository.  As I wrote above, it is important to assign testing areas and their cases to specific players in your team.

Give them tasks (and the time) to update and maintain their tests, both during the preparation stages but also during the regular testing process.  You should not expect people to maintain their test cases during the frenzy and craziness of your regular testing cycle.

Rebuilding Your Agile QA Strategy and Plan ?

Here are three problem patterns I’ll speak about:

We want to do Agile development but it keeps not going well
We want to do good QA with Agile but how do we do that well
The plans we have which map our sprints to a timeline keep not working
I’ll talk about some possible root causes to the above.

I’ll often ask what your goals are as an organization and how you are applying a QA strategy to ensure those goals.  Then I’ll ask how do you know its a good strategy?  A good conversation talks about measurement, evaluation, and action plans.

I’ll pose these scenarios when I am interviewing technical people.  The general landscape to a good answer is that a good QA strategy can answer the conceptual questions about who, what, and how you are testing your systems.  The way that you build a QA strategy, therefore, is to build a conceptual framework for how you think about QA strategy.  Any conceptual framework is better than none, and I will offer a framework here.

So, strategy and tactics are different at both the conceptual level and the level of applying them.

Conceptually, a strategy is an emergent accumulation of the answers to the following 5 questions:

Who are we?
What are our ultimate goals here?  (Note: Goals answer the question why, and are tightly coupled with who you are.  From this conversation you get to know your Values.)
What do we need to do to achieve those goals?
How will we do it? (This answer together with your Values form your Mission.)
What [people, procedures, technology, human] resources will we employ in doing it?
A QA strategy traces the big picture of the system under test into functional modules, test data, operational correctness, and interdependencies into priorities.  Remember: Strategy shows priorities.  A QA strategy:

combines values and mission
to produce a workable plan that
can be used as a measuring stick to
see how you are doing at any point along the way in order to
feed expected value decisions that balance [cost, risk, and reward]
Your QA strategy should identify the anatomy of your system under test, the users, user personas perhaps, user roles probably, how users interact with the system, how the system processes input to produce output, timing diagrams, physical architecture decisions, and recommendations on end to end testing as well as module specific testing.  A strategy must be a living document, so keep it short, use pictures whenever possible, and avoid acronyms and technical identifiers.

A QA Plan sequences the resources and actions needed to accomplish the Mission.  Remember: Plans show sequencing.  A QA Plan:

Is produced by a strategic expected value decisions which
Contain measurable, workable, deliverable, verifiable goals which are
Broken down by the roles needed to accomplish them and
Assigned to responsible people in those roles who can own the goal
Your QA plan should show who is doing what work and when they’ll probably be done.  Your plan shows dependencies and provides solutions for them.  Your plan is tied to a staffing plan and why you need the people you need, and possible plays around uncertainties.

The art of good QA management is practicing the above, noting your failures and determining what was missing, fixing it, and doing it again.  Good luck!

What’s your testing approach?

Approach you should follow :

Too often we complain about our daily routine. We wake up most everyday of the week and go through the same motions and home and at work. Our mood might change, so we approach our daily tasks differently perhaps, but the routine remains the same. However, this is not a bad thing!

You don’t realize how great routine can be until it is gone or taken away, and I don’t mean because you’ve gone on vacation. We are creatures of habit, and rightly so. Routine gives us structure and makes us feel safe, confident and is comforting. The same applies to our work practices and the routine approaches we use on the job.

This got me thinking about our different testing approaches as testers, and how they dictate the routine of our work. While we probably vary in our approaches, we all have the same professional goal – to do the best job possible, “leave no bug unturned”. So what is your testing approach?

For instance, when you get a new feature you :
1. Go over the documentation for it
2. Run a short exploratory testing session to get to know it first hand
3. Create some high level or low level testing scenarios for it
4. Run your scenarios while taking notes on how to improve them
5. Run a short session with your team to give your feedback on the feature, its stability and some functional improvement ideas

What makes a website fast ?

Point by which you can control the speed on loading time of a website:-

1. Tell dev team to Consider implementing a content delivery network (CDN). A CDN takes a website’s static files – such as CSS, images and JavaScript – and delivers them on servers that are close to the user’s physical location. Because servers are closer to the user, they load more quickly. Larger websites implement CDNs to make sure their visitors from around the world have as fast an experience as possible.
2. Tell UI team to Implement new image formats to reduce the size of your images. According to the HTTP Archive, 61 percent of a website’s page weight on a desktop computer is images. Switching between different-sized and different-quality images to save bandwidth using tools like Picture fill and Adaptive Images can help. Adopting new image formats, such as WebP and JPeg XR, can also help reduce image weight by 20 to 50 percent without sacrificing quality.
3. Cache, cache, cache. Browser caching stores cached versions of static resources, a process that quickens page speed tremendously and reduces server lag. When a user visits a page on your website, the cached version will usually be served unless it has changed since it was last cached; this saves a lot of requests to your server and as a result makes it faster.
4. Evaluate your plugins. Plugins can bring new functionality and features to your website, but the more plugins your website has, the more work it has to do to load. Poor or outdated plugins can slow down website performance dramatically as well. This can be easily fixed by evaluating your current plugins and removing those that duplicate functionality, are out of date or are no longer used.
5. Tell dev team to combine images into CSS sprites. If you have many images on your page, you are forcing multiple round trips of the server to get all the resources secured, which slows down page speed. Sprites combine all background images on a page into one single image. The proper image segment will be displayed because of the CSS background-image and background-position properties.
6. Tell team to enable HTTP keep-alive response headers. HTTP requests are simple: they grab and send a single file and then close. That may be simple, but it isn’t very fast. Keep-alive allows the web browser and server to agree to use the same connection to grab and send multiple files. In other words, the server holds the connection open while a user is on the site instead of opening a new connection with every request, easing the load for the processor, network and memory.
7. Enable compression. You can compress resources to lower the number of bytes a page is sending over a network. Using the GZIP compression algorithm, popular web servers like Apache and IIS do this automatically on HTML, CSS and Javascript. You will need to optimize your content for compression by creating consistency across your HTML and CSS code.
8. Tell team to use expires headers. When a user visits your website, your website files will be stored on their computer so that your website loads faster for them the next time the visit; there’s an expiration date in the file header that determines how long these files will be stored on their computer, however. This expires header is usually set to 24 hours by default. You can configure the expires header so that the files never time out, or you can increase the expiration date significantly so that it doesn’t impact your server and page load time.
9. Tell team to minify JavaScript and CSS. By removing unnecessary line breaks, extra space, and so on, you will speed up parsing, downloading and executing. This simple task can cut bytes of data from your page, and every little bit counts.
10. Review your hosting provider and package. If you’ve taken the steps above and your pages are still loading too slowly, it might be time to consider a new hosting package. On a typical shared hosting account, you might be sharing server space with dozens of other companies, and the speed of your website is affected by the number of people using that server. If shared hosting no longer meets your needs, it might be time to consider dedicated hosting, where you alone have access to the server, or a VPS (Virtual Private Server), a physical computer partitioned into multiple servers each running its own operating system. 
11.                                                           

Software Test Execution points to be noted ?

Lesson 1: Software Test Execution

•  Test Execution
•  Test Case Grouping
•  Test Bed Set-up
•  Decision to stop software testing
•  Software Testing Result Recording
•  Test Result Content

Lesson 2: Defects in Software

•  Defects in software
•  Defect classification
•  Sample template for defect report
•  Defect Tracking
•  Defect Life Cycle
•  Defect Resolution
•  Defect retesting

Lesson 3: Defect Analysis & Prevention

•  Defect Analysis
•  Defect Causal Analysis
•  Defect Prevention

Lesson 4: Software Testing Metrics

•  Meaning of the software testing metrics
•  Metrics classification
•  Metrics identification
•  Metrics preparation
•  Key testing metrics

Levels of Software Testing

 Various levels of Software Testing

 Unit Testing

 Integration Testing

 System Testing

 User acceptance Testing

Best online browser for testing

Best Tools to check online browser testing :-

- Ghost Lab - http://vanamco.com/ghostlab/
- Browser Stack - http://www.browserstack.com/ - Best
- Sauce Labs - https://saucelabs.com/home
- Cross Browser testing - http://crossbrowsertesting.com/
- Browser shots - http://browsershots.org/
- Browser ling - https://browserling.com/
- Litmus - http://litmus.com/page-tests
- Testing Bot - http://testingbot.com/

Difference between Mobile Website app and an App, which is better and what are the advantages of both.

Difference Between a Mobile Website app and an App?

Before you can evaluate the benefits of a mobile website vs. an app it’s important to understand the key differences between the two. Both apps and mobile websites are accessed on a handheld devices such as smartphones (e.g. iPhone, Android and Blackberry) and tablets.

A mobile website is similar to any other website in that it consists of browser-based HTML pages that are linked together and accessed over the Internet (for mobile typically WiFi or 3G or 4G networks). The obvious characteristic that distinguishes a mobile website from a standard website is the fact that it is designed for the smaller handheld display and touch-screen interface.

Like any website, mobile websites can display text content, data, images and video. They can also access mobile-specific features such as click-to-call (to dial a phone number) or location-based mapping.

Apps are actual applications that are downloaded and installed on your mobile device, rather than being rendered within a browser. Users visit device-specific portals such as  Apple’s App Store, Android Market, or Blackberry App World in order to find and download apps for a given operating system. The app may pull content and data from the Internet, in similar fashion to a website, or it may download the content so that it can be accessed without an Internet connection.

Which is Better – an App or a Mobile Website?

When it comes to deciding whether to build a native app or a mobile website, the most appropriate choice really depends on your end goals. If you are developing an interactive game an app is probably going to be your best option. But if your goal is to offer mobile-friendly content to the widest possible audience then a mobile website is probably the way to go. In some cases you may decide you need both a mobile website and a mobile app, but it’s pretty safe to say that it rarely makes sense to build an app without already having a mobile website in place.

Generally speaking, a mobile website should be considered your first step in developing a mobile web presence, whereas an app is useful for developing an application for a very specific purpose that cannot be effectively accomplished via a web browser.

Advantages of a Mobile Website vs. Native Apps

If your goals are primarily related to marketing or public communications, a mobile website is almost always going to make sense as a practical first step in your mobile outreach strategy. This is because a mobile website has a number of inherent advantages over apps, including broader accessibility, compatibility and cost-effectiveness.

 What do native apps do better than Web apps? How long will this remain the case?
When we asked publishers that offer both application interfaces to compare the two, twice as many publishers saw higher user adoption, usage volume and user engagement (i.e. duration of usage per session) over native apps. In particular 30 percent of these publishers actually saw over 100 percent higher usage volume and engagement on native apps as compared to Web apps. Our study also found that native apps deliver a higher click-through rate (CTR) among the ad-serving publishers, although experiences can vary by company and content category.
While we do expect native apps to maintain their lead in user adoption and engagement in the near future, it is important to recognize the large variances in publishers’ experiences and, in many cases, the difference in adoption is driven by the gap in user friendliness between the same company’s native and Web app interfaces. Many developers argue that the relatively poor user experience offered by currently available Web apps are due to a lack of access to native device features such as GPS, camera, calendar and accelerometer, but that is soon to change.

QTP interview Questions and Answers

Q. What are the features and benefits of Quick Test Pro(QTP)?

1. Key word driven testing
2. Suitable for both client server and web based application
3. VB script as the script language
4. Better error handling mechanism
5. Excellent data driven testing features

Q. How to handle the exceptions using recovery scenario manager in QTP?

You can instruct QTP to recover unexpected events or errors that occurred in your testing environment during test run. Recovery scenario manager provides a wizard that guides you through the defining recovery scenario. Recovery scenario has three steps
1. Triggered Events
2. Recovery steps
3. Post Recovery Test-Run

Q. What is the use of Text output value in QTP?

Output values enable to view the values that the application talks during run time. When parameterized, the values change for each iteration. Thus by creating output values, we can capture the values that the application takes for each run and output them to the data table.

Q. How to use the Object spy in QTP 8.0 version?

There are two ways to Spy the objects in QTP
1) Thru file toolbar: In the File ToolBar click on the last toolbar button (an icon showing a person with hat).
2) Thru Object repository Dialog: In Objectrepository dialog click on the button “object spy…” In the Object spy Dialog click on the button showing hand symbol. The pointer now changes in to a hand symbol and we have to point out the object to spy the state of the object. If at all the object is not visible or window is minimized then hold the Ctrl button and activate the required window to and release the Ctrl button.

Q. What is the file extension of the code file and object repository file in QTP? 
File extension of
Per test object rep: filename.mtr
Shared Object rep: filename.tsr
Code file extension id: script.mts

Q. Explain the concept of object repository and how QTP recognizes objects?

Object Repository: displays a tree of all objects in the current component or in the current action or entire test( depending on the object repository mode you selected).
we can view or modify the test object description of any test object in the repository or to add new objects to the repository.
Quicktest learns the default property values and determines in which test object class it fits. If it is not enough it adds assistive properties, one by one to the description until it has compiled the unique description. If no assistive properties are available, then it adds a special Ordianl identifier such as objects location on the page or in the source code.

Q. What are the properties you would use for identifying a browser and page when using descriptive programming?

“name” would be another property apart from “title” that we can use. OR
We can also use the property “micClass”.
ex: Browser(“micClass:=browser”).page(“micClass:=page”)

Q. What are the different scripting languages you could use when working with QTP?

You can write scripts using following languages:
Visual Basic (VB), XML, JavaScript, Java, HTML

Q. Tell some commonly used Excel VBA functions.

Common functions are:
Coloring the cell, Auto fit cell, setting navigation from link in one cell to other saving

Q. Explain the keyword createobject with an example.

Creates and returns a reference to an Automation object
syntax: CreateObject(servername.typename [, location])
Arguments
servername:Required. The name of the application providing the object.
typename : Required. The type or class of the object to create.
location : Optional. The name of the network server where the object is to be created.

Q. Explain in brief about the QTP Automation Object Model.

Essentially all configuration and run functionality provided via the QuickTest interface is in some way represented in the QuickTest automation object model via objects, methods, and properties. Although a one-on-one comparison cannot always be made, most dialog boxes in QuickTest have a corresponding automation object, most options in dialog boxes can be set and/or retrieved using the corresponding object property, and most menu commands and other operations have corresponding automation methods. You can use the objects, methods, and properties exposed by the QuickTest automation object model, along with standard programming elements such as loops and conditional statements to design your program.

Q. How to handle dynamic objects in QTP?

QTP has a unique feature called Smart Object Identification/recognition. QTP generally identifies an object by matching its test object and run time object properties. QTP may fail to recognize the dynamic objects whose properties change during run time. Hence it has an option of enabling Smart Identification, wherein it can identify the objects even if their properties changes during run time.
Check out this: 
If QuickTest is unable to find any object that matches the recorded object description, or if it finds more than one object that fits the description, then QuickTest ignores the recorded description, and uses the Smart Identification mechanism to try to identify the object.
While the Smart Identification mechanism is more complex, it is more flexible, and thus, if configured logically, a Smart Identification definition can probably help QuickTest identify an object, if it is present, even when the recorded description fails.

The Smart Identification mechanism uses two types of properties: 
Base filter properties – The most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link’s tag was changed from to any other value, you could no longer call it the same object. Optional filter properties – Other properties that can help identify objects of a particular class as they are unlikely to change on a regular basis, but which can be ignored if they are no longer applicable.

Q. What is a Run-Time Data Table? Where can I find and view this table?

In QTP, there is data table used, which is used at runtime.
-In QTP, select the option View->Data table.
-This is basically an excel file, which is stored in the folder of the test created, its name is Default.xls by default.

Q. Where can we use a Function or an Action?

It all depends on the scenario.

If we want to use the OR feature then we 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.

Q. What is the difference between an Action and a Function?

Action is a activity 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.

Q. What are the various events available in the Recovery Scenario Manager?

1) Application Crash: This event is useful in handling crashed applications at runtime.

2) Pop Up Window: This event is useful in managing various unwanted application windows,
which get built-up at runtime.

3) Test Run Error: This event is useful in handling VBScript statement errors at runtime.

4) Object State: This event is useful in handling object related errors at runtime.

Q. What are the Elements of Recovery Scenario?

Steps to handle the exceptions are

1) Trigger Event: Is an unexpected event like appearance of a Pop-up window, object
state, test run error causing application crash or interruption in our running session.

2) Recovery Steps: Constitutes a series of steps required to be performed to enable QTP
to proceed further with the process of test after some trigger event has interrupted the run
session. Examples of a recovery operation can be 1) A keyboard or mouse Operation like a
Click over the “OK” button in the Pop-up window 2) Close Application Process 3) Function
Call 4) Restarting the OS etc.

3) Post-Recovery Test Run: Are a set of instructions designed to be provided to QTP on
proceeding further with the test after some recovery operation has been carried out.
Examples of Post Recovery actions can be repeating the complete test from the beginning or
some steps may be skipped altogether & continuing with the remaining steps in the test.

Q. When to use a Recovery Scenario and When to use “on error resume next”?

Recovery scenarios are useful when it is difficult to predict at which step the errors can
come or when we are confident that the error will not come in the QTP script, whereas it can
be anywhere outside the QTP Script.

For illustration; Pop-up message of “out of paper”, as caused by the printer device driver.
“On error resume next” is preferred when we are sure that the error is expected one and
wish to perform some other actions.

Q. What are the key features of QTP at a glance

Ease of Use: QTP allows even novice testers to become productive in minutes. We can
create a test script by simply pressing a Record button and using an application to perform
a typical business process. Each step in the business process is automated documented with
a plain-English sentence and screen shot. Users can easily modify, remove, or rearrange
test steps in the Keyword View.

# Simple Interface: QTP is much simpler to understand. It presents a test case as a
simple business workflow to the tester.

# Simple Language: QTP uses Microsoft’s VBScript for its test procedures, and to
manipulate the objects and controls of the application under test. VBScript is a real
programming language where several existing functions & resources are easily available for
implementation these days.

# Use of Zero-Configuration Technology: QTP uses next-generation “zero-configuration”
Keyword Driven testing technology. This helps in faster test creation, easier maintenance,
and provides more powerful data-driving capability.

# Automatic Insertion of Checkpoints: QTP enables thorough validation of applications
through a full complement of checkpoints. QTP can automatically introduce checkpoints to
verify application properties and functionality, for example to validate output or check link
validity.

# Marvelous Interface with Data-tables: QTP allows entry of test data into the Data
Table, an integrated spreadsheet with the full functionality of Excel, to manipulate data sets
and create multiple test iterations, without programming, to expand test case coverage.
Data can be typed in or imported from databases, spreadsheets, or text files. QTP has
better and easier to use Data table integration compared to WinRunner.

# Better Object Identification Mechanism: QTP Identifies objects with Unique Smart
Object Recognition, even if objects change from build to build, thereby enabling reliable
unattended script execution.

# Support of Variety of Environment: QTP supports functional testing of all popular
environments, like Windows, Web, .Net, Visual Basic, ActiveX, Java, SAP, Siebel, Oracle,
PeopleSoft, terminal emulators, and Web services.

# Easy Adaptability of Microsoft Object Models: QTP can easily create and implement
Microsoft Object Model like: Outlook objects, ADO objects, FileSystem objects, supports
DOM, WSH, etc.

# Auto-Documentation Technology: QTP renders test documentation and test creation
to a single step with the help of its auto-documentation technology

Q. What are various types of properties when using Object Identification in
QTP?

QTP uses three types of properties when identifying an object

1. Mandatory Properties: Always learn these properties for the object

2. Assistive Properties: Learn in case Mandatory properties are not enough to identify the
object uniquely

3. Ordinal Identifiers: Learn in case both mandatory and assistive properties are not able
to recognize the objects correctly

Q. What are the various ways to insert a Action in a test in QTP?

There are three ways to insert an Action in a test

1. Insert Call to New…

2. Insert Call to Copy…

3. Insert Call to Existing…

Q. 29: What is the use of Parameterization in QTP?

Parameterization is helpful in aspects like:

# Parameterization allows us to pick different values at run time.

# Reduces Time and Effort.

# Usage of data drivers allows us to use the same data for various input boxes.

# Parameterization can also be done for checkpoints.

Q. What are Data Tables in QTP?

Data Table is MS Excel like spreadsheet which can be used for parameterizing a test case

DataTable are of two types like:

1. Global Data Table: Is a Data table for Test flow

2. Local Data Table: Is a Data table for every action

Q. What are the Environment Variables?

Environment variables are global variables available to all Actions

# They can be used to run a test case on different environment

# To add a new Environment variable go to Test -> Settings…->Environment (Tab)

# Environment variables are of two types like:

1. Built in Environment Variables: These provide information about the system and the
current test

2. User-Defined Environment Variables: These are added in the Environment tab of Test
Settings. These are Read-only during the test run

Q. How many types of Parameters are there in QTP?

There are two types of parameters like:

1) Test parameters:
# These can be set in Test->Settings…->Parameters (Tab)
# Test parameters value can be provided when replaying the test
# Test arguments can be accessed in the test using TestArgs(“”)

2) Action parameters :
# Used to pass parameters to Action
# Output parameters can only be used when Action is being called for a single iteration
# Ex – RunAction “Login”, oneIteration, “TestUser”, “TestPass”, out

# A parameter can be accessed using Parameter(“ParamName”)

Q. What is Descriptive Programming?

Descriptive Programming is an alternate way of writing test cases without having objects in
object repository

Descriptive programming can be done in two ways

1. Using Object Description
2. Using String Description

In Descriptive Programming objects are identified by describing all the identification
properties

Q. After creating the test, what is the purpose of running them?

1) To Check the Application: The test starts running from the first line in our test and
stops at the end of the test. While running, QTP connects to our application and performs
each operation in our test, including any checkpoints, such as checking any text strings,
objects, tables, and so forth. If we had parameterized our test with Data Table parameters,
QTP repeats the test (or specific actions in your test) for each set of data values we had
defined.

2) To Debug the Application: We can control our run session to help us identify and
eliminate defects in our test. We can use the Step Into, Step Over, and Step Out commands
to run our test step by step. We can begin our run session from a specific step in our test,
or run the test until a specific step is reached. We can also set breakpoints to pause our test
at predetermined points. We can view the value of variables in our test each time it stops at
a breakpoint in the Debug Viewer.

3) To Update the Application: We can run our test using Update Run Mode to update the
property sets used for test object descriptions, the expected checkpoint values, the data
available to retrieve in output values, and the Active Screen images and values.

We can run our test using Maintenance Run Mode when we know that our application has
changed, and we therefore expect that QTP will not be able to identify the objects in our
test. When we run tests in Maintenance Run Mode, a wizard opens for steps that fail
because an object could not be found in the application. The wizard then guides us through
the steps of resolving the issue, and, after we resolve the issue, the run continues.

Q. What are the main stages of Testing with QTP?

Testing with QTP involves main stages like:

Planning
Creating Tests
Running Tests
Analysing Results

Q. How can we do the Analysis of Results in QTP?

After we run our test, we can view the results.

# View the results in the Test Results window: After we run our test, we can view the
results of the run in the Test Results window. We can view a summary of our results as well
as a detailed report. If we had captured still images or movies of our application during the
run, we can view these from the Test Results window.
Report defects detected during a run session: If we have access to Quality Center, the HP
centralized quality solution, we can report the defects we discover to the project database.

We can instruct QTP to automatically report each failed step in our test, or we can report
them manually from the Test Results window.

Q. What is Business Process Testing?

Business Process Testing is a role-based testing model that enables Subject Matter
Experts—who understand the various parts of the application being tested—to create
business process tests in Quality Center. Automation Engineers—who are experts in QTP
and automated testing—use QTP to define all of the resources and settings required to
create business process tests.

# Business Process Testing uses a keyword-driven methodology for testing, based on the
creation and implementation of business components and business process tests. A business
component is an easily-maintained, reusable unit comprising one or more steps that
perform a specific task within an application.

Q. What is the role of Keyword View in QTP?

The Keyword View enables us to create and view the steps of our test in a keyword-driven,
modular, table format. The Keyword View is comprised of a table-like view, in which each
step is a separate row in the table, and each column represents different parts of the steps.
We can modify the columns displayed to suit our requirements.

We create and modify tests by selecting items and operations in the Keyword View and
entering information as required. Each step is automatically documented as we complete it,
enabling us to view a description of our test steps in understandable English.

Each operation performed on our application during a recording session is recorded as a row
in the Keyword View.

Q. What is the role of Expert View in QTP?

In the Expert View, QTP displays each operation performed on our application in the form of
a script, comprised of VBScript statements. The Expert View is a script editor with many
script editing capabilities. For each object and method in an Expert View statement, a
corresponding row exists in the Keyword View.

Q. What are the various utilities and tools available in QTP?

Tools Menu contains the following utilities and tools which are helpful in the testing process:

Action Conversion Tool: Enables us to convert test actions that were created using QTP
to scripted components for use in business process testing.

Additional Installation Requirements: Opens the Additional Installation Requirements
dialog box, which displays any prerequisite software that we must install or configure to
work with QTP.

Business Component Upgrade Tool: Opens the Business Component Upgrade Tool. If
we are connected to a Quality Center project, this tool enables us to upgrade all of the
business components in a Quality Center project, from an earlier component version to the
format required by the current version.

HP Micro Player: Opens the HP Micro Player, which enables us to view captured movies
of a run session without opening QuickTest.

License Validation Utility: Opens the License Validation utility, which enables us to
retrieve and validate license information.

Password Encoder: Opens the Password Encoder dialog box, which enables us to
encode passwords. We can use the resulting strings as method arguments or Data Table
parameter values (tests only).

QTP Script Editor: Opens the QTP Script Editor, which enables us to open and modify
the scripts of multiple tests and function libraries, simultaneously.

Register New Browser Control: Opens the Register Browser Control Utility, which
enables us to register our browser control application so that QTP recognizes our Web object
when recording or running tests.

Remote Agent: Activates the QuickTest Remote Agent, which enables us to configure
how QTP behaves when a test is run by a remote application such as Quality Center.

Save and Restore Settings: Opens the Save and Restore Settings dialog box, which
enables us to save our existing configurations before uninstalling an old version, and then
restore them after installing a new version.

Silent Test Runner: Opens the Silent Test Runner dialog box, which enables us to run a
QTP test the way it is run from LoadRunner and Business Availability Center.

Test Batch Runner: Opens the Test Batch Runner dialog box, which enables us to set up
QTP to run several tests in succession.

Test Results Deletion Tool: Opens the Test Results Deletion Tool dialog box, which
enables us to delete unwanted or obsolete results from our system according to specific
criteria that you define.

Q. What is the concept of Test Object Model in QTP?

QTP tests our dynamically changing application by learning and identifying test objects and
their expected properties and values. To do this, QTP analyzes each object in our application
in much the same way that a person would look at a photograph and remember its details.

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 class has a list of properties that can uniquely
identify objects of that class and a set of relevant methods that QuickTest can learn about
it.

A test object is an object that QTP creates in the test to represent the actual object in your
application. QTP stores information on the object that will help it identify and check the
object during the run session.

A run-time object is the actual object in our application on which methods are performed
during the run session.

Q. Please explain some real world scenario explaining Object Learning process
of QTP?

QTP learns objects just as we would. For example, suppose as part of an experiment, Bob is
told that he will be shown a photograph of a picnic scene for a few seconds during which
someone will point out one item in the picture. Bob is told that he will be expected to
identify that item again in identical or similar pictures one week from today.

Before he is shown the photograph, Bob begins preparing himself for the test by thinking
about which characteristics he wants to learn about the item that the tester indicates.
Obviously, he will automatically note whether it is a person, inanimate object, animal, or
plant. Then, if it is a person, he will try to commit to memory the gender, skin color, and
age. If it is an animal, he will try to remember the type of animal, its color, and so forth.

The tester shows the scene to Bob and points out one of three children sitting on a picnic
blanket. Bob notes that it is a Caucasian girl about 8 years old. In looking at the rest of the
picture, however, he realizes that one of the other children in the picture could also fit that
description. In addition to learning his planned list of characteristics, he also notes that the
girl he is supposed to identify has long, brown hair.

Now that only one person in the picture fits the characteristics he learned, he is fairly sure
that he will be able to identify the girl again, even if the scene the tester shows him next
week is slightly different.

Since he still has a few moments left to look at the picture, he attempts to notice other,
more subtle differences between the child he is supposed to remember and the others in the
picture—just in case.

If the two similar children in the picture appeared to be identical twins, Bob might also take
note of some less permanent feature of the child, such as the child’s position on the picnic
blanket. That would enable him to identify the child if he were shown another picture in
which the children were sitting on the blanket in the same order.

Q. What is the method used by QTP to learn objects?

QTP “looks” at the object being learned and stores it as a test object, determining in which
test object class it fits. In the same way, Bob immediately checked whether the item was a
person, animal, plant, or inanimate object. QTP might classify the test object as a standard
Windows dialog box, a Web button, or a Visual Basic scroll bar object, for example.

Then, for each test object class, QTP has a list of mandatory properties that it always
learns; similar to the list of characteristics that Bob planned to learn before seeing the
picture. When QTP learns an object, it always learns these default property values, and then
“looks” at the rest of the objects on the page, dialog box, or other parent object to check
whether this description is enough to uniquely identify the object. If it is not, QTP adds
assistive properties, one by one, to the description, until it has compiled a unique
description; similar to when Bob added the hair length and color characteristics to his list. If
no assistive properties are available, or if those available are not sufficient to create a
unique description, QTP adds a special ordinal identifier, such as the object’s location on the
page or in the source code, to create a unique description.

Q. What is Test Object Method in QTP?

It is a method that QTP recognizes as applicable to a particular test object. For example, the
Click method is applicable to a WebButton test object. As we add steps to our test, we
specify which method to perform on each test object. If we record steps, QTP records the
relevant method as it is performed on an object.

During a run session, QTP performs the specified test object method on the run-time object.
Run-time object methods are the methods of the object in our application as defined by the

object creator. We can access and perform run-time object methods using the Object
property.

Q. What are the Test Object Properties in QTP?

Test object properties are the properties whose values are captured from the objects in our
application when QTP learns the object. QTP uses the values of these properties to identify
run-time objects in our application during a run session.

Property values of objects in our application may change dynamically each time our
application opens, or based on certain conditions. We may need to modify the test object
property values to match the run-time object property values. We can modify test object
properties manually while designing our test, or use SetTOProperty statements during a run
session.

Q. How to decide on whether to save the objects in Local or Shared Object
Repositories?

Local object repository is easiest to use when we are creating simple tests, especially under
the following conditions:

We have only one, or very few, tests that correspond to a given application, interface, or
set of objects.

We do not expect to frequently modify object properties.

We generally create single-action tests.

Shared object repository is the preferred option when:

We are creating tests using keyword-driven methodologies & not by recording.

We have several tests that test elements of the same application, interface, or set of
objects.

We expect the object properties in our application to change from time to time and we
regularly need to update or modify object properties.

We often work with multi-action tests and regularly use the Insert Copy of Action and
Insert Call to Action options.

Q. What are the possibilities of Exporting the data among various Object
Repositories?

When QTP learns a test object, it adds it to the local object repository & not to the shared
object repository — unless the same test object already exists in an associated shared
object repository. In this case, QTP uses the existing information in the shared object
repository.

We can export objects from the local object repository to a shared object repository. We can
also export the local object repository and replace it with a shared object repository. This
enables us to make the local objects accessible to other actions.

We can also merge objects from the local object repository directly to a shared object
repository that is associated with the same action. This can help reduce maintenance since
we can maintain the objects in a single shared location, instead of multiple locations.

Q. What is the effect of restoring Default Properties for a Test Object in QTP?

When we restore the default properties, it restores the mandatory property set defined for
the selected object class in the Object Identification dialog box.

Any changes that we have made to the description property set for the test object will be
overwritten. However, if property values were defined for any of the mandatory properties
they are not modified.

Q. What is the use of Ordinal Identifiers in QTP?

An ordinal identifier assigns a numerical value to a test object that indicates its order or
location relative to other objects with an otherwise identical description for objects having
the same values for all properties.

This ordered value provides a backup mechanism that enables QTP to create a unique
description to recognize an object when the defined properties are not sufficient to do so.
We can specify the ordinal identifier for test objects in the local object repository using the
Object Repository window or Object Properties dialog box, and for test objects in the shared
object repository using the Object Repository Manager.